जब कोई भुगतान विफल होता है, तो Dodo Payments आपको एक मानकीकृत
error_code और एक मानव-पठनीय error_message के माध्यम से क्यों बताता है। यह गाइड दिखाता है कि उन फ़ील्ड्स को कैसे पढ़ें, यह निर्णय लें कि पुनः प्रयास सार्थक है या नहीं, और ग्राहकों को संवेदनशील जानकारी उजागर किए बिना भुगतान कैसे प्राप्त करें।Dodo Payments विफलता की रिपोर्ट कैसे करता है
हर विफल भुगतान — चाहे एक बार का चेकआउट हो या सदस्यता नवीकरण — भुगतान ऑब्जेक्ट पर समान विफलता फ़ील्ड्स ले जाता है:| Field | Type | Description |
|---|---|---|
status | string | विफल भुगतान के लिए failed। अन्य गैर-सफल राज्यों में शामिल हैं cancelled, requires_customer_action, और requires_payment_method। |
error_code | string | null | मानकीकृत विफलता का कारण, उदाहरण के लिए INSUFFICIENT_FUNDS या PROCESSING_ERROR। पूरी सूची के लिए Transaction Failures संदर्भ देखें। |
error_message | string | null | विफलता का मानव-पठनीय स्पष्टीकरण। |
retry_attempt | integer | मूल शुल्क के लिए 0। 1 या उससे अधिक निर्धारित सदस्यता नवीकरण पुनः प्रयास को पहचानता है। |
error_code और error_message null हैं जब तक कि वास्तव में कोई भुगतान विफल नहीं होता है। हमेशा पहले status की जाँच करें, फिर त्रुटि फ़ील्ड पढ़ें।payment.failed वेबहूक
एक विफलता का पता लगाने का सबसे विश्वसनीय तरीका है payment.failed वेबहूक। ईवेंट पूरे भुगतान ऑब्जेक्ट को data में लपेटता है:
payment.failed payload
error_code पढ़ता है और उस पर मार्ग बनाता है:
यह तय करें कि पुनः प्रयास करें: नरम बनाम कठोर अस्वीकृति
error_code आपको बताता है कि क्या उसी भुगतान विधि को पुनः प्रयास करना सार्थक है।
| Decline type | इसका मतलब क्या है | क्या करें |
|---|---|---|
| Soft decline | अस्थायी या सुधार योग्य (उदाहरण के लिए INSUFFICIENT_FUNDS, PROCESSING_ERROR, NETWORK_ERROR, TRY_AGAIN_LATER)। | फिर से प्रयास करना — एक देरी के बाद, या जब ग्राहक उनकी इनपुट को ठीक करता है — सफल हो सकता है। |
| Hard decline | अंतिम (उदाहरण के लिए STOLEN_CARD, LOST_CARD, DO_NOT_HONOR, FRAUDULENT)। | उसी कार्ड को पुनः प्रयास न करें। ग्राहक से एक अलग भुगतान विधि मांगें। |
error_code के लिए अस्वीकृति प्रकार और अनुशंसित कार्रवाई को सूचीबद्ध करता है।
चेकआउट पर बनाम नवीकरण पर विफलताओं को संभालना
आपकी वसूली इस पर निर्भर करती है कि क्या ग्राहक उपस्थित है।- At checkout (customer present)
- On subscription renewal (customer not present)
ग्राहक सक्रिय रूप से चेकआउट कर रहा है। एक स्पष्ट संदेश पेश करें और उन्हें तुरंत पुनः प्रयास करने दें या एक अन्य कार्ड का उपयोग करें।
requires_payment_method— ग्राहक ने कभी भुगतान विधि प्रदान नहीं की: उन्होंने कार्ड विवरण नहीं दर्ज किए, या एक के लिए कहा गया था और कोई कार्रवाई नहीं की। यह आमतौर पर एक चेकआउट ड्रॉप-ऑफ है, अस्वीकृति नहीं — भुगतान पूर्ण करने के लिए ग्राहक को फिर से संलग्न करें (देखें Abandoned Cart Recovery).requires_customer_action— अतिरिक्त प्रमाणीकरण (जैसे 3DS) की आवश्यकता है; ग्राहक को इसे पूरा करने दें। देखें 3D Secure handling.
एक विफल भुगतान को पुनः प्रयास करना
- Subscriptions: Subscription Payment Retries को सक्षम करें ताकि बिना किसी एकीकरण कार्य के नरम अस्वीकृतियों को पुनः प्राप्त किया जा सके। आप ग्राहक के माध्यम से उनकी भुगतान विधि को अपडेट कराकर पुनर्प्राप्ति को ट्रिगर कर सकते हैं Update Payment Method API, जो किसी भी बकाया राशि को चार्ज करता है।
- One-time payments: चेकआउट या
payment_linkको पुनः भेजें ताकि ग्राहक किसी भिन्न विधि से पुनः प्रयास कर सकें। वन टाइम भुगतान के लिए कोई स्वचालित पुन: प्रयास नहीं है।
त्रुटियों को ग्राहकों तक सुरक्षित रूप से पहुँचाएं
ग्राहकों को एक मित्रवत संदेश दिखाएं — कभी भी कच्चाerror_code नहीं।
Customer-facing messaging
संबंधित
Transaction Failures
प्रत्येक अस्वीकृति कोड, उसका प्रकार, और अनुशंसित क्रिया।
Error Codes
ऐपीआई और व्यापार-तर्क त्रुटियाँ जो कार्ड अस्वीकृति नहीं हैं।
Subscription Payment Retries
सदस्यता नवीकरण पर नरम अस्वीकृतियों की स्वचालित वसूली।
Subscription Dunning
ईमेल अनुक्रम जो कठोर अस्वीकृतियों को पुनः प्राप्त करते हैं।
Payment Webhooks
भुगतान ईवेंट्स के लिए पूरा पेलोड स्कीमा।
Testing Failures
ऐसे परीक्षण कार्ड्स जो अस्वीकृतियों और नवीकरण विफलताओं का अनुकरण करते हैं।