चौथी बार रिफंड मांगने वाला कोई नाखुश ग्राहक नहीं है। वह एक रूटीन चला रहा है, और इसमें आपको रिटर्न हुए रेवेन्यू के साथ-साथ ऑर्डर पूरा करने में जो भी खर्च हुआ, उसका नुकसान होता है। Apple और Google दोनों एक आइडेंटिटी फील्ड देते हैं, एक तरफ appAccountToken और दूसरी तरफ obfuscated account ID, जो इन अलग-अलग घटनाओं को एक साफ दिखने वाले पैटर्न में बदल देता है।
मुख्य बातें
आपकी तरफ से दिया गया सबूत स्टोर तक ठीक दो स्थितियों में पहुंचता है: Apple का CONSUMPTION_REQUEST, जिसका जवाब 12 घंटे के भीतर देना होता है, और Google Play का Review Refund API के ज़रिए चार्जबैक रिव्यू, जिसका जवाब 24 घंटे के भीतर देना होता है। बाकी सब कुछ आपकी मौजूदगी के बिना तय हो जाता है।
Apple पर, आपके द्वारा जेनरेट किया गया UUID परचेज़ के साथ appAccountToken के रूप में जाता है। StoreKit उसे ट्रांज़ैक्शन से जोड़ देता है, जिसका मतलब है कि बाद में होने वाला कोई भी रिफंड आपके अपने रेकॉर्ड्स में एक पहचान योग्य अकाउंट से जुड़ जाता है।
Google का समकक्ष फील्ड एक हैश्ड स्ट्रिंग है जो 64 कैरेक्टर से ज़्यादा लंबी नहीं होती। Google खुद इसे पढ़ता है, और इस फील्ड का उपयोग असामान्य व्यवहार पहचानने के लिए करता है, जैसे एक ही अकाउंट से कम समय में अविश्वसनीय रूप से कई डिवाइस पर खरीदारी होना।
उस Google फील्ड में क्लियरटेक्स्ट पर्सनल डेटा होने पर परचेज़ सीधे ब्लॉक हो जाएंगे। एन्क्रिप्टेड वैल्यू या वन-वे हैश ज़रूरी है। रॉ ईमेल एड्रेस नहीं चलेगा।
Play का voidedReason friendly_fraud और fraud को एक सामान्य मन-बदलने वाले रिफंड से अलग पहचानता है, जिससे आपको रिपीट ऑफेंडर्स को डिफॉल्ट "रिफंड दें और आगे बढ़ें" रास्ते के बजाय रिव्यू क्यू में भेजने का आधार मिलता है।
Google का कहना है कि उसने 2022 के दौरान $2 बिलियन से ज़्यादा के फ्रॉडुलेंट और दुरुपयोग वाले ट्रांज़ैक्शन रोके। ये सुरक्षा उपाय आइडेंटिटी सिग्नल्स पर चलते हैं जो तभी मौजूद होते हैं जब आपके परचेज़ उन्हें लेकर आते हैं।
रिफंड के बावजूद बचा हुआ एक्सेस स्टोरेज, कंप्यूट और API बजट खाता रहता है जिसके लिए अब आपको पैसा नहीं मिल रहा, और जानबूझकर रिफंड लेने वाला व्यक्ति इसी नतीजे को बार-बार इंजीनियर कर रहा होता है।
परिचय
रिफंड होते रहते हैं, और उनमें से एक सिर्फ एक ओवरहेड है। जो तस्वीर बदलती है वह यह है कि वही अकाउंट चौथी बार लौटता है, हर पिछली बार सामान इस्तेमाल करने के बाद। यह व्यवहार आपके लिए तभी पढ़ा जा सकता है जब हर ट्रांज़ैक्शन के साथ आपके द्वारा दिया गया आइडेंटिफायर मौजूद हो। दोनों प्लेटफॉर्म यह देते हैं। दोनों एक संकरी सी रिस्पॉन्स विंडो भी खोलते हैं, नतीजा तय होने से पहले। आइडेंटिफायर को छोड़ दें, या विंडो चूक जाएं, तो सिस्टम का फायदा उठा रहा कोई व्यक्ति एक सच्ची शिकायत वाले पहली बार के ग्राहक से अलग नहीं दिखता। इन दोनों में क्या फर्क है, और यह फर्क पैसों में कितना महत्व रखता है, यही आगे बताया गया है।
रिफंड दुरुपयोग वास्तव में एक आइडेंटिटी समस्या है जो रिफंड का भेष धारण करती है
रिफंड का फैसला स्टोर का होता है। ग्राहक मांगेंगे, और ज़्यादातर फ्लो में स्टोर मान जाएगा, और आपकी कोई राय शामिल नहीं होगी। आपका असर कहीं और है: यह तय करना कि क्या इस खास अकाउंट का ऐसा करने का इतिहास है, और क्या जो उन्होंने खरीदा वह वास्तव में डिलीवर हुआ और इस्तेमाल हुआ। दोनों ही सवाल आइडेंटिटी के सवाल हैं। इस ट्रांज़ैक्शन के पीछे कौन सा यूज़र है, और उसने पहले क्या किया है। जो परचेज़ आपके यूज़र रेकॉर्ड्स से कोई स्थिर लिंक नहीं रखते, वे दोनों सवालों को अनुत्तरित छोड़ देते हैं, इसलिए हर रिफंड बिना किसी संदर्भ के तय हो जाता है।
यही वह खाई है जिसे पाटना फायदेमंद है। नीति मेकैनिक्स तय करती है और आप उन्हें बदल नहीं सकते। लेकिन सबूत जोड़ना आपके हाथ में है, और यह जुड़ना चेकआउट से शुरू होता है, रिफंड से नहीं।
दो विंडो जहां आपका भेजा गया सबूत वाकई मायने रखता है
केवल दो फ्लो आपके इनपुट को इनपुट की तरह मानते हैं। जब कोई ग्राहक किसी कंज़्यूमेबल या ऑटो-रिन्यूएबल सब्सक्रिप्शन पर रिफंड मांगता है, तो Apple का CONSUMPTION_REQUEST ट्रिगर होता है, और आपका जवाब 12 घंटे के भीतर देना होता है। जब कोई ग्राहक अपने बैंक के साथ चार्ज को विवादित करता है, तो Google Play का चार्जबैक रिव्यू ट्रिगर होता है, जिसका जवाब Review Refund API के ज़रिए 24 घंटे के भीतर देना होता है। इन दोनों से बाहर, फैसला आपके बिना होता है: Play का 48-घंटे वाला सेल्फ-सर्विस रिफंड, सपोर्ट द्वारा दिया गया रिफंड, या किसी ऐसे परचेज़ के लिए ऑटो-रिफंड जिसे आपने कभी स्वीकार नहीं किया।
दोनों चैनल तब काफी ज़्यादा प्रभावी हो जाते हैं जब ट्रांज़ैक्शन पहले से ही आपका आइडेंटिफायर लेकर आता है। Apple को भेजी गई कंज़म्पशन जानकारी में appAccountToken उस अकाउंट के खर्च और इतिहास के साथ शामिल किया जा सकता है, जबकि Google का रिव्यू एक obfuscated account ID पर आधारित होता है जिसे वह परचेज़ पूरा होने के बाद से देख रहा है। जहां कोई आइडेंटिफायर नहीं है, वहां सबमिट करने के लिए कोई इतिहास भी नहीं है।
दोनों आइडेंटिटी फील्ड्स की तुलना
दोनों कंपनियां अलग-अलग नामों और अलग-अलग बाधाओं के तहत लगभग एक जैसे समाधान पर पहुंचीं। हर एक आपको किसी परचेज़ पर एक वैल्यू अंकित करने देता है जो आपके अपने यूज़र रेकॉर्ड पर वापस जाकर जुड़ता है। दोनों में से कोई भी आपके लिए खुद से सक्रिय नहीं होता। और दोनों तब तक बेकार हैं जब तक परचेज़ के समय ही सेट न किए जाएं।
Apple: appAccountToken
एक UUID जेनरेट करें, परचेज़ शुरू होते वक्त उसे पास करें, और StoreKit उसे बनने वाले ट्रांज़ैक्शन से जोड़ देगा। यह फिर आपके सर्वर द्वारा वेरिफाई किए जाने वाले ट्रांज़ैक्शन डेटा में सामने आता है, और फिर से उस कंज़म्पशन जानकारी में जो आप CONSUMPTION_REQUEST के दौरान वापस भेजते हैं। चूंकि यह वैल्यू आपकी तरफ से शुरू हुई थी, यह किसी नाम या ईमेल को शामिल किए बिना किसी स्टोर ट्रांज़ैक्शन को डेटाबेस की एक रो से जोड़ देती है। केवल असली UUID ही चलते हैं; बाकी कुछ भी रिजेक्ट कर दिया जाता है। Apple ने इसके बाद Set App Account Token एंडपॉइंट भी जारी किया है, जो उन ट्रांज़ैक्शन पर टोकन लिख या अपडेट कर सकता है जो पहले ही हो चुके हैं, जिसमें ऑफर-कोड रिडेम्पशन और इसी तरह के ऐप के बाहर हुए परचेज़ भी शामिल हैं।
Google Play: obfuscated account ID
setObfuscatedAccountId इसका Google वर्ज़न है, एक वैकल्पिक स्ट्रिंग जो खरीदने वाले अकाउंट से बंधी होती है। Google के डॉक्यूमेंटेशन में इसका उद्देश्य बिना किसी लाग-लपेट के बताया गया है: Play इस वैल्यू का उपयोग असामान्य गतिविधि पहचानने के लिए करता है, जैसे कम समय के भीतर एक ही अकाउंट पर कई डिवाइस से ट्रांज़ैक्शन होना, और इससे कुछ फ्रॉडुलेंट परचेज़ पूरे होने से पहले ही रुक जाते हैं। इसकी सीमा 64 कैरेक्टर है, और क्लियरटेक्स्ट पर्सनल डेटा वर्जित है। उसमें रॉ ईमेल डालने पर परचेज़ ब्लॉक हो जाता है, क्योंकि यह फील्ड एक एन्क्रिप्टेड वैल्यू या वन-वे हैश की अपेक्षा रखता है। जिन ऐप्स में एक अकाउंट में कई प्रोफाइल होते हैं, उनके लिए एक साथी फील्ड भी है, setObfuscatedProfileId।
appAccountToken Apple का फील्ड है। यह UUID ही होना चाहिए, कुछ और नहीं, आपका कोड इसे चेकआउट के दौरान सेट करता है, और जब तक आप इसे जोड़ें नहीं, तब तक यह मौजूद नहीं होता। Apple इसका उपयोग ट्रांज़ैक्शन को आपके यूज़र से जोड़ने के लिए करता है, और यह ट्रांज़ैक्शन व कंज़म्पशन पेलोड्स में फिर से दिखता है।
obfuscatedAccountId Google Play का फील्ड है। यह अधिकतम 64 कैरेक्टर की हैश्ड स्ट्रिंग लेता है, आपका कोड इसे चेकआउट के दौरान सेट करता है, और डिफॉल्ट रूप से यह भी मौजूद नहीं होता। Google इसे असामान्य-गतिविधि डिटेक्शन में फीड करता है और इसका उपयोग कुछ फ्रॉडुलेंट परचेज़ को पूरा होने से पहले ही रोकने के लिए करता है।
एक असमानता बहुत मायने रखती है। Google कोई भी बैकफिल नहीं देता। आइडेंटिफायर के बिना पूरा हुआ कोई Play परचेज़ हमेशा के लिए अनाम रहता है, और भविष्य के परचेज़ को टैग करना ही एकमात्र उपाय है। Apple का Set App Account Token एंडपॉइंट इतिहास को सुधार सकता है, जो इसे नियम न कि अपवाद बनाता है।
बार-बार दोहराने वाले से होने वाले रिफंड की लागत का हिसाब
रिटर्न हुआ रेवेन्यू दिखने वाला हिस्सा है और साथ ही छोटा हिस्सा भी। रिफंड देने से बिक्री मूल्य वापस चला जाता है, जो आपके लेजर में दर्ज होता है। उस लाइन में शामिल नहीं होता वह सब कुछ जो ग्राहक को अब मुफ्त में मिले सामान को बनाने में खर्च हुआ।
एक कंज़्यूमेबल पर विचार करें जो असली काम शुरू कर देता है: इमेज जेनरेट होना, किसी मॉडल प्रोवाइडर को कॉल्स की एक सीरीज़, एक वीडियो एक्सपोर्ट होना, किसी क्रिएटर को पेआउट जाना। वह कंप्यूट इस्तेमाल के उस पल में खरीदा गया था। रिफंड देने से बिक्री मूल्य वापस मिल जाता है और प्रोवाइडर का इनवॉइस ठीक वहीं रह जाता है जहां था। जिस किसी ने भी यह समझ लिया है कि सामान रिफंड के बाद भी बना रहता है, वह बस यह क्रम दोहराता है, खरीदना, इस्तेमाल करना, रिफंड लेना, और हर दोहराव आपसे डिलीवरी की लागत फिर से वसूल लेता है।
इसके साथ ही प्लेटफॉर्म भी लागत को आपकी तरफ खिसका रहा है। 3 अगस्त, 2026 से, Google Play उस तारीख से किए गए ऑर्डर के लिए परचेज़ प्राइस और बैंक की चार्जबैक फीस दोनों डेवलपर्स को सौंपता है। जो विवाद पहले बड़े हिस्से में Google का खर्च थे, वे अब आपका गया हुआ रेवेन्यू प्लस एक फीस बन जाते हैं, और आदतन चार्जबैक करने वाला व्यक्ति हर कोशिश के साथ यह आंकड़ा और बढ़ा देता है। आइडेंटिटी फील्ड्स ही वह चीज़ हैं जो 24 घंटे की विंडो के भीतर Review Refund API को पढ़ने लायक कुछ देना संभव बनाती हैं।
Google समस्या के आकार का एक आंकड़ा देता है: 2022 के दौरान $2 बिलियन से ज़्यादा के फ्रॉडुलेंट और दुरुपयोग वाले ट्रांज़ैक्शन रोके गए। यह आंकड़ा इसलिए मौजूद है क्योंकि इसके पीछे के सिग्नल्स, जिनमें obfuscated account ID भी शामिल है, वास्तव में भरे गए थे। उन फील्ड्स को खाली छोड़ कर परचेज़ भेजना उस सुरक्षा से बाहर रहने का फैसला है।
स्टोर के फैसले से पहले बार-बार रिफंड लेने वालों को पकड़ना
हर परचेज़ पर अपनी नियंत्रित आइडेंटिटी की मुहर लगाएं
किसी भी प्लेटफॉर्म को बिना आइडेंटिफायर के कोई परचेज़ नहीं देखना चाहिए। StoreKit परचेज़ appAccountToken लेकर आते हैं, Play Billing परचेज़ setObfuscatedAccountId लेकर आते हैं, और दोनों वैल्यू आपके अपने यूज़र रेकॉर्ड से शुरू होती हैं। Apple को उस अकाउंट से मैप किया गया एक असली UUID चाहिए, Google को हैश किया गया अकाउंट की चाबी चाहिए ताकि कोई पर्सनल जानकारी खुले रूप में न जाए। चेकआउट ही दोनों के लिए सही पल है, और Google पर यह समय बाद में फिर से तय नहीं किया जा सकता।
उस आइडेंटिटी पर आधारित एक लेजर बनाए रखें
डिलीवरी, कंज़म्पशन इवेंट्स, परचेज़ और रिफंड को लॉग करें, सब उस आइडेंटिफायर के तहत दर्ज। इसके बाद कोई CONSUMPTION_REQUEST या चार्जबैक रिव्यू आने पर उस अकाउंट का पूरा इतिहास, पिछले रिफंड शामिल, सिर्फ एक क्वेरी दूर रहता है। Apple की कंज़म्पशन जानकारी में ठीक इसी सामग्री के लिए समर्पित फील्ड मौजूद हैं: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, और आपकी अपनी refundPreference।
voidedReason को रूटिंग फैसले की तरह लें
वॉयडेड Play परचेज़ के साथ एक voidedReason आता है जो कारण बताता है, और friendly_fraud व fraud को सामान्य मन-बदलने के मामलों से अलग दर्ज किया जाता है। इन्हें एक रिव्यू क्यू और ज़्यादा सख्त नीति की ज़रूरत है, न कि वह ऑटोमेटिक व्यवहार जो पहली बार के रिफंड को मिलता है। Google का गाइडेंस बढ़ते हुए रिस्पॉन्स का वर्णन करता है: पहले एक चेतावनी, दोहराव पर कुछ ज़्यादा सख्त, और लगातार ऐसा करने वाले अकाउंट्स के लिए परचेज़ बंद कर देना।
विंडो को कभी न चूकें
देर से सबमिट किया गया सबूत न होने जैसा ही है। CONSUMPTION_REQUEST के जवाब को ऑटोमेट करें ताकि वह आराम से 12 घंटे के भीतर भेजा जाए, और चार्जबैक रिव्यू 24 घंटे के भीतर। डेडलाइन के बाद दर्ज की गई एक बेदाग अकाउंट हिस्ट्री ऐसी हिस्ट्री है जिसे स्टोर पर कोई नहीं खोलेगा।
एक ही अकाउंट से एक साथ अविश्वसनीय रूप से कई डिवाइस पर ट्रांज़ैक्शन पकड़ने के लिए, Google Play की असामान्य-गतिविधि डिटेक्शन पर निर्भर रहें, जो obfuscated account ID को पढ़ती है।
इस अकाउंट पर पहले का रिफंड इतिहास देखने के लिए, अपने ही रेकॉर्ड्स पर निर्भर रहें, यानी वह लेजर जो आपने किसी भी प्लेटफॉर्म के आइडेंटिफायर के आधार पर बनाया है।
सामान वास्तव में खरीदार तक पहुंचा और इस्तेमाल हुआ, इसकी पुष्टि के लिए Apple पर निर्भर रहें, जहां consumptionStatus और deliveryStatus कंज़म्पशन इंफो के भीतर मौजूद होते हैं।
ऐसा विवाद जो वास्तव में खरीदार द्वारा आपके साथ धोखाधड़ी है, उसे पकड़ने के लिए Google Play पर निर्भर रहें, जहां voidedReason friendly_fraud के रूप में वापस आता है।
जहां प्लेटफॉर्म मदद करते हैं, और जहां वे रुक जाते हैं
ज़िम्मेदारी के बंटवारे के बारे में सटीक होना फायदेमंद है, क्योंकि यह मान लेना आसान है कि स्टोर दुरुपयोग को संभाल लेते हैं, और वे शायद ही कभी यह बताते हैं कि वे कहां रुकते हैं। Google वास्तव में कुछ फ्रॉड को खरीद से पहले रोकने के लिए obfuscated account ID पढ़ता है, और प्लेटफॉर्म-स्तर के सिस्टम काफी बड़ी मात्रा को रोक लेते हैं। Apple हर रिफंड फैसले को अपने पास रखता है और आपकी कंज़म्पशन जानकारी को वोट के बजाय सबूत की तरह मानता है। जो न तो कोई स्टोर करता है वह है आपकी ओर से किसी दुरुपयोगकर्ता की सूची रखना, रिफंड हुए कंज़्यूमेबल को आपके बैलेंस में वापस क्रेडिट करना, या आपकी तरफ से किसी बार-बार रिफंड लेने वाले को इनकार करना। हाशिए पर आइडेंटिटी पर कार्रवाई करना स्टोर का काम है। बाकी हर जगह यह आपका काम है।
Refund Sensor इसी आइडेंटिटी के आसपास डिज़ाइन किया गया है, और इसी वजह से। एक ही अकाउंट से जुड़ा रिफंड, चार्जबैक रिव्यू और कंज़म्पशन रिक्वेस्ट एक ही इतिहास में समाहित हो जाते हैं, जिससे बार-बार होने वाला पैटर्न चौथे इनवॉइस का पैसा चुकाए जाने के बाद नहीं, बल्कि दूसरी बार में ही दिखने लगता है।
यह नियम कहां दर्ज हैं
अक्सर पूछे जाने वाले प्रश्न
यह उस ग्राहक की स्थिति बताता है जो खरीदी गई चीज़ को डिलीवर होने और इस्तेमाल करने के बाद बार-बार रिफंड की मांग करता है, यानी फायदा भी बनाए रखता है और पेमेंट भी वापस ले लेता है। ऐप स्टोर के संदर्भ में यह आम तौर पर एक ही अकाउंट द्वारा कंज़्यूमेबल्स या सब्सक्रिप्शन के लिए बार-बार रिफंड लेने के रूप में दिखता है, या फ्रेंडली फ्रॉड के रूप में, जिसमें एक वैध चार्ज को बैंक के ज़रिए विवादित किया जाता है।
Apple पर आप एक UUID जेनरेट करते हैं, परचेज़ शुरू होते समय उसे appAccountToken के रूप में सौंपते हैं, और StoreKit उसे उस परचेज़ से बनने वाले ट्रांज़ैक्शन से जोड़ देता है, जहां से वह ट्रांज़ैक्शन डेटा और कंज़म्पशन डेटा दोनों में फिर से सामने आता है। Google पर आप उस अकाउंट से निकाले गए हैश्ड वैल्यू का उपयोग करके setObfuscatedAccountId कॉल करते हैं। दोनों तरीके किसी पर्सनल जानकारी को उजागर किए बिना किसी स्टोर ट्रांज़ैक्शन को आपके अपने यूज़र रेकॉर्ड से जोड़ देते हैं।
दोनों में से कोई भी नहीं बताएगा, कम से कम सीधे तौर पर नहीं। Google खरीद से पहले कुछ फ्रॉड रोकने और गड़बड़ गतिविधि पहचानने के लिए obfuscated account ID को पढ़ता है, और Apple कंज़म्पशन रिक्वेस्ट के दौरान सबमिट की गई अकाउंट हिस्ट्री को स्वीकार करता है, लेकिन दोनों कंपनियों में से किसी से भी रिपीट ऑफेंडर्स की कोई सूची वापस नहीं मिलती। वह सूची बनाना आपकी ज़िम्मेदारी है, जो उन आइडेंटिफायर्स के तहत आपके द्वारा दर्ज किए गए रेकॉर्ड्स से बनती है।
इसकी सामान्य वजह obfuscated account ID में क्लियरटेक्स्ट पर्सनल डेटा होना है। उसमें रॉ ईमेल एड्रेस जैसी कोई चीज़ डालने से Play परचेज़ को सीधे ब्लॉक कर देता है। इसके बदले एक एन्क्रिप्टेड वैल्यू या वन-वे हैश दें, और 64-कैरेक्टर की सीमा के भीतर रहें।
यह दुरुपयोग को रोकने के बजाय कम करता है। CONSUMPTION_REQUEST उन केवल दो रास्तों में से एक है जहां आपका सबूत फैसले से पहले पहुंचता है, और डिलीवरी व कंज़म्पशन डेटा के साथ अकाउंट हिस्ट्री Apple को रिटर्न दुरुपयोग और फ्रेंडली फ्रॉड पहचानने में मदद करती है। फिर भी फैसला Apple ही लेता है, और उन फ्लो के ज़रिए आने वाला दुरुपयोग जिन्हें आप चुनौती नहीं दे सकते, वैसा ही बना रहता है।
