Skip to main content
Payment Retries विफल subscription renewal payments को back-off schedule पर अपने-आप फिर से charge करता है। जब कोई retry सफल होता है, तो subscription बिना customer action और बिना किसी integration work के active पर लौट आती है।

Payment Retries क्या हैं?

जब subscription renewal payment विफल होता है, तो subscription on_hold पर चली जाती है, या यदि आप grace period सेट करते हैं, तो past_due पर चली जाती है। Payment Retries चालू होने पर, Dodo Payments customer की saved payment method को एक schedule के अनुसार फिर से charge करता है, जब तक कि charge सफल न हो जाए या recovery window बंद न हो जाए। Retries अस्थायी विफलताओं के कारण खोए हुए revenue को recover करते हैं, जैसे card पर अस्थायी hold, अपर्याप्त funds जिन्हें customer बाद में top up कर देता है, या transient network error। Customer को कोई email नहीं मिलता और उसे कुछ भी बदलने की आवश्यकता नहीं होती।
Payment Retries केवल subscription renewal payments पर लागू होते हैं। Subscription का पहला payment (mandate setup), one-time payments, plan-change charges और on-demand charges को retry नहीं किया जाता।

Payment Retries कैसे काम करते हैं

1

Renewal fails

Subscription renewal payment विफल होता है और subscription on_hold पर चली जाती है, या grace period के दौरान past_due पर चली जाती है।
2

Retryability check

Dodo Payments विफलता का error code जाँचता है। Soft declines, जैसे अपर्याप्त funds, generic decline या processing अथवा network error, retry किए जा सकते हैं। Hard declines retry chain को समाप्त कर देते हैं, क्योंकि एक और प्रयास से परिणाम नहीं बदलेगा। Error code के बिना हुई विफलता को hard decline माना जाता है।
3

Scheduled retry

यदि decline retry किया जा सकता है और अगला प्रयास recovery window के भीतर आता है, तो Dodo Payments उसे schedule करता है। प्रत्येक retry customer की saved payment method पर किया गया off-session charge होता है और प्रत्येक delay पिछली विफलता से गिना जाता है।
4

Recovery

पहले सफल retry पर subscription active पर लौट आती है और अगली billing date सफल retry के एक billing period बाद हो जाती है। यदि कोई retry सफल होने से पहले window बंद हो जाती है, तो retries रुक जाते हैं और subscription अपना status बनाए रखती है, जैसे on_hold।

Payment Retries configure करना

अपने dashboard में Settings → Recovery से Payment Retries चालू और configure करें।
Recovery Settings page with the Enable Payment Retries toggle on and a Recovery window (days) field set to 13

Payment Retries settings under Settings → Recovery

इस page में दो settings हैं: Recovery window तब शुरू होती है जब विफल renewal का invoice बनाया जाता है। Dodo Payments किसी attempt को तभी schedule करता है जब उस attempt तक के सभी delays का योग window के भीतर आता हो और window अभी खुली हो।

Retry Schedule

Retries धीरे-धीरे बढ़ते हुए back off होते हैं। Dodo Payments अधिकतम 8 attempts करता है, बशर्ते प्रत्येक attempt आपकी recovery window के भीतर आता हो:
13 दिनों की default window attempts 1 से 5 तक को कवर करती है, क्योंकि attempt 5 विफलता के लगभग 10.5 दिन बाद होता है। बाद के, अधिक अंतराल वाले attempts चलाने के लिए window बढ़ाएँ: attempt 6 के लिए कम-से-कम 16 दिन, attempt 7 के लिए कम-से-कम 23 दिन और attempt 8 के लिए 30 दिनों की maximum window आवश्यक है।

Subscription Status Transitions

Retries subscription को इन statuses के बीच ले जाते हैं:
जब subscription cancelled होती है, तो उसकी retry chain समाप्त हो जाती है और कोई और attempt नहीं किया जाता। हर दूसरा status (on_hold, past_due, expired, pending, failed) retry करता रहता है, क्योंकि open renewal invoice उस अवधि का debt है जिसे customer पहले ही उपयोग कर चुका है। जब invoice का payment किसी अन्य तरीके से हो जाता है, तब भी retries रुक जाते हैं, उदाहरण के लिए customer द्वारा अपनी payment method update करने के बाद, या जब आप customer को अपनी blocklist में जोड़ते हैं।
ये transitions standard subscription webhook events emit करते हैं, इसलिए आपकी entitlement logic को retry-specific handling की आवश्यकता नहीं होती:

Subscription Webhook Payloads

Subscription lifecycle events के full webhook payload schemas देखें।

Retryable vs. Non-Retryable Failures

सबसे हाल की विफलता का error code तय करता है कि chain जारी रहेगी या नहीं:
Hard decline को retry करने से परिणाम नहीं बदलेगा, इसलिए hard decline होते ही chain समाप्त हो जाती है। ऐसे मामलों में customer से नई payment method माँगने के लिए Payment Retries को Subscription Dunning के साथ उपयोग करें। प्रत्येक code के type के लिए Transaction Failures देखें।

Retrying on Demand

आपको अगले scheduled attempt का इंतज़ार करने की आवश्यकता नहीं है। जब subscription on_hold हो, तब आप dashboard में विफल payment के detail page से या POST /payments/{payment_id}/retry के साथ retry भेज सकते हैं। Manual retries schedule से स्वतंत्र रूप से चलते हैं: वे किसी automatic attempt को consume या move नहीं करते और Payment Retries बंद होने पर भी काम करते हैं। Manual Payment Retry देखें।

Payment Retries vs. Dunning

Payment Retries और Subscription Dunning अलग-अलग प्रकार की failures को recover करते हैं: व्यापक coverage के लिए दोनों को चालू करें: automatic retries transient failures को पकड़ते हैं और dunning उन customers को वापस लाता है जिनकी payment method को replace करने की आवश्यकता है।

Manual Payment Retry

अगले scheduled attempt का इंतज़ार करने के बजाय तुरंत retry भेजें।

Subscription Dunning

Customers से अपनी payment method update करने के लिए कहने वाले email sequences।

Abandoned Cart Recovery

Recovery emails के साथ abandoned या failed checkouts recover करें।

Subscriptions

वे subscription states जिनके बीच recovery flows move करते हैं।

Subscription Webhooks

subscription.on_hold और subscription.active events पर प्रतिक्रिया दें।
अंतिम संशोधन 26 सितंबर 2026