संक्षिप्त उत्तर: Google Play आपको यह जानने के दो तरीके देता है कि कोई purchase रिफंड या revoke किया गया था। Real-time Developer Notifications (RTDN) events होने के तुरंत बाद उन्हें Google Cloud Pub/Sub के माध्यम से आपके सर्वर पर push करता है। Voided Purchases API आपको मांग पर voided purchases की सूची pull करने देता है। ये विकल्प नहीं हैं, RTDN आपको स्पीड देता है, Voided Purchases API आपको एक सेफ्टी नेट देता है, और एक भरोसेमंद सेटअप दोनों का उपयोग करता है ताकि कुछ भी छूटे नहीं।
Google आपको दो मैकेनिज़्म क्यों देता है
Google Play पर, ज्यादातर रिफंड आपसे पूछे बिना होते हैं, Google उन्हें जारी करता है, entitlement को revoke करता है, और आपका काम यह पता लगाना है ताकि आपका ऐप और एनालिटिक्स सटीक बने रहें। (आप क्या contest कर सकते हैं और क्या नहीं, इसके लिए देखें Google Play Refunds & Chargebacks.)
Google इसका पता लगाने के लिए दो अलग-अलग टूल्स देता है, और वे इस समस्या को विपरीत दिशाओं से हल करते हैं। एक events होने पर आपको push करता है। दूसरा आपको जब चाहें सूची मांगने देता है। साथ में उपयोग करने पर ये एक-दूसरे की कमजोरियों को कवर करते हैं; अलग-अलग उपयोग करने पर, हर एक में एक गैप रह जाता है।
android रिफंड ट्रैकिंग पर फोकस करने वाले डेवलपर्स के लिए, इस अंतर को समझना जरूरी है क्योंकि एक real-time event stream और एक historical reconciliation मैकेनिज़्म रिफंड-मॉनिटरिंग समस्या के अलग-अलग हिस्सों को हल करते हैं।
Real-time Developer Notifications (push)
Real-time Developer Notifications (RTDN) push मैकेनिज़्म है। जब किसी subscription या purchase के साथ कुछ होता है, जिसमें रिफंड और voided purchases शामिल हैं, Google एक event को Google Cloud Pub/Sub topic पर publish करता है जिसे आपका backend subscribe करता है। मुख्य बात तुरंतता है: आपको event के बारे में उसके होने के करीब पता चल जाता है, बजाय इसके कि आप इसे घंटों बाद खोजें।
RTDN Google Play इंटीग्रेशन खोजने वाले डेवलपर्स के लिए, यह वह मैकेनिज़्म है जो Google Play billing events को आपके backend से जोड़ता है। किसी भी समय-संवेदनशील मामले के लिए, जैसे chargeback review, जहां आपके पास जवाब देने के लिए लगभग 24 घंटे होते हैं, यह तुरंतता ही सबकुछ है। अगर आप समय-समय पर चेक करने पर निर्भर हैं, तो आप वह समय पहले ही खो चुके हैं जो आपके पास नहीं था।
पेंच यह है: RTDN Pub/Sub पर चलता है, जिसका मतलब है Google Cloud project सेटअप, एक topic, Google Play के लिए सही publish permissions, और आपकी तरफ एक subscriber। यह एक सिंगल webhook से ज्यादा moving parts है, और यहीं पर कई डेवलपर्स अटक जाते हैं।
The Voided Purchases API (pull)
Google Play Voided Purchases API pull मैकेनिज़्म है। यह उन orders की सूची लौटाता है जो voided, refunded, charged back, या revoked किए गए हैं, जिसे आप मांग पर query कर सकते हैं। किसी event का इंतज़ार करने के बजाय, आप Google से सीधे पूछते हैं: क्या voided हुआ है?
इसकी ताकत पूर्णता और रिकवरी है। अगर कोई push notification देरी से आया, छूट गया, या कभी प्रोसेस नहीं हुआ, तो Google Play Voided Purchases API के खिलाफ एक pull फिर भी voided purchase को सामने ला देता है। इस तरह आप reconcile करते हैं और सुनिश्चित करते हैं कि आपका रिकॉर्ड Google के रिकॉर्ड से मेल खाता है।
इसका ट्रेड-ऑफ यह है कि यह स्वभाव से तुरंत नहीं है, यह कुछ ऐसा है जिसे आप query करते हैं, इसलिए अपने आप में यह एक trigger के बजाय एक safety net है।
आपको दोनों की जरूरत क्यों है, एक की नहीं
यहाँ वह अंतर है जो लोगों को उलझा देता है: यह "बेहतर वाला चुनें" का फैसला नहीं है।
केवल RTDN आपको स्पीड देता है लेकिन पूर्णता की कोई गारंटी नहीं देता, किसी notification को मिस करें या गलत तरीके से हैंडल करें और वह event आपकी नज़र से गायब हो जाता है।
केवल Voided Purchases API आपको पूर्णता देता है लेकिन स्पीड नहीं, आपको रिफंड के बारे में तभी पता चलेगा जब आप अगली बार query करेंगे।
RTDN Google Play आपके backend को एक real-time सिग्नल देता है, जबकि Google Play Voided Purchases API छूटे या देरी से आए events के लिए reconciliation लेयर प्रदान करता है।
एक भरोसेमंद सेटअप RTDN को real-time trigger के रूप में और Voided Purchases API को reconciliation लेयर के रूप में उपयोग करता है जो push path से छूटी किसी भी चीज़ को पकड़ लेता है। स्पीड के साथ एक सेफ्टी नेट। इनमें से कोई भी एक अकेला एक ऐसा छेद छोड़ देता है जिसमें आप आखिरकार गिर जाएंगे।
यहाँ यह जटिल हो जाता है
इसे सही तरीके से सेट करना जितना लगता है उससे ज्यादा जटिल है, और यह प्रयास एक बार का नहीं बल्कि लगातार चलने वाला है:
Pub/Sub प्रोविजनिंग। Topic बनाना, Google Play को publish करने का अधिकार देना, अपने backend को subscribe करना, और permissions को ठीक-ठीक सही करना वह चरण है जो सबसे ज्यादा समय खा सकता है। यह Pub/Sub Play Billing सेटअप आपके billing इंफ्रास्ट्रक्चर के बढ़ने के साथ भी भरोसेमंद बना रहना चाहिए।
सिंक में रखने के लिए दो सिस्टम। अब आप एक push consumer और एक scheduled pull-and-reconcile job चला रहे हैं, और यह सुनिश्चित कर रहे हैं कि वे आपस में मेल खाते हैं।
Deduplication और ordering। एक ही event आपके पास एक से ज्यादा बार पहुँच सकता है, या गलत क्रम में; आपकी हैंडलिंग idempotent होनी चाहिए।
अपडेटेड बने रहना। Google billing APIs और event types को संशोधित करता रहता है, और आपके इंटीग्रेशन को इसके साथ कदम मिलाना होता है या यह चुपचाप पुराना हो जाता है।
Google Play रिफंड नोटिफिकेशन। आपके सिस्टम को हर संबंधित Google Play रिफंड नोटिफिकेशन को सही तरीके से प्रोसेस करना होगा और इसे सही purchase, entitlement, और customer रिकॉर्ड से जोड़ना होगा।
अकेले में, इनमें से कुछ भी असामान्य नहीं है। साथ में, यह बनाने और मेंटेन करने के लिए इंफ्रास्ट्रक्चर का एक वास्तविक हिस्सा है, उन रिफंडों को सटीक रूप से ट्रैक करने के विशेषाधिकार के लिए जिन्हें आप वैसे भी ज्यादातर contest नहीं कर सकते।
यह रिफंड हैंडलिंग में कैसे फिट होता है
टुकड़ों को जोड़ें तो Google Play रिफंड हैंडलिंग के दो हिस्से हैं: जिस एक चीज़ को आप contest कर सकते हैं (chargeback review) उसे उसकी विंडो के भीतर पकड़ें, और बाकी सब कुछ सटीक रूप से रिकॉर्ड करें जिन्हें आप contest नहीं कर सकते ताकि आपके entitlements और एनालिटिक्स सही बने रहें। दोनों हिस्से RTDN + Voided Purchases फाउंडेशन के मजबूत होने पर निर्भर करते हैं।
उन टीमों के लिए जो पूछती हैं कि RTDN और Voided Purchases API के साथ Google Play रिफंड को कैसे ट्रैक करें, जवाब है तेज़ event detection के लिए RTDN का उपयोग करें और reconciliation और recovery के लिए Voided Purchases API का। यह आपके backend को रिफंड, voided purchases, और chargebacks की एक अधिक पूर्ण तस्वीर देता है।
यह वह लेयर है जिसे RefundSensor आपके लिए मैनेज करता है। यह Pub/Sub topic को auto-provision करता है ताकि आपको सिर्फ एक topic नाम Play Console में paste करना हो, RTDN को real time में consume करता है, voided purchases के खिलाफ reconcile करता है ताकि कुछ भी छूटे नहीं, chargeback reviews पर विंडो के भीतर decline recommendation सबमिट करता है, और हर अन्य रिफंड को रिकॉर्ड करता है, सब कुछ आपके Apple रिफंड के साथ एक ही dashboard में। आपको एक सही दो-मैकेनिज़्म सेटअप का रिजल्ट मिलता है बिना किसी भी मैकेनिज़्म को बनाए या मेंटेन किए।
आधिकारिक स्रोत {#official-sources}
Google के billing APIs बदलते रहते हैं, इसलिए इसके documentation को अंतिम प्राधिकरण मानें:
एक सेटअप, दोनों मैकेनिज़्म, शून्य मेंटेनेंस। RefundSensor Pub/Sub को auto-provision करता है, RTDN को real time में consume करता है, voided purchases के खिलाफ reconcile करता है, और chargeback reviews को हैंडल करता है Google Play और Apple के लिए, एक ही dashboard में। फ्री शुरू करें →
पब्लिश होने के बाद जोड़ने के लिए internal links: Google Play refunds cornerstone · Apple refund automation cornerstone · the 12-hour window.
अक्सर पूछे जाने वाले प्रश्न
RTDN events को Pub/Sub के माध्यम से real time में आपके सर्वर पर push करता है; Voided Purchases API आपको मांग पर voided orders की सूची pull करने देता है। RTDN स्पीड देता है, Voided Purchases API पूर्णता देता है।
एक भरोसेमंद सेटअप के लिए, हाँ। RTDN आपका real-time trigger है और Voided Purchases API आपका reconciliation सेफ्टी नेट है उस हर चीज़ के लिए जो push path से छूट गई। हर एक अकेले में एक गैप छोड़ देता है।
एक ऐसा order जो अब वैध नहीं है, सामान्यतः रिफंड, chargeback, या revocation के कारण। Voided purchases को ट्रैक करने से आपके entitlements और एनालिटिक्स सटीक बने रहते हैं।
RTDN Google Cloud Pub/Sub पर चलता है, इसलिए इसमें एक topic, Google Play के लिए publish permissions, और आपकी तरफ एक subscriber शामिल होता है, जो एक सिंगल URL paste करने से ज्यादा moving parts हैं। RefundSensor उस दिक्कत को दूर करने के लिए Pub/Sub topic को auto-provision करता है।
ज्यादातर नहीं। सामान्य रिफंड और revocations Google द्वारा तय किए जाते हैं। एक contestable मामला chargeback under review है, जिसे आपको RTDN के माध्यम से पकड़ना चाहिए और इसकी ~24 घंटे की विंडो के भीतर जवाब देना चाहिए।
