Konzipierung von Zahlungsabläufen für SCA

New regulation known as Strong Customer Authentication, or SCA, is changing online payments in Europe. See the impact it may have on your payment flows and learn how Stripe can help.


Last updated on September 14, 2019

Starting September 14, 2019 new payments regulation is being rolled out in Europe, which mandates Strong Customer Authentication (SCA) for many online payments in the European Economic Area (EEA). SCA is part of the second Payment Services Directive (PSD2).

To meet the new SCA requirements, a form of two-factor authentication is required for many online card payments in Europe. Without authentication, many payments may be declined by your customers’ banks. We designed new foundational payments APIs to help businesses handle this change and take full advantage of any SCA exemptions.

We recommend using this guide to understand how different types of payment flows have to change due to SCA, and to reference it as you redesign your payment flows.

How payments are changing

Traditional card payments usually involve two steps: authorization and capture. A payment is authorized when a customer’s bank or card issuer decides to approve a payment, and the payment is captured when the card is charged.

With SCA, there is an additional and mandatory step before authorization and capture: authentication. This step helps protect customers by preventing fraud. To authenticate a payment, a customer responds to a prompt from their bank and provides additional information. This may be something they know, like a password, something they use, like their phone, or something that’s part of who they are, like their fingerprint.

The most common way to authenticate a payment is a method called 3D Secure. You may recognize 3D Secure by its branded names, such as “Visa Secure” or “Mastercard Identity Check.” There’s a new version, called 3D Secure 2, that is expected to become the standard method to authenticate payments. You can learn about the differences between these methods in our 3D Secure 2 guide. Our new payments APIs, Stripe Billing, and the new version of Stripe Checkout, all support 3D Secure 2.

No matter what method you use, customers must be on-session to authenticate, which means they need to be using your website or app. Adding this step is be simpler for businesses that charge customers right away, and more complex for businesses that charge customers after they’ve left the checkout flow. (This is sometimes called off-session.)

The scenarios in this guide offer examples of how these three steps (authentication, authorization, and capture) can vary depending on how and when you charge your customers.

  1. Authentifizieren
    Ein Kunde authentifiziert eine Online-Zahlung.

    Ein Kunde reagiert auf eine 3D Secure-Eingabeaufforderung von der Bank und liefert zusätzliche Informationen, um die Zahlung zu authentifizieren. Siehe 3D Secure aus der Kundenperspektive.

    Die Authentifizierung ist erforderlich, wenn keine Ausnahme für eine Zahlung geltend gemacht werden kann bzw. wenn die Kundenbank die Anforderung einer Ausnahme ablehnt. Unsere Payment Intents API fordert automatisch alle zutreffenden Ausnahmen an, bevor der Authentifizierungsschritt hinzugefügt wird. Dies vereinfacht den Bezahlvorgang und beugt einem Einbruch der Konversionsrate vor.

    Hinweis: Die Authentifizierung muss durchgeführt werden, wenn Kunden sich noch in der Sitzung befinden bzw. wenn diese Ihre Website oder App verwenden. Daher erfolgt dieser Schritt für gewöhnlich, wenn Kunden das Zahlungsformular ausfüllen.

  2. Autorisieren
    Ihr Unternehmen bittet die Kundenbank, die Zahlung zu genehmigen.

    Die Kundenbank entscheidet, ob eine Zahlung genehmigt oder abgelehnt wird. Bei Genehmigung werden die Gelder gehalten und sieben Tage lang garantiert. Wenn eine Authentifizierungsanfrage abgelehnt wird, benötigt Ihr Unternehmen eine Möglichkeit, die Kunden zur Sitzung zurückzubringen, um die Zahlung erneut zu authentifizieren und einen neuen Autorisierungsversuch zu unternehmen.

    Hinweis: Eine Autorisierungsanfrage kann auch noch nach der Authentifizierung von der Kundenbank abgelehnt werden. Dies kann dann passieren, wenn unzureichende Gelder zur Verfügung stehen oder die Karte abgelaufen ist.

  3. Bis zu 7 Tage

    Der Zeitraum zwischen Autorisierung und Erfassung kann bis zu sieben Tage betragen. Viele Unternehmen erfassen eine Zahlung jedoch sofort nach der Autorisierung.

    Hinweis: Eine Kundenbank gibt eine Zahlung möglicherweise als „ausstehend“ an, wenn diese autorisiert, jedoch nicht erfasst wurde.

  4. Erfassen
    Das Unternehmen belastet die Kundenkarte und schließt die Zahlung ab.

Understanding exemptions

There are certain types of payments—such as low-risk transactions, fixed-amount subscriptions, phone sales, and merchant-initiated transactions—that may be exempt from SCA. Merchant-initiated transactions are payments made with a saved card when the customer is off-session. Common examples include a gym membership payment or utility bill. To qualify for this exemption, your business must have an agreement with your customer and have them authenticate their card when it’s being saved or authenticate the first payment. Our Strong Customer Authentication guide goes into greater detail about these exemptions and others.

Stripe’s SCA-ready payment APIs and products help businesses take full advantage of these opportunities by automatically requesting exemptions. When exemptions are accepted by your customers’ banks, your customers won’t have to authenticate, minimizing the impact on conversion.

However, businesses can’t rely on exemptions and must design their payment flows to authenticate customers when necessary. This is because the rules around exemptions depend on your customers’ banks. The banks evaluate each payment and decide whether an exemption applies—and individual banks will apply exemptions differently.


Um die Auswirkungen und Geltungsbereiche der SCA darzustellen, haben wir zusammengefasst, wie ein Authentifizierungsschritt in Zahlungsabläufe für verschiedene Geschäftsmodelle integriert werden kann.

Zurück zu den Leitfäden
You’re viewing our website for Estonia, but it looks like you’re in the United States. Switch to the United States site