एक purchase क्लियर होती है, customer को उसका product मिल जाता है, और तीन दिन बाद वह गायब हो जाता है। Google Play charge को reverse कर देता है और entitlement वापस खींच लेता है, बिना customer के माँगे और बिना आपकी support team के किसी सदस्य के कोई बटन दबाए। Purchase चुपचाप fail हो गई क्योंकि आपके server ने Google को कभी बताया ही नहीं कि उसे handle कर लिया गया है।
बस यही पूरा rule है: Google Play की किसी purchase को तीन दिन के अंदर acknowledge करें, वरना Google उसे auto-refund करके revoke कर देता है। हर बार, बिना किसी अपवाद के। किसी भी store पर sale के reverse होने के तमाम तरीकों में से, यह उन चुनिंदा तरीकों में से एक है जो पूरी तरह आपके अपने integration के भीतर है, जिससे यह revenue को सबसे चुपचाप बहाने वाले तरीकों में से भी एक बन जाता है।
यह कोई fraud check नहीं है और न ही कोई policy decision। यह एक ऐसा callback है जो कभी fire ही नहीं हुआ। इसे ठीक करना छोटा-सा काम है, लेकिन इसे नज़रअंदाज़ करने से जो पैसा आप गँवाते हैं वह छोटा नहीं है, इसलिए यह जानना ज़रूरी है कि rule असल में क्या कहता है, purchases इससे कैसे चूक जाती हैं, और हर गायब हुई sale अपने साथ क्या-क्या ले डूबती है।
Google का documentation असल में क्या माँगता है
Play Billing के मुताबिक़ आपके app को Google को सूचित करना ज़रूरी है, जैसे ही वह entitlement दे चुका हो और user को बता चुका हो कि purchase सफल रही। Google का documentation इस पर एक सख्त संख्या तय करता है: यह notification "तीन दिन के भीतर करना ज़रूरी है ताकि purchase अपने आप refund न हो और entitlement revoke न हो।" One-time product की docs भी बिना किसी ढील के यही बात दोहराती हैं। Acknowledgement छोड़ दें तो "user को अपने आप refund मिल जाता है, और Google Play purchase को revoke कर देता है।" Subscription की शुरुआती purchase भी बिल्कुल यही rule follow करती है।
Acknowledgement कोई कागज़ी कार्रवाई नहीं है। यह अकेला ऐसा signal है जो Google के पास यह बताने के लिए है कि delivery असल में हुई। कोई signal न मिलने का मतलब है कि Google यह मान लेता है कि कुछ भी deliver नहीं हुआ, इसलिए वह आपसे पूछे बिना buyer के लिए पूरा लेन-देन reverse कर देता है। Buyer को एक अप्रत्याशित refund दिखता है। आपको अपनी बहीखातों से गायब हुई एक sale दिखती है।
मुख्य बातें
किसी sale को 72 घंटे तक unconfirmed छोड़ दें और reversal अपने आप हो जाता है: buyer को पैसा वापस, entitlement वापस, किसी से कुछ नहीं पूछा गया। इसे किसी shopper ने trigger नहीं किया। यह आपके backend ने किया, कुछ न बोलकर, और आपका backend इसे रोक भी उतनी ही आसानी से सकता है।
PURCHASED state तक पहुँचना ही countdown शुरू करता है, जिससे checkout का पल आपकी deadline के लिए बेमानी हो जाता है। जो कुछ भी PENDING में टिका है उस पर कोई timer नहीं लगा होता और उसे अभी किसी confirmation call की ज़रूरत नहीं।
दो में से कोई भी call यह जिम्मेदारी पूरी कर देती है। किसी consumable पर purchases.products.consume चलाएँ, या जो consumable नहीं है उस पर purchases.products.acknowledge और purchases.subscriptions.acknowledge का इस्तेमाल करें। Google हर एक को सामान पहुँचने के सबूत के रूप में मानता है।
Subscriptions यह काम आपसे ठीक एक बार, signup के वक़्त माँगती हैं। इसके बाद का हर billing cycle Google खुद निपटा देता है, और आपके code को कुछ भी किए बिना confirmed के रूप में flag कर देता है।
कोई prepaid plan बेच रहे हैं जो सात दिन से कम चलता है? आपकी मोहलत plan की अवधि के पचास प्रतिशत तक सिमट जाती है। जितना छोटा product, उतनी ही छोटी fuse।
सिर्फ ticket price ही shopper के पास वापस जाती है। Compute time, model API पर खर्च, storage bills, creator payouts: यह पैसा fulfilment के दौरान आपके account से निकल चुका था और इसमें से कुछ भी वापस नहीं आता। असली नुकसान refund की लाइन में दिखाए गए आँकड़े से कहीं ज़्यादा होता है।
iOS पर ऐसा कुछ भी नहीं होता। StoreKit हर launch पर किसी अधूरे transaction को फिर से सामने लाता है और धैर्य से इंतज़ार करता है, charge को कभी reverse नहीं करता। यह खास तरह का खतरा सिर्फ Google Play पर है, कहीं और नहीं।
Deadline checkout से शुरू नहीं होती
"Buy" पर टैप करना timer शुरू नहीं करता। Purchase की state पहले PURCHASED में बदलनी चाहिए, और कुछ purchases इससे पहले PENDING में टिकी रहती हैं। Cash payment methods ऐसा करते हैं, धीमे bank transfers और parent-approval requests भी। Google इसे सीधे शब्दों में कहता है: "तीन दिन की acknowledgement window तभी शुरू होती है जब purchase की state PENDING से PURCHASED में बदलती है।"
इसका मतलब है कि आपके flow बनाने के तरीके पर दो असर पड़ते हैं। Entitlement तभी दें जब state PURCHASED दिखाए, PENDING में कभी नहीं, वरना आप उस पैसे के बदले product दे देंगे जो असल में आया ही न हो। और किसी PENDING purchase को भी acknowledge न करें, क्योंकि अभी acknowledge करने के लिए कुछ है ही नहीं। BillingClient सेट करते वक़्त enablePendingPurchases() को कॉल करें, state के बदलने का इंतज़ार करें, और गिनती तभी शुरू करें जब वह PURCHASED पर पहुँच जाए।
PENDING को "अभी बिका नहीं" समझें। कुछ भी देय नहीं है: न entitlement, न acknowledgement, न कुछ revenue के रूप में दर्ज। जिस पल यह PURCHASED में बदलती है, उसी पल entitlement और तीन दिन का countdown दोनों आपकी समस्या बन जाते हैं।
आपने जो बेचा उसके लिए सही API call चुनना
दो API paths deadline को क्लियर करते हैं, और कौन-सा लागू होगा यह इस पर निर्भर करता है कि आपने क्या बेचा। दोनों requirement को समान रूप से पूरा करते हैं। जो चीज़ उन्हें अलग करती है वह यह है कि वे बाद में product के साथ और क्या करते हैं।
Consumables को consume किया जाता है। यह है किसी secure backend पर purchases.products.consume, या client पर Play Billing Library का consumeAsync()। Consume करना दोहरा काम करता है, क्योंकि यह acknowledgement की requirement भी पूरी करता है और item को दोबारा खरीदने लायक भी बना देता है। Coins, credits, या किसी भी one-shot generation के लिए यही चाहिए जिसे customer बार-बार खरीद सकता है।
Non-consumables और subscriptions को इसकी बजाय acknowledge किया जाता है, purchases.products.acknowledge, purchases.subscriptions.acknowledge, या client पर acknowledgePurchase() के ज़रिए। यह deadline को क्लियर कर देता है लेकिन item को दोबारा purchase के लिए नहीं खोलता।
यहाँ देखें कि हर product type किस call और deadline से जुड़ता है:
किसी consumable के लिए, purchases.products.consume या consumeAsync() को कॉल करें। इससे item दोबारा खरीदने लायक भी बन जाता है, और आपकी deadline PURCHASED से तीन दिन है।
किसी non-consumable के लिए, purchases.products.acknowledge या acknowledgePurchase() को कॉल करें। Entitlement बिना दोबारा purchase के confirm हो जाती है, और आपकी deadline PURCHASED से तीन दिन है।
किसी subscription की शुरुआती purchase के लिए, purchases.subscriptions.acknowledge या acknowledgePurchase() को कॉल करें। इससे नया subscription confirm हो जाता है, और आपकी deadline PURCHASED से तीन दिन है।
किसी subscription renewal के लिए, आपको कोई call करने की ज़रूरत ही नहीं। Google इसे अपने आप acknowledged mark कर देता है, इसलिए कोई deadline नहीं है।
किसी हफ़्ते से छोटे prepaid plan के लिए, वही acknowledgement calls इस्तेमाल करें, लेकिन आपकी deadline सिमटकर plan की अवधि के आधे पर आ जाती है।
यह जिम्मेदारी पहली payment पर ही खत्म हो जाती है
Subscription renewals को acknowledgement की ज़रूरत बिल्कुल नहीं होती। Google सीधे कहता है: "आपको subscription renewals को acknowledge करने की ज़रूरत नहीं है," और यह हर एक को अपने आप acknowledged mark कर देता है। यह subscription की बिल्कुल पहली purchase होती है जो pending acknowledgement state में आती है और जब तक आप उसे क्लियर नहीं करते तब तक आपके हिस्से रहती है। कोई भी कार्रवाई करने से पहले server-side पर acknowledgement state चेक करें, या client पर isAcknowledged() इस्तेमाल करें। इस तरह आप कभी भी duplicate acknowledgement call नहीं भेजते।
Short-term prepaid plans के लिए एक सख़्त घड़ी
एक हफ़्ते या उससे लंबे prepaid plans standard तीन दिन के rule को follow करते हैं। छोटे plans नहीं करते। Google का documentation कहता है कि "एक हफ़्ते से कम अवधि वाले plans को plan की अवधि के आधे समय के भीतर acknowledge करना ज़रूरी है।" एक तीन दिन का prepaid plan आपको डेढ़ दिन देता है, पूरी window नहीं। अगर छोटे prepaid top-ups आपके catalog का हिस्सा हैं, तो acknowledgement का रास्ता तेज़ और server-driven होना चाहिए, कभी भी customer के app दोबारा खोलने पर निर्भर नहीं।
Acknowledgement call आमतौर पर कहाँ खो जाती है
कोई भी जान-बूझकर इस step को नहीं छोड़ता। यह इसलिए गायब हो जाता है क्योंकि acknowledgement की logic गलत trigger से जुड़ी होती है। आम anti-pattern वह client है जो तभी acknowledge करता है जब purchase flow वापस foreground में आता है। यह उस customer को cover करता है जो खरीदारी पूरी करके तुरंत app इस्तेमाल करता रहता है। यह बाकी किसी को cover नहीं करता।
Developers को यह लगातार झेलना पड़ता है। Google की अपनी developer community में threads हर बार एक जैसी ही कहानी दोहराते हैं, किसी user को खरीदारी के तीन दिन बाद अपने आप refund मिल जाने का कोई-न-कोई version, या यह समझने की गुहार कि payments दिन तीन पर खुद-ब-खुद reverse क्यों होते रहते हैं। निदान शायद ही कभी बदलता है: acknowledgement call किसी ऐसे user action से जोड़ी गई थी जो कभी हुआ ही नहीं, इसलिए वह बस कभी fire ही नहीं हुई।
Free trials और वह customer जो app दोबारा कभी नहीं खोलता
इसका सबसे भद्दा version है एक free trial, या वह purchase जो किसी के आपका app हमेशा के लिए बंद करने से ठीक पहले के आख़िरी पलों में की गई हो। जब acknowledgement अगले app open का इंतज़ार करती है और अगला app open कभी आता ही नहीं, तो purchase बस समय के साथ expire हो जाती है। Google उसे दिन तीन पर refund और revoke कर देता है। जो trial convert होने की राह पर था, उसके लिए आप वह पहली billing गँवा देते हैं जो आप कभी charge ही नहीं कर पाए, और साथ ही एक customer entitlement भी चुपचाप गायब हो जाता है। इनमें से कोई भी आपकी support queue में नहीं दिखता। अगर आप ढूँढें, तो दोनों एक voided purchase के रूप में दिखते हैं।
जो acknowledgement अगले app open पर निर्भर है वह हर बार एक sale है जो आप तब गँवाते हैं जब कोई customer तीन दिन तक दूर रहता है। Trials और one-tap purchases ठीक वही पल होते हैं जब customers दूर रहते हैं।
किसी unacknowledged refund के पीछे का असली बिल
Refund की लाइन यह कम करके दिखाती है कि आपने असल में क्या गँवाया। Google sale को reverse करता है, आप कीमत वापस कर देते हैं, और यही वह संख्या है जो सब देखते हैं। यह पूरा बिल नहीं है।
एक ऐसा consumable लें जो किसी के खरीदते ही असली काम शुरू कर देता है। Image generations का एक batch, किसी model provider के API पर calls की एक सीरीज़, एक video export, किसी creator को देय एक payout। आपने उस compute, उन API calls, उस storage, और उन payouts के लिए इस्तेमाल के वक़्त ही पैसा चुका दिया था। Refund customer को sale price वापस कर देता है। यह provider का invoice आपको वापस नहीं करता। असली लागत बाहर जा चुकी थी और उसके बदले कुछ भी वापस नहीं आया।
Subscriptions और trials के लिए, नुकसान है वह पहली billing जो आप कभी collect ही नहीं कर पाते, साथ ही एक customer relationship जो शुरू होने से पहले ही खत्म हो गया। और दांव अब और बढ़ने वाले हैं। 3 अगस्त, 2026 से, Google Play उस तारीख़ के बाद किए गए orders के लिए chargeback की purchase price और bank fees developers पर डाल देगा, जिससे किसी भी टाले जा सकने वाले leak को अभी सील कर लेना बाद में करने से बेहतर है। Unacknowledged refund कोई chargeback नहीं है, लेकिन यह वही सबक सिखाता है। जो पैसा आप पहले ही खर्च कर चुके हैं वह अपने आप आपका बचा हुआ पैसा नहीं बन जाता।
Acknowledgement step को इस तरह बनाना कि वह चूके ही नहीं
भरोसेमंद pattern आपके app को critical path से पूरी तरह हटा देता है। इसे अपने backend पर चलाएँ, notifications से संचालित, न कि इस बात से कि कोई screen दोबारा खोलता है या नहीं।
Real-time developer notifications को subscribe करें। एक one-time product purchase event, या एक subscription purchase event, आपके server तक उसी पल पहुँच जाता है जब Google sale को register करता है, चाहे app चल रहा हो या नहीं।
Play Developer API के ज़रिए purchase token को validate करें और पुष्टि करें कि state PENDING नहीं बल्कि PURCHASED दिखाती है।
Entitlement को अपने सिस्टम में दर्ज करें, उस customer के account से जोड़कर।
बिना देर किए consume या acknowledge करें। Consumables consume होते हैं, non-consumables और initial subscriptions acknowledge होते हैं। पहले acknowledgement state पढ़ें ताकि call कभी दो बार न जाए।
एक client-side backfill बनाए रखें। onResume() में queryPurchasesAsync() को कॉल करना वह सब कुछ पकड़ लेता है जो app बंद रहते वक़्त settle हुआ था। इसे main route नहीं, बीमा समझें।
पूरी बात यह है कि acknowledgement उस event से fire होती है जो Google आपको देता है, न कि किसी ऐसे user action से जिसकी गारंटी आपके पास नहीं है। जो कोई एक बार खरीदकर कभी वापस नहीं आता वह भी पूरी तरह cover रहता है, क्योंकि आपके server ने purchase आते ही वह काम पहले ही कर दिया था।
जो कुछ फिर भी निकल जाए उसके लिए एक backstop
Pipeline चाहे कितना भी अच्छा बना हो, उसके नीचे फिर भी एक safety net होनी चाहिए। Google का Voided Purchases API उन orders की सूची देता है जो refund, revocation, या chargeback पर खत्म हुए, और वह उस खास scenario को अलग से चिह्नित करता है जहाँ वजह यह थी कि purchase "कभी developer द्वारा acknowledge नहीं की गई, और इसलिए शायद developer के records में मौजूद ही न हो।" इसे एक नियमित rhythm पर query करें और आप उन सबकी access हटा सकते हैं जिनका order Google ने आपकी जानकारी के बिना चुपचाप undo कर दिया है। हालाँकि एक सीमा का ध्यान रखें: सिर्फ पिछले 30 दिन ही retrieve किए जा सकते हैं, जिससे यह एक scheduled job बन जाता है, न कि कोई ऐसा काम जिसे आप हर तिमाही देख लें।
iOS को कभी आपके साथ ऐसा करने के लिए नहीं बनाया गया
App Store की तरफ़ जाएँ तो इसमें से कुछ भी लागू नहीं होता। Apple ने अपना एक अलग closing step बनाया है, transaction को finish करना, सिवाय इसके कि इसे छोड़ देने का penalty उल्टी दिशा में चलता है। एक अधूरा transaction Apple की queue में टिका रहता है। यह हर app launch पर फिर से सामने आता है, और फिर जब भी observer attach होता है, जिससे आपको बार-बार मौक़ा मिलता है वह देने का जो customer ने पैसे देकर खरीदा था। Apple इस पर कोई reversal जारी नहीं करता। उस platform पर 72 घंटे के किसी refund trigger जैसा कुछ भी मौजूद नहीं है।
यही वजह है कि एक अकेला mental model दोनों stores पर फिट नहीं बैठ सकता। Android आपको एक countdown और एक ऐसी sale देता है जो आपके हारते ही भाप बन जाती है। iOS आपको एक लगातार याद दिलाने वाला reminder और उसका जवाब देने के लिए असीमित समय देता है। iOS की आदतों को Android codebase में ले आएँ, तो देर-सवेर आप reversed orders के ढेर को घूरते रह जाएँगे जिसका हिसाब team में कोई नहीं दे पाएगा।
इस gap को सील करना ठीक वही काम है जो Refund Sensor करता है। Confirmation सीधे store notification से fire होती है, उसके आते ही कुछ ही पलों में, जबकि Voided Purchases API के मुक़ाबले एक लगातार चलने वाला reconciliation pass हर जगह से access हटा देता है जहाँ Google पहले ही आपकी जानकारी के बिना कोई order undo कर चुका है। जो countdown आप हार सकते थे, वह एक ऐसा box बन जाता है जो आपके चेक करने के बारे में सोचने से पहले ही tick हो चुका होता है।
ये rules कहाँ documented हैं
अक्सर पूछे जाने वाले प्रश्न
आपके server ने समय पर acknowledgement call भेजी ही नहीं। जब कोई purchase PURCHASED तक पहुँचने के तीन दिन बाद भी acknowledge नहीं होती, तो Google sale को reverse कर देता है और entitlement अपने आप वापस ले लेता है। यह customer की कोई गलती नहीं है, और न ही यह Google की कोई penalty है। यह सिर्फ एक missing acknowledgement call है, और store notification से server-side acknowledge करने से यह समस्या पूरी तरह खत्म हो जाती है।
दोनों ही तीन दिन की timer को रोक देते हैं, लेकिन product को अलग-अलग स्थिति में छोड़ते हैं। Consume करना, purchases.products.consume या consumeAsync() के ज़रिए, consumables के लिए होता है। यह deadline को क्लियर कर देता है और item को दोबारा बिक्री के लिए उपलब्ध कर देता है। Acknowledge करना, purchases.products.acknowledge, purchases.subscriptions.acknowledge, या acknowledgePurchase() के ज़रिए, non-consumables और subscriptions के लिए होता है। यह product को दोबारा खरीदने लायक बनाए बिना entitlement की पुष्टि करता है।
नहीं, सिर्फ पहली purchase को। Google renewals को acknowledge करने की ज़रूरत नहीं रखता और उन्हें अपने आप acknowledged के रूप में mark कर देता है। सिर्फ subscription की शुरुआती purchase, जो pending acknowledgement state में आती है, तब तक आपकी जिम्मेदारी बनी रहती है जब तक आप उसे क्लियर नहीं करते।
नहीं, PURCHASED का इंतज़ार करें। कोई PENDING purchase, जैसे cash payment या parent-approval request, तीन दिन की timer को बिल्कुल भी शुरू नहीं करती। Entitlement तभी दें और acknowledgement तभी भेजें जब state वास्तव में PENDING से PURCHASED में बदल चुकी हो।
नहीं, और यह जानना ज़रूरी है इससे पहले कि आप मान लें कि Android और iOS एक जैसा व्यवहार करते हैं। एक अधूरा StoreKit transaction हर app launch पर फिर से deliver होता रहता है जब तक आप उसे finish नहीं करते। Apple इसे कभी auto-refund नहीं करता। तीन दिन का auto-refund सिर्फ Google Play में होता है, इसलिए दोनों platforms को अलग-अलग तरीके से handle करना पड़ता है।
Refund को खुद वापस नहीं पलटा जा सकता। आप जो कर सकते हैं वह है reconcile करना। Voided Purchases API पिछले 30 दिनों की refunded और revoked purchases दिखाता है और खासतौर पर उन्हें flag करता है जो सिर्फ इसलिए void हुईं क्योंकि उन्हें कभी acknowledge नहीं किया गया, ताकि आप वह entitlement वापस ले सकें जो आपने दी थी। आगे से, store notification से acknowledge करना ही अगली purchase को फिसलने से बचाता है।
