Digiseller API: पेमेंट और डिलीवरी का ऑटोमेशन
Digiseller पहले पेमेंट और ऑटो-डिलीवरी इंजन है, स्टोरफ़्रंट बाद में। रीसेलर के लिए इसकी असली वैल्यू तभी बनती है जब प्रोडक्ट कार्ड को कोई इंसान या अपलोड की गई टेक्स्ट फ़ाइल नहीं, बल्कि आपकी अपनी सर्विस सर्व करती है — जो पेमेंट आते ही wholesale सप्लायर को कॉल करके काम करने वाला कोड लौटा देती है। यह लेख बताता है कि ऐसा इंटीग्रेशन कैसे बनता है, कहाँ टूटता है और उसे कैसे ठीक करें।
अगर आपने अभी तक इस प्लेटफ़ॉर्म पर काम नहीं किया, तो बेसिक्स से शुरू करें — Digiseller पर डिजिटल सामान बेचना।
Digiseller API किन हिस्सों में बँटा है
API कुछ अर्थपूर्ण ब्लॉक्स में बँटता है। मेथड नाम और पैरामीटर मौजूदा documentation से मिलाएँ — नीचे लॉजिक है, signature लिस्ट नहीं।
| ब्लॉक | क्या करता है | रीसेलर को क्यों चाहिए |
|---|---|---|
| Authentication | seller ID और signed request के बदले अस्थायी token | बाक़ी हर कॉल इसी पर निर्भर है |
| Products | कार्ड, क़ीमत, विवरण, उपलब्धता बनाना और बदलना | अपने सिस्टम से bulk price update |
| Orders | ऑर्डर नंबर या बायर के unique code से सेल जानकारी | पेमेंट असली है यह पुष्टि करना |
| Fulfilment | बायर को कंटेंट देना और ऑर्डर delivered मार्क करना | सौदा बंद करता है और विवाद घटाता है |
| Operations | सेलर अकाउंट का बैलेंस और मनी मूवमेंट | reconciliation और असली margin |
एक buyer-messaging ब्लॉक भी है। वह बिक्री को ऑटोमेट नहीं करता, पर सपोर्ट बनाने में काम आता है।
Token स्थिर नहीं होता
Token expire होता है और request आपके secret तथा timestamp पर hash से sign होती है। व्यावहारिक नतीजा — हर कॉल पर नया token मत माँगिए और एक token को हमेशा के लिए cache भी मत कीजिए। सही तरीक़ा है token को expiry के साथ स्टोर करना, ख़त्म होने से एक-दो मिनट पहले refresh करना, और expired-authorisation रिस्पॉन्स मिलने पर ठीक एक बार forced re-auth करना।
पेमेंट से डिलीवरी तक, क़दम दर क़दम
आपके backend की नज़र से पूरी चेन इस तरह दिखती है।
- बायर पेमेंट करता है Digiseller स्टोरफ़्रंट या Plati.Market पर। पैसा प्लेटफ़ॉर्म के पास होल्ड रहता है, अभी अंतिम रूप से आपका नहीं है।
- प्लेटफ़ॉर्म सेल की सूचना देता है। या तो आपके URL पर notification आता है, या आपकी सर्विस ऑर्डर के हिसाब से API poll करती है। Notification तेज़ है, polling भरोसेमंद — व्यवहार में दोनों चाहिए।
- आप authenticity जाँचते हैं। notification body पर अकेले भरोसा न करें: ऑर्डर नंबर से API को वापस कॉल करें और पुष्टि करें कि सेल मौजूद है, राशि मेल खाती है और प्रोडक्ट वही है।
- अपने डेटाबेस में ऑर्डर देखें। रिकॉर्ड मौजूद है और कोड जारी हो चुका है, तो वही कोड लौटाएँ। नहीं है तो
pendingस्टेटस के साथ नया रिकॉर्ड बनाएँ। - wholesale सोर्स को कॉल करें। आपकी सर्विस mapped SKU पर सप्लायर को ऑर्डर देती है और कोड पाती है।
- कंटेंट बायर को दें और प्लेटफ़ॉर्म पर ऑर्डर delivered मार्क करें।
- नतीजा वापस लिखें — कोड, purchase cost, सप्लायर order ID, timestamp।
क़दम 4 और 7 ही सबसे ज़्यादा छोड़े जाते हैं, और यही डेमो को सिस्टम बनाते हैं। State लॉजिक विस्तार से यहाँ है — API order flow कैसे काम करता है।
प्रोडक्ट कार्ड के पीछे upstream सप्लायर
विचार सीधा है: प्लेटफ़ॉर्म का कार्ड शो-विंडो है, गोदाम wholesaler के पास है। बिक्री के क्षण पर आपका middleware प्लेटफ़ॉर्म SKU को सप्लायर SKU में बदलता है, ऑर्डर देता है और कोड लौटाता है।
इसके लिए क्या चाहिए:
- Mapping table. एक प्लेटफ़ॉर्म प्रोडक्ट = एक सप्लायर प्रोडक्ट, साथ में region और denomination। activation region साफ़ न हो तो refund की धारा बन जाती है।
- बिक्री से पहले availability check. सप्लायर स्टॉक poll करें और ख़त्म होने पर आइटम बिक्री से हटाएँ — पेड ऑर्डर कैंसिल करने से बहुत सस्ता है।
- Fallback सोर्स. टॉप SKU पर दूसरा सप्लायर अधिकांश stockout जोखिम हटा देता है।
- Cost-price कंट्रोल. थोक क़ीमतें बदलती हैं; storefront अपडेट न करें तो आप कुछ समय लागत से नीचे बेचते रहेंगे।
Idempotency header में नहीं, आपके डेटाबेस में रहती है
सबसे महँगी ग़लती है एक ही सेल के लिए दो बार कोड ख़रीद लेना। कारण साधारण हैं — प्लेटफ़ॉर्म का दोहराया notification, सप्लायर कॉल पर timeout, worker restart।
यह मत मानिए कि सप्लायर की तरफ़ का idempotency header आपको बचा लेगा। उदाहरण के लिए FoxReload API में Idempotency-Key header है ही नहीं — दोहराया POST दूसरा ऑर्डर बना देगा। इसके बजाय यह पैटर्न काम करता है:
- सप्लायर को कॉल करने से पहले अपने डेटाबेस में intent लिखें — platform sale ID, SKU, timestamp, status
pending; - किसी भी अस्पष्ट error (timeout, connection drop, 5xx) पर पहले status check करें — सप्लायर के हालिया ऑर्डर लाएँ और SKU व समय से अपना ढूँढें;
- नया ऑर्डर तभी बनाएँ जब पुष्टि हो जाए कि पिछला बना ही नहीं;
- अपनी table में platform sale ID पर unique index आख़िरी रक्षा-पंक्ति है।
पूरा पैटर्न यहाँ है — idempotency keys और सुरक्षित retry।
Retry और queue
Error को वर्ग में बाँटें और हर वर्ग पर अलग प्रतिक्रिया दें।
| रिस्पॉन्स | मतलब | कार्रवाई |
|---|---|---|
| Network timeout | पता नहीं request पहुँची या नहीं | status check, फिर फ़ैसला |
| 401 / 403 | token expire या scope कम | token refresh, एक retry |
| 400 / 422 | request ग़लत बनी है | retry नहीं, लॉग करें |
| 404 | ऐसा SKU या ऑर्डर नहीं | retry नहीं, आइटम बिक्री से हटाएँ |
| 429 | rate limit | limit header के अनुसार रुकें, फिर retry |
| 5xx | upstream समस्या | exponential backoff, सीमित attempts |
Backoff बढ़ता रखें और थोड़ा jitter डालें, वरना सप्लायर के ठीक होते ही आपके सारे worker एक लहर में टूट पड़ेंगे। Attempt count सीमित रखें: जो ऑर्डर उचित समय में सेटल न हो वह manual queue में जाना चाहिए, अनंत लूप में नहीं।
Reconciliation ही मुनाफ़े को भ्रम से अलग करती है
Reconciliation के बिना ऑटोमेशन सुंदर पर ग़लत तस्वीर बनाता है। रोज़ का न्यूनतम सेट:
- प्लेटफ़ॉर्म सेल्स बनाम आपके ऑर्डर. हर सेल के सामने ठीक एक सप्लायर ऑर्डर होना चाहिए।
- सप्लायर ऑर्डर बनाम डिलीवर किए गए कोड. ख़रीदा पर डिलीवर न हुआ कोड शुद्ध नुक़सान और भावी विवाद है।
- पैसा. प्लेटफ़ॉर्म रेवेन्यू माइनस प्लेटफ़ॉर्म फ़ीस माइनस लागत माइनस withdrawal फ़ीस — यही margin है।
- अटके ऑर्डर. जो भी N मिनट से ज़्यादा
pendingमें है, रिपोर्ट में जाए।
अंतर हमेशा रहेंगे। अहम यह है कि वे अपने-आप पकड़े जाएँ, बायर की शिकायत से नहीं।
इस सेटअप के लिए स्टॉक कहाँ से लें
पूरा डिज़ाइन उतना ही अच्छा है जितना कार्ड के पीछे बैठा सोर्स। FoxReload का थोक कैटलॉग यही भूमिका निभाता है: गेम keys, gift cards, top-up और subscriptions में 900+ SKU, दर्जनों बिखरे सप्लायर के बजाय एक REST API और ऑटोमैटिक डिलीवरी। इससे आप Digiseller स्टोरफ़्रंट के पीछे एक ही इंटीग्रेशन लेयर रख पाते हैं और हर बार सप्लायर बदलने पर कोड दोबारा नहीं लिखना पड़ता।
संबंधित सामग्री: डिजिटल कोड डिलीवरी का ऑटोमेशन, ऑर्डर webhooks और Digiseller में SBP जोड़ना।