> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.
# v1.101.0 (2 जून, 2026)
> स्वचालित सदस्यता भुगतान पुनः प्रयास विफल नवीकरण राजस्व को पुन: प्राप्त करने के लिए, व्यवसाय-स्तर के अनुपात डिफ़ॉल्ट्स को उत्पाद-संग्रह के लिए ओवरराइड्स के साथ, और B2B चालानों के लिए व्यवसाय नाम संग्रह — साथ में बग फिक्स और सुधार।
## नई विशेषताएँ
### 1. **सदस्यता भुगतान पुनः प्रयास**
विफल सदस्यता **नवीकरण** भुगतान अब स्वचालित रूप से पुनः प्रयास किए जा सकते हैं राजस्व को पुनः प्राप्त करने के लिए, बिना किसी एकीकरण कार्य की आवश्यकता के। इसे **Settings → Recovery** से सक्षम करें, एक पुनर्प्राप्ति विंडो सेट करें, और Dodo Payments एक स्मार्ट शेड्यूल पर पुनर्नवीकरण को तब तक पुनः प्रयास करता है जब तक यह सफल नहीं होता या विंडो बंद नहीं होती।
| सेटिंग | विवरण | डिफ़ॉल्ट |
| --------------------------------- | ----------------------------------------------------------------------- | ------------ |
| **भुगतान पुनः प्रयास सक्षम करें** | विफल सदस्यता नवीकरण भुगतान को पुनः प्रयास करें। | बंद (opt-in) |
| **पुनर्प्राप्ति विंडो (दिन)** | विफल भुगतान को छोड़ने से पहले कितने समय तक पुनः प्रयास किया जाए (1–30)। | 13 |
**यह कैसे काम करता है**
1. एक सदस्यता नवीकरण भुगतान विफल हो जाता है और सदस्यता `on_hold` पर चली जाती है।
2. अगर अस्वीकार retryable है (जैसे अपर्याप्त धन या एक अस्थायी नेटवर्क त्रुटि), अगला प्रयास स्वचालित रूप से अनुसूचित किया जाता है।
3. पुनः प्रयास उप-सेशन में एक बैक-ऑफ शेड्यूल पर फायर होते हैं, आपके पुनर्प्राप्ति विंडो द्वारा सीमित।
4. पहले सफल पुनः प्रयास पर, सदस्यता `active` पर लौट आती है और अगली बिलिंग तिथि सामान्य रूप से बढ़ जाती है।
**पुनः प्रयास शेड्यूल**
पुनः प्रयास प्रगतिशील रूप से बैक ऑफ होते हैं, विफल इनवॉइस बनाए जाने के समय पर एंकर होते हैं। जब तक वे आपके पुनर्प्राप्ति विंडो के अंदर फिट रहते हैं, तब तक **8 प्रयास** किए जाते हैं:
| प्रयास | पिछले के बाद देरी |
| ------ | ----------------- |
| 1 | 12 घंटे |
| 2 | 24 घंटे |
| 3 | 48 घंटे |
| 4 | 72 घंटे |
| 5 | 96 घंटे |
| 6 | 120 घंटे |
| 7 | 7 दिन |
| 8 | 7 दिन |
केवल **मृदु अस्वीकार** पुनः प्रयास किए जाते हैं (उदा. अपर्याप्त धन, सामान्य अस्वीकार, प्रसंस्करण या नेटवर्क त्रुटियाँ)। **कठिन अस्वीकार** तुरंत पुनः प्रयास श्रंखला को समाप्त कर देते हैं, क्योंकि पुनः प्रयास करने से परिणाम नहीं बदलेगा।
यह मौजूदा पुनर्प्राप्ति उपकरणों को पूरा करता है — **सदस्यता डनिंग** ग्राहक को उनके भुगतान विधि को अपडेट करने के लिए ईमेल करता है, जबकि भुगतान पुनः प्रयास मौन रूप से मौजूदा एक का पुनः प्रयास करता है। वे अच्छे से साथ काम करते हैं।
और जानें: [सदस्यता भुगतान पुनः प्रयास](/features/recovery/payment-retries) | [सदस्यता डनिंग](/features/recovery/subscription-dunning)
### 2. **व्यवसाय अनुपात सेटिंग्स**
आप अब व्यवसाय स्तर पर एक बार **डिफ़ॉल्ट अपग्रेड और डाउनग्रेड व्यवहार** सेट कर सकते हैं बजाय हर योजना परिवर्तन पर अनुपात पैरामीटर पास करने के। ये डिफ़ॉल्ट्स लागू होते हैं जब भी कोई ग्राहक ग्राहक पोर्टल से अपनी योजना बदलता है, और आप **उन्हें प्रति उत्पाद संग्रह ओवरराइड कर सकते हैं**।
प्रत्येक दिशा (उन्नयन और डाउनग्रेड) के पास दो स्वतंत्र नियंत्रण होते हैं, साथ में एक साझा भुगतान-विफलता नीति:
| सेटिंग | फ़ील्ड | डिफ़ॉल्ट (अपग्रेड) | डिफ़ॉल्ट (डाउनग्रेड) |
| ------------------------------------- | --------------------------------------------------------------------------- | ------------------------ | ------------------------ |
| **जब नई योजना शुरू होती है** | `effective_at_on_upgrade` / `effective_at_on_downgrade` | `immediately` | `next_billing_date` |
| **ग्राहक कैसे चार्ज किया जाता है** | `proration_billing_mode_on_upgrade` / `proration_billing_mode_on_downgrade` | `difference_immediately` | `difference_immediately` |
| **अगर ग्राहक का भुगतान विफल होता है** | `on_payment_failure` | `apply_change` | `apply_change` |
**जब नई योजना शुरू होती है** (`effective_at`)
| मूल्य | व्यवहार |
| ------------------- | ------------------------------------------------------------------------------------------ |
| `immediately` | ग्राहक तुरंत नई योजना पर चला जाता है। |
| `next_billing_date` | ग्राहक अपनी वर्तमान योजना पर अगले बिलिंग दिनांक तक रहता है, फिर नई योजना पर स्विच होता है। |
**ग्राहक कैसे चार्ज किया जाता है** (`proration_billing_mode`)
| मूल्य | व्यवहार |
| ------------------------ | -------------------------------------------------------------------------------- |
| `prorated_immediately` | अभी प्रचलित बिलिंग चक्र में छोड़े गए समय के आधार पर एक अनुपातित राशि चार्ज करें। |
| `full_immediately` | अभी नई योजना की पूरी कीमत चार्ज करें। |
| `difference_immediately` | केवल नई योजना और वर्तमान योजना के बीच का मूल्य अंतर चार्ज करें। |
| `do_not_bill` | अभी कुछ भी चार्ज न करें। कोई भी समायोजन अगले इनवॉइस पर लागू होता है। |
**अगर ग्राहक का भुगतान विफल होता है** (`on_payment_failure`)
| मूल्य | व्यवहार |
| ---------------- | ------------------------------------------------------------------------------------------- |
| `prevent_change` | अगर भुगतान नहीं हो पाता है तो ग्राहक को उनकी वर्तमान योजना पर रखें। |
| `apply_change` | अगर भुगतान नहीं हो पाता है तो ग्राहक को नई योजना पर ले जाएं। आप राशि बाद में वसूल सकते हैं। |
**प्रति-संग्रह ओवरराइड**
हर उत्पाद संग्रह इन डिफ़ॉल्ट्स को ओवरराइड कर सकता है। प्रत्येक फ़ील्ड स्वतंत्र है — इसे व्यवसाय से **अनुवांशिकता प्राप्त करें** पर छोड़ दें व्यवसाय डिफ़ॉल्ट का पालन करने के लिए, या उस संग्रह के लिए ओवरराइड करने के लिए एक स्पष्ट मान सेट करें।
प्रत्येक सेटिंग इस क्रम में हल होती है:
```
per-request value (Change Plan API) → collection field (if set) → business field → system default
```
[परिवर्तन योजना API](/api-reference/subscriptions/change-plan) (`proration_billing_mode`, `effective_at`, `on_payment_failure`) को दी गई प्रति-प्रश्निता का मूल्य हमेशा संग्रह और व्यवसाय डिफ़ॉल्ट्स पर प्राथमिकता रखता है। नई सेटिंग्स केवल उस स्थिति में परिवर्तन करती हैं जब कोई स्पष्ट मान प्रदान नहीं किया गया हो — जो सभी ग्राहक-पोर्टल योजना परिवर्तनों के लिए होता है।
और जानें: [सदस्यता अपग्रेड और डाउनग्रेड](/developer-resources/subscription-upgrade-downgrade) | [उत्पाद संग्रह](/features/product-collections)
### 3. **B2B चालानों के लिए व्यवसाय नाम इकट्ठा करना**
B2B ग्राहक अब अपने **कानूनी व्यवसाय नाम** को खरीदने वाली इकाई के रूप में प्रस्तुत कर सकते हैं। जब चेकआउट पर एक वैध टैक्स आईडी प्रदान की जाती है, तो आप संबंधित `customer_business_name` भी संग्रह कर सकते हैं ताकि चलान क्रेता इकाई को दर्शाए।
जब ग्राहक **व्यवसाय के रूप में खरीदारी** को चेकआउट पर चुनते हैं, तो उन्हें **व्यवसाय नाम** और **टैक्स आईडी नंबर** दोनों के लिए प्रेरित किया जाता है।
व्यवसाय का नाम केवल तब चालान पर दिखाई देता है जब **सभी तीन** शर्तें पूरी होती हैं:
1. लेन-देन B2B है (`b2b = true`)
2. एक `tax_id` मौजूद है
3. एक गैर-खाली `customer_business_name` प्रदान किया गया है
अन्यथा ग्राहक का व्यक्तिगत नाम उपयोग होता है।
**इसे चेकआउट पर एकत्रित करना**
`customer_business_name` को सीधे सेट करें, और/या ग्राहकों को उनके टैक्स आईडी के साथ-साथ इसे दर्ज करने या संपादित करने के लिए `allow_customer_editing_business_name` सक्षम करें:
```typescript theme={null}
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_abc', quantity: 1 }],
customer: { email: 'buyer@acme.com' },
tax_id: 'GB123456789',
customer_business_name: 'Acme Corp Ltd',
feature_flags: {
allow_tax_id: true,
allow_customer_editing_business_name: true // let the customer enter/edit it
},
return_url: 'https://yoursite.com/return'
});
```
**यह कहाँ लागू होता है**
| सरफेस | फ़ील्ड | नोट्स |
| ----------- | ------------------------------------------------------------------------------ | --------------------------------------------------------- |
| चेकआउट सत्र | `customer_business_name`, `feature_flags.allow_customer_editing_business_name` | अधिकतम 250 वर्ण; ध्वज डिफ़ॉल्ट है `false` |
| भुगतान | `customer_business_name` | अधिकतम 250 वर्ण |
| सदस्यताएँ | `customer_business_name` | सेट या साफ़ करें `PATCH /subscriptions/{id}` के माध्यम से |
`customer_business_name` को एक `tax_id` के बिना सेट नहीं किया जा सकता। बिना टैक्स आईडी के किसी व्यवसाय नाम को भेजना अस्वीकार कर दिया जाता है। `tax_id` को साफ़ करना भी व्यवसाय नाम को साफ़ करता है, क्योंकि दोनों चालान पर युग्मित होते हैं।
परिवेश व्हाइटस्पेस ट्रिम किया जाता है, और केवल व्हाइटस्पेस मान स्पष्ट रूप से साफ़ किए गए माने जाते हैं — इसलिए संग्रहित डेटा हमेशा उस पर प्रदर्शित होता है जो चालान पर होता है।
और जानें: [B2B भुगतान](/features/b2b-payments) | [चालान प्रबंधन](/features/invoice-generation) | [चेकआउट सत्र](/developer-resources/checkout-session)
## बग फिक्स और सुधार
* प्लेटफ़ॉर्म पर मामूली बग फिक्स और स्थिरता सुधार।