FunPay पर विक्रेता को खरीदार को क्या देना अनिवार्य है
FunPay पर हारे गए ज्यादातर dispute न fraud होते हैं न खराब माल — वे अधूरी डिलीवरी होते हैं। विक्रेता ने key भेजी पर region नहीं बताया। Account सौंपा पर recovery email भूल गया। Currency ट्रांसफर की पर credit confirm नहीं किया। औपचारिक रूप से प्रोडक्ट चला गया, व्यावहारिक रूप से खरीदार उसे इस्तेमाल नहीं कर सका।
इस लेख में देखेंगे कि हर कैटेगरी में पूरी डिलीवरी में क्या-क्या शामिल है, अधूरापन arbitration लगभग अपने आप क्यों हरा देता है, और विक्रेता को बचाने वाला evidence checklist कैसा दिखता है।
यह FunPay पर बिक्री की मूल गाइड और dispute playbook का अगला हिस्सा है।
मूल सिद्धांत — प्रोडक्ट एक bundle है, string नहीं
नया विक्रेता asset की भाषा में सोचता है: उसने key बेची, तो key देनी है। प्लेटफॉर्म और उसका arbitration नतीजे की भाषा में सोचता है: खरीदार ने खेलने की क्षमता के लिए पैसे दिए, तो उसे activation के लिए जरूरी हर चीज़ मिलनी चाहिए।
इन दोनों मॉडल के बीच का फासला ही वह जगह है जहां पैसा गायब होता है। टेस्ट सीधा है — क्या खरीदार आपसे एक भी अतिरिक्त सवाल पूछे बिना प्रोडक्ट इस्तेमाल कर सकता है? अगर नहीं, तो डिलीवरी अधूरी थी, चाहे आप उसे कुछ भी मानें।
व्यावहारिक नतीजा: हर प्रोडक्ट कैटेगरी का एक अनिवार्य bundle होता है, और उसे पहली बिक्री से पहले template के रूप में तय करना चाहिए, हर ऑर्डर में नए सिरे से गढ़ना नहीं।
कैटेगरी के हिसाब से डिलीवरी की संरचना
| कैटेगरी | अनिवार्य न्यूनतम | आम चूक |
|---|---|---|
| Game key | Code, activation region, platform या launcher | अकेला code भेजना |
| Account | Login, password, linked email, recovery data | Email तक पहुंच नहीं |
| Game currency | Credit confirmation, transaction identifier | Credit का कोई प्रमाण नहीं |
| Subscription या top-up | Code या confirmed credit, wallet region, denomination | Region नहीं बताया |
Keys
पूरा bundle है code, activation region और platform. Region बताए बिना key एक लॉटरी है: दूसरे region का खरीदार activation error पाएगा और वह सही होगा, क्योंकि hand-off के समय यह पाबंदी उसे बताई ही नहीं गई। Platform वहां जरूरी है जहां वही title कई ecosystems में मौजूद है — खरीदार को पता होना चाहिए कि redeem कहां करना है।
अगर activation window है तो उसे अलग से बताएं, साथ में यह भी कि error आने पर क्या होगा। Regional पाबंदियों की मैकेनिक्स region-locked keys वाले लेख में है।
Accounts
यह सबसे चौड़ा bundle है और यहीं सबसे ज्यादा हार होती है। चलता हुआ login और password मालिकाना हक का हस्तांतरण नहीं, अस्थायी पहुंच है। पूरी डिलीवरी में linked email उस तक पहुंच सहित और recovery data शामिल है, वरना खरीदार का asset पर नियंत्रण नहीं और वह उसे कभी भी खो सकता है।
अगर कैटेगरी नियमों के चलते कोई हिस्सा सौंपना असंभव है, तो वह पाबंदी listing में साफ़ लिखी हो और delivery message में दोहराई जाए। यहां चुप्पी विक्रेता के खिलाफ पढ़ी जाती है।
Currency और top-ups
In-game transfer में सौदा भेजने के पल पर नहीं, credit confirmation पर बंद होता है। Transfer के तुरंत बाद अपनी तरफ से भेजा गया screenshot या transaction identifier «सच में आया या नहीं» वाला सवाल खत्म कर देता है। इस कैटेगरी की बारीकियां FunPay पर game currency बेचने की गाइड में हैं।
अधूरी डिलीवरी dispute क्यों हराती है
प्लेटफॉर्म arbitration आपकी नीयत दोबारा नहीं गढ़ता और आपकी नेकनीयती नहीं आंकता। वह दो चीज़ों की तुलना करता है: listing ने क्या वादा किया और chat में खरीदार तक असल में क्या पहुंचा। इन दो बिंदुओं के बीच की हर चीज़ — आपका अनुभव, आपकी साख, आपके supplier पर आपका भरोसा — का सबूत के तौर पर लगभग कोई वजन नहीं।
तीन व्यावहारिक नतीजे निकलते हैं:
- Composition का फर्क तुरंत दिखता है। अगर listing में region लिखा है और delivery message में नहीं, तो यह सेकंडों में दिखता है और non-performance माना जाता है।
- चुप्पी गलती से भी बुरी है। शिकायत के एक मिनट बाद छूटा हिस्सा भेजने वाला विक्रेता आमतौर पर मामला बंद कर लेता है। एक दिन बाद जवाब देने वाला पहले ही हार चुका है।
- बाहरी channels गिने नहीं जाते। Messenger से भेजा डेटा arbitration के लिए लगभग मौजूद ही नहीं है, और साथ ही यह प्लेटफॉर्म नियमों का उल्लंघन है — देखें नियम और bans वाला लेख।
Delivery evidence checklist
आपका सबूत बिक्री के पल पर खुद बनना चाहिए। शिकायत के बाद इकट्ठा करना मतलब आप पहले ही देर कर चुके। प्रति ऑर्डर न्यूनतम:
- सटीक hand-off timestamp, जिसे payment time से मिलाया जा सके।
- Delivery message का पूरा text, ठीक उसी रूप में जैसा खरीदार को मिला।
- उस विशेष unit का identifier — इस ऑर्डर में कौन सा code या कौन सा transaction गया।
- Supplier confirmation कि transfer के समय validity, region और platform क्या थे।
- प्लेटफॉर्म chat का पूरा पत्राचार, आपके स्पष्टीकरण वाले सवालों समेत।
यहां अनुशासन से ज्यादा automation काम आता है: सेट किया गया auto-delivery log खुद बनाता है और हर ऑर्डर में bundle एक जैसा रखता है। इसे कैसे सेट करें, यह FunPay auto-delivery setup गाइड में है।
Delivery template एक operational उपकरण के तौर पर
सबसे सस्ता सुधार है हर कैटेगरी के लिए एक तय template, जिसे operator गढ़ता नहीं, भरता है। Template में हर अनिवार्य field, छोटा activation निर्देश, और activation fail होने पर क्या करें — एक लाइन।
तीन असर होते हैं: composition operator के मूड पर निर्भर करना बंद कर देती है, जवाब की रफ्तार बढ़ती है, और arbitration में आप सारांश नहीं, सटीक text पेश करते हैं। Scaling की दिक्कत भी हटती है — नया कर्मचारी पहले दिन से template पर काम करता है।
जब पूरा bundle सौंपना संभव ही न हो
स्थितियों का एक अलग वर्ग है जहां कुछ डेटा वाकई सौंपा नहीं जा सकता — कैटेगरी नियम, platform पाबंदियां या supplier की शर्तें इसकी इजाजत नहीं देतीं। यह सामान्य है और इससे आप बेईमान नहीं हो जाते। बेईमान आप इस पर चुप रहने से होते हैं।
काम करने वाला तरीका तीन चरणों का है, और इनमें से कोई भी छोड़ना आपको वापस जोखिम क्षेत्र में ले आता है:
- पाबंदी listing में साफ़ शब्दों में लिखी हो, इशारे में नहीं। «recovery data नहीं दिया जाएगा» जैसी बात भुगतान से पहले विवरण में होनी चाहिए, बाद की chat में नहीं।
- पाबंदी delivery message में दोहराई जाए। जिस खरीदार ने इसे दो बार देखा हो, वह यह दावा नहीं कर सकता कि उसे पता नहीं था।
- नतीजे बताए जाएं। खरीदार ठीक क्या नहीं कर पाएगा और कोशिश करने पर क्या होगा — यह आगे आने वाली आधी शिकायतें हटा देता है।
अलग से यह भी जांचें कि पाबंदी खुद प्लेटफॉर्म नियमों से टकराती तो नहीं। कुछ कैटेगरी एक न्यूनतम हस्तांतरण अनिवार्य करती हैं, और जो listing वह नहीं देती वह moderation में अटक सकती है या दंड झेल सकती है। असल में दंडनीय क्या है, यह नियम और bans वाले लेख में है।
व्यावहारिक कसौटी: अगर कोई पाबंदी इतनी बड़ी है कि आप उसे विवरण में लिखना नहीं चाहते, तो listing छापें ही नहीं। जो प्रोडक्ट सिर्फ चुप्पी के दम पर बिकता है, वह मुनाफे से ज्यादा तेज़ी से dispute देता है।
Stock कहां से लें ताकि bundle पूरा रहे
डिलीवरी की पूर्णता आपसे नहीं, आपके supplier से शुरू होती है: अगर वह code के साथ region और platform नहीं देता, तो आप खरीदार को वे बता ही नहीं सकते। इसलिए खरीद में कीमत जितना ही जरूरी है प्रति unit मिलने वाला data set.
FoxReload समस्या का यही हिस्सा संभालता है: 900+ SKU का catalog जिसमें multi-region items हैं, एक single REST API, और automatic delivery जहां region और platform code के साथ ही आते हैं — यानी आपका delivery template बिना manual खोजबीन के भर जाता है। थोक channel चुनने पर और जानकारी digital-goods थोक suppliers के विश्लेषण में है।