FunPay सेलर नियम: किन वजहों से अकाउंट ब्लॉक होता है और क्या जोखिम हैं
FunPay पर ban शायद ही कभी अचानक आता है — वह लगभग हमेशा कुछ गिनी-चुनी दोहराई जाने वाली श्रेणियों में फिट बैठता है। इस लेख में enforcement की मैकेनिक्स है: प्लेटफॉर्म किन कामों को उल्लंघन मानता है, गेम पब्लिशर्स की अपनी ToS मार्केटप्लेस नियमों के ऊपर कैसे लागू होती है, और seller अकाउंट को लंबे समय तक जिंदा रखने के लिए व्यावहारिक रूप से क्या करना है। कोई "आसान कमाई" का वादा नहीं, और policy की exact wording का हवाला भी नहीं — वह बदलती रहती है और उसे स्रोत पर ही जांचना चाहिए।
यह हमारे बेसिक FunPay पर बेचने के गाइड का अगला हिस्सा है, जो खास तौर पर risk साइड पर केंद्रित है।
ब्लॉक होते ही क्यों हैं
मार्केटप्लेस की economics इस पर टिकी है कि खरीदार किसी अलग सेलर पर नहीं, प्लेटफॉर्म पर भरोसा करे। guarantor सिस्टम — जिसमें पैसा तब तक रुका रहता है जब तक खरीदार receipt कन्फर्म न करे — असल में FunPay का प्रोडक्ट ही है। जो कुछ भी इस मैकेनिज्म को कमजोर करता है, उस पर सख्ती करना प्लेटफॉर्म की मजबूरी है, वरना उसके अस्तित्व का आधार ही खत्म हो जाता है।
इससे enforcement का आकार समझ आता है: सबसे कड़ी सजा "खराब प्रोडक्ट" पर नहीं, बल्कि उस व्यवहार पर मिलती है जो डील को प्लेटफॉर्म के नियंत्रण से बाहर निकालता है या व्यवस्थित रूप से खरीदारों के लिए जोखिम बनाता है। यह सिद्धांत समझ लेने पर आप वह क्लॉज़ भी predict कर सकते हैं जो आपने पढ़ा नहीं है।
श्रेणी 1: प्लेटफॉर्म के बाहर डील
नए सेलर का अकाउंट सबसे ज्यादा सीधे पेमेंट का ऑफर देने से जाता है। यह मासूम लग सकता है — खरीदार डिस्काउंट माँगता है, सेलर fee बचाने के लिए card transfer सुझा देता है। या बातचीत messenger में चली जाती है क्योंकि "वहाँ nickname कन्फर्म करना आसान है"।
इस श्रेणी में क्या आता है:
- guarantor के बाहर सीधे पेमेंट का प्रस्ताव — card, wallet, crypto।
- डील जारी रखने के लिए messenger contacts शेयर करना।
- इशारे और घुमा-फिराकर कही बातें — detection सिर्फ सीधे वाक्यों तक सीमित नहीं है।
- चैट या listing description में अपनी साइट या Telegram bot का लिंक।
अहम बात: खरीदार की पहल सेलर को नहीं बचाती। भले ही बाहर जाने का प्रस्ताव क्लाइंट ने दिया हो, जिम्मेदारी उस अकाउंट की है जिसने हामी भरी। सही प्रतिक्रिया है प्लेटफॉर्म चैट के भीतर ही विनम्र इनकार, ताकि वह इनकार लॉग में दर्ज रहे।
श्रेणी 2: प्रतिबंधित और उच्च-जोखिम सामान
हर मार्केटप्लेस की एक सूची होती है जिन categories को वह सर्विस नहीं करना चाहता — payment provider की शर्तों, rights-holder के दबाव या बेकाबू dispute rate की वजह से। सही सूची असली नियमों में पढ़ें, पर filter का तर्क predictable है। आमतौर पर वह सब बैन या सख्त सीमा में आता है जो:
- किसी गेम की ToS का इतना साफ उल्लंघन करता है कि पब्लिशर transaction पलट देगा;
- ऐसे access का ट्रांसफर शामिल करता है जिसे पब्लिशर non-transferable मानता है;
- unfair advantage देने वाले software से जुड़ा है;
- guarantor द्वारा सैद्धांतिक रूप से verify ही नहीं किया जा सकता।
पब्लिशर के नियम कैसे टकराते हैं
दूसरी परत है गेम कंपनियों की अपनी ToS। पब्लिशर account transfer, unauthorised sellers से खरीदी currency या real-money item trading पर रोक लगा सकता है। FunPay तकनीकी रूप से listing लगाने दे सकता है, पर जब पब्लिशर buyer accounts पर mass ban लगाता है या balance पलटता है, dispute आप तक पहुँचता है।
व्यावहारिक निष्कर्ष: कोई नई category शुरू करने से पहले दोनों rule sets देखें। मार्केटप्लेस द्वारा औपचारिक रूप से अनुमत category भी गेम की तरफ के reversal rate की वजह से आर्थिक रूप से घाटे की हो सकती है। यह मैकेनिज्म डिजिटल कोड रीसेलिंग के जोखिमों वाले लेख में विस्तार से है।
श्रेणी 3: description और सामान का मेल न खाना
Listing description एक offer है। अगर खरीदार को वह नहीं मिला जो उसने पढ़ा था, तो डिफॉल्ट रूप से वह सही है और प्लेटफॉर्म लगभग हमेशा उसका पक्ष लेगा।
आम बेमेल:
| क्या वादा था | खरीदार को क्या मिला | नतीजा |
|---|---|---|
| Global key | Region-restricted key | Dispute, refund, आंकड़ों पर चोट |
| PC platform | Console version का code | Refund, description की शिकायत |
| Instant delivery | घंटों बाद manual delivery | समय का dispute, rating गिरना |
| नया अकाउंट | history और linked services वाला अकाउंट | शिकायत, पब्लिशर reversal का जोखिम |
Region, platform, activation window, delivery method और हर restriction description में साफ लिखे होने चाहिए। यह सिर्फ ban से बचाव नहीं है — गलत खरीदारों के खिलाफ सबसे अच्छा filter भी है। जिस क्लाइंट ने region restriction पढ़कर भी खरीदा, वह लगभग कभी dispute नहीं करता। इन restrictions की मैकेनिक्स region-locked keys में समझाई गई है।
श्रेणी 4: refund और dispute खुद एक trigger
भले ही हर अलग dispute समझ में आने लायक लगे, उनका अनुपात एक स्वतंत्र सिग्नल की तरह काम करता है। प्लेटफॉर्म आंकड़े देखता है — जिस सेलर का refund, cancellation या support escalation का प्रतिशत औसत से साफ ऊपर है, वह किसी एक केस की खूबियों से परे manual review में चला जाता है।
Chargeback अलग समस्या है — खरीदार सामान पाने के बाद पेमेंट पलट देता है। यहाँ सेलर दोहरा नुकसान उठाता है, प्रोडक्ट और पैसा दोनों जाते हैं, और प्लेटफॉर्म पर problem order दर्ज हो जाता है। बचाव की रणनीति chargeback से बचने वाले लेख में है।
श्रेणी 5: multi-accounting और पाबंदी से बचाव
"जरूरत पड़ी तो काम आएगा" वाला दूसरा अकाउंट इस सूची की सबसे महंगी गलती है। प्लेटफॉर्म कई संकेतों के मेल से अकाउंट जोड़ते हैं — payment details, devices, network fingerprints, behavioural patterns, chat history के overlap। लिंक पकड़े जाने पर आमतौर पर एक अकाउंट की पाबंदी सभी जुड़े अकाउंट्स पर फैल जाती है और अस्थायी उपाय स्थायी बन जाता है।
अगर आप सच में टीम के रूप में काम करते हैं और कई अकाउंट चाहिए, तो यह शुरू करने से पहले प्लेटफॉर्म की अपनी प्रक्रिया से हल करें, बाद में नहीं।
अकाउंट हाइजीन: व्यवहार में क्या करें
एक छोटा rule set जो ज्यादातर जोखिम बंद कर देता है:
- सारी बातचीत प्लेटफॉर्म चैट में। क्लाइंट के कहने पर भी messenger में मत जाइए।
- Listings सटीक लिखें। Region, platform, delivery timing, restrictions — साफ और बिना दो अर्थ वाले।
- जहाँ संभव हो instant delivery। पेमेंट और receipt के बीच जितना कम अंतर, dispute के उतने कम आधार।
- हर ऑर्डर का log। Delivery timestamp, code identifier, supplier confirmation — claim window बंद होने तक रखें।
- Verifiable सप्लाई सोर्स। अपारदर्शी चैनल के codes टलते हुए dispute हैं।
- एक ही अकाउंट। कोई अपवाद नहीं, कोई spare नहीं।
स्टॉक कहाँ से लें ताकि dispute कम रहें
ब्लॉक का बड़ा हिस्सा बुरी नीयत से नहीं, खराब सप्लाई से पैदा होता है — revoke हुआ code, गलत रीजन की key, manual purchasing से देर हुई डिलीवरी। FoxReload इसी हिस्से को कवर करता है: 900+ SKU का wholesale catalog — game keys, gift cards, top-ups, subscriptions — instant delivery वाला single REST API और region साफ बताए गए SKUs। जब delivery automated हो और हर code का provenance दर्ज हो, तो disputed orders तेजी से घटते हैं और आपके अकाउंट की समीक्षा की वजहें भी।
औपचारिक supplier criteria के लिए gift card सप्लायर verify करना देखें। Dispute खुल जाने के बाद क्या करना है, इसके लिए FunPay dispute playbook देखें।
निष्कर्ष
FunPay के ban predictable हैं — वे guarantor से बचने, प्रतिबंधित categories, गलत descriptions, ऊँचे refund rate और multi-accounting के इर्द-गिर्द जमा होते हैं। प्लेटफॉर्म नियमों के ऊपर हमेशा दूसरी परत — पब्लिशर्स के अपने agreements — मौजूद रहती है और उसे नजरअंदाज नहीं किया जा सकता। कोई category शुरू करने से पहले exact wording और आधारों की मौजूदा सूची FunPay के अपने नियमों में जांचें। और operational हिस्सा — supply source, delivery speed, log की पूर्णता — ऐसे बनाएं कि disputed order अपवाद हो, रोज़ की पृष्ठभूमि नहीं।