सभी लेख
Playbookपढ़ने में 8 मिनट

हर Google Play खरीद पर एक obfuscated account id लगाएं, वरना चार्जबैक आने पर उसे ट्रेस करने का कोई तरीका नहीं बचता

Google Play आपको हर खरीद पर एक स्थिर, हैश किया हुआ id अंकित करने देता है और विवाद आने पर उसे वापस पढ़ता है। इसे सेट करें और एक चार्जबैक समीक्षा ठीक उसी उपयोगकर्ता से जुड़ जाती है जिसका उपयोग आपको रिपोर्ट करना है। इसे छोड़ दें और आप 24 घंटे की घड़ी के तहत एक अकेले order id को अनुमानों से मिलाते रह जाते हैं।

एक डेवलपर के हाथ एक Android फोन के पास एक कागज़ी खरीद रसीद पर एक छोटा खाली टैग बांधते हुए, जो एक खरीद पर Google Play obfuscated account id अंकित करने का प्रतीक है

मुख्य बातें

  • obfuscated account id एक स्ट्रिंग है जिसे आप setObfuscatedAccountId के साथ एक Google Play खरीद पर जोड़ते हैं। Google Play इसे order के साथ संग्रहीत करता है और बाद में obfuscatedExternalAccountId के रूप में लौटाता है, ताकि एक खरीद को उस उपयोगकर्ता तक ट्रेस किया जा सके जिसने इसे आपके सिस्टम में किया था।
  • Google के शब्दों में, यह फ़ील्ड Google Play को अनियमित गतिविधि का पता लगाने देता है, जैसे कि थोड़े समय के भीतर एक ही खाते पर कई डिवाइस खरीद करते हुए। इसे सेट करना खरीद के समय, लेन-देन पूरा होने से पहले Google की अपनी धोखाधड़ी जांच को पोषित करता है।
  • यह पहचानकर्ता 64 अक्षरों तक सीमित है और इसमें व्यक्तिगत जानकारी सादे रूप में नहीं होनी चाहिए। Google कहता है कि इस फ़ील्ड में ईमेल जैसी PII संग्रहीत करने से खरीदें ब्लॉक हो जाती हैं, और इसके बजाय एकतरफा हैश या एन्क्रिप्शन की सिफारिश करता है।
  • जब किसी बैंक चार्जबैक को आपकी समीक्षा की ज़रूरत होती है, तो Google Play एक PendingRefundReviewNotification भेजता है जो एक order का नाम लेता है, किसी व्यक्ति का नहीं। obfuscated account id वह जोड़ने वाली कुंजी है जो उस order को उस उपयोगकर्ता रिकॉर्ड से मैप करती है जिसका उपयोग आपको रिपोर्ट करना है।
  • आप एक विवाद का उत्तर 24 घंटों के भीतर orders.reviewrefund को एक refundPreference, एक sampleContentProvided फ़्लैग, और consumptionPercentageMilliunits तथा consumptionUsageEvents जैसे उपभोग साक्ष्य के साथ कॉल करके देते हैं। आप वह साक्ष्य तभी बना सकते हैं जब आप जानते हों कि order किस उपयोगकर्ता का है।
  • 3 August, 2026 को या उसके बाद की गई Google Play orders के लिए, एक हारा हुआ चार्जबैक डेवलपर से खरीद मूल्य में से Google की सेवा शुल्क घटाकर, साथ ही बैंक की चार्जबैक शुल्क वसूलता है। एक विवाद जिसका आप उत्तर नहीं दे सकते क्योंकि आप order की पहचान नहीं कर सकते, अब एक सीधी लागत है, केवल एक खोई बिक्री नहीं।
  • id को हर खरीद पर सेट करें, केवल सब्सक्रिप्शन पर नहीं, और इसे सर्वर-साइड पर वापस पढ़ें। क्लाइंट पर यह Purchase.getAccountIdentifiers से आता है, और आपके बैकएंड पर यह खरीद रिकॉर्ड पर obfuscatedExternalAccountId फ़ील्ड है।

एक Google Play चार्जबैक समीक्षा एक order और एक purchase token का नाम लेते हुए सामने आती है। यह आपको नहीं बताती कि ग्राहक कौन है। यदि आपने उस खरीद पर कभी अपना पहचानकर्ता अंकित नहीं किया, तो अब आप 24 घंटे की घड़ी के तहत एक अकेले order id को अपनी उपयोगकर्ता तालिका से मिला रहे हैं, और आपको उपयोग साक्ष्य के साथ उत्तर देना है जिसे शायद आप ढूंढ ही न पाएं। obfuscated account id इसका समाधान है। यह एक छोटी स्ट्रिंग है जिसे आप चेकआउट पर जोड़ते हैं जिसे Google Play खरीद के साथ संग्रहीत करता है और बाद में आपको वापस देता है, ताकि हर order को ठीक उस उपयोगकर्ता तक ट्रेस किया जा सके जिसने इसे किया। यहां बताया गया है कि यह फ़ील्ड क्या है, यह क्यों तय करता है कि आप किसी विवाद का उत्तर दे भी पाएंगे या नहीं, और इसे छोड़ने की क्या लागत है अब जब एक हारा हुआ चार्जबैक एक बिल है।

obfuscated account id वास्तव में क्या है

obfuscated account id एक वैकल्पिक स्ट्रिंग है जिसे आप Google Play बिलिंग फ़्लो में पास करते हैं जब कोई ग्राहक कुछ खरीदता है। आप इसे BillingFlowParams बिल्डर पर setObfuscatedAccountId के साथ सेट करते हैं, और Google इसे खरीद के साथ संग्रहीत करता है। यह ग्राहक का नाम नहीं है, उनका ईमेल नहीं, और उनका Google खाता नहीं। यह आपके अपने उपयोगकर्ता के लिए आपका अपना पहचानकर्ता है, एक ऐसे रूप में लिखा गया जिसे Google इस व्यक्ति की पहचान जाने बिना रख सकता है।

यह एक स्ट्रिंग है जिसे आप चेकआउट पर सेट करते हैं, नाम नहीं

Google के शब्दों में, setObfuscatedAccountId एक वैकल्पिक obfuscated स्ट्रिंग निर्दिष्ट करता है जो आपके ऐप में खरीदार के उपयोगकर्ता खाते के साथ विशिष्ट रूप से जुड़ी होती है। शब्द obfuscated असली काम कर रहा है। Google आपका कच्चा उपयोगकर्ता id या ऐसा कुछ नहीं चाहता जो व्यक्ति की पहचान करे। यह एक स्थिर टोकन चाहता है जो आपकी ओर से एक उपयोगकर्ता से एक-से-एक मैप हो, और बस इतना ही। यह फ़ील्ड 64 अक्षरों तक सीमित है, जो एक हैश को आराम से रखता है और उससे ज़्यादा कुछ नहीं।

Google इसे पहले अपनी धोखाधड़ी जांच के लिए पढ़ता है

आपके लिए उपयोगी होने से पहले, यह फ़ील्ड Google के लिए एक काम करता है। बिलिंग दस्तावेज़ीकरण कहता है कि Google Play इस मूल्य का उपयोग अनियमित गतिविधि का पता लगाने के लिए कर सकता है, जैसे कि थोड़े समय के भीतर एक ही खाते पर कई डिवाइस खरीद करते हुए, और यह कि Google इस डेटा का उपयोग संदिग्ध व्यवहार का पता लगाने और कुछ प्रकार के धोखाधड़ी वाले लेन-देन को पूरा होने से पहले ब्लॉक करने के लिए करता है। तो इसे सेट करने का पहला लाभ ऊपर की ओर है, साफ़ खरीदों में और उन धोखाधड़ी वाली खरीदों में से कम में जो बाद में void और विवाद बन जाती हैं। Google obfuscated account id और Voided Purchases API को एक कारण से अपने दो मुख्य दुरुपयोग-रोधी उपकरणों के रूप में एक साथ सूचीबद्ध करता है।

चार्जबैक समीक्षा आने पर यह क्यों मायने रखता है

जो रिफंड आप आते हुए देख सकते हैं, वह आसान है। कठिन मामला बैंक चार्जबैक है, क्योंकि यह आपके ग्राहक के आपसे बात करने से शुरू नहीं होता। यह बैंक से शुरू होता है, और Google Play इसे एक घड़ी के साथ एक समीक्षा के रूप में आपको आगे भेजता है।

विवाद एक order का नाम लेता है, किसी व्यक्ति का नहीं

जब कोई ग्राहक अपने बैंक के साथ किसी शुल्क का विवाद करता है और Google को आपके इनपुट की ज़रूरत होती है, तो Google Play एक PendingRefundReviewNotification भेजता है। वह संदेश order की पहचान करता है। इसमें आपका उपयोगकर्ता id नहीं होता, क्योंकि Google के पास आपका उपयोगकर्ता id कभी था ही नहीं। इसके पास केवल वही था जो आपने खरीद पर अंकित किया। यदि वह कुछ नहीं था, तो अब आप एक अकेले order id और purchase token को अपने रिकॉर्ड के विरुद्ध उल्टा खोज रहे हैं, यह उम्मीद करते हुए कि आपने खरीद के समय टोकन लॉग किया और यह उम्मीद करते हुए कि मिलान असंदिग्ध है। यदि आपने एक obfuscated account id सेट किया, तो खरीद आपका अपना हैश ले जाती है, आप एक ही क्वेरी में उपयोगकर्ता को देख लेते हैं, और पहचान ढूंढने के बजाय साक्ष्य बनाने की ओर बढ़ जाते हैं।

orders.reviewrefund वास्तव में आपसे क्या मांगता है

विवाद का उत्तर देने का मतलब है 24 घंटों के भीतर orders.reviewrefund विधि को कॉल करना। Google आपकी पहली कॉल दर्ज करता है और बाकी को अनदेखा करता है, इसलिए पहला उत्तर ही एकमात्र उत्तर है। ये वे फ़ील्ड हैं जो यह चाहता है, और हर एक साक्ष्य फ़ील्ड यह मानकर चलता है कि आप पहले से जानते हैं कि order किस उपयोगकर्ता का है।

फ़ील्डआवश्यकयह क्या ले जाता है
pendingRefundTokenहांउस PendingRefundReviewNotification का टोकन जिसका आप उत्तर दे रहे हैं
refundPreferenceहांAPPROVE, DECLINE, या NEUTRAL, आपकी सिफारिश कि Play को रिफंड करना चाहिए या नहीं
sampleContentProvidedहांक्या आपने खरीद से पहले एक मुफ़्त नमूना, ट्रायल, या फ़ीचर का विवरण दिया
consumptionPercentageMilliunitsवैकल्पिकग्राहक ने खरीद का कितना उपभोग किया, 0 to 100,000 milliunits
consumptionUsageEventsवैकल्पिकघटनाओं की एक सूची, प्रत्येक एक उदाहरण जहां उपयोगकर्ता ने जो खरीदा उसका उपभोग या उपयोग किया
एक छोटा खाली कागज़ी टैग डोरी से बंधा हुआ एक छपे हुए बैंक स्टेटमेंट पर रखा है, एक स्मार्टफोन के पास जो लेन-देन की एक धुंधली सूची दिखा रहा है, जो एक Google Play खरीद को टैग करने का प्रतीक है ताकि बाद का विवाद किसी उपयोगकर्ता तक ट्रेस किया जा सके

इसे छोड़ने की वास्तव में क्या लागत है

Google Play के अधिकांश इतिहास में, एक चार्जबैक जिसका आप बचाव नहीं कर सकते थे, एक खोई बिक्री और एक कंधे उचकाना था। वह बदल गया। 3 August, 2026 को या उसके बाद की गई orders के लिए, एक हारा हुआ चार्जबैक डेवलपर से खरीद मूल्य में से Google की सेवा शुल्क घटाकर, साथ ही बैंक की चार्जबैक शुल्क वसूलता है। वह विवाद जिसका आप उत्तर नहीं दे सकते, अब एक लाइन आइटम है।

एक order पर चलें। एक ग्राहक अपने बैंक के साथ $9.99 की खरीद का विवाद करता है। Google Play समीक्षा भेजता है, और आपके पास 24 घंटे हैं। यदि आपने खरीद को टैग किया, तो आप उपयोगकर्ता को ढूंढ लेते हैं, देखते हैं कि उन्होंने जो खरीदा उसका अधिकांश उपभोग किया, और DECLINE प्राथमिकता तथा उपभोग साक्ष्य के साथ reviewrefund का उत्तर देते हैं, जिससे Google को एक अवैध विवाद का मुकाबला करने के लिए एक वास्तविक मामला मिलता है। यदि आपने इसे टैग नहीं किया, तो या तो आप समय पर order की पहचान नहीं कर सकते या आप कुछ नहीं के साथ उत्तर देते हैं, विवाद आपके पक्ष के बिना तय हो जाता है, और 3 August के बाद की एक order पर आप $9.99 में से Google की शुल्क घटाकर वापस देते हैं, साथ ही एक निश्चित बैंक चार्जबैक शुल्क जो अक्सर $20 के पास पड़ती है। एक छोटी बिक्री पर, वह निश्चित शुल्क अकेले उससे बड़ी हो सकती है जो आपने नेट में कमाया।

  • खोई हुई आय: बिक्री में आपका शुद्ध हिस्सा, उलट दिया गया।
  • बैंक की चार्जबैक शुल्क: एक निश्चित लागत जो कार्ड नेटवर्क तय करता है, 3 August, 2026 के बाद की गई orders पर ऊपर से वसूली जाती है, जो एक सादा रिफंड कभी नहीं ले जाता।
  • बर्बाद हुआ खर्च: कंप्यूट, तृतीय-पक्ष API कॉल, और स्टोरेज जो खाते ने पहले ही उपयोग किया, चला गया चाहे आप उत्तर दे पाएं या नहीं।
  • वह पैटर्न जो आप नहीं देख सकते: एक स्थिर account id के बिना आप यह भी नहीं बता सकते कि वही उपयोगकर्ता बार-बार विवाद कर रहा है, इसलिए क्रमिक दुरुपयोग असंबंधित एकबारगी नुकसान के रूप में पढ़ा जाता है।

इसे बिना खरीदें ब्लॉक हुए कैसे सेट करें

दो नियम लगभग हर उस गलती को कवर करते हैं जो टीमें इस फ़ील्ड के साथ करती हैं। id को हैश करें, और इसे हर जगह सेट करें।

अपने उपयोगकर्ता id को हैश करें, कभी PII न भेजें

इस फ़ील्ड में कोई ईमेल, फ़ोन नंबर, या कोई कच्चा व्यक्तिगत विवरण न डालें। Google स्पष्ट है कि इस फ़ील्ड में सादे रूप में ईमेल जैसी PII संग्रहीत करने से खरीदें ब्लॉक हो जाती हैं, और यह मूल्य उत्पन्न करने के लिए एकतरफा हैश या एन्क्रिप्शन की सिफारिश करता है। साफ़ पैटर्न आपके आंतरिक उपयोगकर्ता id का एकतरफा हैश है, हर बार उसी तरह गणना किया गया ताकि वही उपयोगकर्ता हमेशा वही 64-अक्षर स्ट्रिंग उत्पन्न करे। व्यक्ति का Google खाता id या आपका डेवलपर id भी उपयोग न करें। मूल्य का अर्थ केवल आपके सिस्टम के लिए होना चाहिए।

इसे हर खरीद पर सेट करें, और इसे अपने सर्वर पर वापस पढ़ें

id को हर बिलिंग फ़्लो से जोड़ें, एक-बार वाले उत्पाद और सब्सक्रिप्शन दोनों, ताकि कोई खरीद कभी बिना लेबल के न हो। खरीद के बाद, इसे दो जगहों पर वापस पढ़ें। क्लाइंट पर, Purchase.getAccountIdentifiers एक ऑब्जेक्ट लौटाता है जिसका getObfuscatedAccountId आपको वह स्ट्रिंग देता है जो आपने सेट की। आपके बैकएंड पर, सर्वर-साइड खरीद रिकॉर्ड इसे obfuscatedExternalAccountId फ़ील्ड के रूप में ले जाता है, और सर्वर कॉपी ही वह है जिस पर भरोसा करना है, क्योंकि एक विवाद आपके सर्वर पर आता है, डिवाइस पर नहीं।

जब एक खाते में कई प्रोफ़ाइल हों तो setObfuscatedProfileId का उपयोग करें

यदि आपका ऐप एक खाते को कई प्रोफ़ाइल रखने देता है, एक स्ट्रीमिंग घराना या कई पात्रों वाला एक गेम, तो setObfuscatedProfileId भी सेट करें। यह उसी तरह की हैश की हुई, 64-अक्षर, बिना-PII स्ट्रिंग है, जो उस प्रोफ़ाइल तक सीमित है जिसने खरीद की। Google नोट करता है कि एक profile id सेट करने पर account id को भी पास करने की मांग होती है, इसलिए दोनों भेजें। परिणाम यह है कि एक विवाद न केवल खाते तक बल्कि ठीक उस प्रोफ़ाइल तक मैप होता है जिसने पैसा खर्च किया।

iOS समानांतर, एक लाइन में

App Store का एक अलग नाम के तहत वही विचार है। iOS पर आप एक खरीद पर एक appAccountToken, एक UUID, जोड़ते हैं, और यह लेन-देन पर और उस CONSUMPTION_REQUEST पर वापस आता है जो Apple भेजता है जब कोई ग्राहक रिफंड मांगता है। समस्या का आकार दोनों स्टोर पर समान है। विवाद या रिफंड फ़्लो एक लेन-देन का संदर्भ देता है, और आपका अपना पहचानकर्ता वही है जो इसे एक उपयोगकर्ता तक वापस बांधता है जिसका उपयोग आप रिपोर्ट कर सकते हैं।

विवरणGoogle PlayApp Store
वह फ़ील्ड जो आप सेट करते हैंsetObfuscatedAccountId के ज़रिए obfuscated account idappAccountToken
प्रारूपहैश की हुई स्ट्रिंग, 64 अक्षर, बिना PIIUUID
यह कहां वापस आता हैखरीद पर obfuscatedExternalAccountIdलेन-देन पर appAccountToken
जिस विंडो को यह पोषित करता हैorders.reviewrefund, 24 घंटेCONSUMPTION_REQUEST, 12 घंटे
आप क्या रिपोर्ट करते हैंउपभोग प्रतिशत और उपयोग घटनाएंApple के उपभोग फ़ील्ड

इसमें से कुछ भी बनाना कठिन नहीं है। इसे छोड़ना आसान है, क्योंकि जिस दिन आप चेकआउट कोड लिखते हैं वह वह दिन नहीं है जब एक चार्जबैक आता है, और इसे छोड़ने की लागत तब तक अदृश्य है। RefundHalt दोनों स्टोर पर account identifier सेट और ट्रैक करता है, खरीद-से-उपयोगकर्ता लिंक रखता है ताकि एक विवाद हमेशा एक वास्तविक ग्राहक तक हल हो, और Google Play के orders.reviewrefund तथा Apple के CONSUMPTION_REQUEST का उनकी विंडो के अंदर बिक्री के समय दर्ज उपभोग साक्ष्य के साथ उत्तर देता है। 24 घंटे की घड़ी यह पता लगाने का क्षण नहीं है कि आप बता नहीं सकते कि चीज़ किसने खरीदी।

अक्सर पूछे जाने वाले सवाल

Google Play बिलिंग में obfuscated account id क्या है?
यह एक वैकल्पिक स्ट्रिंग है जिसे आप setObfuscatedAccountId के साथ एक खरीद पर जोड़ते हैं जो आपके ऐप में खरीदार के उपयोगकर्ता खाते के साथ विशिष्ट रूप से जुड़ी होती है। Google Play इसे order के साथ संग्रहीत करता है, अनियमित गतिविधि जैसे एक खाते पर कई डिवाइस खरीदते हुए का पता लगाने के लिए इसका उपयोग करता है, और बाद में इसे obfuscatedExternalAccountId के रूप में आपको लौटाता है ताकि आप एक खरीद को एक विशिष्ट उपयोगकर्ता तक बांध सकें।
क्या मैं obfuscated account id फ़ील्ड में किसी उपयोगकर्ता का ईमेल या id डाल सकता हूं?
नहीं। Google कहता है कि इस फ़ील्ड में सादे रूप में ईमेल जैसी व्यक्तिगत रूप से पहचान योग्य जानकारी संग्रहीत करने से खरीदें ब्लॉक हो जाती हैं। मूल्य उत्पन्न करने के लिए एकतरफा हैश या एन्क्रिप्शन का उपयोग करें, इसे 64 अक्षरों के भीतर रखें, और व्यक्ति का Google खाता id या आपका डेवलपर id उपयोग न करें।
obfuscated account id एक Google Play चार्जबैक में कैसे मदद करता है?
एक चार्जबैक समीक्षा, PendingRefundReviewNotification, order का नाम लेती है, आपके उपयोगकर्ता का नहीं। obfuscated account id वह जोड़ने वाली कुंजी है जो उस order को सही उपयोगकर्ता रिकॉर्ड तक मैप करती है, ताकि आप 24 घंटों के भीतर orders.reviewrefund का उत्तर वास्तविक उपभोग साक्ष्य के साथ दे सकें, यह अनुमान लगाने के बजाय कि order किस ग्राहक का है।
क्या मुझे obfuscated account id सब्सक्रिप्शन पर सेट करना चाहिए या केवल एक-बार वाली खरीदों पर?
इसे हर खरीद पर सेट करें, एक-बार वाले उत्पाद और सब्सक्रिप्शन दोनों। कोई भी बिना लेबल वाली खरीद वह है जिसे आप किसी उपयोगकर्ता तक वापस ट्रेस नहीं कर सकते जब एक विवाद या void आता है, और विवाद किसी भी order प्रकार पर आ सकते हैं।
obfuscated account id और obfuscated profile id में क्या अंतर है?
account id एक खरीद को आपके ऐप में एक उपयोगकर्ता खाते तक मैप करता है। profile id इसे उस खाते के अंदर एक विशिष्ट प्रोफ़ाइल तक मैप करता है, उन ऐप्स के लिए जहां एक खाता कई प्रोफ़ाइल या पात्र रखता है। दोनों बिना PII वाली हैश की हुई, 64-अक्षर स्ट्रिंग हैं, और Google नोट करता है कि एक profile id सेट करने पर account id को भी पास करने की आवश्यकता होती है।

स्रोत और आगे की जानकारी

RefundHalt

App Store और Google Play के लिए refund ऑटोपायलट

आगे पढ़ें

Deep diveपढ़ने में 8 मिनट

बैंक स्टेटमेंट पर एक न पहचाना गया शुल्क चार्जबैक बन जाता है, और एक चार्जबैक आपको रिफंड से ज़्यादा महंगा पड़ता है

जब कोई ग्राहक यह नहीं बता पाता कि आपके ऐप ने उससे किस चीज़ का शुल्क लिया, तो वह आपके बजाय बैंक को कॉल करता है, और वह विवाद एक चार्जबैक के रूप में सामने आता है। Apple सब कुछ apple.com/bill के रूप में दिखाता है और आपको कुछ भी बदलने नहीं देता। Google Play आपको स्टेटमेंट नाम सेट करने देता है। यहाँ बताया गया है कि हर एक की क्या लागत है और आप किस पर नियंत्रण रखते हैं।

Deep diveपढ़ने में 8 मिनट

Apple पहले से दिया गया रिफंड पलट सकता है, और आपका सर्वर जिस पलटे हुए रिफंड को अनदेखा करता है वह भुगतान कर चुके ग्राहक को बाहर कर देता है

जब App Store पहले से दिया गया रिफंड पलटता है, तो वह उम्मीद करता है कि आपका सर्वर वह एक्सेस बहाल कर दे जिसे आपने रद्द किया था। यहाँ बताया गया है कि App Store और Google Play पर रिफंड, रिफंड अस्वीकृत, और पलटा हुआ रिफंड नोटिफिकेशन कैसे काम करते हैं, और जब आप हर एक को अनदेखा करते हैं तो उसकी क्या कीमत चुकानी पड़ती है।

अगला refund अनुरोध पहले ही रास्ते में है.

RefundHalt को उतने समय में सेटअप करें, जितने में आप उस refund के बारे में एक और सपोर्ट ईमेल पढ़ते हैं जिस पर आपत्ति नहीं कर पाए.