Plati.market पर सेल और डिलीवरी कैसे होती है
खरीदार के लिए डिजिटल स्टोरफ्रंट पर सेल एक क्लिक जैसी दिखती है, पर सेलर के लिए यह छह-सात स्थितियों की श्रृंखला है, जिनमें से हर एक में कुछ गलत हो सकता है। नीचे पूरा ऑर्डर लाइफसाइकिल है — पेमेंट से लेकर guarantee window बंद होने तक — इस ब्योरे के साथ कि हर स्टेप पर सेलर को असल में क्या दिखता है और आम डिलीवरी खराबियाँ कैसे ठीक होती हैं।
अगर आपने अभी लॉन्च नहीं किया, तो पहले प्रोडक्ट कार्ड बनाना देखें।
कौन क्या करता है: इंजन बनाम स्टोरफ्रंट
पूरी मैकेनिक की चाबी है Digiseller और Plati.market के बीच ज़िम्मेदारियों का बँटवारा। Digiseller इंजन है — यह पेमेंट स्वीकार करता है, लिस्टिंग और कोड पूल स्टोर करता है, डिलीवरी करता है, सेलर बैलेंस रखता है और शिकायतें संभालता है। Plati.market उसी इंजन के ऊपर स्टोरफ्रंट है — सर्च, कैटेगरी, रिव्यू, प्रोडक्ट पेज।
सेलर के लिए इसका व्यावहारिक नतीजा सीधा है। अगर डिलीवरी टूटी है तो उसे इंजन के डैशबोर्ड में ठीक करें, स्टोरफ्रंट सेटिंग्स में नहीं। और उलटा — अगर प्रोडक्ट सर्च में नहीं मिल रहा, तो दिक्कत लिस्टिंग की प्रस्तुति में है, ऑटो-डिलीवरी कॉन्फ़िग में नहीं। सपोर्ट में बर्बाद होने वाला आधा समय गलत लेयर पर गलती ढूँढ़ने में जाता है।
ऑर्डर लाइफसाइकिल, स्टेज दर स्टेज
| स्टेज | क्या होता है | सेलर को क्या दिखता है | कहाँ टूटता है |
|---|---|---|---|
| लिस्टिंग व्यू | खरीदार प्रोडक्ट खोलता है | सिर्फ़ व्यू काउंटर | region और platform नहीं बताए गए |
| चेकआउट | खरीदार पेमेंट मेथड चुनता है | कुछ नहीं | उस खरीदार के लिए मेथड उपलब्ध नहीं |
| पेमेंट | भुगतान क्लियर और कन्फर्म होता है | ऑर्डर paid दिखता है | प्रोसेसर डिक्लाइन, धीमा कन्फर्मेशन |
| इशू | इंजन पूल या external source से यूनिट लेता है | ऑर्डर delivered स्थिति में जाता है | खाली पूल, source API error, timeout |
| प्राप्ति | खरीदार कोड और निर्देश देखता है | ऑर्डर delivered चिह्नित | कोड अपठनीय, निर्देश गायब |
| Redemption | खरीदार प्लेटफ़ॉर्म पर कोड भुनाता है | सब ठीक हो तो कुछ नहीं | ग़लत region, कोड पहले से redeem |
| Guarantee window | शिकायत की खिड़की खुली | ऑर्डर अभी अंतिम नहीं | शिकायत, dispute, पैसे का reversal |
| क्लोज़ | guarantee खत्म | कमाई पक्की मानी जाती है | — |
टेबल जो दिखाती है वह यह है कि सेलर पूरी प्रक्रिया नहीं देखता। इशू और redemption के बीच एक blind spot है जहाँ खरीदार के पास कोड आ चुका है पर उसने अभी पुष्टि नहीं की कि वह काम करता है। हर dispute इसी blind spot में जन्म लेता है, और इसीलिए आपके कोड source की गुणवत्ता किसी भी स्टोरफ्रंट सेटिंग से ज़्यादा मायने रखती है।
इशू के समय असल में क्या होता है
तकनीकी रूप से इशू ही वह इकलौता स्टेप है जो सचमुच आपके नियंत्रण में है, और यह दो मोड में चलता है।
पूल से डिलीवरी। आप पहले से कोड की सूची लिस्टिंग में अपलोड कर देते हैं। पेमेंट होते ही इंजन अगली खाली यूनिट उठाता है, उसे used चिह्नित करता है और खरीदार को दे देता है। तेज़ है, पर पूल सीमित है — और वह रात में खत्म होता है।
External source से डिलीवरी। पेमेंट पर लिस्टिंग आपके बैकएंड या सप्लायर API को कॉल करती है और ऑर्डर के समय कोड लेती है। जब तक सप्लायर के पास स्टॉक है, पूल व्यावहारिक रूप से असीमित है। इसके लिए चालू endpoint, समझदार timeout और कॉल फेल होने पर तय fallback व्यवहार चाहिए। मैकेनिक विस्तार से डिजिटल कोड डिलीवरी के ऑटोमेशन में है।
Webhooks पर एक नोट। कुछ सप्लायर ऑर्डर-स्टेटस नोटिफ़िकेशन push करते हैं, कुछ सिर्फ़ शेड्यूल्ड polling देते हैं। यह कोई सार्वभौमिक मानक नहीं है, इसलिए callbacks के इर्द-गिर्द डिलीवरी लॉजिक डिज़ाइन करने से पहले जाँचें कि आपका विशिष्ट सप्लायर इन्हें सचमुच लागू करता है या नहीं, और callback न आने पर क्या होता है। समझदार अंतराल वाली polling उन webhooks की सुंदर आर्किटेक्चर से ज़्यादा भरोसेमंद है जो मौजूद ही नहीं हैं।
Guarantee window, शिकायत और dispute
कोड मिलते ही guarantee window खुलती है — वह अवधि जिसमें खरीदार खराब आइटम की रिपोर्ट कर सकता है। इसकी लंबाई हर लिस्टिंग पर सेट होती है और प्लेटफ़ॉर्म अपने नियमों में बाहरी सीमाएँ तय करता है; कुछ भी कॉन्फ़िगर करने से पहले मौजूदा अनुमत मान जाँच लें।
सेलर के लिए इसका व्यावहारिक अर्थ यह है कि इस window के भीतर का पैसा अभी आपका नहीं है। जब तक guarantee खुली है, ऑर्डर शिकायत में, शिकायत dispute में और dispute रिफंड में बदल सकता है। जिस कमाई की guarantee बंद नहीं हुई, उससे अगली खरीद फंड करना कैश गैप तक पहुँचने का जाना-पहचाना रास्ता है।
शिकायत का क्रम ऐसा चलता है — खरीदार समस्या बताता है, सेलर जवाब देता है, और दोनों या तो निपटारा कर लेते हैं या प्लेटफ़ॉर्म arbitration तक जाते हैं। नतीजा लगभग हमेशा दो चीज़ें तय करती हैं — जवाब की रफ़्तार और सबूत। जो सेलर मिनटों में जवाब देकर replacement देता है, वह उलझे केस भी जीत जाता है। जो एक दिन चुप रहता है, वह सही होकर भी हार जाता है।
रिफंड या replacement
Replacement लगभग हमेशा बेहतर है। रिफंड में आइटम, कमाई और लिस्टिंग पोज़िशन तीनों जाते हैं; replacement में सिर्फ़ एक यूनिट की लागत जाती है और बाकी सब बच जाता है। इसलिए काम का नियम सीधा है — replacement के लिए अलग से रिज़र्व स्टॉक रखें, यह मानकर मत चलिए कि उन्हें अगली खरीद से कवर कर लेंगे।
रिफंड वहाँ सही है जहाँ आप वस्तुनिष्ठ रूप से चालू आइटम दे ही नहीं सकते — जैसे regional restriction खरीद के बाद सामने आया और उस region का वर्ज़न आपके पास नहीं है। वहाँ तेज़ स्वैच्छिक रिफंड हारे हुए dispute से सस्ता है, क्योंकि वह अकाउंट हिस्ट्री पर नकारात्मक निशान नहीं छोड़ता। पेमेंट लेयर भी ध्यान में रखें — कुछ reversals प्लेटफ़ॉर्म dispute से नहीं, खरीदार के बैंक से आते हैं, और उस मोड़ पर आपकी दलीलें कोई नहीं सुनता।
चार खराबियाँ और उनसे उबरना
खाली पूल
लक्षण: ऑर्डर pending लटके रहते हैं या लिस्टिंग error देती है। पहचान: शून्य पर नहीं, stock threshold पर अलर्ट रखें — चेतावनी घटना से पहले आनी चाहिए। रिकवरी: लिस्टिंग हटाएँ, खुले ऑर्डर वैकल्पिक source से मैनुअली पूरे करें, स्टॉक बहाल करें। स्थायी रूप से मैनुअल पूल की जगह external source लाएँ। देखें सप्लायर स्टॉकआउट से रिकवरी।
दो बार इशू हुआ डुप्लिकेट कोड
लक्षण: दूसरे खरीदार को पहले से इस्तेमाल हुई यूनिट मिलती है। यह आमतौर पर डुप्लिकेट वाली मैनुअल अपलोड, या साझा हिसाब के बिना समानांतर चल रहे दो sources का नतीजा होता है। पहचान: अपलोड से पहले सूची deduplicate करें और इशू हुई यूनिट्स को ऑर्डर लॉग से मिलाएँ। रिकवरी: तुरंत replacement और पूरे batch का ऑडिट, सिर्फ़ शिकायत वाली यूनिट का नहीं।
ग़लत region
लक्षण: कोड तकनीकी रूप से वैध होते हुए भी खरीदार को activation error मिलता है। यह खराब आइटम नहीं, बल्कि लिस्टिंग region और खरीदार के region का बेमेल है। पहचान: region शीर्षक में लिखें, विवरण के आख़िर में नहीं। रिकवरी: उस region का वर्ज़न हो तो बदल दें, वरना रिफंड। विस्तार से — region-locked keys की व्याख्या।
सप्लाई चेन में पहले ही redeem हो चुका कोड
लक्षण: आपने कोड पहली बार इशू किया, फिर भी प्लेटफ़ॉर्म उसे used बताता है। यह सप्लायर-साइड संकेत है — batch दो बार बिका, revocation हुआ, या source शुरू से ही संदिग्ध था। पहचान: कम समय में एक ही खरीद से कई शिकायतें। रिकवरी: और शिकायतें आने से पहले उस पूरे batch की बिक्री रोकें, इशू हो चुकी यूनिट्स बदलें और सप्लायर के सामने दावा रखें। बड़े पैमाने के revocation के लिए देखें कोड revocation और region locks संभालना।
स्टॉक कहाँ से लें ताकि डिलीवरी टूटना बंद हो
ऊपर की ज़्यादातर खराबियाँ प्लेटफ़ॉर्म की नहीं, source की समस्याएँ हैं। FoxReload ठीक इसी लेयर को कवर करता है — 900+ SKU का थोक कैटलॉग (गेम कीज़, गिफ्ट कार्ड, इन-गेम करेंसी टॉप-अप, eSIM, सब्सक्रिप्शन, सॉफ़्टवेयर लाइसेंस), instant delivery, multi-region SKUs और एक single REST API जिसे आपकी लिस्टिंग ऑर्डर के समय कॉल करती है। पूल सीमित रहना बंद कर देता है, और रात के स्टॉकआउट व कैंसिलेशन रोज़मर्रा नहीं रह जाते।