हर रिन्यूअल को अपनी अलग Google Play ऑर्डर ID मिलती है, और किसी को रिफ़ंड देने से पहले यही नंबर जाँचना चाहिए

किसी Google Play ग्राहक को रिफ़ंड देने से पहले ऑर्डर नंबर का आखिरी हिस्सा देखें। GPA.1234-5678-9012-34567 सब्सक्रिप्शन का पहला चार्ज है। GPA.1234-5678-9012-34567..2 तीसरा है। दोनों का आधार एक है, पर ये अलग-अलग भुगतान हैं, और रिफ़ंड करते समय Play Console इन्हें अलग तरह से संभालता है। Google Play ऑर्डर ID ही एकमात्र पहचानकर्ता है जो आपका ग्राहक देख सकता है, इसलिए वही आपके सपोर्ट इनबॉक्स में पहुँचती है। इसे सही पढ़ें, तो आप उसी चार्ज का रिफ़ंड करेंगे जिससे ग्राहक सच में परेशान है, और सिर्फ़ एक बार।

Google Play ऑर्डर ID आपको क्या बताती है

Google के Play Billing Library दस्तावेज़ उदाहरण के ज़रिए इसका फ़ॉर्मैट बताते हैं। ऑर्डर ID GPA से शुरू होती है, फिर अंकों के समूह आते हैं। सब्सक्रिप्शन में हर रिन्यूअल को मूल ऑर्डर ID के साथ दो बिंदु और शून्य से शुरू होने वाला एक काउंटर मिलता है। यानी मूल खरीदारी में कोई सफ़िक्स नहीं होता, पहला रिन्यूअल ..0 है, दूसरा ..1, और इसी तरह आगे।

इससे सफ़िक्स यह जल्दी बता देता है कि कोई कितने समय से भुगतान कर रहा है। GPA.3333-4137-0319-36762..11 के बारे में लिखने वाले ग्राहक का सब्सक्रिप्शन बारह बार रिन्यू हो चुका है। जो ग्राहक बिना सफ़िक्स वाली मूल ID बताता है, उसने या तो कुछ एक बार खरीदा है या वह अपने सबसे पहले भुगतान की बात कर रहा है।

ऑर्डर ID कहाँ दिखती है, और आपको उसका कौन-सा रूप मिलता है

यहीं टीमें अक्सर चूक जाती हैं। अलग-अलग जगहें एक ही ID को अलग-अलग रूप में देती हैं।

• ग्राहक की Google Play रसीद उसी चार्ज की ऑर्डर ID दिखाती है जिसकी वह रसीद है, रिन्यूअल भी शामिल।
• आपके ऐप में, Play Billing Library का Purchase.getOrderId() सब्सक्रिप्शन रिन्यूअल के लिए शुरुआती ऑर्डर की ID लौटाता है। Google का अपना उदाहरण: GPA.1234-5678-9012-34567..0 के बजाय आपको GPA.1234-5678-9012-34567 मिलती है।
• आपके सर्वर पर, purchases.subscriptionsv2 हर लाइन आइटम को latestSuccessfulOrderId देता है, जो उस आइटम के सबसे हाल के सफल ऑर्डर की ID है। Google ने यह फ़ील्ड 21 मई 2025 को जोड़ा।
• Voided Purchases API में, orderId किसी एक बार की खरीदारी, सब्सक्रिप्शन खरीदारी या सब्सक्रिप्शन रिन्यूअल की अलग पहचान करता है। Google के दस्तावेज़ कहते हैं कि रिन्यूअल में फ़र्क करने के लिए परचेज़ टोकन नहीं, orderId इस्तेमाल करें।

तो फिर परचेज़ टोकन किस काम का है

परचेज़ टोकन पूरी खरीदारी की पहचान करता है। सब्सक्रिप्शन के लिए एक ही टोकन मूल चार्ज और उसके बाद के हर रिन्यूअल को कवर करता है। इसीलिए यह एक्सेस अधिकार (entitlement) के लिए सही कुंजी है और रिफ़ंड के लिए गलत। रिफ़ंड और चार्जबैक किसी एक चार्ज पर होते हैं, और सिर्फ़ ऑर्डर ID ही किसी एक चार्ज को नाम देती है।

Google Play ऑर्डर कैसे खोजें

Play Console में

ऑर्डर प्रबंधन (Order management) अपने सर्च बॉक्स में ऑर्डर ID या ग्राहक का पूरा ईमेल पता, दोनों में से कोई भी स्वीकार करता है। हर ऑर्डर इनमें से एक स्थिति दिखाता है: प्रोसेस हो गया (Processed), रद्द (Cancelled), लंबित (Pending), रिफ़ंड लंबित (Pending refund), रिफ़ंड हो गया (Refunded), आंशिक रिफ़ंड लंबित (Pending partial refund) या आंशिक रूप से रिफ़ंड (Partially refunded)। अगर ग्राहक रसीद के बजाय ईमेल देता है, तो ईमेल से खोजें और तारीख के हिसाब से चार्ज चुनें, फिर कोई कदम उठाने से पहले सफ़िक्स की पुष्टि करें।

Orders API से

21 मई 2025 से, Google Play Developer API के Orders संसाधन में एक ऑर्डर के लिए orders.get और सूची के लिए orders.batchget है। व्यवहार में कुछ सीमाएँ मायने रखती हैं:

• batchget हर अनुरोध में 1 से 1,000 ऑर्डर ID लेता है, और वे अलग-अलग होनी चाहिए।
• अगर कोई एक भी ऑर्डर ID नहीं मिलती या पैकेज से संबंधित नहीं है, तो पूरा batchget अनुरोध विफल हो जाता है।
• Orders API कॉल आपके Play Developer API कोटा में गिनी जाती हैं, जो डिफ़ॉल्ट रूप से प्रति दिन 2,00,000 कॉल है।

असली काम का हिस्सा वह Order है जो आपको वापस मिलता है। इसमें ऑर्डर की स्थिति, उसका purchaseToken, createTime और lastEventTime, कुल राशि और टैक्स, IN_APP या PLAY_STORE जैसा salesChannel, और प्रोसेसिंग, रद्दीकरण, रिफ़ंड और आंशिक रिफ़ंड की घटनाओं वाला orderHistory होता है। इसमें developerRevenueInBuyerCurrency भी होता है, जिसे Google खरीदार की मुद्रा में आपकी आय के रूप में परिभाषित करता है, आंशिक रिफ़ंड, टैक्स और शुल्क घटाने के बाद। जब Google मर्चेंट ऑफ़ रिकॉर्ड (merchant of record) होता है, तो खरीदार के पते में सिर्फ़ देश होता है।

सही ऑर्डर का रिफ़ंड

जब आपको पता चल जाए कि ग्राहक किस चार्ज की बात कर रहा है, तो Play Console आपको एक विकल्प देता है जो इस पर निर्भर करता है कि वह ऑर्डर सब्सक्रिप्शन में कहाँ है।

API के ज़रिए, orders.refund पैकेज नाम और ऑर्डर ID लेता है। 3 साल से पुराने ऑर्डर रिफ़ंड नहीं किए जा सकते। वैकल्पिक revoke पैरामीटर को true पर सेट करने से सब्सक्रिप्शन या इन-ऐप आइटम तक पहुँच तुरंत खत्म हो जाती है। Google की सहायता में यह भी लिखा है कि रिफ़ंड जारी होने के बाद उसे पलटा नहीं जा सकता, इसलिए आप जो ऑर्डर ID भेजते हैं वह अंतिम है।

किसी सब्सक्राइबर के लिए $0.00 का ऑर्डर क्यों दिखता है?

Google के सब्सक्रिप्शन लाइफ़साइकल दस्तावेज़ इसे समझाते हैं। जब कोई उपयोगकर्ता अपना सब्सक्रिप्शन खत्म होने से पहले आपके ऐप से उसी बेस प्लान के लिए फिर से साइन अप करता है, तो Google Play $0.00 का ऑर्डर बनाता है। उससे कोई शुल्क नहीं लिया जाता, क्योंकि वह मौजूदा अवधि का भुगतान पहले ही कर चुका है, और सामान्य बिलिंग मूल रिन्यूअल तारीख से फिर शुरू होती है। यह न तो फ़्री ट्रायल है, न कोई प्रमोशन। इस ऑर्डर पर रिफ़ंड करने के लिए कुछ नहीं है। अगर ग्राहक पैसे वापस चाहता है, तो उससे पहले वाला भुगतान किया हुआ ऑर्डर खोजें।

गलत ऑर्डर का रिफ़ंड आपको कितना महँगा पड़ता है

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

ऐसा कैसे होता है, देखिए। मासिक प्लान वाला एक ग्राहक ..4 चार्ज के बारे में लिखता है, यानी पिछले हफ़्ते वाले चार्ज के बारे में। आपकी टीम का कोई सदस्य ईमेल से खोजता है, सबसे ऊपर पहला ऑर्डर देखता है, और महीनों पुराने मूल ऑर्डर पर केवल रिफ़ंड करें पर क्लिक कर देता है। अब ग्राहक को उस अवधि के पैसे वापस मिल गए जिसका उसने इस्तेमाल किया था। जिस चार्ज की उसने शिकायत की थी, वह जस का तस है, और उसका सब्सक्रिप्शन अब भी रिन्यू हो रहा है। वह अब भी अपने बैंक से पिछले हफ़्ते का चार्ज पलटने को कह सकता है।

अब बैंक वाला रास्ता ही सबसे महँगा है। 3 अगस्त 2026 के बाद किए गए ऑर्डर के लिए Google कहता है कि जब चार्जबैक सफल होता है, तो डेवलपर खरीद मूल्य (Play की सर्विस फ़ीस घटाकर) और बैंक द्वारा लिए गए चार्जबैक शुल्क के लिए ज़िम्मेदार होता है। बैंक में चार्जबैक अंतिम होते हैं। एक गलत पढ़ा गया सफ़िक्स दो रिफ़ंड जितने पैसे गँवाने और ऊपर से शुल्क चुकाने पर खत्म हो सकता है।

कौन-से रिफ़ंड आपके इनबॉक्स तक कभी नहीं पहुँचते

ज़्यादातर Google Play रिफ़ंड में न आपकी ज़रूरत होती है, न ऑर्डर ID की। Google की रिफ़ंड नीति कहती है कि ग्राहक खरीदारी के 48 घंटों के भीतर Google Play के ज़रिए रिफ़ंड पा सकता है, और 48 घंटों के बाद उसे डेवलपर से संपर्क करना चाहिए। Google उन सब्सक्रिप्शन का भी रिफ़ंड करके उन्हें रद्द कर देता है जिन्हें आप तीन दिनों के भीतर स्वीकार (acknowledge) नहीं करते। इनके बारे में आपको बाद में Voided Purchases API से पता चलता है, जो voidedSource (उपयोगकर्ता के लिए 0, डेवलपर के लिए 1, Google के लिए 2) और Remorse, Chargeback या Unacknowledged_purchase जैसा voidedReason बताता है।

Google Play में सिर्फ़ एक रिफ़ंड प्रक्रिया आपका पक्ष पूछती है। जब किसी चार्जबैक को डेवलपर समीक्षा की ज़रूरत होती है, तो आपके पास orders.reviewrefund के ज़रिए APPROVE, DECLINE या NEUTRAL रिफ़ंड प्राथमिकता और खरीदारी के उपयोग के सबूत के साथ जवाब देने के लिए 24 घंटे होते हैं। RefundHalt आपके पास पहले से मौजूद उपयोग डेटा का इस्तेमाल करके, इसी समय-सीमा के भीतर आपकी ओर से उस समीक्षा का जवाब देता है, ताकि विवादित ऑर्डर को चुप्पी के बजाय आपके सबूत मिलें।

ऑर्डर ID वाले सपोर्ट टिकट के लिए एक छोटी चेकलिस्ट

• Google Play रसीद से पूरी ऑर्डर ID माँगें, सफ़िक्स सहित।
• उसे Play Console में या orders.get से खोजें और पहले उसकी स्थिति जाँचें।
• पुष्टि करें कि चार्ज की तारीख ग्राहक के बताए विवरण से मेल खाती है।
• रिफ़ंड करें और रद्द करें सिर्फ़ सबसे हाल के ऑर्डर पर इस्तेमाल करें, और केवल रिफ़ंड करें पुराने ऑर्डर पर।
• जिस ऑर्डर ID का रिफ़ंड किया, उसे दर्ज करें, ताकि किसी दूसरे ऑर्डर पर बाद में आने वाला चार्जबैक आसानी से पकड़ में आए।