Mit 3D Secure authentifizieren

Sie können die Authentifizierung per 3D Secure (3DS) auf mehreren Plattformen in Ihren Bezahlvorgang integrieren, einschließlich für Web, iOS, Android und React Native. Im Rahmen der Integration wird 3D Secure 2 (3DS2) ausgeführt, insofern die Kundenbank dies unterstützt. Andernfalls wird die Authentifizierung mit 3D Secure 1 vorgenommen. Wenn Sie den 3DS-Dienst von Stripe mit anderen Verarbeitern nutzen möchten, kontaktieren Sie bitte unser Support-Team.

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 Vorschriften wie die starke Kundenauthentifizierung in Europa oder Branchenrichtlinien wie die Sicherheitsrichtlinien für Kreditkarten in Japan dies erfordern, wenn dies von einem Aussteller mit einem Soft Decline-Code verlangt wird oder wenn bestimmte Stripe-Optimierungen gelten.

Sie können auch Radar-Regeln oder die API verwenden, um zu steuern, wann Nutzer/innen aufgefordert werden sollen, die 3DS-Authentifizierung abzuschließen. Dabei wird für jede Nutzerin/jeden Nutzer eine Entscheidung basierend auf den gewünschten Parametern getroffen. Allerdings unterstützen nicht alle Transaktionen 3DS, beispielsweise Wallets oder Off-Session-Zahlungen.

When a payment triggers 3DS, Stripe requires the user to perform authentication to complete the payment if 3DS authentication is available for a card. Depending on what front end you use, 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.
   • Erforderlich: Stripe startet den 3DS-Authentifizierungsablauf, indem der Aussteller des 3D Secure Access Control Server (ACS) kontaktiert und der 3DS-Ablauf gestartet wird.
4. Wenn Stripe 3DS-Ablaufinformationen von dem Aussteller erhält, versuchen wir, die Authentifizierung durchzuführen. 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 Standard-Radarregeln, um 3DS dynamisch anzufordern, wenn ein PaymentIntent oder 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. Manuelles 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, legen Sie payment_method_options[card][request_three_d_secure] auf any oder challenge fest, je nachdem, wofür Sie beim Erstellen oder Bestätigen eines PaymentIntent, SetupIntent oder einer Checkout-Sitzung eine Optimierung erzielen möchten. Dieses Verfahren ist sowohl bei einmaligen Zahlungen also auch bei der Einrichtung einer Zahlungsmethode für zukünftige Zahlungen dasselbe. Wenn Sie diesen Parameter angeben, versucht Stripe, 3DS auszuführen, und setzt alle Radar-Regeln für Dynamic 3D Secure für den PaymentIntent, den SetupIntent oder die Checkout-Sitzung außer Kraft.

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 SCA-Regeln von Stripe werden automatisch ausgeführt, unabhängig davon, ob Sie 3DS manuell anfordern oder nicht. All Ihre 3DS-Anforderungen sind zusätzlich und für SCA nicht erforderlich.

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

Die Haftungsverlagerungsregel gilt für Zahlungen, die erfolgreich mit 3D Secure authentifiziert wurden. In einigen Fällen gilt die Haftungsverlagerung bei gleichwertigen Kryptogrammen wie Apple Pay oder Google Pay. Wenn ein/e Karteninhaber/in eine 3DS-Zahlung als betrügerisch anficht, geht die Haftung in der Regel von Ihnen auf den Kartenaussteller über.

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 anfordert, dies jedoch für die Karte oder den Aussteller nicht verfügbar ist. Dies kann geschehen, wenn der 3DS-Server des Ausstellers ausfällt, oder wenn der Aussteller 3DS nicht unterstützt, obwohl das Kartennetzwerk eine Unterstützung verlangt. Während des Zahlungsvorgangs werden Karteninhaber/innen nicht aufgefordert, die 3DS-Authentifizierung abzuschließen, da die Karte nicht registriert ist. Obwohl Karteninhaber/innen die 3DS-Authentifizierung nicht durchgeführt haben, 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.

Manchmal kommt es bei Zahlungen, die mit 3DS erfolgreich authentifiziert wurden, nicht zu einer Haftungsverlagerung. Dies ist selten und kann beispielsweise vorkommen, wenn Ihr Konto einen übermäßigen Anteil an Betrug aufweist und Sie an einem Betrugsüberwachungsprogramm teilnehmen. Bestimmte Netzwerke haben zudem einige Branchen von der Haftungsverlagerung ausgenommen – zum Beispiel unterstützt Visa keine Haftungsverlagerung bei Unternehmen, die Überweisungen oder Zahlungsanweisungen durchführen, bei Nicht-Finanzinstituten, die Fremd- oder Nicht-Fiat-Währungen anbieten oder beim Kauf oder Aufladen von Wertkarten.

In seltenen Fällen kann es vorkommen, dass die Haftungsverlagerung nach der Autorisierung herabgestuft wird oder das System der Zahlungsablehnung der Kartennetzwerke die Haftungsverlagerung für eine Transaktion nicht erkennt. Wenn Sie in diesen Fällen die Zahlungsanfechtung ablehnen, fügt Stripe automatisch den angeforderten ECI und das Ergebnis der 3DS-Authentifizierung zu Ihren Beweisdaten hinzu. Wir empfehlen Ihnen, zusätzliche Details anzugeben, um Ihre Chancen, die Zahlungsanfechtung für sich zu entscheiden, zu steigern.

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.