नई विशेषताएँ
1. सदस्यता भुगतान पुनः प्रयास
विफल सदस्यता नवीकरण भुगतान अब स्वचालित रूप से पुनः प्रयास किए जा सकते हैं राजस्व को पुनः प्राप्त करने के लिए, बिना किसी एकीकरण कार्य की आवश्यकता के। इसे Settings → Recovery से सक्षम करें, एक पुनर्प्राप्ति विंडो सेट करें, और Dodo Payments एक स्मार्ट शेड्यूल पर पुनर्नवीकरण को तब तक पुनः प्रयास करता है जब तक यह सफल नहीं होता या विंडो बंद नहीं होती।
| सेटिंग | विवरण | डिफ़ॉल्ट |
|---|
| भुगतान पुनः प्रयास सक्षम करें | विफल सदस्यता नवीकरण भुगतान को पुनः प्रयास करें। | बंद (opt-in) |
| पुनर्प्राप्ति विंडो (दिन) | विफल भुगतान को छोड़ने से पहले कितने समय तक पुनः प्रयास किया जाए (1–30)। | 13 |
- एक सदस्यता नवीकरण भुगतान विफल हो जाता है और सदस्यता
on_hold पर चली जाती है।
- अगर अस्वीकार retryable है (जैसे अपर्याप्त धन या एक अस्थायी नेटवर्क त्रुटि), अगला प्रयास स्वचालित रूप से अनुसूचित किया जाता है।
- पुनः प्रयास उप-सेशन में एक बैक-ऑफ शेड्यूल पर फायर होते हैं, आपके पुनर्प्राप्ति विंडो द्वारा सीमित।
- पहले सफल पुनः प्रयास पर, सदस्यता
active पर लौट आती है और अगली बिलिंग तिथि सामान्य रूप से बढ़ जाती है।
पुनः प्रयास शेड्यूल
पुनः प्रयास प्रगतिशील रूप से बैक ऑफ होते हैं, विफल इनवॉइस बनाए जाने के समय पर एंकर होते हैं। जब तक वे आपके पुनर्प्राप्ति विंडो के अंदर फिट रहते हैं, तब तक 8 प्रयास किए जाते हैं:
| प्रयास | पिछले के बाद देरी |
|---|
| 1 | 12 घंटे |
| 2 | 24 घंटे |
| 3 | 48 घंटे |
| 4 | 72 घंटे |
| 5 | 96 घंटे |
| 6 | 120 घंटे |
| 7 | 7 दिन |
| 8 | 7 दिन |
केवल मृदु अस्वीकार पुनः प्रयास किए जाते हैं (उदा. अपर्याप्त धन, सामान्य अस्वीकार, प्रसंस्करण या नेटवर्क त्रुटियाँ)। कठिन अस्वीकार तुरंत पुनः प्रयास श्रंखला को समाप्त कर देते हैं, क्योंकि पुनः प्रयास करने से परिणाम नहीं बदलेगा।
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 (proration_billing_mode, effective_at, on_payment_failure) को दी गई प्रति-प्रश्निता का मूल्य हमेशा संग्रह और व्यवसाय डिफ़ॉल्ट्स पर प्राथमिकता रखता है। नई सेटिंग्स केवल उस स्थिति में परिवर्तन करती हैं जब कोई स्पष्ट मान प्रदान नहीं किया गया हो — जो सभी ग्राहक-पोर्टल योजना परिवर्तनों के लिए होता है। 3. B2B चालानों के लिए व्यवसाय नाम इकट्ठा करना
B2B ग्राहक अब अपने कानूनी व्यवसाय नाम को खरीदने वाली इकाई के रूप में प्रस्तुत कर सकते हैं। जब चेकआउट पर एक वैध टैक्स आईडी प्रदान की जाती है, तो आप संबंधित customer_business_name भी संग्रह कर सकते हैं ताकि चलान क्रेता इकाई को दर्शाए।
जब ग्राहक व्यवसाय के रूप में खरीदारी को चेकआउट पर चुनते हैं, तो उन्हें व्यवसाय नाम और टैक्स आईडी नंबर दोनों के लिए प्रेरित किया जाता है।
व्यवसाय का नाम केवल तब चालान पर दिखाई देता है जब सभी तीन शर्तें पूरी होती हैं:
- लेन-देन B2B है (
b2b = true)
- एक
tax_id मौजूद है
- एक गैर-खाली
customer_business_name प्रदान किया गया है
अन्यथा ग्राहक का व्यक्तिगत नाम उपयोग होता है।
इसे चेकआउट पर एकत्रित करना
customer_business_name को सीधे सेट करें, और/या ग्राहकों को उनके टैक्स आईडी के साथ-साथ इसे दर्ज करने या संपादित करने के लिए allow_customer_editing_business_name सक्षम करें:
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 को साफ़ करना भी व्यवसाय नाम को साफ़ करता है, क्योंकि दोनों चालान पर युग्मित होते हैं।
परिवेश व्हाइटस्पेस ट्रिम किया जाता है, और केवल व्हाइटस्पेस मान स्पष्ट रूप से साफ़ किए गए माने जाते हैं — इसलिए संग्रहित डेटा हमेशा उस पर प्रदर्शित होता है जो चालान पर होता है।
बग फिक्स और सुधार
- प्लेटफ़ॉर्म पर मामूली बग फिक्स और स्थिरता सुधार।
