रिफंड हैंडलिंग चुपचाप टूटती है, इसलिए किसी असली ग्राहक से पहले sandbox में in-app purchase रिफंड टेस्ट करें
आपकी रिफंड हैंडलिंग तभी चलती है जब ग्राहक पहले ही जा चुका होता है, इसलिए इसमें कोई बग असली पैसे खर्च होने तक अदृश्य रहता है। दोनों स्टोर आपको पहले एक टेस्ट माहौल में रिफंड ट्रिगर करने देते हैं। यहाँ बताया गया है कि किसी रिफंड के असली होने से पहले App Store और Google Play पर in-app purchase रिफंड कैसे टेस्ट करें।
मुख्य बातें
- Xcode की StoreKit टेस्टिंग आपको Transaction Manager में रिफंड एरो पर क्लिक करके किसी खरीद को स्थानीय रूप से रिफंड करने देती है, जो आपके ऐप के Transaction.updates listener को ट्रिगर करता है, लेकिन यह Apple से कभी संपर्क नहीं करता, इसलिए कोई App Store Server Notification नहीं भेजा जाता।
- Apple पर सर्वर साइड टेस्ट करने के लिए, एक sandbox App Store Server Notifications V2 URL को अपने backend की ओर इंगित करें: फिर एक sandbox रिफंड आपके सर्वर पर एक असली REFUND, और एक रिफंड अनुरोध एक CONSUMPTION_REQUEST पहुँचाता है।
- Apple का Request a Test Notification endpoint आपके कॉन्फ़िगर किए गए URL पर TEST प्रकार की एक नोटिफिकेशन भेजता है और एक testNotificationToken लौटाता है, ताकि आप किसी असली इवेंट के फायर होने से पहले पुष्टि कर सकें कि आपका webhook पहुँच योग्य है।
- Apple का sandbox किसी विफल नोटिफिकेशन को कभी दोबारा नहीं भेजता, इसलिए जो webhook sandbox के फायर होते समय बंद हो, वह इवेंट को बिना दूसरे प्रयास के छोड़ देता है, यह वही तरह की चूक है जो बाद में आपको एक असली रिफंड विंडो में महँगी पड़ती है।
- Google Play लाइसेंस टेस्टर्स को एक भुगतान विधि देता है जिसका नाम Test card, approves then charges back है, जो खरीद के कुछ ही पल बाद एक PendingRefundReviewNotification फायर करती है ताकि आप अपनी 24 घंटे की orders.reviewrefund प्रतिक्रिया का पूर्वाभ्यास कर सकें।
- Google Play पर किसी लाइसेंस टेस्टर के लिए, एक बिना acknowledge की गई खरीद production के 3 दिन के बजाय 3 मिनट बाद अपने आप रिफंड हो जाती है, इसलिए एक टूटा acknowledgment पथ टेस्टिंग में जल्दी और साफ़ तौर पर विफल होता है।
- जिस रिफंड हैंडलर को आपने कभी टेस्ट नहीं किया वही रिफंड किए गए ग्राहक की भुगतान वाली पहुँच चालू रखता है, और 3 अगस्त 2026 से एक बिना टेस्ट की गई Google Play चार्जबैक प्रतिक्रिया आपको खरीद मूल्य में से Play की सेवा शुल्क घटाकर, साथ ही बैंक का शुल्क, चुका सकती है।
आपकी रिफंड हैंडलिंग वह एकमात्र कोड पथ है जो तभी चलता है जब ग्राहक पहले ही जा चुका होता है। आपकी सामान्य QA में कुछ भी इसे नहीं छूता, क्योंकि इस तक पहुँचने के लिए आपको सचमुच रिफंड पाना पड़ता है। इसलिए यह बिना टेस्ट के शिप होता है, महीनों चुप बैठा रहता है, और फिर किसी असली रिफंड पर विफल होता है, जहाँ विफलता एक लाल टेस्ट के बजाय पैसे खर्च कराती है। इसका उपाय है रिफंड को कोई ऐसी चीज़ मानना बंद करना जो आपके साथ होती है और जानबूझकर एक रिफंड ट्रिगर करना शुरू करना। Apple और Google दोनों आपको एक टेस्ट माहौल में रिफंड फायर करने और अपने सर्वर की प्रतिक्रिया देखने देते हैं। यहाँ बताया गया है कि किसी भुगतान करने वाले ग्राहक द्वारा आपके हैंडलर के टूटे होने को साबित करने से पहले App Store और Google Play पर in-app purchase रिफंड कैसे टेस्ट करें।
तीन माहौल जिनमें एक रिफंड फायर हो सकता है, और उनमें से केवल एक production है
जब आप निर्माण करते हैं तब तीन अलग जगहें हैं जहाँ एक Apple या Google रिफंड ट्रिगर हो सकता है, और वे आपस में बदली नहीं जा सकतीं। इनमें से दो आपके लिए माँग पर ट्रिगर करने योग्य हैं। तीसरा production है, जहाँ आप कभी नहीं चाहते कि किसी रिफंड बग से पहली बार मुलाकात हो। जाल यह मान लेना है कि आसान वाला, Xcode में स्थानीय टेस्टिंग, आपकी पूरी पाइपलाइन को साबित करता है। यह आपके ऐप को साबित करता है। यह आपके सर्वर के बारे में कुछ नहीं कहता।
Xcode StoreKit टेस्टिंग स्थानीय है, इसलिए यह आपके ऐप को परखती है और कुछ नहीं
Xcode की अंतर्निहित StoreKit टेस्टिंग आपके Mac पर एक कॉन्फ़िगरेशन फ़ाइल के विरुद्ध चलती है, Apple के साथ बिना किसी राउंड ट्रिप के। debug bar से StoreKit Transaction Manager खोलें, एक खरीदे गए लेनदेन को चुनें, और घुमावदार रिफंड एरो पर क्लिक करें। लेनदेन refunded में बदल जाता है और आपके ऐप का Transaction.updates listener फायर होता है, ठीक वैसे ही जैसे असल दुनिया में होता। आप असली रिफंड शीट दिखाने के लिए beginRefundRequest भी कॉल कर सकते हैं, और Xcode माहौल में आप जो समस्या चुनते हैं वह एक-से-एक एक RevocationReason पर मैप होती है, रिफंड तुरंत लागू होकर। यह साबित करने का सबसे तेज़ तरीका है कि जैसे ही revocationDate non-nil होता है आपका क्लाइंट पहुँच काट देता है। यही सब कुछ है जो स्थानीय टेस्टिंग आपको बता सकती है, क्योंकि यहाँ कुछ भी Apple के सर्वर तक कभी नहीं पहुँचता, इसलिए कोई App Store Server Notification नहीं भेजा जाता। आपका backend कुछ भी नहीं सीखता।
sandbox वह जगह है जहाँ आपका सर्वर आख़िरकार किसी रिफंड के बारे में सुनता है
अपने इंटीग्रेशन के उस आधे हिस्से को टेस्ट करने के लिए जो पैसे का फैसला करता है, आपके सर्वर को, आपको Apple के sandbox की ज़रूरत है। App Store Connect में एक sandbox App Store Server Notifications V2 URL कॉन्फ़िगर करें, किसी डिवाइस पर एक sandbox tester से साइन इन करें, और खरीदें। अब sandbox में एक रिफंड आपके backend पर एक असली REFUND नोटिफिकेशन पहुँचाता है, और किसी consumable या auto-renewable पर एक रिफंड अनुरोध एक CONSUMPTION_REQUEST पहुँचाता है, वही signed payload जो आपके production सर्वर को मिलेगा। कुछ भी ट्रिगर करने से पहले, Request a Test Notification endpoint कॉल करें। यह App Store server को आपके कॉन्फ़िगर किए गए URL पर TEST प्रकार की एक नोटिफिकेशन भेजने को कहता है और आपको एक testNotificationToken देता है, जिसे आप डिलीवरी की पुष्टि के लिए Get Test Notification Status को पास करते हैं। यदि वह राउंड ट्रिप काम नहीं करता, तो कोई असली नोटिफिकेशन भी नहीं करेगा।
| माहौल | यह क्या ट्रिगर कर सकता है | यह क्या साबित करता है | यह क्या नहीं कर सकता |
|---|---|---|---|
| Xcode StoreKit टेस्टिंग | Transaction Manager या beginRefundRequest शीट के ज़रिए एक रिफंड | आपका ऐप स्थानीय रूप से, सेकंडों में, एक रिफंड पर प्रतिक्रिया देता है | Apple से कभी संपर्क नहीं करता, इसलिए कोई सर्वर नोटिफिकेशन नहीं भेजा जाता |
| Sandbox | आपके सर्वर पर असली REFUND और CONSUMPTION_REQUEST, साथ ही माँग पर एक TEST नोटिफिकेशन | आपका backend signed payload पाता है, सत्यापित करता है, और उस पर कार्रवाई करता है | जो नोटिफिकेशन आपका endpoint पाने में विफल रहता है उसे दोबारा नहीं भेजता |
| Production | हर रिफंड, असली पैसे के लिए | यहाँ पहली बार सीखने लायक कुछ नहीं | आप किसी बग की लागत को पलट नहीं सकते |
App Store पर in-app purchase रिफंड कैसे टेस्ट करें
इसे इसी क्रम में चलाएँ, सस्ती क्लाइंट जाँच से लेकर पूरे सर्वर राउंड ट्रिप तक। हर चरण एक अलग हिस्से को परखता है, और बाद वाले वही हैं जिनके लिए production असल में आपसे बिल लेता है।
- App Store Connect में Users and Access, Integrations, In-App Purchase के तहत एक In-App Purchase key बनाएँ, और अपने App Store Server API कॉल्स पर हस्ताक्षर करने के लिए इसका उपयोग करें।
- अपने sandbox App Store Server Notifications V2 URL को अपने backend की ओर इंगित करें, फिर Request a Test Notification कॉल करें और पुष्टि करें कि
TESTpayload आता है और Apple की certificate chain के विरुद्ध सत्यापित होता है। - Xcode के Transaction Manager में, एक खरीद को रिफंड करें और पुष्टि करें कि जैसे ही
revocationDateसेट होता है आपका ऐप entitlement छोड़ देता है। - एक sandbox tester से साइन इन करें, एक consumable खरीदें, एक रिफंड का अनुरोध करें, और पुष्टि करें कि आपका सर्वर
CONSUMPTION_REQUESTपाता है और 12 घंटे की विंडो के भीतर एक Send Consumption Information उत्तर तैयार करके भेज सकता है। - एक sandbox खरीद को रिफंड करें और पुष्टि करें कि
REFUNDनोटिफिकेशन आपके सर्वर तक पहुँचता है, कि आप पहुँच रद्द करते हैं या consumable शेष घटाते हैं, और कि उसी नोटिफिकेशन की दोहराई गई डिलीवरी दोबारा लागू नहीं होती।
Google Play पर एक रिफंड और एक चार्जबैक का पूर्वाभ्यास कैसे करें
Google Play में Xcode जैसा कोई स्थानीय मोड नहीं है। सब कुछ Google के सर्वरों के विरुद्ध चलता है, लेकिन लाइसेंस टेस्टर्स इसे मुफ़्त और सुरक्षित रखते हैं। Play Console में अपने टेस्ट Google खातों को लाइसेंस टेस्टर के रूप में जोड़ें और उन्हें टेस्ट भुगतान विधियों का एक सेट मिलता है जो कभी असली पैसे नहीं चार्ज करता। Google हर टेस्ट खरीद को खरीद डायलॉग के बीच में एक सूचना के साथ चिह्नित करता है, और कर की गणना नहीं होती। रिफंड टेस्टिंग के लिए जो मायने रखता है वह यह है कि आप कौन सा टेस्ट instrument चुनते हैं, क्योंकि हर एक एक अलग परिणाम की ओर ले जाता है।
| Test payment method | यह क्या सिमुलेट करता है | आप इसका उपयोग क्यों करेंगे |
|---|---|---|
| Test instrument, always approves | एक साफ़ सफल खरीद | एक ऑर्डर तैयार करें जिसे आप फिर रिफंड या रद्द कर सकें |
| Test instrument, always declines | एक विफल भुगतान | पुष्टि करें कि किसी अस्वीकृति पर आप कुछ नहीं देते |
| Slow test card, approves after a few minutes | एक लंबित खरीद जो बाद में सफल होती है | पहुँच देने से पहले अपनी PENDING हैंडलिंग को परखें |
| Slow test card, declines after a few minutes | एक लंबित खरीद जो बाद में विफल होती है | पुष्टि करें कि एक लंबित अस्वीकृति कभी entitlement लीक नहीं करती |
| Test card, approves then charges back | एक उपयोगकर्ता द्वारा शुरू किया गया चार्जबैक | एक PendingRefundReviewNotification फायर करें और अपनी 24 घंटे की प्रतिक्रिया का पूर्वाभ्यास करें |
एक रिफंड, एक चार्जबैक, और acknowledgment ऑटो-रिफंड ट्रिगर करें
- approve-then-charge-back टेस्ट कार्ड से खरीदें, और कुछ ही पल बाद आपके Real-time Developer Notifications topic पर एक
PendingRefundReviewNotificationआता है। इसका उत्तर एक हीorders.reviewrefundकॉल से दें, क्योंकि Google केवल आपकी पहली प्रतिक्रिया रखता है। - एक
VoidedPurchaseNotificationफायर करने के लिए Play Console में Orders टैब से एक टेस्ट ऑर्डर को रिफंड और रद्द करें, और पुष्टि करें कि आपका सर्वर entitlement खींच लेता है। - किसी लाइसेंस टेस्टर की खरीद को जानबूझकर बिना acknowledge छोड़ दें। Google इसे production द्वारा दिए गए 3 दिन के बजाय 3 मिनट बाद अपने आप रिफंड कर देता है, और आपको रद्दीकरण का ईमेल भेजता है, इसलिए एक टूटा acknowledgment पथ मिनटों में सामने आता है, production में चौथे दिन नहीं।
एक बिना टेस्ट किया रिफंड पथ असल में क्या खर्च कराता है
एक रिफंड हैंडलर सजावट नहीं है। यह वह कोड है जो आपको किसी ऐसे व्यक्ति की सेवा करने के लिए भुगतान करने से रोकता है जो अब आपको भुगतान नहीं करता। जब यह चुपचाप विफल होता है, तब रिफंड फिर भी हो जाता है, लेकिन उसके पीछे की पहुँच, शेष, और खर्च नहीं रुकते।
पैसे के रास्ते पर चलें। जब Apple या Google किसी खरीद को रिफंड करता है, तो आप बिक्री मूल्य लौटाते हैं और स्टोर अपना कमीशन लौटाता है, यहाँ तक तो खाता बराबर है। जो वापस नहीं आता वह है वह सब कुछ जो आप उत्पाद पहुँचाने में पहले ही खर्च कर चुके हैं: एक जनरेट किए गए परिणाम के पीछे का compute, model API कॉल्स, उपयोगकर्ता द्वारा सहेजे गए के लिए storage, वह payout जो आप पहले ही किसी creator को भेज चुके हैं। एक रिफंड हैंडलर जो पहुँच कभी रद्द नहीं करता, एक रिफंड किए गए उपयोगकर्ता को वे सब आपके बजट पर खर्च करते रहने देता है, सिस्टम में उन्हें रोकने के लिए कुछ बचा नहीं।
दो साक्ष्य विंडो इसे और तीखा बनाती हैं। एक CONSUMPTION_REQUEST जिसे आपने sandbox में कभी नहीं परखा, वह एक उत्तर है जिसे आप विकृत या देर से भेजते हैं, और Apple अक्सर रिफंड डिफ़ॉल्ट रूप से मंज़ूर कर देता है जब आपका उत्तर 12 घंटे के भीतर नहीं पहुँचता। एक Google Play चार्जबैक प्रतिक्रिया जिसे आपने कभी टेस्ट कार्ड से फायर नहीं किया, वह एक 24 घंटे की विंडो है जिसे आप लाइव फंबल करते हैं, और 3 अगस्त 2026 से एक हारा हुआ Play चार्जबैक आपको खरीद मूल्य में से Play की सेवा शुल्क घटाकर, साथ ही बैंक का चार्जबैक शुल्क, चुकाता है। इनमें से हर विफलता को पहले एक टेस्ट माहौल में मुफ़्त में दोहराया जा सकता है। इनमें से कोई भी production में सस्ती नहीं है।
| बिना टेस्ट किया पथ | यह production में कैसे विफल होता है | यह आपको क्या खर्च कराता है |
|---|---|---|
| REFUND handler | एक रिफंड किया गया उपयोगकर्ता पहुँच बनाए रखता है | वह compute, API कॉल्स, storage, और payouts जो आप उन पर खर्च करते रहते हैं |
| CONSUMPTION_REQUEST reply | विकृत, या 12 घंटे के बाद भेजा गया | Apple रिफंड डिफ़ॉल्ट रूप से मंज़ूर कर देता है, इसलिए आप बिक्री और खर्च दोनों खो देते हैं |
| orders.reviewrefund response | 24 घंटे के भीतर चूका या गलत | 3 अगस्त 2026 से, खरीद मूल्य में से Play की सेवा शुल्क घटाकर, साथ ही बैंक का चार्जबैक शुल्क |
रिफंड हैंडलिंग शिप करने से पहले एक छोटी चेकलिस्ट
आपको एक लैब की ज़रूरत नहीं है। आपको बस एक बार हर इवेंट को अपने कोड से टकराते देखना है।
- आपका ऐप उसी पल पहुँच छोड़ देता है जब एक StoreKit लेनदेन एक
revocationDateदिखाता है, Xcode के Transaction Manager में पुष्टि की गई। - आपका sandbox सर्वर URL एक
TESTनोटिफिकेशन पाता है और उसे Apple के certificates के विरुद्ध सत्यापित करता है। - एक sandbox
REFUNDपहुँच रद्द करता है या शेष घटाता है, और एक दोहराई गई डिलीवरी दोबारा गिनती नहीं करती। - एक sandbox
CONSUMPTION_REQUEST12 घंटे के भीतर एक वैध Send Consumption Information उत्तर तैयार करता है। - चार्जबैक टेस्ट कार्ड से एक Google
PendingRefundReviewNotificationठीक एकorders.reviewrefundकॉल तैयार करता है। - एक बिना acknowledge की गई Google Play टेस्ट खरीद 3 मिनट में अपने आप रिफंड होती है और आपका reconciliation इसे नोटिस करता है।
उस सूची को एक बार चलाएँ और रिफंड हैंडलिंग वह कोड बनना बंद कर देती है जिसके काम करने की आप उम्मीद करते हैं। यह वह कोड बन जाता है जिसे आपने काम करते देखा है।
अक्सर पूछे जाने वाले सवाल
- क्या मैं किसी असली खरीद के बिना एक App Store रिफंड टेस्ट कर सकता हूँ?
- हाँ। Xcode की StoreKit टेस्टिंग आपको Transaction Manager के ज़रिए किसी खरीद को स्थानीय रूप से रिफंड करने देती है, बिना असली पैसे और बिना App Store खाते के, जो आपके ऐप के Transaction.updates listener को फायर करता है। यह एक सर्वर नोटिफिकेशन नहीं भेजता, इसलिए यह केवल आपके ऐप को टेस्ट करता है, आपके backend को नहीं।
- क्या स्थानीय StoreKit टेस्टिंग App Store Server Notifications भेजती है?
- नहीं। Xcode की StoreKit टेस्टिंग पूरी तरह आपके Mac पर एक स्थानीय कॉन्फ़िगरेशन के विरुद्ध चलती है और Apple के सर्वरों से कभी संपर्क नहीं करती, इसलिए REFUND या CONSUMPTION_REQUEST सहित कोई App Store Server Notification कभी नहीं भेजा जाता। अपने सर्वर को टेस्ट करने के लिए sandbox का उपयोग करें।
- मैं एक Google Play चार्जबैक प्रतिक्रिया कैसे टेस्ट करूँ?
- Test card, approves then charges back नाम की लाइसेंस-टेस्टर भुगतान विधि का उपयोग करें। यह खरीद के कुछ ही पल बाद एक PendingRefundReviewNotification फायर करती है, वही नोटिफिकेशन जो एक असली बैंक चार्जबैक भेजता है, ताकि आप अपनी 24 घंटे की orders.reviewrefund उत्तर का पूर्वाभ्यास कर सकें।
- मेरी Google Play टेस्ट खरीद कुछ मिनटों बाद रिफंड क्यों हो जाती है?
- लाइसेंस टेस्टर्स के लिए, यदि आपके ऐप ने किसी खरीद को acknowledge नहीं किया है तो Google उसे 3 मिनट बाद अपने आप रिफंड कर देता है, और आपको रद्दीकरण का ईमेल भेजता है। Production 3 दिन इंतज़ार करता है, लेकिन टेस्टर्स को तेज़ किया गया संस्करण मिलता है ताकि एक टूटा acknowledgment पथ जल्दी सामने आए।
- क्या Apple का sandbox एक विफल रिफंड नोटिफिकेशन दोबारा भेजता है?
- नहीं। sandbox App Store Server Notifications दोबारा नहीं भेजता, इसलिए यदि जब एक sandbox रिफंड फायर होता है तब आपका endpoint बंद हो, तो नोटिफिकेशन बिना दूसरे प्रयास के छोड़ दिया जाता है। पहले Request a Test Notification से पुष्टि करें कि आपका URL पहुँच योग्य है।
स्रोत और आगे की जानकारी
- Apple Developer: Testing refund requests
- Apple Developer: Testing App Store server notifications
- Apple Developer: Request a Test Notification (App Store Server API)
- Apple Developer: Testing In-App Purchases with the sandbox
- Android Developers: Test your Google Play Billing Library integration
- Android Developers: Help Google dispute chargebacks (orders.reviewrefund)
- Play Console Help: Updates to refund protection and chargeback cost responsibility
RefundHalt
App Store और Google Play के लिए refund ऑटोपायलट
आगे पढ़ें
किसी रिफंड की लागत आपके ऐप के लिए उस कीमत से कहीं ज्यादा है जो आप वापस लौटाते हैं
रिफंड की गई कीमत बिल की सबसे छोटी पंक्ति है। रिफंड स्टोर का कमीशन भी उलट देता है, इसलिए आप अपना हिस्सा खोते हैं, और जो कंप्यूट, API कॉल, स्टोरेज और भुगतान आप पहले ही खर्च कर चुके हैं वे चले जाते हैं। 3 अगस्त, 2026 के बाद Google Play चार्जबैक इसके ऊपर बैंक का शुल्क जोड़ देता है। यहाँ पूरा बिल है।
सब्सक्रिप्शन रिफंड, वन-टाइम रिफंड की तरह काम नहीं करते, और आप जिस स्टोर पर हैं वही तय करता है कि आपकी कितनी चलेगी
एक सब्सक्रिप्शन रिफंड पूरी बिलिंग अवधि को उलटता है, एक अकेली बिक्री को नहीं। App Store पर Apple फैसला करता है और आपका सर्वर सिर्फ़ परिणाम जान पाता है। Google Play पर आप खुद पूरा या आनुपातिक रिफंड चुनते हैं। यह रहा कि हर स्टोर सब्सक्रिप्शन रिफंड को कैसे संभालता है, और एक रिफंड की आपको क्या लागत पड़ती है।