Mit 3D Secure authentifizieren

Sie können die 3D Secure (3DS)-Authentifizierung auf mehreren Plattformen in Ihren Bezahlvorgang integrieren, einschließlich Web, iOS, Android und React Native. Diese Integration führt 3D Secure 2 (3DS2) aus, wenn sie von der Bank der Kundin/des Kunden unterstützt wird. Andernfalls wird 3D Secure 1 angewendet. Sie können die 3DS-Authentifizierung auch auf Stripe durchführen, während Sie die Transaktion bei einem anderen Zahlungsdienstleister (PSP) akquirieren, indem Sie das Produkt Standalone 3DS verwenden.

Web

iOS

Android

Die Kundin/der Kunde gibt die Kartenangaben ein.

Die Kundenbank bewertet die Transaktion und kann das 3D Secure-Verfahren in diesem Schritt abschließen.

Falls von der Bank gefordert, führt die Kundin/der Kunde einen zusätzlichen Authentifizierungsschritt durch.

3DS-Ablauf steuern

Stripe löst 3DS automatisch aus, wenn dies durch Vorschriften wie die starke Kundenauthentifizierung in Europa oder durch Branchenrichtlinien wie die Sicherheitsrichtlinien für Kreditkarten in Japan vorgeschrieben ist, wenn dies von einem Aussteller mit einem Soft Decline-Code angefordert wird oder wenn bestimmte Optimierungen von Stripe gelten.

Sie können auch Radar oder die API verwenden, um zu entscheiden, wann Nutzer/innen zur 3DS-Authentifizierung aufgefordert werden sollen. Auf diese Weise können Sie den Authentifizierungsvorgang für jede Nutzerin/jeden Nutzer basierend auf den von Ihnen gewählten Parametern anpassen. Allerdings unterstützen nicht alle Transaktionen 3DS, beispielsweise Wallets oder Off-Session-Zahlungen.

When a payment triggers 3DS, the card issuer might require the customer to authenticate to complete the payment, as long as 3DS authentication is supported for that card. While Stripe initiates the authentication request, the requirement comes from the issuer. Depending on the front end you’re using, this might require you to display the 3DS flow.

Bei einem typischen Payment Intent API-Ablauf, der 3DS auslöst:

1. Die Nutzerin/der Nutzer gibt die Zahlungsinformationen ein, wodurch ein PaymentIntent oder ein SetupIntent bestätigt wird, oder fügt einer Kundin/einem Kunden eine PaymentMethod hinzu.
2. Stripe prüft anhand von behördlichen Vorschriften, Radar-Regeln, manuellen API-Anfragen, vorübergehenden Ablehnungen (Soft Declines) des Ausstellers und anderen Kriterien, ob die Transaktion 3DS unterstützt und verlangt.
3. Wenn 3DS:
   • Nicht erforderlich: Aufgrund einer Befreiung versucht Stripe beispielsweise, die Zahlung durchzuführen. Der PaymentIntent wechselt in den Status processing. Wenn der Aussteller dies mit einem Soft Decline verlangt, versuchen wir es automatisch erneut und fahren bei Bedarf fort.
   • Nicht unterstützt: Der PaymentIntent geht in den Status requires_payment_method über. Je nachdem, aus welchem Grund 3DS ausgelöst wurde, kann es zulässig sein, mit dem Autorisierungsschritt der Zahlung fortzufahren. In diesem Fall geht der PaymentIntent in den Status processing über.
   • Required: Stripe starts the 3DS authentication flow by contacting the card issuer’s 3DS Access Control Server (ACS) and starting the 3DS flow.
4. Wenn 3DS-Ablaufinformationen vom Aussteller empfangen werden, reicht Stripe die Anfrage an den Aussteller ein, um den/die Karteninhaber/in zu authentifizieren. Der PaymentIntent geht in den Status requires_action über:
   • Nachfolgend erfahren Sie, wie die erforderliche 3DS-Aktion angezeigt wird. Aussteller können verschiedene Arten von 3DS-Ablaufaktionen anfordern, die möglicherweise nicht immer zur Anzeige eines abfragebasierten 3DS-Ablaufs führen (z. B. ein reibungsloser Ablauf).
   • Wenn der Aussteller 3DS überhaupt nicht unterstützt oder ein Ausfall auftritt, kann Stripe versuchen, die Zahlung ohne Authentifizierung abzuschließen, sofern dies zulässig ist.
   • Die Daten für 3DS-Authentifizierungsanfragen werden in der Regel von Kundinnen/Kunden zum Zeitpunkt der Transaktion bereitgestellt. Um Komplikationen und die Möglichkeit einer fehlgeschlagenen Authentifizierung zu verringern, können wir diese Anfragen mit Daten vervollständigen, die wir aus anderen Quellen ableiten, zum Beispiel Daten, die während des Zahlungsvorgangs von Ihrem Kunden/Ihrer Kundin erfasst wurden, Aufzeichnungen zu früheren Transaktionen, die Ihr Kunde/Ihre Kundin mit Ihnen getätigt hat, oder relevante Informationen, die über die Karte des Kunden/der Kundin oder die Aussteller/innen verfügbar sind.
   • Wenn Stripe bereits Zugriff auf alle erforderlichen 3DS-Datenelemente hat, versucht unser optimierter 3DS-Server möglicherweise, die Authentifizierungsanfrage für Sie abzuschließen, während er den PaymentIntent bestätigt. Dies kann dazu führen, dass der PaymentIntent direkt in den Status processing wechselt, wenn der 3DS-Ablauf erfolgreich ist, oder in den Status requires_action, wenn zusätzliche Schritte oder Datenelemente erforderlich sind, um den 3DS-Ablauf abzuschließen.
5. Je nach Ergebnis der 3DS-Authentifizierung:
   • Authentifiziert: Stripe versucht, die Zahlung durchzuführen, und der PaymentIntent geht in den Status processing über.
   • Fehlgeschlagen: Der PaymentIntent geht in den Status requires_payment_method über. Dies gibt an, dass Sie es mit einer anderen Zahlungsmethode versuchen müssen oder 3DS durch erneute Bestätigung erneut versucht werden kann.
   • Andere Szenarien: Je nach dem Grund, aus dem 3DS für die Zahlung ausgelöst wurde, kann es in Grenzfällen zulässig sein, die Autorisierung für die Zahlung fortzusetzen. Beispielsweise führt das Ergebnis attempt_acknowledged zu einer Zahlung und der PaymentIntent wechselt in den Status processing.
     • Eine Ausnahme bildet die Erstellung von indischen E-Mandaten für wiederkehrende Zahlungen. Alle anderen Ergebnisse außer einem authenticated Ergebnis werden als Fehlschlag behandelt.
6. Der PaymentIntent wechselt je nach Zahlungsergebnis zu einem der folgenden Status: succeeded, requires_capture oder requires_payment_method.

Um nachzuverfolgen, ob bei einer Kartenzahlung das 3DS-Verfahren unterstützt und versucht wurde, lesen Sie die Eigenschaft three_d_secure der Karteninformationen in den payment_method_details der Zahlung. Stripe füllt die Eigenschaft three_d_secure aus, wenn die Kundin/der Kunde versucht, die Karte zu authentifizieren. three_d_secure.result gibt das Ergebnis der Authentifizierung an.

Radar-Regeln im Dashboard verwenden

Stripe bietet Betrugskontrollen, um 3DS dynamisch anzufordern, wenn ein PaymentIntent oder ein SetupIntent erstellt oder bestätigt wird. Sie können diese Regeln in Ihrem Dashboard konfigurieren.

Wenn Sie über Radar for Fraud Teams verfügen, können Sie nutzerdefinierte 3DS-Regeln hinzufügen.

3DS manuell über die API anfordern

Bei der Standardmethode zum Auslösen von 3DS handelt es sich um die Verwendung von Radar zur dynamischen Anforderung von 3D Secure basierend auf der Risikostufe und weiteren Anforderungen. Das manuelle Auslösen von 3DS ist nur für erfahrene Nutzer/innen vorgesehen, die Stripe mit ihrer eigenen Betrugs-Engine vernetzen.

Um 3DS manuell auszulösen, setzen Sie payment_method_options[card][request_three_d_secure] entsprechend dem, was Sie optimieren möchten, wenn Sie entweder eine PaymentIntent erstellen oder bestätigen oder SetupIntent oder beim Erstellen einer Checkout-Sitzung. Dieser Vorgang ist derselbe für einmalige Zahlungen oder beim Einrichten einer Zahlungsmethode für zukünftige Zahlungen. Wenn Sie diesen Parameter angeben, versucht Stripe, 3DS durchzuführen, und überschreibt alle Dynamic 3D Secure Radar-Regeln in der PaymentIntent-, SetupIntent- oder Checkout-Sitzung.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=1000 \
  -d currency=usd \
  -d "payment_method_options[card][request_three_d_secure]"=any

Wann Sie diesen Parameter angeben, richtet sich danach, wann Ihre Betrugs-Engine ein Risiko erkennt. Wenn Ihre Betrugs-Engine beispielsweise nur Kartendaten prüft, wissen Sie, ob Sie 3DS anfordern müssen, bevor Sie den PaymentIntent oder SetupIntent erstellen. Überprüft Ihre Betrugs-Engine sowohl Karten- als auch Transaktionsdaten, geben Sie den Parameter während der Bestätigung an, sobald Ihnen mehr Informationen vorliegen. Übergeben Sie dann den resultierenden PaymentIntent oder SetupIntent an Ihren Client, um den Vorgang abzuschließen.

Untersuchen Sie die Verwendung des Parameters request_three_d_secure für alle unterschiedlichen Fälle in der API-Dokumentation:

• PaymentIntent erstellen
• PaymentIntent bestätigen
• SetupIntent erstellen
• SetupIntent bestätigen
• Checkout-Sitzung erstellen

Legen Sie request_three_d_secure auf any fest, um 3DS manuell mit einer Präferenz für einen frictionless Ablauf anzufordern, um die Wahrscheinlichkeit zu erhöhen, dass die Authentifizierung ohne zusätzliche Kundeneingaben abgeschlossen wird.

Legen Sie request_three_d_secure auf challenge fest, um 3DS mit einer Präferenz für einen challenge-Ablauf anzufordern, bei dem die Kundin/der Kunde auf eine Aufforderung zur aktiven Authentifizierung reagieren muss.

Stripe kann Ihre Präferenz nicht garantieren, da der Aussteller den endgültigen Authentifizierungsablauf bestimmt. Sie können herausfinden, welches der letztendliche Authentifizierungsablauf war, indem Sie den authentication_flow für die Eigenschaft three_d_secure der Zahlung oder des SetupAttempt überprüfen. Um mehr über 3DS-Abläufe zu erfahren, lesen Sie unseren Leitfaden.

Die obligatorischen Authentifizierungsregeln von Stripe werden automatisch ausgeführt, unabhängig davon, ob Sie 3DS manuell anfordern oder nicht. Alle 3DS-Anfragen von Ihnen kommen zu den für die starke Kundenauthentifizierung erforderlichen Anfragen hinzu.

3DS-Ablauf anzeigen

next_action: {
    type: 'redirect_to_url',
    redirect_to_url: {
      url: 'https://hooks.stripe.com/...',
      return_url: 'https://mysite.com'
    }
}

var action = intent.next_action;
  if (action && action.type === 'redirect_to_url') {
    window.location = action.redirect_to_url.url;
  }

stripe.confirmCardPayment(
  '{{PAYMENT_INTENT_CLIENT_SECRET}}',
  {
    payment_method: {card: cardElement},
    return_url: 'https://example.com/return_url'
  },
  // Disable the default next action handling.
  {handleActions: false}
).then(function(result) {
  // Handle result.error or result.paymentIntent
  // More details in Step 2.
});

curl https://api.stripe.com/v1/payment_intents/{{PAYMENT_INTENT_ID}}/confirm \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  --data-urlencode return_url="https://example.com/return_url"

var iframe = document.createElement('iframe');
  iframe.src = paymentIntent.next_action.redirect_to_url.url;
  iframe.width = 600;
  iframe.height = 400;
  yourContainer.appendChild(iframe);

window.top.postMessage('3DS-authentication-complete');

function on3DSComplete() {
    // Hide the 3DS UI
    yourContainer.remove();

    // Check the PaymentIntent
    stripe.retrievePaymentIntent('{{PAYMENT_INTENT_CLIENT_SECRET}}')
      .then(function(result) {
        if (result.error) {
          // PaymentIntent client secret was invalid
        } else {
          if (result.paymentIntent.status === 'succeeded') {
            // Show your customer that the payment has succeeded
          } else if (result.paymentIntent.status === 'requires_payment_method') {
            // Authentication failed, prompt the customer to enter another payment method
          }
        }
      });
  }

  window.addEventListener('message', function(ev) {
    if (ev.data === '3DS-authentication-complete') {
      on3DSComplete();
    }
  }, false);

3DS-Ablauf testen

Verwenden Sie eine Stripe-Testkarte mit einer beliebigen CVC/Prüfnummer und Postleitzahl und einem beliebigen zukünftigen Ablaufdatum, um abfragebasierte 3DS-Authentifizierungsabläufe auszulösen, während Sie sich in einer Sandbox befinden.

Wenn Sie eine Integration mit Ihren Test-API-Schlüsseln erstellen, wird beim Authentifizierungsvorgang eine Pseudo-Authentifizierungsseite angezeigt. Auf dieser Seite können Sie die Zahlung autorisieren oder stornieren. Bei der Autorisierung der Zahlung wird eine erfolgreiche Authentifizierung simuliert und Sie werden an die angegebene Rückgabe-URL weitergeleitet. Durch Klicken auf die Schaltfläche Fehlgeschlagen wird ein erfolgloser Authentifizierungsversuch simuliert.

Bei allen anderen Visa- und Mastercard-Testkarten ist keine Authentifizierung durch die Kartenaussteller der Kundinnen/Kunden erforderlich.

Sie können nutzerdefinierte Radar-Regeln in einer Testumgebung erstellen, um die Authentifizierung für Testkarten auszulösen. Erfahren Sie mehr über das Testen Ihrer Radar-Regeln.

Angefochtene Zahlungen und Haftungsverlagerung

The liability shift rule typically applies to payments successfully authenticated using 3DS. In some cases, liability shift applies with equivalent cryptograms, such as Apple Pay or Google Pay. If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer.

Wenn eine Karte 3DS nicht unterstützt oder während des Authentifizierungsvorgangs ein Fehler auftritt, wird die Zahlung normal ausgeführt. In diesem Fall geht die Haftung in der Regel nicht auf den Aussteller über, da keine erfolgreiche 3DS-Authentifizierung stattgefunden hat.

In der Praxis bedeutet dies, dass Sie üblicherweise keine als betrügerisch gekennzeichneten Zahlungsanfechtungen erhalten werden, wenn die Zahlung unter die Haftungsverlagerungsregel fällt. Sie erhalten jedoch möglicherweise dennoch eine frühzeitige Betrugswarnung. Es ist immer noch möglich, dass Sie einen geringen Prozentsatz von Zahlungsanfechtungen aufgrund von Betrug erhalten. Im Folgenden listen wir einige Fälle auf, in denen die Haftungsverlagerungsregel möglicherweise nicht gilt.

Möglicherweise erhalten Sie eine Anfrage zu einer angefochtenen Zahlung zu einer erfolgreich mit 3DS authenfizierten Zahlung. Diese Art von Zahlungsanfechtung führt nicht zu einer Rückbuchung, da es sich nur um eine Anfrage nach Informationen handelt.

Anfragen zu Abbuchungen, die mit 3D Secure authentifiziert werden, müssen Sie unbedingt beantworten. Wenn Sie nicht reagieren, kann die Karteninhaberbank eine Rückbuchung, auch „Rückbuchung ohne Antwort“ genannt, einleiten, was die Haftungsverlagerung zunichtemachen könnte. Um Rückbuchungen von 3DS-Abbuchungen ohne Antwort zu verhindern, sollten Sie unbedingt ausreichend Informationen zu der Zahlung übermitteln. Sie sollten angeben, was bestellt wurde, wie und an wen es geliefert wurde (ob es sich um physische oder elektronische Waren oder Dienstleistungen handelt).

Eine Haftungsverlagerung kann auch dann stattfinden, wenn das Kartennetzwerk 3DS verlangt, dies jedoch für die Karte oder den Aussteller nicht zur Verfügung steht. Dies kann vorkommen, wenn der 3DS-Anbieter des Ausstellers nicht verfügbar ist oder wenn der Aussteller 3DS nicht unterstützt, obwohl das Kartennetzwerk eine Unterstützung verlangt. Während des Zahlungsvorgangs wird der/die Karteninhaber/in nicht aufgefordert, die 3DS-Authentifizierung abzuschließen, da die Karte nicht registriert ist. Obwohl der/die Karteninhaber/in die 3DS-Authentifizierung nicht durchgeführt hat, kann die Haftung dennoch auf den Aussteller übergehen.

Stripe gibt den angeforderten Electronic Commerce Indicator (ECI) im electronic_commerce_indicator des Ergebnisses der 3DS-Authentifizierung zurück. Dieser Indikator kann dabei helfen, zu ermitteln, ob eine Zahlung der Haftungsverlagerungsregel entsprechen sollte. Da 3DS im Anschluss an die Antwort auf die anfängliche Zahlungsabsicht durchgeführt wird, erhalten Sie diese in der Regel von einem charge.succeeded-Ereignis, das an einen Ihrer konfigurierten Webhook-Endpoints oder andere Ereignisziele gesendet wird. Ein angeforderter ECI könnte in der Antwort des Ausstellers herabgestuft werden, was wir nicht bekannt geben.

It’s also possible for liability shift to get downgraded post-authorization, or the card network’s dispute rejection system might fail to catch liability shift for a transaction. In these cases, if you counter the dispute, Stripe automatically adds the requested ECI and the 3DS authentication outcome of the payment to your evidence details, but we recommend you also include additional details to increase your chance of winning the dispute.

Nutzerdefinierte Radar-Regeln für 3DS und Haftungsverlagerung

Wenn Sie Radar for Fraud Teams nutzen, können Sie Ihre Regeln anpassen. So steuern Sie, wann 3DS angefordert werden soll und wie jede spezifische Authentifizierung und Haftungsverlagerung behandelt werden soll. Die Regeln der starken Kundenauthentifizierung (SCA) von Stripe werden automatisch und unabhängig von nutzerdefinierten Radar-Regeln ausgeführt und blockieren nicht authentifizierte Zahlungen, sofern sie nicht ausgenommen sind.