Payment Retries विफल subscription renewal payments को progressive back-off schedule पर स्वचालित रूप से फिर से प्रयास करता है। जब कोई retry सफल हो जाता है, तो subscription अपने आप reactivated हो जाता है — customer की किसी कार्रवाई या integration कार्य की आवश्यकता नहीं होती।
Payment Retries क्या हैं?
जब subscription renewal payment विफल हो जाता है, तो subscription को on hold कर दिया जाता है। Payment Retries सक्षम होने पर, Dodo Payments payment सफल होने या recovery window बंद होने तक smart schedule पर customer के मौजूदा payment method से स्वचालित रूप से दोबारा charge करता है। यह temporary failures के कारण हुए revenue loss को recover करता है — जैसे expired card holds, बाद में top up हो जाने वाले insufficient funds, और transient network errors — customer को email भेजे बिना या उनसे कुछ update करने के लिए कहे बिना।Payment Retries केवल subscription renewal payments पर लागू होते हैं। First payments (mandate setup), one-time payments, plan-change charges और on-demand charges को इस feature द्वारा retry नहीं किया जाता।
Payment Retries कैसे काम करते हैं
1
Renewal fails
Subscription renewal payment विफल हो जाता है और subscription
on_hold state में चला जाता है।2
Retryability check
Failure का error code check किया जाता है। Soft declines (insufficient funds, generic decline, processing या network errors आदि) retryable होते हैं। Hard declines retry chain को तुरंत समाप्त कर देते हैं, क्योंकि retry करने से परिणाम नहीं बदलेगा।
3
Scheduled retry
यदि decline retryable है और recovery window इसकी अनुमति देती है, तो अगला attempt schedule किया जाता है। Retries progressive back-off schedule पर customer के मौजूदा payment method के विरुद्ध off-session चलाए जाते हैं।
4
Recovery
पहले सफल retry पर subscription
active पर लौट आता है और अगली billing date सामान्य रूप से आगे बढ़ जाती है। यदि कोई retry सफल होने से पहले window बंद हो जाती है, तो retries रुक जाते हैं और subscription on hold रहता है।Payment Retries configure करना
अपने dashboard में Settings → Recovery से Payment Retries को enable और configure करें।
Payment Retries settings under Settings → Recovery
Recovery window उस समय से निर्धारित होती है जब विफल renewal invoice बनाया गया था। Retries केवल तभी schedule किए जाते हैं जब cumulative back-off delay अभी भी window के भीतर फिट होता हो।
Retry Schedule
Retries progressively back off होते हैं। अधिकतम 8 attempts किए जाते हैं, बशर्ते प्रत्येक attempt आपकी recovery window के भीतर फिट हो:Subscription Status Transitions
यदि retries schedule होने के दौरान subscription cancel कर दिया जाता है, तो retry chain तुरंत समाप्त हो जाती है और कोई और attempt नहीं किया जाता। अन्य non-active statuses (
on_hold, expired, pending, failed) retry होते रहते हैं, क्योंकि उनके open renewal invoices उन periods के debt को दर्शाते हैं जिन्हें customer पहले ही consume कर चुका है।Subscription Webhook Payloads
Subscription lifecycle events के लिए full webhook payload schemas देखें।
Retryable बनाम Non-Retryable Failures
Hard decline को retry करने से परिणाम नहीं बदलेगा, इसलिए hard decline देखे जाते ही retry chain समाप्त हो जाती है। इन मामलों में customer को अपना payment method update करने के लिए prompt करने हेतु Payment Retries को Subscription Dunning के साथ उपयोग करें।
Payment Retries बनाम Dunning
Payment Retries और Subscription Dunning एक-दूसरे के पूरक recovery tools हैं:
दोनों को enable करने से आपको सबसे व्यापक recovery coverage मिलती है: automatic retries transient failures को पकड़ते हैं, जबकि dunning उन customers को वापस लाता है जिनके payment method को वास्तव में update करने की आवश्यकता है।
संबंधित
Subscription Dunning
Customers को अपना payment method update करने के लिए prompt करने वाले email sequences।
Abandoned Cart Recovery
Targeted emails के साथ incomplete या failed one-time checkouts recover करें।
Subscriptions
Recovery flows में शामिल subscription states को समझें।
Subscription Webhooks
subscription.on_hold और subscription.active events पर प्रतिक्रिया दें।