सीरियल refund का दुरुपयोग आपको दोहरी चोट देता है, यहाँ बताया गया है कि स्टोर आपको जवाबी लड़ाई का मौका कैसे देते हैं
जो ग्राहक बार-बार refund लेता है वह कोई इत्तेफाक नहीं है। refund का दुरुपयोग आपको पैसा वापस देने पर तो नुकसान देता ही है, साथ ही वह compute भी छीन लेता है जो आप पहले ही खर्च कर चुके हैं, और दोनों स्टोर आपको इस पैटर्न को जोड़ने के लिए एक पहचान संकेत देते हैं, Apple का appAccountToken और Google का obfuscated account ID।
मुख्य बातें
- केवल दो refund flow ही किसी developer को refund के दुरुपयोग के खिलाफ सबूत जमा करने देते हैं: Apple का CONSUMPTION_REQUEST, जिसमें 12 घंटे की window होती है, और Google Play की chargeback समीक्षा जो Review Refund API के जरिए होती है, जिसमें 24 घंटे की window होती है।
- Apple का appAccountToken एक UUID है जिसे आप खुद बनाते हैं और किसी purchase से जोड़ते हैं, और StoreKit इसे बनने वाले transaction से बांध देता है, ताकि आपका server हर refund को ठीक उसी account तक जोड़ सके जिसने वह किया।
- Google Play का obfuscated account ID एक hash की गई string है, जो अधिकतम 64 वर्ण की होती है, जिसे Google खुद असामान्य गतिविधि का पता लगाने के लिए इस्तेमाल करता है, जैसे कि किसी एक account पर कम समय में कई डिवाइसों से खरीदारी।
- Google के obfuscated account ID में साफ़ (cleartext) निजी डेटा रखने से आपकी purchases ब्लॉक हो जाती हैं, इसलिए इस field में एक encrypted value या one-way hash होना चाहिए, कभी भी कच्चा email नहीं।
- Google Play का voidedReason field, friendly_fraud और fraud को एक सामान्य remorse refund से अलग कारण के रूप में चिह्नित करता है, जिससे आप बार-बार दुरुपयोग करने वालों को स्वचालित refund-and-forget रास्ते के बजाय एक review queue में भेज सकते हैं।
- Google का कहना है कि उसने 2022 में $2 billion से अधिक की धोखाधड़ी और दुरुपयोग वाली transactions को रोका, और उस सिस्टम को खिलाने वाले पहचान field तभी काम करते हैं जब आप उन्हें हर purchase पर भरें।
- हर वह refund की गई purchase जो अपनी पहुँच बनाए रखती है, वह compute, storage और API खर्च है जिसे आप उस पैसे पर चुकाते रहते हैं जो आप पहले ही लौटा चुके हैं, और एक सीरियल refunder जानबूझकर उस बिल को कई गुना बढ़ा देता है।
एक अकेला refund कारोबार करने की एक लागत है। वही account चौथी बार refund ले, हर बार जो खरीदा उसे इस्तेमाल करने के बाद, यह refund का दुरुपयोग है, और यह एक पैटर्न है जिसे आप तभी देख सकते हैं जब हर purchase एक ऐसी पहचान रखे जो आपके नियंत्रण में हो। Apple और Google दोनों आपको वह पहचान देते हैं, और दोनों आपको एक refund या chargeback तय होने से पहले उसे स्टोर के सामने रखने के लिए एक संकरी window देते हैं। window चूक जाइए, या पहचान कभी जोड़िए ही नहीं, तो एक सीरियल refunder बिलकुल पहली बार के नाराज़ ग्राहक जैसा दिखता है। यहाँ बताया गया है कि उन्हें कैसे अलग पहचानें, और यह फर्क पैसे में कितना कीमती है।
refund का दुरुपयोग एक refund की समस्या नहीं, बल्कि पहचान की समस्या क्यों है
refund स्टोर तय करता है। आप किसी ग्राहक को मांगने से नहीं रोक सकते, और ज़्यादातर flow पर आप स्टोर को मंज़ूर करने से नहीं रोक सकते। आप जो कर सकते हैं वह यह तय करना है कि किसी खास account ने पहले भी ऐसा किया है या नहीं, और उसने जो सामग्री खरीदी वह वाकई पहुँचाई और इस्तेमाल की गई या नहीं। ये दोनों पहचान के बारे में सवाल हैं: आपका कौन सा उपयोगकर्ता इस transaction के पीछे है, और उसका इतिहास क्या है। अगर आपकी purchases आपके अपने उपयोगकर्ता रिकॉर्ड तक एक स्थिर पहचानकर्ता नहीं ले जातीं, तो आप इनमें से कोई भी सवाल नहीं सुलझा सकते, और हर refund बिना किसी संदर्भ के आता है।
यही असली खाई है। refund की कार्यप्रणाली नीति से तय है। आप उनके सामने जो सबूत लाते हैं वह पूरी तरह आपका बनाया हुआ है, और यह purchase के पल से शुरू होता है, refund के पल से नहीं।
वे दो windows जहाँ सबूत नतीजा बदल देते हैं
ठीक दो flow हैं जहाँ आपका भेजा हुआ कुछ भी किसी फैसले को हिला सकता है। Apple का CONSUMPTION_REQUEST तब चलता है जब कोई ग्राहक किसी consumable या auto-renewable subscription पर refund मांगता है, और जवाब देने के लिए आपके पास 12 घंटे होते हैं। Google Play की chargeback समीक्षा तब चलती है जब कोई उपयोगकर्ता अपने बैंक के साथ किसी charge पर विवाद करता है, और Review Refund API के जरिए जवाब देने के लिए आपके पास 24 घंटे होते हैं। हर दूसरा refund, 48 घंटे वाला Play सेल्फ-सर्विस refund, सपोर्ट द्वारा दिया गया refund, एक बिना-स्वीकृत purchase का स्वचालित refund, आपके बिना ही तय हो जाता है।
वे दोनों सबूत के चैनल तब कहीं ज़्यादा मज़बूत होते हैं जब transaction पहले से आपका पहचानकर्ता रखे। Apple की consumption information में account के इतिहास और खर्च के साथ appAccountToken शामिल हो सकता है, और Google की समीक्षा उस obfuscated account ID पर टिक सकती है जिसे वह purchase के बाद से देख रहा है। बिना किसी पहचानकर्ता वाला account एक ऐसा account है जिसका जमा करने के लिए कोई इतिहास नहीं है।
दो पहचान field, आमने-सामने
Apple और Google ने वही समस्या लगभग एक ही तरह से सुलझाई, अलग नामों और अलग नियमों के साथ। दोनों आपको किसी purchase पर एक ऐसी value मुहर लगाने देते हैं जो आपके अपने उपयोगकर्ता रिकॉर्ड की ओर इशारा करती है। कोई भी डिफ़ॉल्ट रूप से चालू नहीं है। दोनों बेकार हैं अगर आप उन्हें purchase के समय सेट नहीं करते।
Apple: appAccountToken
appAccountToken एक UUID है जिसे आप बनाते हैं और तब पास करते हैं जब कोई purchase शुरू होती है। StoreKit इसे बनने वाले transaction से जोड़ता है, और यह उस transaction डेटा में दिखता है जिसे आपका server सत्यापित करता है और उस consumption information में जिसे आप किसी CONSUMPTION_REQUEST के दौरान वापस भेजते हैं। चूँकि यह आपकी value है, यह किसी स्टोर transaction को सीधे आपके डेटाबेस के account पर मैप करता है, बिना किसी email या नाम के। इसे एक असली UUID होना चाहिए, और बाकी कुछ भी अस्वीकार कर दिया जाता है। बाद में Apple ने एक Set App Account Token endpoint जोड़ा जो पुराने transactions पर token को जोड़ या अपडेट कर सकता है, जिसमें आपके ऐप के बाहर की गई purchases जैसे offer-code रिडेम्पशन भी शामिल हैं।
Google Play: obfuscated account ID
Google का समकक्ष setObfuscatedAccountId है, एक वैकल्पिक string जो खरीदने वाले account से जुड़ी होती है। Google का अपना दस्तावेज़ इसके मकसद के बारे में सीधा है: Google Play इसका इस्तेमाल असामान्य गतिविधि का पता लगाने के लिए करता है, जैसे कि थोड़े समय के भीतर एक ही account पर कई डिवाइसों से खरीदारी, और कुछ धोखाधड़ी वाली transactions को पूरा होने से पहले रोकने के लिए। यह 64 वर्ण तक सीमित है, और इसमें साफ़ (cleartext) निजी डेटा नहीं होना चाहिए। वहाँ एक कच्चा email रखिए और Google purchase को सीधे ब्लॉक कर देता है, क्योंकि यह field एक encrypted value या one-way hash की अपेक्षा करता है। एक साथी field, setObfuscatedProfileId, उन ऐप्स के लिए मौजूद है जहाँ एक account कई profile रखता है।
| Field | Store | प्रकार और सीमा | किसके द्वारा सेट | डिफ़ॉल्ट | स्टोर इसके साथ क्या करता है |
|---|---|---|---|---|---|
| appAccountToken | Apple | UUID | आप, purchase पर | सेट नहीं | transaction को आपके उपयोगकर्ता से बांधता है, transaction और consumption डेटा में लौटाया जाता है |
| obfuscatedAccountId | Google Play | Hash की गई string, अधिकतम 64 वर्ण | आप, purchase पर | सेट नहीं | असामान्य गतिविधि का पता लगाता है और पूरा होने से पहले कुछ धोखाधड़ी रोकता है |
एक सीरियल दुरुपयोगकर्ता का refund असल में कितना महंगा पड़ता है
refund अपने आप में बिल का सबसे छोटा हिस्सा है। जब कोई स्टोर refund मंज़ूर करता है, तो आप राजस्व लौटाते हैं, और उतना ही खाते-बही पर दिखता है। refund की लाइन पर जो नहीं है वह है वह सब कुछ जो आपने उस उत्पाद को पहुँचाने में खर्च किया जो अब मुफ्त है।
एक ऐसे consumable की कल्पना कीजिए जो असली काम शुरू करता है: एक image generation, किसी model provider को API calls का एक बैच, एक video export, किसी creator को भुगतान। आपने उस compute का भुगतान उसी पल किया जब ग्राहक ने उसका इस्तेमाल किया। refund कीमत वापस खींच लेता है, पर वह provider का इनवॉइस वापस नहीं खींचता। एक सीरियल refunder वह है जिसने सीख लिया है कि सामग्री refund के बाद भी बची रहती है, इसलिए वह लूप फिर चलाता है: खरीदो, इस्तेमाल करो, refund लो, दोहराओ। हर चक्र में, आप डिलीवरी की लागत दूसरी बार झेलते हैं।
फिर स्टोर की अपनी लागत का बदलाव है। August 3, 2026 से, Google Play उस तारीख के बाद दिए गए orders के लिए purchase की कीमत और बैंक की chargeback फीस को developer पर डाल देता है। एक chargeback जो पहले ज़्यादातर Google की समस्या थी, अब आपका राजस्व और एक फीस बन जाती है, और एक बार-बार charge करने वाला उस संख्या को हर बार बढ़ाता है। पहचान field ही वह हैं जो आपको 24 घंटे की window के भीतर किसी अवैध विवाद का मुकाबला करने के लिए Review Refund API को सबूत खिलाने देते हैं।
Google पैमाने को साफ़ तौर पर बताता है: उसका कहना है कि उसने 2022 में $2 billion से अधिक की धोखाधड़ी और दुरुपयोग वाली transactions को रोका। वह संख्या इसलिए मौजूद है क्योंकि संकेत, उनमें obfuscated account ID भी, भरे गए थे। एक ऐप जो खाली पहचान field के साथ purchases भेजता है, उस सुरक्षा से बाहर हो जाता है।
स्टोर के फैसला लेने से पहले बार-बार refund लेने वालों को कैसे पकड़ें
हर purchase को एक ऐसी पहचान से टैग करें जो आपकी अपनी हो
हर StoreKit purchase पर appAccountToken और हर Play Billing purchase पर setObfuscatedAccountId सेट करें, दोनों आपके अपने उपयोगकर्ता रिकॉर्ड से बनाए गए। Apple पर, account से मैप किया गया एक असली UUID इस्तेमाल करें। Google पर, account key को hash करें ताकि कोई निजी डेटा साफ़ रूप में न जाए। यह purchase के समय करें, क्योंकि Google पर यह वह एक कदम है जिसे आप बाद में वापस नहीं पा सकते।
उस पहचान पर आधारित एक खाता-बही रखें
हर purchase, delivery, consumption event और refund को उस पहचानकर्ता के सामने संग्रहीत करें। जब कोई CONSUMPTION_REQUEST या chargeback समीक्षा आए, तो account का पूरा इतिहास, पिछले refund सहित, एक lookup की दूरी पर होता है। Apple की consumption information में ठीक इसी के लिए स्पष्ट field हैं: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, और आपका refundPreference।
voidedReason पढ़ें और दुरुपयोगकर्ताओं को अलग रास्ता दें
जब कोई Google purchase रद्द (voided) की जाती है, तो voidedReason field आपको बताता है कि क्यों, और friendly_fraud तथा fraud एक सामान्य remorse refund से अलग value हैं। उन्हें एक review queue और एक सख्त नीति की ओर भेजें, न कि वही स्वचालित रास्ता जो किसी पहली बार के refund को मिलता है। Google का अपना मार्गदर्शन एक कई-बार-चेतावनी वाला मॉडल है: पहले अपराधी को चेतावनी दें, बार-बार करने वालों पर कड़ी कार्रवाई करें, और जो account लगातार यही करता रहे उसके लिए purchases बंद कर दें।
हर बार window का जवाब दें
सबूत केवल दो windows के भीतर ही गिना जाता है। CONSUMPTION_REQUEST के जवाब को स्वचालित करें ताकि वह 12 घंटे के भीतर अच्छी तरह चले, और chargeback समीक्षा को ताकि वह 24 घंटे के भीतर चले। एक बेहतरीन इतिहास जो आप देर से जमा करते हैं वह एक ऐसा इतिहास है जिसे स्टोर कभी नहीं पढ़ता।
| जिस संकेत को आप पकड़ना चाहते हैं | वह कहाँ रहता है | वह field या flow जो उसे सामने लाता है |
|---|---|---|
| वही account, कई डिवाइस, थोड़ा समय | Google Play | Obfuscated account ID असामान्य-गतिविधि पहचान |
| इस account ने पहले भी refund लिया है | आपकी खाता-बही | appAccountToken या obfuscated account ID पर आधारित इतिहास |
| सामग्री पहुँचाई और इस्तेमाल की गई | Apple | consumption info में deliveryStatus और consumptionStatus |
| एक विवाद असल में फर्स्ट-पार्टी धोखाधड़ी है | Google Play | voidedReason value friendly_fraud |
स्टोर आपके लिए क्या करेंगे और क्या नहीं
श्रम के बंटवारे के बारे में सटीक होना ज़रूरी है, क्योंकि यह मान लेना आसान है कि स्टोर दुरुपयोग संभाल लेते हैं, और वे ज़्यादातर आपको तब नहीं बताते जब वे नहीं संभालते। Google सक्रिय रूप से obfuscated account ID का इस्तेमाल किसी purchase के पूरा होने से पहले कुछ धोखाधड़ी रोकने के लिए करता है, और उसके सिस्टम एक बड़े हिस्से को प्लेटफ़ॉर्म स्तर पर पकड़ते हैं। Apple हर refund खुद तय करता है और आपकी consumption information को एक इनपुट मानता है, कभी वोट नहीं। कोई भी स्टोर आपके लिए आपकी दुरुपयोगकर्ता सूची नहीं रखता, किसी refund की गई consumable को आपके बैलेंस से नहीं घटाता, या आपकी ओर से किसी बार-बार refund लेने वाले को मना नहीं करता। पहचान किनारों पर स्टोर के कार्य करने के लिए है और बाकी हर जगह आपके।
यही वजह है कि RefundHalt हर चीज़ को purchase की पहचान पर आधारित रखता है: एक ही account के लिए एक refund, एक chargeback समीक्षा, और एक consumption request एक ही इतिहास तक पहुँचते हैं, ताकि एक सीरियल refunder पहली बार दोहराते ही एक पैटर्न के रूप में सामने आ जाए, न कि चौथे इनवॉइस के बाद जो आप पहले ही चुका चुके हैं।
अक्सर पूछे जाने वाले सवाल
- किसी ऐप में refund का दुरुपयोग क्या है?
- refund का दुरुपयोग तब होता है जब कोई ग्राहक जो खरीदा उसे पाकर और इस्तेमाल करके बार-बार refund मांगता है, ताकि वह सामग्री या लाभ रखते हुए पैसा भी वापस पा ले। ऐप स्टोर पर यह आमतौर पर वही account द्वारा consumables या subscriptions को बार-बार refund करने के रूप में दिखता है, या friendly fraud के रूप में, जहाँ एक वैध charge का बैंक के साथ विवाद किया जाता है।
- मैं किसी in-app purchase को किसी खास उपयोगकर्ता से कैसे जोड़ूँ?
- Apple पर, एक UUID बनाएं और purchase शुरू होने पर उसे appAccountToken के रूप में पास करें, और StoreKit इसे transaction से बांध देता है तथा transaction और consumption डेटा में लौटाता है। Google Play पर, account से जुड़ी एक hash की गई value के साथ setObfuscatedAccountId कॉल करें। दोनों किसी स्टोर transaction को आपके अपने उपयोगकर्ता रिकॉर्ड से जोड़ते हैं, बिना निजी डेटा उजागर किए।
- क्या Apple या Google मुझे बता सकते हैं कि कोई account बार-बार refund लेने वाला है?
- सीधे नहीं। Google obfuscated account ID का इस्तेमाल असामान्य गतिविधि का पता लगाने और purchase से पहले कुछ धोखाधड़ी रोकने के लिए करता है, और Apple आपको किसी consumption request के दौरान account इतिहास जमा करने देता है, पर कोई भी स्टोर आपको बार-बार refund लेने वालों की सूची नहीं देता। वह आप खुद अपनी खाता-बही से पहचान field के आधार पर बनाते हैं।
- जब मैं account ID सेट करता हूँ तो Google मेरी purchase क्यों ब्लॉक कर देता है?
- क्योंकि obfuscated account ID में साफ़ (cleartext) निजी डेटा नहीं होना चाहिए। उसमें कच्चे email पते जैसी कोई चीज़ रखने से Google Play purchase को ब्लॉक कर देता है। एक encrypted value या one-way hash इस्तेमाल करें, और इसे 64 वर्ण की सीमा के भीतर रखें।
- क्या consumption request के जरिए refunds का मुकाबला करना दुरुपयोग को रोक देता है?
- यह उसे कम कर सकता है। CONSUMPTION_REQUEST केवल दो flow में से एक है जहाँ आपका सबूत स्टोर के फैसला लेने से पहले उस तक पहुँचता है, और account इतिहास तथा delivery और consumption डेटा Apple को return abuse और friendly fraud पहचानने में मदद करते हैं। पर यह कोई ब्लॉक नहीं है। Apple फिर भी खुद तय करता है, और जो दुरुपयोग गैर-मुकाबले-योग्य flow से आता है वह अप्रभावित रहता है।
स्रोत और आगे की जानकारी
- Apple: appAccountToken (App Store Server API)
- Apple: ConsumptionRequest (App Store Server API)
- Android: BillingFlowParams.Builder.setObfuscatedAccountId
- Android: Fight fraud and abuse (Play Billing security)
- Google Play Developer API: Voided Purchases
- Google Play Billing: Provide refund and chargeback suggestions (Review Refund API)
- Android Developers Blog: Play Commerce prevented over $2 billion in fraudulent and abusive transactions in 2022
- Google Play Console Help: Updates to refund protection and chargeback cost responsibility
RefundHalt
App Store और Google Play के लिए refund ऑटोपायलट
आगे पढ़ें
The refunds you cannot contest: what Apple and Google decide without asking you
Only two refund flows ever ask for your evidence: Apple's consumption request and Google Play's chargeback review. Everything else, the 48-hour Play refund, support refunds, voided purchases, unacknowledged trials, is decided without you. Here is the full map, what you can prevent, and what you can only record.
Apple's CONSUMPTION_REQUEST, explained: the 12 hours that decide your refund
When a customer asks Apple for a refund, Apple asks you first. Here's exactly what the CONSUMPTION_REQUEST notification contains, what Apple expects back, how to answer one end to end, and why most developers silently forfeit.