Skip to main content
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:
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.
error_message från merchant API är text för handlaren. Den kan ange den verkliga orsaken till ett avslag, inklusive bedrägerirelaterade orsaker, så återge den aldrig direkt för en kund. Mappa i stället error_code till din egen kundsäkra formulering, enligt exemplet i Visa fel för kunder på ett säkert sätt.

Webhooken payment.failed

Det mest tillförlitliga sättet att upptäcka ett misslyckande är webhooken payment.failed. Händelsen kapslar in hela betalningsobjektet i data:
payment.failed payload
En minimal handler läser error_code och dirigerar utifrån det:
Verifiera alltid webhookens signatur innan du behandlar den. Se Webhooks guide för hela konfigurationen, inklusive signaturverifiering och idempotens.

Avgör om du ska försöka igen: mjuka kontra hårda avslag

error_code visar om det är meningsfullt att försöka igen med samma betalningsmetod. Referensen Transaction Failures listar typen av avslag och den rekommenderade åtgärden för varje error_code.

Hantera misslyckanden i checkout jämfört med vid förnyelse

Hur du återställer betalningen beror på om kunden är närvarande.
Kunden genomför aktivt checkout. Visa ett tydligt meddelande och låt kunden försöka igen direkt eller använda ett annat kort.
  • requires_payment_method — kunden angav aldrig någon betalningsmetod: hen angav inte kortuppgifter eller blev ombedd att ange dem men vidtog ingen åtgärd. Detta är vanligtvis ett avbrutet köp, inte ett avslag — återengagera kunden så att hen slutför betalningen (se Återställning av övergivna kundvagnar).
  • requires_customer_action — ytterligare autentisering (till exempel 3DS) krävs; be kunden slutföra den. Se Hantering av 3D Secure.

Försöka igen med en misslyckad betalning

  • Prenumerationer: Aktivera Subscription Payment Retries för att återställa mjuka avslag utan integrationsarbete. Du kan också utlösa återställning genom att låta kunden uppdatera sin betalningsmetod via Update Payment Method API, som debiterar eventuella utestående belopp.
  • Engångsbetalningar: Skicka checkout eller payment_link igen så att kunden kan försöka med en annan metod. Det finns inget automatiskt nytt försök för engångsbetalningar.
Försök inte igen med hårda avslag mot samma kort. Kortnätverk kan flagga upprepade avslag som missbruk, vilket försämrar din auktoriseringsgrad.

Visa fel för kunder på ett säkert sätt

Visa kunderna ett vänligt meddelande — aldrig det råa error_code och aldrig det error_message som är avsett för handlaren.
På ytor som styrs av Dodo Payments — checkout, Customer Portal och kravmejl — är denna mappning redan gjord åt dig, inklusive återgången till ett generiskt meddelande för bedrägerirelaterade avslag. Du behöver bara mappningen nedan när du återger misslyckanden i din egen produkt.
Customer-facing messaging
Avslöja aldrig den verkliga orsaken till STOLEN_CARD, LOST_CARD, PICKUP_CARD eller FRAUDULENT. Om du visar dessa kan du ge en bedragare information. Visa ett generiskt avslagsmeddelande och logga endast det specifika error_code internt.

Relaterat

Transaction Failures

Varje avslagskod, dess typ och den rekommenderade åtgärden.

Error Codes

API- och affärslogikfel som inte är kortavslag.

Subscription Payment Retries

Automatisk återställning av mjuka avslag vid förnyelse av prenumerationer.

Subscription Dunning

E-postsekvenser som återställer hårda avslag.

Payment Webhooks

Fullständigt schema för nyttolasten för betalningshändelser.

Testing Failures

Testkort som simulerar avslag och misslyckade förnyelser.
Senast ändrad 8 augusti 2026