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

अवलोकन

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

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

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

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

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

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

एंडपॉइंट: POST /subscriptions मुख्य अनुरोध फ़ील्ड (शरीर):
product_id
string
आवश्यक
सब्सक्रिप्शन के लिए उत्पाद ID।
quantity
integer
आवश्यक
इकाइयों की संख्या। न्यूनतम 1।
billing
object
आवश्यक
ग्राहक के लिए बिलिंग पता।
customer
object
आवश्यक
या तो एक मौजूदा ग्राहक को संलग्न करें या ग्राहक विवरण प्रदान करें।
यदि सत्य है, तो आदेश अधिकृत करने और वैकल्पिक प्रारंभिक भुगतान के लिए एक होस्टेड चेकआउट लिंक बनाता है।
return_url
string
होस्टेड चेकआउट पूरा करने के बाद ग्राहक को पुनर्निर्देशित करने के लिए।
on_demand.mandate_only
boolean
आवश्यक
यदि सत्य है, तो निर्माण के दौरान ग्राहक को चार्ज किए बिना भुगतान विधि को अधिकृत करता है।
on_demand.product_price
integer
प्रारंभिक चार्ज राशि (सबसे छोटे मुद्रा इकाई में)। यदि निर्दिष्ट किया गया है, तो यह मान उत्पाद निर्माण के दौरान सेट की गई उत्पाद की मूल कीमत को ओवरराइड करता है। यदि छोड़ा गया, तो उत्पाद की संग्रहीत कीमत का उपयोग किया जाता है। उदाहरण: $1.00 चार्ज करने के लिए, 100 पास करें।
on_demand.product_currency
string
प्रारंभिक चार्ज के लिए वैकल्पिक मुद्रा ओवरराइड। उत्पाद मुद्रा पर डिफ़ॉल्ट।
on_demand.product_description
string
बिलिंग और लाइन आइटम के लिए वैकल्पिक विवरण ओवरराइड।
on_demand.adaptive_currency_fees_inclusive
boolean
यदि सत्य है, तो product_price के भीतर अनुकूलनात्मक मुद्रा शुल्क शामिल हैं। यदि गलत है, तो शुल्क ऊपर जोड़े जाते हैं। अनुकूलनात्मक मूल्य निर्धारण अक्षम होने पर अनदेखा किया जाता है।

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

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.subscriptions.create({
    billing: { city: 'SF', country: 'US', state: 'CA', street: '1 Market St', zipcode: '94105' },
    customer: { customer_id: 'customer_123' },
    product_id: 'prod_sub_123',
    quantity: 1,
    payment_link: true,
    return_url: 'https://example.com/billing/success',
    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,
    },
  });

  // If payment_link was true, redirect the customer to authorize the mandate
  console.log(subscription.payment_link);
}

main().catch(console.error);
payment_link: true सेट करें, ग्राहक को आदेश अधिकृत करने के लिए payment_link पर पुनर्निर्देशित करें।
Success
{
  "subscription_id": "sub_123",
  "payment_link": "https://pay.dodopayments.com/checkout/...",
  "customer": { "customer_id": "customer_123", "email": "[email protected]", "name": "Alex Doe" },
  "metadata": {},
  "recurring_pre_tax_amount": 0,
  "addons": []
}

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

आदेश अधिकृत होने के बाद, आवश्यकतानुसार चार्ज बनाएं। एंडपॉइंट: 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,
  environment: 'test_mode', // defaults to 'live_mode'
});

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 और हस्ताक्षर गुप्त कुंजी कॉन्फ़िगरेशन की पुष्टि करें.