Waarom slagen sommige betalingen zonder authenticatie, zelfs wanneer 3D Secure is aangevraagd?

Als een betaling 3D Secure-authenticatie vereist, maar we deze niet kunnen starten, zullen we een laatste poging doen om de betaling te voltooien zonder authenticatie. De resultaten van deze alternatieve betaling werkt de PaymentIntent-status bij naar een van de volgende:

Doorgaans leidt een betaling die 3D Secure activeert tot een PaymentIntent met de status requires_action. Hier volgt een stapsgewijze uitleg van een typisch betaalproces waarbij 3D Secure wordt aangevraagd:

  1. Je klant levert zijn betaalinformatie aan en deze wordt gekoppeld aan de PaymentIntent.
  2. Stripe controleert of 3D Secure nodig is. Dit kan worden opgemaakt uit Radar-regels, uit of de informatie handmatig werd aangevraagd voor de betaling en andere factoren
  3. Stripe stelt vast dat 3D Secure
    1. niet vereist is, dus gaan we proberen de betaling van de kaart af te schrijven. Op dat moment kan de bank een 'soft decline' terugsturen, wat inhoudt dat authenticatie nodig is om de betaling te laten slagen
    2. vereist is, dus gaan we door met de volgende stap om 3DS te activeren
  4. Stripe start 3D Secure
  5. Stripe kon 3D Secure aanvragen en nu wachten we totdat de klant authenticeert. De Payment Intent schakelt over naar een status van requires_action.

Als stappen 4 of 5 niet slaagden, zou het bovenstaande betaalproces veranderen en er ongeveer zo uit gaan zien:

  1. Je klant levert zijn betaalinformatie aan en deze wordt gekoppeld aan de PaymentIntent.
  2. Stripe controleert of 3D Secure nodig is (dit kan worden opgemaakt uit Radar-regels, uit of het handmatig werd aangevraagd voor de betaling en andere factoren).
  3. Stripe stelt vast dat 3D Secure vereist is en doet een poging om het authenticatieproces uit te voeren.
  4. We lopen tegen een probleem aan bij het opstarten van het 3D Secure-proces. Dit kan gebeuren om verschillende redenen, zoals dat de kaart geen 3DS ondersteunt, een verwerkingsfout, een storing bij de 3D Secure-server van de uitgever, etc.
  5. Ook al is 3DS niet succesvol uitgevoerd, gaan we door om een laatste betalingspoging te doen zonder authenticatie. Dit zorgt dat de PaymentIntent overschakelt naar de status geslaagd, requires_capture of requires_payment_method afhankelijk van het resultaat van de betaling.

De reden waarom we dit proberen in plaats van direct de betaling te blokkeren of een foutmelding terug te sturen, is dat we ervoor kiezen om de conversie te optimaliseren.

Als de alternatieve betaling mislukt, dan wordt de PaymentIntent-status bijgewerkt naar requires_payment_method. In het geval dat deze alternatieve betaling slaagt, wordt de betaling niet gedekt door een verschuiving van aansprakelijkheid, tenzij de alternatieve betaling de status attempt_acknowledged heeft op payment_method_details.card.three_d_secure.result.

Voor meer informatie over ongeauthenticeerde betalingen en verschuiving van aansprakelijkheid, zie Radar for Fraud Teams gebruiken om betalingen zonder verschuiving van aansprakelijkheid te voorkomen