Apple का DeviceCheck रिफंड का दुरुपयोग करने वाले के फ़ोन को याद रखता है, नए अकाउंट से साइन अप करने के बाद भी

अकाउंट बैन करने से वह व्यक्ति नहीं रुकता जो उसी फ़ोन पर दोबारा साइन अप कर लेता है। Apple का DeviceCheck और Google Play का डिवाइस रिकॉल (device recall) ठीक इसी कमी के लिए बने हैं। दोनों आपके सर्वर को किसी भौतिक डिवाइस से आपके अपने अर्थ वाले कुछ बिट जोड़ने देते हैं, जो स्टोर के सर्वर पर सहेजे जाते हैं। इसलिए जब उसके पीछे का व्यक्ति नए ईमेल पते के साथ लौटता है, तब भी फ़्लैग वहीं मौजूद रहता है। कोई भी टूल आपको डिवाइस ID नहीं देता, और कोई भी रिफंड नहीं रोक सकता। वे बस आपको साइन अप के समय या पेवॉल पर यह बताते हैं कि यह डिवाइस पहले भी आपको नुकसान पहुँचा चुका है।

नीचे बताया गया है कि हर स्टोर वास्तव में क्या सहेजता है, समय की वह बाधा जो तय करती है कि आप फ़्लैग सेट कर भी पाएँगे या नहीं, और पकड़े जाने से पहले बार-बार दुरुपयोग करने वाला आपको कितना महँगा पड़ता है।

नया अकाउंट हर अकाउंट-स्तरीय सुरक्षा को क्यों मात देता है

ज़्यादातर रिफंड सुरक्षाएँ किसी अकाउंट से जुड़ी होती हैं। Apple का appAccountToken किसी ट्रांज़ैक्शन को आपके डेटाबेस के किसी यूज़र से जोड़ता है। Android पर Google Play का obfuscated account ID यही काम करता है। हर खरीदारी पर दोनों को सेट करना सही है, और दोनों किसी व्यक्ति के अकाउंट का वर्णन करते हैं, उसके हाथ के हार्डवेयर का नहीं। अकाउंट हटाइए, नए ईमेल से साइन अप कीजिए, और उस व्यक्ति का आपका पूरा इतिहास शून्य से शुरू हो जाता है।

स्टोर यह कमी आपके लिए पूरी नहीं करते। App Store की रिफंड सूचना बताती है कि कौन सा ट्रांज़ैक्शन रिफंड हुआ। Google Play की रद्द खरीदारी आपको purchase token, order ID और एक voidedReason देती है। इनमें से किसी में भी डिवाइस पहचानकर्ता नहीं होता। एक डेटिंग ऐप डेवलपर ने Apple Developer Forums के एक थ्रेड में इसका नतीजा बताया: धोखेबाज़ प्रोफ़ाइल बार-बार प्रीमियम सदस्यता खरीदती रहीं जो बाद में रिफंड हो जाती थी, और डेवलपर के अपने तरीके से उनके डिवाइस बैन करने से कोई फ़ायदा नहीं हुआ।

क्या नया अकाउंट स्टोर के अपने ट्रायल को रीसेट कर देता है?

उसी Apple Account पर नहीं। Apple के दस्तावेज़ों के अनुसार इंट्रोडक्टरी ऑफ़र, मुफ़्त ट्रायल समेत, उन्हीं ग्राहकों को मिलते हैं जिन्होंने उस प्रोडक्ट या उसी सब्सक्रिप्शन ग्रुप के किसी प्रोडक्ट के लिए पहले ऐसा ऑफ़र नहीं लिया है। इसलिए आपके ऐप में नया लॉगिन दूसरा Apple ट्रायल नहीं दिलाता। नया Apple Account दिला देता है, और वह सब भी जो आप खुद देते हैं: साइन अप क्रेडिट, सर्वर के खर्च पर चलने वाला ट्रायल, रेफ़रल बोनस। डिवाइस फ़्लैग इन्हीं उपहारों की रक्षा करता है।

Apple का DeviceCheck वास्तव में क्या सहेजता है

DeviceCheck के दो हिस्से हैं। ऐप में DCDevice क्लास एक अस्थायी टोकन बनाती है जो डिवाइस की पहचान करता है। आपके सर्वर पर, आप यह टोकन अपने डेवलपर अकाउंट की कुंजी से साइन किए गए JSON वेब टोकन के साथ Apple को भेजते हैं, और Apple आपको उस डिवाइस के दो बिट पढ़ने या अपडेट करने देता है। क्वेरी के जवाब में bit0, bit1 और last_update_time आते हैं, जो साल और महीने के रूप में होता है। Apple के अपने उदाहरण हैं: ऐसा डिवाइस जिसने पहले ही प्रमोशनल ऑफ़र ले लिया है, और ऐसा डिवाइस जिसे आपने धोखाधड़ी वाला पाया है।

बिट Apple रखता है, लेकिन उनका अर्थ आपका है। उसके दस्तावेज़ कहते हैं कि बिट का अर्थ याद रखना और उन्हें कब रीसेट करना है यह तय करना आपकी ज़िम्मेदारी है, और उदाहरण के तौर पर बेचे गए डिवाइस का ज़िक्र करते हैं। दो बिट से चार स्थितियाँ बनती हैं, इसलिए एक सरल योजना यह है: एक बिट भारी उपयोग के बाद रिफंड के लिए और एक पहले ही मुफ़्त क्रेडिट मिल चुके होने के लिए।

• टोकन एक ही बार इस्तेमाल होता है। Apple कहता है कि यह अनुरोध दोबारा भेजने लायक समय तक मान्य रहता है, लेकिन हर कॉल के लिए नया टोकन बनाना चाहिए।
• डेवलपमेंट बिल्ड api.development.devicecheck.apple.com से बात करते हैं। प्रोडक्शन को api.devicecheck.apple.com का इस्तेमाल करना चाहिए, वरना आपके फ़्लैग गलत जगह पहुँचते हैं।
• Apple DeviceCheck को कुल जोखिम आकलन का एक इनपुट बताता है, अंतिम फ़ैसला नहीं। सेट बिट को ध्यान से देखने का कारण मानिए।

Android पर Google का डिवाइस रिकॉल क्या जोड़ता है

Google का संस्करण Play Integrity API के अंदर है और अभी बीटा में है, जिसके लिए रुचि फ़ॉर्म भरना होता है। स्वीकृति मिलने और Play Console में इसे चालू करने के बाद हर इंटीग्रिटी वर्डिक्ट में डिवाइस के तीन कस्टम बिट आते हैं। आप इन्हें deviceRecall:write एंडपॉइंट पर सर्वर कॉल से लिखते हैं, एक ऐसे इंटीग्रिटी टोकन के साथ जिसे आप पहले ही सत्यापित कर चुके हैं। Google कहता है कि डेटा ऐप को दोबारा इंस्टॉल करने और डिवाइस रीसेट के बाद भी बना रहता है, क्योंकि यह Google के सर्वर पर रहता है।

Google के दस्तावेज़ उपयोग के बारे में असामान्य रूप से स्पष्ट हैं। वे गंभीर दुरुपयोग के सबूत वाले डिवाइस, मुफ़्त ट्रायल जैसी कोई महँगी चीज़ पहले ही ले चुके डिवाइस, और दुरुपयोग के लिए बार-बार नए अकाउंट बनाने में इस्तेमाल हुए डिवाइस का नाम लेते हैं। सीमा के बारे में भी वे उतने ही स्पष्ट हैं: डिवाइस रिकॉल का उपयोग केवल ऐप सुरक्षा और दुरुपयोग, धोखाधड़ी और अनधिकृत पहुँच से लड़ने के लिए किया जा सकता है, कभी भी अलग-अलग यूज़र को फ़िंगरप्रिंट या ट्रैक करने के लिए नहीं, और कभी भी उम्र, लिंग या लोकेशन जैसी संवेदनशील जानकारी सहेजने के लिए नहीं।

समय की समस्या: रिफंड टोकन खत्म होने के बाद आते हैं

दोनों टूल को फ़्लैग करने से पहले डिवाइस से ही कुछ चाहिए। Apple को नया DCDevice टोकन चाहिए। Google को उसी डिवाइस का ऐसा इंटीग्रिटी टोकन चाहिए जो 14 दिन से पुराना न हो। इस बीच रिफंड आपके सर्वर पर स्टोर की एक सूचना के ज़रिए आता है जिसे डिवाइस के बारे में कुछ पता नहीं। इसलिए सवाल यह नहीं है कि डिवाइस को फ़्लैग करें या नहीं। सवाल यह है कि रिफंड आने पर क्या आपके पास उस डिवाइस तक पहुँचने का कोई तरीका बचा होगा।

Google के 48 घंटे वाले रिफंड 14 दिन की विंडो में आ जाते हैं

Google Play के सेल्फ़-सर्विस रिफंड खरीदारी के 48 घंटों के भीतर ही उपलब्ध हैं, जो उन 14 दिनों के काफ़ी अंदर है जिनमें इंटीग्रिटी टोकन लिखने के लिए उपयोगी रहता है। खरीदारी के समय इंटीग्रिटी जाँच चलाइए, सत्यापित टोकन को order ID के साथ रखिए, और जब उस ऑर्डर के लिए रद्द खरीदारी आए, तो आप तुरंत बिट लिख सकते हैं। चार्जबैक कठिन मामला है, क्योंकि बैंक विवाद 14वें दिन के बहुत बाद भी आ सकता है।

Apple के रिफंड के लिए डिवाइस का लौटना ज़रूरी है

Apple का रिफंड खरीदारी के हफ़्तों बाद आ सकता है, और सहेजा गया DeviceCheck टोकन दोबारा इस्तेमाल के लिए नहीं है। व्यावहारिक तरीका यह है कि पहले अकाउंट को चिह्नित करें और फिर डिवाइस को। जब रिफंड सूचना आए, अपने डेटाबेस में अकाउंट को फ़्लैग करें। अगली बार जब वह अकाउंट ऐप खोले, DeviceCheck टोकन माँगें और बिट सेट करें। रिफंड के बाद कंटेंट रखने वाले दुरुपयोगकर्ता आमतौर पर लौटते हैं, क्योंकि उसका उपयोग करना ही उनका मकसद था।

• खरीदारी के समय, appAccountToken या obfuscated account ID के ज़रिए ट्रांज़ैक्शन को अपने अकाउंट से दर्ज करें।
• रिफंड या रद्दीकरण पर, अपने सर्वर पर उस अकाउंट को फ़्लैग करें।
• फ़्लैग किए गए अकाउंट के अगले सत्र में, डिवाइस टोकन लें और अपना बिट सेट करें।
• हर साइन अप पर, कोई भी ऐसी चीज़ देने से पहले बिट पढ़ें जिसकी कीमत आपको चुकानी पड़ती है।

बार-बार रिफंड का दुरुपयोग करने वाला आपको कितना महँगा पड़ता है

रिफंड की गई कीमत दिखने वाला हिस्सा है। बाकी वह सब है जो खरीदारी पहले ही शुरू कर चुकी होती है। अगर आपका ऐप अपनी बेची चीज़ देने में पैसे खर्च करता है, तो खरीदने, इस्तेमाल करने और रिफंड लेने का हर चक्र वह पैसा खर्च करवा देता है: जनरेट की गई इमेज के लिए GPU समय, किसी मॉडल या डेटा API की पेड कॉल, ग्राहक द्वारा रखे गए एक्सपोर्ट का स्टोरेज, और बिक्री पर गिने गए क्रिएटर भुगतान। नया अकाउंट यह चक्र फिर से खोल देता है, और आपका लेजर उसे बिल्कुल नए ग्राहक के रूप में दर्ज करता है।

मुफ़्त उपहार भी बिना किसी रिफंड के इसी तरह रिसते हैं। जो डिवाइस दस अकाउंट पर साइन अप क्रेडिट बटोरता है, वह एक ट्रायल के लिए तय बजट से दस गुना कंप्यूट खाता है। Google Play पर 3 अगस्त 2026 के बाद के ऑर्डर पर चार्जबैक आपको खरीद मूल्य में से Google की सर्विस फ़ीस घटाकर, साथ में बैंक की फ़ीस भी, महँगा पड़ता है। इसलिए जो व्यक्ति हर बार नए अकाउंट से विवाद करता है, वह आपको हर बार पूरा विवाद फिर से महँगा पड़ता है।

फ़्लैग किए गए डिवाइस के साथ क्या करें

फ़्लैग एक सवाल का जवाब देता है: क्या इस डिवाइस को फिर से कुछ मुफ़्त मिलना चाहिए? अपनी प्रतिक्रिया संतुलित रखें, क्योंकि सेट बिट सबूत है, प्रमाण नहीं। फ़ोन दोबारा बिकते हैं, परिवार iPad साझा करते हैं, और Google इसी कारण स्पष्ट रूप से कहता है कि पुराने डेटा को अनदेखा करने या रीसेट करने पर विचार करें।

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

क्या आप डिवाइस को सीधे बैन कर सकते हैं?

आप अपने मुफ़्त अतिरिक्त लाभ देने से मना कर सकते हैं, और डिवाइस फ़्लैग का असली फ़ायदा यहीं है। पूरी तरह लॉक कर देना ज़्यादा जोखिम भरा है। आज फ़ोन रखने वाला व्यक्ति शायद वह नहीं है जिसने उसका दुरुपयोग किया, और Google की अपनी शर्तें डिवाइस रिकॉल को दुरुपयोग रोकने तक सीमित करती हैं, लोगों को ट्रैक करने तक नहीं। जिन चीज़ों पर आपका पैसा लगता है उन्हें नियंत्रित करें और पेड रास्ता खुला रखें।

Keychain (कीचेन) या डिवाइस पहचानकर्ता के बारे में क्या?

डेवलपर अक्सर पूछते हैं कि क्या Keychain मार्कर या हार्डवेयर ID यही काम कर सकता है। आपके ऐप द्वारा फ़ोन पर सहेजा गया मार्कर डिवाइस रीसेट के बाद मिट जाता है, और Apple इस काम के लिए ऐप्स को कोई स्थिर हार्डवेयर पहचानकर्ता नहीं देता। DeviceCheck और डिवाइस रिकॉल स्टोर द्वारा मान्य जवाब हैं, ठीक इसलिए कि बिट फ़ोन पर नहीं, Apple और Google के सर्वर पर रहते हैं।

जहाँ फ़ैसला अब भी स्टोर करता है

डिवाइस फ़्लैग बदलते हैं कि आपका ऐप आगे क्या मुफ़्त देगा। वे सामने के रिफंड को नहीं छूते। केवल दो रिफंड प्रक्रियाएँ आपको स्टोर के फ़ैसले से पहले सबूत देने देती हैं। Apple एक CONSUMPTION_REQUEST भेजता है और 12 घंटों के भीतर उपयोग डेटा माँगता है। Google Play एक चार्जबैक समीक्षा खोलता है जिसका जवाब आप orders.reviewrefund के ज़रिए 24 घंटों के भीतर देते हैं। बाकी सब, Google Play के 48 घंटे वाले रिफंड से लेकर सपोर्ट रिफंड और बिना स्वीकृति वाली खरीदारियों के ऑटो-रिफंड तक, आपके बिना तय होता है। बैंक के फ़ैसले के बाद चार्जबैक अंतिम होते हैं।

RefundHalt हर CONSUMPTION_REQUEST और Google Play चार्जबैक समीक्षा का जवाब उसकी समय सीमा के भीतर आपके असली उपयोग डेटा के साथ देता है, और हर रिफंड को उस अकाउंट से जोड़ता है जिसने उसे लिया, ताकि अगली बार डिवाइस के लौटने पर आपके सर्वर को पता हो कि किस डिवाइस को फ़्लैग करना है।