मुख्य सामग्री पर जाएं

अवलोकन

ऑन-डिमांड सब्सक्रिप्शन आपको एक ग्राहक के भुगतान विधि को एक बार अधिकृत करने और फिर जब भी आवश्यकता हो, परिवर्तनीय राशि चार्ज करने की अनुमति देता है, बजाय इसके कि एक निश्चित कार्यक्रम पर। यह सुविधा सभी खातों के लिए उपलब्ध है—कोई अनुमोदन आवश्यक नहीं। इस गाइड का उपयोग करें:
  • एक ऑन-डिमांड सब्सक्रिप्शन बनाएं (वैकल्पिक प्रारंभिक मूल्य के साथ एक जनादेश अधिकृत करें)
  • कस्टम राशियों के साथ बाद के चार्ज को ट्रिगर करें
  • वेबहुक का उपयोग करके परिणामों को ट्रैक करें
सामान्य सब्सक्रिप्शन सेटअप के लिए, सब्सक्रिप्शन इंटीग्रेशन गाइड देखें।

पूर्वापेक्षाएँ

  • डोडो पेमेंट्स व्यापारी खाता और API कुंजी
  • वेबहुक गुप्त कुंजी कॉन्फ़िगर की गई और घटनाओं को प्राप्त करने के लिए एक एंडपॉइंट
  • आपके कैटलॉग में एक सब्सक्रिप्शन उत्पाद
यदि आप चाहते हैं कि ग्राहक होस्टेड चेकआउट के माध्यम से जनादेश को स्वीकृत करे, तो payment_link: true सेट करें और एक return_url प्रदान करें।

ऑन-डिमांड कैसे काम करता है

  1. आप एक सब्सक्रिप्शन बनाते हैं जिसमें on_demand ऑब्जेक्ट का उपयोग करके एक भुगतान विधि को अधिकृत करते हैं और वैकल्पिक रूप से एक प्रारंभिक चार्ज एकत्र करते हैं।
  2. बाद में, आप समर्पित चार्ज एंडपॉइंट का उपयोग करके उस सब्सक्रिप्शन के खिलाफ कस्टम राशियों के साथ चार्ज बनाते हैं।
  3. आप वेबहुक (जैसे, payment.succeeded, payment.failed) को सुनते हैं ताकि अपने सिस्टम को अपडेट कर सकें।

एक ऑन-डिमांड सब्सक्रिप्शन बनाएं

एंडपॉइंट: POST /checkouts मुख्य अनुरोध फ़ील्ड (शरीर):
कृपया उन्हें चेकआउट सत्र बनाएं में देखें।

एक ऑन-डिमांड सब्सक्रिप्शन बनाएं

import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
  environment: 'test_mode', // defaults to 'live_mode'
});

async function main() {
  const subscription = await client.checkoutSessions.create({
    product_cart: [{ product_id: 'pdt_123', quantity: 1 }],
    billing_address:  { city: 'SF', country: 'US', state: 'CA', street: '1 Market St', zipcode: '94105' },
    customer: { customer_id: 'cus_123' },
    return_url: 'https://example.com/billing/success',
    subscription_data: {
        on_demand: {
            mandate_only: true // set false to collect an initial charge
            // product_price: 1000, // optional: charge $10.00 now if mandate_only is false
            // product_currency: 'USD',
            // product_description: 'Custom initial charge',
            // adaptive_currency_fees_inclusive: false,
        }
    }
  });

  console.log(subscription.checkout_url);
}

main().catch(console.error);
Success
{
  "session_id": "cks_123",
  "checkout_url": "https://test.checkout.dodopayments.com/session/cks123"
}

एक ऑन-डिमांड सब्सक्रिप्शन चार्ज करें

जब जनादेश अधिकृत हो जाए, तो आवश्यकतानुसार चार्ज बनाएं। एंडपॉइंट: POST /subscriptions/{subscription_id}/charge मुख्य अनुरोध फ़ील्ड (शरीर):
product_price
integer
आवश्यक
चार्ज करने के लिए राशि (सबसे छोटे मुद्रा इकाई में)। उदाहरण: $25.00 चार्ज करने के लिए, 2500 पास करें।
product_currency
string
चार्ज के लिए वैकल्पिक मुद्रा ओवरराइड।
product_description
string
इस चार्ज के लिए वैकल्पिक विवरण ओवरराइड।
adaptive_currency_fees_inclusive
boolean
यदि सत्य है, तो product_price के भीतर अनुकूलनात्मक मुद्रा शुल्क शामिल हैं। यदि गलत है, तो शुल्क ऊपर जोड़े जाते हैं।
metadata
object
भुगतान के लिए अतिरिक्त मेटाडेटा। यदि छोड़ा गया, तो सब्सक्रिप्शन मेटाडेटा का उपयोग किया जाता है।
import DodoPayments from 'dodopayments';

const client = new DodoPayments({ bearerToken: process.env.DODO_PAYMENTS_API_KEY });

async function chargeNow(subscriptionId) {
  const res = await client.subscriptions.charge(subscriptionId, { product_price: 2500 });
  console.log(res.payment_id);
}

chargeNow('sub_123').catch(console.error);
Success
{ "payment_id": "pay_abc123" }
एक सब्सक्रिप्शन को चार्ज करना जो ऑन-डिमांड नहीं है, विफल हो सकता है। चार्ज करने से पहले सुनिश्चित करें कि सब्सक्रिप्शन में on_demand: true इसके विवरण में है।

भुगतान पुनः प्रयास

हमारी धोखाधड़ी पहचान प्रणाली आक्रामक पुनः प्रयास पैटर्न को अवरुद्ध कर सकती है (और उन्हें संभावित कार्ड परीक्षण के रूप में चिह्नित कर सकती है)। एक सुरक्षित पुनः प्रयास नीति का पालन करें।
बर्स्ट पुनः प्रयास पैटर्न को हमारी जोखिम प्रणालियों और प्रोसेसर द्वारा धोखाधड़ी या संदिग्ध कार्ड परीक्षण के रूप में चिह्नित किया जा सकता है। क्लस्टर किए गए पुनः प्रयासों से बचें; नीचे दिए गए बैकऑफ शेड्यूल और समय संरेखण मार्गदर्शन का पालन करें।

सुरक्षित पुनः प्रयास नीतियों के लिए सिद्धांत

  • बैकऑफ तंत्र: पुनः प्रयासों के बीच गुणात्मक बैकऑफ का उपयोग करें।
  • पुनः प्रयास सीमाएँ: कुल पुनः प्रयासों को सीमित करें (3-4 प्रयास अधिकतम)।
  • बुद्धिमान फ़िल्टरिंग: केवल पुनः प्रयास करने योग्य विफलताओं पर पुनः प्रयास करें (जैसे, नेटवर्क/जारीकर्ता त्रुटियाँ, अपर्याप्त धन); कभी भी कठिन अस्वीकृतियों पर पुनः प्रयास न करें।
  • कार्ड परीक्षण रोकथाम: ऐसी विफलताओं पर पुनः प्रयास न करें जैसे DO_NOT_HONOR, STOLEN_CARD, LOST_CARD, PICKUP_CARD, FRAUDULENT, AUTHENTICATION_FAILURE
  • मेटाडेटा में भिन्नता (वैकल्पिक): यदि आप अपनी स्वयं की पुनः प्रयास प्रणाली बनाए रखते हैं, तो मेटाडेटा (जैसे, retry_attempt) के माध्यम से पुनः प्रयासों में भिन्नता करें।

सुझाई गई पुनः प्रयास अनुसूची (सब्सक्रिप्शन)

  • 1st प्रयास: जब आप चार्ज बनाते हैं तो तुरंत
  • 2nd प्रयास: 3 दिन बाद
  • 3rd प्रयास: 7 और दिनों के बाद (कुल 10 दिन)
  • 4th प्रयास (अंतिम): 7 और दिनों के बाद (कुल 17 दिन)
अंतिम चरण: यदि अभी भी भुगतान नहीं हुआ है, तो अपनी नीति के आधार पर सब्सक्रिप्शन को अनपेक्षित के रूप में चिह्नित करें या इसे रद्द करें। ग्राहक को उनके भुगतान विधि को अपडेट करने के लिए सूचित करें।

बर्स्ट पुनः प्रयासों से बचें; प्राधिकरण समय के अनुसार संरेखित करें

  • अपने पोर्टफोलियो में “बर्स्ट” व्यवहार से बचने के लिए पुनः प्रयासों को मूल प्राधिकरण टाइमस्टैम्प से जोड़ें।
  • उदाहरण: यदि ग्राहक आज 1:10 बजे एक परीक्षण या जनादेश शुरू करता है, तो अपने बैकऑफ के अनुसार अगले प्रयासों को 1:10 बजे अगले दिनों में शेड्यूल करें (जैसे, +3 दिन → 1:10 बजे, +7 दिन → 1:10 बजे)।
  • वैकल्पिक रूप से, यदि आप अंतिम सफल भुगतान समय को स्टोर करते हैं T, तो समय-समय पर संरेखण बनाए रखने के लिए अगला प्रयास T + X days पर शेड्यूल करें।
समय क्षेत्र और DST: अनुसूची के लिए एक सुसंगत समय मानक का उपयोग करें और केवल प्रदर्शित करने के लिए परिवर्तित करें ताकि अंतराल बनाए रखा जा सके।

अस्वीकृति कोड जिन पर आपको पुनः प्रयास नहीं करना चाहिए

  • STOLEN_CARD
  • DO_NOT_HONOR
  • FRAUDULENT
  • PICKUP_CARD
  • AUTHENTICATION_FAILURE
  • LOST_CARD
अस्वीकृति कारणों की एक व्यापक सूची और क्या वे उपयोगकर्ता-सुधार योग्य हैं, के लिए देखें लेनदेन विफलताएँ दस्तावेज़।
केवल नरम/अस्थायी मुद्दों पर पुनः प्रयास करें (जैसे, insufficient_funds, issuer_unavailable, processing_error, नेटवर्क टाइमआउट)। यदि वही अस्वीकृति दोहराई जाती है, तो आगे के पुनः प्रयासों को रोकें।

कार्यान्वयन दिशानिर्देश (कोई कोड नहीं)

  • सटीक टाइमस्टैम्प को बनाए रखने के लिए एक शेड्यूलर/क्यू का उपयोग करें; अगले प्रयास को समय-समय पर ऑफसेट पर सटीक समय पर गणना करें (जैसे, T + 3 days उसी HH:MM पर)।
  • अंतिम सफल भुगतान टाइमस्टैम्प T को बनाए रखें और संदर्भित करें ताकि अगले प्रयास की गणना की जा सके; एक ही समय में कई सब्सक्रिप्शन को एकत्रित न करें।
  • हमेशा अंतिम अस्वीकृति कारण का मूल्यांकन करें; ऊपर दिए गए स्किप सूची में कठिन अस्वीकृतियों के लिए पुनः प्रयास रोकें।
  • ग्राहक और प्रति खाता समवर्ती पुनः प्रयासों को सीमित करें ताकि आकस्मिक वृद्धि से बचा जा सके।
  • सक्रिय रूप से संवाद करें: अगले निर्धारित प्रयास से पहले ग्राहक को उनके भुगतान विधि को अपडेट करने के लिए ईमेल/SMS करें।
  • केवल अवलोकन के लिए मेटाडेटा का उपयोग करें (जैसे, retry_attempt); कभी भी धोखाधड़ी/जोखिम प्रणालियों से “बचने” के लिए तुच्छ फ़ील्ड को घुमाने का प्रयास न करें।

वेबहुक के साथ परिणामों को ट्रैक करें

ग्राहक यात्रा को ट्रैक करने के लिए वेबहुक हैंडलिंग लागू करें। वेबहुक लागू करना देखें।
  • subscription.active: जनादेश अधिकृत और सब्सक्रिप्शन सक्रिय
  • subscription.failed: निर्माण विफल (जैसे, जनादेश विफलता)
  • subscription.on_hold: सब्सक्रिप्शन होल्ड पर रखा गया (जैसे, अनपेक्षित स्थिति)
  • payment.succeeded: चार्ज सफल
  • payment.failed: चार्ज विफल
ऑन-डिमांड प्रवाह के लिए, उपयोग-आधारित चार्जों को समायोजित करने के लिए payment.succeeded और payment.failed पर ध्यान केंद्रित करें।

परीक्षण और अगले कदम

1

परीक्षण मोड में बनाएं

अपने परीक्षण API कुंजी का उपयोग करके जनादेश के साथ सब्सक्रिप्शन बनाएं payment_link: true, फिर लिंक खोलें और जनादेश पूरा करें।
2

चार्ज ट्रिगर करें

एक छोटे product_price (जैसे, 100) के साथ चार्ज एंडपॉइंट को कॉल करें और सत्यापित करें कि आपको payment.succeeded प्राप्त होता है।
3

लाइव जाएं

एक बार जब आप घटनाओं और आंतरिक स्थिति अपडेट को मान्य कर लें, तो अपने लाइव API कुंजी पर स्विच करें।

समस्या निवारण

  • 422 अमान्य अनुरोध: सुनिश्चित करें कि निर्माण पर on_demand.mandate_only प्रदान किया गया है और चार्ज के लिए product_price प्रदान किया गया है।
  • मुद्रा त्रुटियाँ: यदि आप product_currency को ओवरराइड करते हैं, तो सुनिश्चित करें कि यह आपके खाते और ग्राहक के लिए समर्थित है।
  • कोई वेबहुक प्राप्त नहीं हुआ: अपने वेबहुक URL और सिग्नेचर गुप्त कुंजी कॉन्फ़िगरेशन की पुष्टि करें.