När en betalning misslyckas talar Dodo Payments om varför genom en standardiserad
error_code och en läsbar error_message. Denna guide visar hur man läser dessa fält, avgör om en ny försök är värt och återställer betalningen utan att exponera känslig information för kunderna.Hur Dodo Payments Rapporterar Ett Fel
Varje misslyckad betalning — oavsett om det är en engångskassa eller en abonnemangsförnyelse — bär samma fel fält på betalningsobjektet:| Fält | Typ | Beskrivning |
|---|---|---|
status | string | failed för en misslyckad betalning. Andra icke-framgångsstatusar inkluderar cancelled, requires_customer_action och requires_payment_method. |
error_code | string | null | Den standardiserade anledningen till misslyckandet, till exempel INSUFFICIENT_FUNDS eller PROCESSING_ERROR. Se referensen för Transaktionsfel för hela listan. |
error_message | string | null | En läsbar förklaring av felet. |
retry_attempt | integer | 0 för den ursprungliga avgiften. 1 eller högre identifierar en schemalagd abonnemangsförnyelseförsök. |
error_code och error_message är null tills en betalning faktiskt misslyckas. Kontrollera alltid status först och läs sedan fält för fel.Webhook för payment.failed
Det mest pålitliga sättet att upptäcka ett fel är webhooken payment.failed. Händelsen omsluter det fullständiga betalningsobjektet i data:
payment.failed payload
error_code och dirigerar utifrån det:
Avgör Om Du Ska Försöka Igen: Mjuka vs. Hårda Avslag
error_code berättar för dig om det är värt att försöka med samma betalningsmetod igen.
| Avslagstyp | Vad det betyder | Vad du ska göra |
|---|---|---|
| Mjukt avslag | Tillfälligt eller korrigerbart (till exempel INSUFFICIENT_FUNDS, PROCESSING_ERROR, NETWORK_ERROR, TRY_AGAIN_LATER). | Att försöka igen — efter en fördröjning, eller när kunden rättar till sin inmatning — kan lyckas. |
| Hårt avslag | Terminal (till exempel STOLEN_CARD, LOST_CARD, DO_NOT_HONOR, FRAUDULENT). | Försök inte med samma kort igen. Be kunden att välja en annan betalningsmetod. |
error_code.
Hantera Fel Vid Checkout vs. Vid Förnyelse
Hur du återställer beror på om kunden är närvarande.- At checkout (customer present)
- On subscription renewal (customer not present)
Kunden handlar aktivt. Visa ett tydligt meddelande och låt dem försöka igen direkt eller använda ett annat kort.
requires_payment_method— kunden har aldrig angett en betalningsmetod: de angav inte kortuppgifter, eller blev ombedda att göra det och gjorde inget. Detta är vanligtvis en checkout avbrott, inte ett avslag — återengagera kunden för att slutföra betalningen (se Återhämtning av Övergivna Varukorgar).requires_customer_action— ytterligare autentisering (såsom 3DS) behövs; be kunden slutföra den. Se 3D Secure hantering.
Försöka med en Misslyckad Betalning Igen
- Abonnemang: Aktivera Abonnemangsbetalningsförsök för att återhämta sig från mjuka avslag utan integrationsarbete. Du kan också utlösa återhämtning genom att kunden uppdaterar sin betalningsmetod via API för Uppdatering av Betalningsmetod, som debiterar alla utestående avgifter.
- Engångsbetalningar: Skicka om checkout eller
payment_linkså att kunden kan försöka igen med en annan metod. Det finns ingen automatisk återförsök för engångsbetalningar.
Visa Fel För Kunder På Ett Säkert Sätt
Visa kunderna ett vänligt meddelande — aldrig den råaerror_code.
Customer-facing messaging
Relaterade
Transaction Failures
Varje avvisningskod, dess typ och den rekommenderade åtgärden.
Error Codes
API- och affärslogiska fel som inte är kortavslag.
Subscription Payment Retries
Automatisk återhämtning av mjuka avslag vid abonnemangsförnyelser.
Subscription Dunning
E-postsekvenser som återhämtar hårda avslag.
Payment Webhooks
Fullständigt payload-schema för betalningshändelser.
Testing Failures
Testkort som simulerar avslag och förnyelsemisslyckanden.