Om en betalning kräver 3D Secure-autentisering men vi inte kan initiera den kommer vi att göra ett sista försök att slutföra betalningen utan autentisering. Resultaten från den här reservdebiteringen uppdaterar PaymentIntent-statusen till något av följande:

• succeeded: Betalningen slutfördes och skapade en debitering med den angivna betalningsmetoden. Inga ytterligare åtgärder krävs.
• requires_capture: Begäran slutfördes utan autentisering, vilket gör att du kan fortsätta att debitera medlen.
• requires_payment_method: Debiteringen misslyckades och det krävs eventuellt en annan betalningsmetod

Normalt sett kommer en betalning som utlöser 3D Secure att resultera i ett PaymentIntent med statusen requires_action. Här är en genomgång av ett typiskt betalningsflöde som begär 3D Secure:

1. Din kund anger sin betalningsinformation och den ansluts till PaymentIntent.
2. Stripe kontrollerar om 3D Secure behövs. Det här kan fastställas med hjälp av Radar-reglerna, huruvida betalningen begärdes manuellt och andra faktorer
3. Stripe fastställer att 3D Secure
   1. inte krävs, så vi går vidare och försöker debitera kortet. I detta läge kan banken skicka tillbaka en "mjukt nekad betalning" som anger att det krävs autentisering för att debiteringen ska kunna genomföras
   2. krävs så vi fortsätter till nästa steg för att utlösa 3DS
4. Stripe startar 3D Secure
5. Stripe kunde begära 3D Secure och nu väntar vi på kundens autentisering. Payment Intent övergår till statusen requires_action.

Om steg 4 eller 5 inte kunde genomföras, ändras ovanstående betalningsflöde till att se ut ungefär så här:

1. Din kund anger sin betalningsinformation och den ansluts till PaymentIntent.
2. Stripe kontrollerar om 3D Secure behövs (avgörs enligt Radar-regler huruvida betalningen begärdes manuellt och andra faktorer).
3. Stripe fastställer att 3D Secure krävs och försöker genomföra autentiseringsprocessen.
4. Vi stöter på ett problem när vi startar 3D Secure-processen. Det kan ske på grund av olika orsaker, som att kortet inte har stöd för 3DS, ett hanteringsfel, att utfärdarens 3D Secure-server är nere etc.
5. Även om 3DS inte kunde genomföras går vi vidare och gör ett sista betalningsförsök utan autentisering. Detta leder till att PaymentIntent övergår till statusen succeeded, requires_capture eller requires_payment_method beroende på resultatet av betalningen.

Anledningen till att vi försöker göra det i stället för att omedelbart blockera betalningen eller returnera ett fel är att vi väljer att optimera för konvertering.

Om reservdebiteringen misslyckas uppdateras PaymentIntent-statusen till requires_payment_method. Om denna reservdebiteringen genomförs omfattas debiteringen inte av ansvarsförskjutning, såvida inte reservdebiteringen har statusen attempt_acknowledged för payment_method_details.card.three_d_secure.result.

Mer information om ej autentiserade betalningar och ansvarsförskjutning finns i Använda Radar for Fraud Teams för att förhindra debiteringar utan ansvarsförskjutning