GGsel Seller API — automation के विकल्प
GGsel की storefront हाथ से चलाना लगभग सौ SKU पर छत छू लेता है — stock खिसकता है, कीमतें बासी हो जाती हैं, और रात तीन बजे code का इंतज़ार करता buyer इस बात से अनजान है कि आप सो रहे थे। यहाँ automation architecture की सुंदरता का मामला नहीं है, बल्कि इस बात का है कि हर मानवीय देरी की क़ीमत पैसे और rating में न चुकानी पड़े। देखते हैं असल में क्या automate होता है, programmatic layer कहाँ रहता है, कौन-सा architecture चुनें, और किन failures का इंतज़ाम पहले से करना ज़रूरी है।
लेख तकनीकी है पर बिना पूर्व integration अनुभव के भी पढ़ा जा सकता है। बिल्कुल शुरुआत में हों तो पहले API quickstart पढ़ें।
API असल में कहाँ रहता है
Storefront के रूप में GGsel Digiseller infrastructure पर बैठता है — वही layer payment acceptance, product cards और digital goods की automatic delivery संभालता है। व्यावहारिक रूप से इसका मतलब है कि seller की programmatic क्षमताएँ उसी layer से तय होती हैं, किसी अलग GGsel API product से नहीं।
पहला नियम यहीं से निकलता है — forum posts और blog लेखों से integration design न करें। Method sets, authentication और rate limits बदलते हैं। Build शुरू करने से पहले, और उनकी तरफ़ किसी बड़े release के बाद, platform की मौजूदा documentation से मिलान करें।
दूसरा नियम — एक SKU से शुरू करें। एक ही product पर पूरा cycle (order, delivery, status, dispute) हज़ार items के catalogue migration से कहीं सस्ते में हर bottleneck दिखा देता है।
क्या automate करना सार्थक है
Stock synchronisation
सबसे ज़्यादा return देने वाली automation। जो चीज़ आपके पास नहीं है उसे बेचना यानी dispute, refund और rating पर चोट। Logic सीधा है — supplier का stock बदलता है, आपका middleware marketplace पर availability update करता है। व्यवहार में:
- Items पहले हटाएँ, शून्य पर नहीं — buffer रखें।
- out of stock और connection failure में फ़र्क़ करें। Supplier timeout पर listing छिपाना उस चीज़ को बेचने से बेहतर है जो आप पूरी नहीं कर सकते।
- हर बदलाव log करें — dispute की समीक्षा में यही history काम आएगी।
Price synchronisation
लागत बदलती है, retail को पीछे चलना चाहिए। Automation cost से price निकालती है, marketplace fee, payment processing और withdrawal लागत जोड़कर — असली दरें platform के मौजूदा tariff page से लें, क्योंकि वे बदलती हैं और उन्हें code में constant की तरह कभी नहीं रखना चाहिए। Margin floor हमेशा लगाएँ: computed price न्यूनतम व्यवहार्यता से नीचे जाए तो item हटे, घाटे में बिके नहीं। तरीक़ा reseller unit economics में है।
Codes की auto-delivery
दो तरीक़े:
| तरीक़ा | कैसे काम करता है | फ़ायदा | नुकसान |
|---|---|---|---|
| Uploaded pool | Codes पहले से card में load | सरल, आपकी service से स्वतंत्र | Manual topping up, ख़ाली होने का जोखिम |
| External issuance | Payment पर आपके middleware से code | एक pool सभी marketplaces के लिए | Service की उच्च availability चाहिए |
व्यवहार में hybrid आम है — सुरक्षा के लिए छोटा buffer pool और मुख्य रास्ता external issuance। सामान्य सिद्धांत digital code delivery की automation में हैं।
Order status
Payment, delivery, dispute, refund — हर event बिना dashboard खोले आपके सिस्टम में आना चाहिए। यही support और financial reconciliation दोनों की नींव है।
Architecture — supplier, middleware, marketplace
टिकने वाला एकमात्र pattern यही है:
Supplier API → आपका middleware → marketplace
Middleware आपकी service है। इसमें normalised catalogue, supplier SKUs और marketplace cards की mapping, pricing rules, order journal और event queue रहते हैं।
Supplier को सीधे marketplace से क्यों नहीं जोड़ सकते:
- एक journal नहीं होता। Dispute में आप साबित नहीं कर सकते कि किस order पर कौन-सा code गया।
- Pricing rules की जगह नहीं। Markup, margin floor और rounding कहीं रह ही नहीं सकते।
- Multi-marketplace रास्ता नहीं। दूसरी storefront पर वही काम दोबारा करना पड़ेगा।
- Failure control नहीं। Retries, idempotency और graceful degradation सिर्फ़ आपकी तरफ़ बन सकते हैं।
कई sources हों तो routing भी जुड़ता है — किसी order पर कौन-सा supplier उस SKU को पूरा करेगा। यह अलग विषय है, देखें multi-source fulfilment routing।
Idempotency — अनिवार्य न्यूनतम
Network responses खोता है; marketplaces और suppliers retry करते हैं। सुरक्षा के बिना दोहराया गया issuance request दूसरा code जला देता है — buyer को एक मिलता है और आप दो के पैसे देते हैं।
काम करने वाला contract:
- हर marketplace order आपके सिस्टम में एक stable idempotency key से जुड़ा हो।
- Supplier को जाने वाले सभी requests वही key ले जाएँ।
- Middleware issuance result सहेजे और repeat पर supplier को दोबारा call किए बिना वही code लौटाए।
- Key इतनी देर जिए कि कोई भी उचित retry window पार कर सके।
Edge cases और आम ग़लतियाँ idempotency keys deep dive में हैं।
Webhooks — events कैसे न खोएँ
नियम सरल हैं और लगभग हमेशा तोड़े जाते हैं:
- किसी भी processing से पहले signature verify करें।
- तेज़ acknowledge करें — accept, enqueue, success लौटाएँ। Handler के अंदर synchronous logic timeouts और retry storm देती है।
- Delivery को unordered और non-guaranteed मानें। Event ID store करें, duplicates गिराएँ, sequence पर भरोसा न करें।
- सुरक्षा के तौर पर API reconciliation job रखें — periodic status polling वह पकड़ लेता है जो छूट गया।
पूरी चर्चा webhook integration में है।
जिन failure modes के लिए design करना ज़रूरी है
| Failure | क्या होता है | उपाय |
|---|---|---|
| Supplier stockout | Order paid, code उपलब्ध नहीं | Fallback source, auto-delist, तैयार buyer message |
| Issuance timeout | पता नहीं code ख़र्च हुआ या नहीं | Idempotent retry, फिर key से reconcile |
| Duplicate webhook | Order दो बार process | Event ID पर deduplication |
| Price drift | लागत से नीचे बिक्री | Margin floor और automatic delisting |
| Code revocation | Delivery के बाद dispute | Issuance journal, supplier को warranty claim |
इनमें से कोई भी असामान्य नहीं है — ये नियमित रूप से होते हैं, और शांत तथा तकलीफ़देह business का फ़र्क़ बस इतना है कि handler पहले से लिखा था या नहीं। Stockout recovery अलग से supplier stockout recovery में है।
Inventory feed कहाँ से आती है
Automation तभी फल देती है जब नीचे predictable programmatic interface वाला supplier हो। FoxReload ठीक यही सतह देता है — games, gift cards, top-ups, eSIM और software में 900+ SKU, auto-delivery वाला एक REST API और multi-region SKUs — दर्जन भर manual channels की जगह एक source जिससे आपका middleware जुड़ता है। Source चुनने और लिखित में क्या माँगें, इसके लिए देखें GGsel sellers game keys कहाँ से लाते हैं।
और ज़रूरी बात दोहरा दें — platform के methods, limits और requirements बदलते हैं। Build करने से पहले Digiseller की मौजूदा documentation और GGsel के नियम जाँचें, पुरानी integration बिना जाँचे आगे मत बढ़ाइए।