तेज़ इवेंट हैंडलिंग के लिए Google Play RTDN का उपयोग करें। वॉयडेड ऑर्डर की जांच करने और अपने रिकॉर्ड को रीकन्साइल करने के लिए Voided Purchases API का उपयोग करें। अधिकतर पेड ऐप्स के लिए, ज़्यादा सुरक्षित विकल्प दोनों का इस्तेमाल करना है।
अगर आप ऐप्स के लिए Google Play रिफंड डिफेंस की योजना बना रहे हैं, तो उस विभाजन से शुरुआत करें। एक रास्ता आपको बताता है कि कुछ बदल गया है। दूसरा रास्ता आपके सर्वर को वॉयडेड खरीद की एक सूची प्राप्त करने और यह जांचने देता है कि उससे क्या छूट गया।
यह चुनाव पूरी तरह से दो नोटिफिकेशन सिस्टम के बीच का नहीं है। Google Play RTDN, Cloud Pub/Sub के माध्यम से मैसेज पुश करता है। Voided Purchases API एक पुल API है: इसे आपका बैकएंड कॉल करता है।
अपने आप में, इनमें से कोई भी किसी को रिफंड का अनुरोध करने से नहीं रोकता। इनकी असली उपयोगिता बदलावों का पता लगाने, ऑर्डर की जांच करने, और यह सुनिश्चित करने में है कि पेड एक्सेस खरीद की स्थिति से मेल खाता हो।
मुख्य बातें
खरीद और सब्सक्रिप्शन इवेंट पर तुरंत प्रतिक्रिया देने के लिए RTDN का उपयोग करें।
प्रभावित ऑर्डर की जांच के लिए एक दूसरे रास्ते के तौर पर वॉयडेड-परचेज़ सूची का उपयोग करें।
कैंसल किए गए सब्सक्रिप्शन को रिफंड का सबूत न मानें।
दोनों रास्तों को एक ही सुरक्षित एक्सेस-अपडेट लॉजिक का उपयोग कराएं।
पेंडिंग चार्जबैक रिव्यू को पूरी हो चुकी वॉयड प्रक्रिया से अलग रखें।
Google Play RTDN क्या है?
Google Play Real-Time Developer Notifications, जिसे आमतौर पर RTDN कहा जाता है, खरीद से जुड़े इवेंट को एक Cloud Pub/Sub टॉपिक पर भेजता है।
आपका बैकएंड एक मैसेज प्राप्त करता है और उसे सही वर्कर तक रूट करता है। मैसेज का प्रकार महत्वपूर्ण होता है। एक रिन्यूअल, एक कैंसलेशन, और एक वॉयडेड परचेज़ एक जैसा इवेंट नहीं है।
रिफंड ट्रैकिंग के लिए, voidedPurchaseNotification पर खास ध्यान दें। इसमें शामिल है:
purchaseToken: इवेंट को किसी खरीद से जोड़ता है।
orderId: प्रभावित ऑर्डर की पहचान करता है।
productType: सब्सक्रिप्शन या एक बार की खरीद की पहचान करता है।
refundType: पूर्ण वॉयड को मात्रा-आधारित आंशिक रिफंड से अलग बताता है।
Google का RTDN रेफरेंस और इवेंट परिभाषाएं इन फील्ड्स और अन्य नोटिफिकेशन प्रकारों के बारे में बताता है।
RTDN तब उपयोगी होता है जब आप किसी बदलाव के तुरंत बाद कार्रवाई करना चाहते हैं। लेकिन एक मैसेज आपका पूरा परचेज़ डेटाबेस नहीं है। एक्सेस बदलने से पहले इसे स्टोर किए गए रिकॉर्ड से मिलाएं और जहां जरूरी हो, संबंधित परचेज़ स्थिति प्राप्त करें।
क्या सब्सक्रिप्शन कैंसलेशन का मतलब रिफंड होता है?
नहीं। एक ग्राहक भविष्य के रिन्यूअल रोक सकता है, जबकि मौजूदा टर्म के बाकी हिस्से के लिए उसका पेड एक्सेस बना रह सकता है।
ऐसा नियम न बनाएं जो SUBSCRIPTION_CANCELED आने पर हर बार एक्सेस हटा दे। इसके बजाय सब्सक्रिप्शन की स्थिति और उसकी समाप्ति की जांच करें। रिवोकेशन और एक्सपायरी के लिए अलग हैंडलिंग की जरूरत होती है।
Voided Purchases API क्या है?
Google Play Voided Purchases API उन खरीद की सूची लौटाता है जो इसके समर्थित दायरे में कैंसल, रिफंड या चार्जबैक की गई थीं।
यह एक बार के इन-ऐप ऑर्डर और सब्सक्रिप्शन दोनों पर लागू होता है। आपका सर्वर इन परिणामों का उपयोग यह जांचने के लिए कर सकता है कि किन खरीद को अब एक्सेस नहीं देना चाहिए।
इस सूची में ऑर्डर ID, परचेज़ टोकन, वॉयड का समय, वॉयड का स्रोत, और वॉयड का कारण शामिल हो सकता है। समर्थित मात्रा-आधारित आंशिक रिफंड के लिए, इसमें रिफंड की गई मात्रा भी शामिल हो सकती है।
Google की Voided Purchases API गाइड 30-दिन की लुकबैक अवधि के बारे में बताती है। यह रिफंड का स्थायी संग्रह नहीं है। प्रोसेस किए गए रिकॉर्ड को अपने सिस्टम में सेव करें।
यह API खासतौर पर किसी वर्कर आउटेज, रूटिंग बग, या आपके लोकल रिकॉर्ड में किसी कमी के बाद उपयोगी होता है। यह आपको प्रोसेस किए गए इवेंट के खिलाफ एक नियमित जांच भी देता है।
RTDN बनाम Voided Purchases API: व्यावहारिक अंतर
प्रश्न | Google Play RTDN | Voided Purchases API |
यह कैसे काम करता है? | Google, Pub/Sub पर एक इवेंट पब्लिश करता है। | आपका सर्वर एक सूची का अनुरोध करता है। |
इसकी मुख्य भूमिका क्या है? | परचेज़-स्थिति में बदलाव की तुरंत हैंडलिंग। | वॉयडेड ऑर्डर की जांच और रीकन्सिलिएशन। |
क्या यह रिफंड के अलावा अन्य इवेंट भी कवर करता है? | हां, रिन्यूअल और अन्य लाइफसाइकिल इवेंट सहित। | यह वॉयडेड परचेज़ पर केंद्रित है। |
क्या यह प्रोसेसिंग में आई कमी के बाद मदद कर सकता है? | Pub/Sub की रिकवरी आपके सेटअप और रिटेंशन पर निर्भर करती है। | यह 30-दिन की अवधि के भीतर उपलब्ध रिकॉर्ड की सूची दे सकता है। |
क्या इसे डुप्लिकेट प्रोटेक्शन की जरूरत है? | हां। | हां, खासकर जब स्कैन ओवरलैप हो या RTDN के साथ इवेंट साझा करे। |
मुख्य सवाल यह नहीं है कि अलग-अलग देखने पर कौन-सा टूल बेहतर है। सवाल यह है कि हर टूल किस तरह की विफलता को संभालने में मदद करता है।
RTDN आपको एक तेज़ रास्ता देता है। API आपको एक जांच वाला रास्ता देता है। आपका अपना डेटाबेस इन दोनों को एक साथ लाना चाहिए।
आपके ऐप को कौन-सा इस्तेमाल करना चाहिए?
जब स्पीड मायने रखती हो, तब RTDN का उपयोग करें
किसी पेड ऐप को परचेज़-स्थिति में बदलाव का पता लगाने के लिए शेड्यूल्ड स्कैन का इंतजार नहीं करना चाहिए।
जब आपके ऐप को सब्सक्रिप्शन, एक बार की खरीद, और वॉयडेड ऑर्डर के लिए तुरंत अपडेट की जरूरत हो, तो RTDN का उपयोग करें। सभी मैसेज पर एक ही रिफंड नियम लागू करने के बजाय हर इवेंट को उसके प्रकार के आधार पर रूट करें।
जब पूर्णता मायने रखती हो, तब API का उपयोग करें
उन वॉयडेड ऑर्डर को ढूंढने के लिए शेड्यूल्ड API जांच का उपयोग करें जिन्हें आपके वर्कर ने आपके रिकॉर्ड में लागू नहीं किया।
उदाहरण के लिए, हो सकता है कि आपके रिसीवर ने एक मैसेज स्वीकार किया हो, लेकिन किसी बग ने बाद में होने वाले एक्सेस अपडेट को रोक दिया हो। सिर्फ डिलीवरी ठीक करने से उस लोकल कमी का समाधान नहीं होगा।
प्रोडक्शन रिफंड वर्कफ़्लो के लिए दोनों का उपयोग करें
अधिकतर पेड ऐप्स के लिए, इन दोनों को मिलाकर इस्तेमाल करें। दोनों रास्तों को एक ही शेयर्ड हैंडलर में फीड करें, जो ऑर्डर की जांच करे और किसी भी बदलाव को सुरक्षित रूप से लागू करे।
इससे किसी एक छूटे हुए इवेंट की वजह से एक्सेस सक्रिय रह जाने का जोखिम कम होता है। इससे इसके विपरीत जोखिम भी कम होता है: एक ही रिफंड के लिए एक्सेस को दो बार हटाना।
Google Play रिफंड का पता चरण-दर-चरण कैसे लगाएं
1. एक परचेज़ लेजर रखें
ऐप पैकेज, परचेज़ टोकन, ऑर्डर ID, प्रोडक्ट, यूज़र मैपिंग, और दी गई मात्रा को स्टोर करें। एक लेजर दरअसल इस बात का स्पष्ट रिकॉर्ड है कि क्या खरीदा गया और उससे क्या एक्सेस मिला।
सब्सक्रिप्शन के लिए, रिन्यूअल ऑर्डर ID भी स्टोर करें। RTDN रेफरेंस बताता है कि हर ऑटो-रिन्यूअल का एक नया ऑर्डर ID होता है। हर प्रभावित रिन्यूअल की पहचान के लिए सिर्फ परचेज़ टोकन पर्याप्त नहीं है।
2. RTDN मैसेज को सुरक्षित करें और रूट करें
Pub/Sub एक्सेस को सही तरीके से कॉन्फ़िगर करें। पुश डिलीवरी के लिए, ऑथेंटिकेटेड रिक्वेस्ट को वेरिफाई करें। पुल डिलीवरी के लिए, यह सीमित करें कि सब्सक्रिप्शन को कौन पढ़ सकता है।
धीमा काम चलाने से पहले मैसेज को डिकोड करें, पैकेज नेम की जांच करें, और उसे सेव करें। टेस्ट इवेंट को पूरे पथ से भेजें, न कि सिर्फ रिसीविंग एंडपॉइंट से।
3. एक शेड्यूल्ड वॉयडेड-परचेज़ स्कैन चलाएं
उपयुक्त क्रेडेंशियल और Play Console अनुमतियों के साथ लिस्ट मेथड को कॉल करें। सभी परिणाम पेजों को फॉलो करें।
दो क्वेरी सेटिंग्स को नज़रअंदाज़ करना आसान है:
type=1 में एक बार की खरीद और सब्सक्रिप्शन दोनों शामिल होते हैं। डिफॉल्ट, 0, में केवल एक बार की खरीद शामिल होती है।
includeQuantityBasedPartialRefund=true में समर्थित मात्रा-आधारित आंशिक रिफंड शामिल होते हैं। इसका डिफॉल्ट false है।
Google का voidedpurchases.list मेथड रेफरेंस रिक्वेस्ट और पेजिनेशन फील्ड्स को कवर करता है।
स्कैन के बीच एक मध्यम ओवरलैप रखें और परिणामों को डीड्यूप्लिकेट करें। अपनी वॉल्यूम, कोटा, और आपका ऐप कितनी देरी स्वीकार कर सकता है, इसके आधार पर स्कैन रेट चुनें। लुकबैक विंडो खत्म होने तक इंतजार न करें।
4. हर बदलाव को सिर्फ एक बार लागू करें
दोनों रास्ते एक ही वॉयड की रिपोर्ट कर सकते हैं। आइडेम्पोटेंट हैंडलिंग बनाएं: एक ही बदलाव को फिर से चलाने पर परिणाम नहीं बदलना चाहिए।
हर बाद के इवेंट को खारिज करने के लिए सिर्फ ऑर्डर ID का उपयोग न करें। एक मल्टी-क्वांटिटी खरीद में कई आंशिक रिफंड हो सकते हैं। प्रोसेस किए गए एडजस्टमेंट और रिफंड की गई मात्रा को ट्रैक करें ताकि बाद में होने वाला कोई असली रिफंड छूट न जाए।
5. सिर्फ मैसेज की संख्या नहीं, बल्कि कमी को भी मॉनिटर करें
आखिरी सफल स्कैन, अधूरे पेज, वर्कर एरर, और बिना मैच हुए ऑर्डर को ट्रैक करें। यह मापें कि किसी कन्फर्म्ड इवेंट के बाद एक्सेस अपडेट होने में कितना समय लगता है।
व्यापक रिपोर्टिंग के लिए, हमारी मोबाइल ऐप रिफंड और चार्जबैक ट्रैकिंग टूल्स गाइड देखें।
उदाहरण: एक रिफंड, दो डिटेक्शन रास्ते
यह एक काल्पनिक वर्कफ़्लो है, कोई रिपोर्ट किया गया ग्राहक मामला नहीं।
एक प्लेयर एक बार का पैक खरीदता है जिससे 500 कॉइन मिलते हैं। बाद में यह खरीद पूरी तरह वॉयड कर दी जाती है।
RTDN एक वॉयडेड-परचेज़ मैसेज भेजता है। आपका वर्कर ऑर्डर ढूंढता है, दर्ज की गई ग्रांट की जांच करता है, और उस खरीद से जुड़े कॉइन पर आपकी प्रकाशित पॉलिसी लागू करता है।
बाद में, शेड्यूल्ड API स्कैन वही ऑर्डर लौटाता है। शेयर्ड हैंडलर देखता है कि फुल-वॉयड एडजस्टमेंट पहले ही लागू किया जा चुका है। यह मैच को रिकॉर्ड करता है और दूसरी बार कोई कटौती नहीं करता।
अब मान लीजिए कि पहला बदलाव लागू करने से पहले वर्कर फेल हो गया। स्कैन ऑर्डर को ढूंढता है और आपके सिस्टम को इसे प्रोसेस करने का एक और रास्ता देता है।
दोनों का उपयोग करने का यही मकसद है। दो अलग-अलग दंड नहीं, बल्कि एक सही परिणाम तक पहुंचने के दो तरीके।
अगर कुछ कॉइन पहले ही खर्च हो चुके हैं, तो किसी असंबंधित पेड पैक से कॉइन अंधाधुंध न हटाएं। एक स्पष्ट पॉलिसी का उपयोग करें, की गई कार्रवाई को समझाएं, और सपोर्ट का एक रास्ता दें।
पेंडिंग रिफंड रिव्यू एक अलग वर्कफ़्लो है
मौजूदा Google दस्तावेज़ीकरण में एक चार्जबैक रिक्वेस्ट के लिए pendingRefundReviewNotification भी सूचीबद्ध है, जिसके लिए डेवलपर रिव्यू आवश्यक होता है।
इस इवेंट के लिए, Google कहता है कि 24 घंटे के भीतर orders.reviewrefund के माध्यम से एक रिफंड सुझाव और परचेज़ उपयोग का सबूत दिया जाए।
इसे voidedPurchaseNotification के साथ भ्रमित न करें। एक का संबंध पेंडिंग रिव्यू से है। दूसरा उस खरीद की रिपोर्ट करता है जो वॉयड कर दी गई है।
Voided Purchases API, पेंडिंग रिव्यू इवेंट को हैंडल करने का विकल्प नहीं है। इस शाखा को अलग रखें, और यह न मानें कि हर रिफंड रिक्वेस्ट से यह इवेंट उत्पन्न होता है।
App Store रिफंड और रेवेन्यू लीकेज: डेवलपर्स को क्या जानना चाहिए
रेवेन्यू लीकेज केवल इस बात तक सीमित नहीं है कि कोई स्टोर पैसा लौटाता है या नहीं। इसका मतलब यह भी हो सकता है कि संबंधित खरीद के अब इसका समर्थन न करने के बाद भी आपका बैकएंड पेड एक्सेस देना जारी रखे।
दोनों प्लेटफॉर्म पर काम करने वाली टीमों के लिए लक्ष्य एक जैसा है: पैसे, परचेज़ की स्थिति, और एक्सेस रिकॉर्ड को एक-दूसरे से मेल में रखें। हालांकि, स्टोर के टूल और इवेंट नियम अलग-अलग हैं। किसी Apple वर्कफ़्लो को बिना बदलाव के Google Play में कॉपी न करें।
हमारी App Store रिफंड रेवेन्यू मैनेजमेंट गाइड व्यापक रेवेन्यू-मैनेजमेंट समस्या को कवर करती है। इस Google Play इंटीग्रेशन के लिए, पहले छूटे हुए वॉयड, डुप्लिकेट कटौती, और गलत सब्सक्रिप्शन एक्सेस बदलावों पर फोकस करें।
Google Play रिफंड फ्रॉड प्रिवेंशन क्या कर सकता है और क्या नहीं
Google Play रिफंड फ्रॉड प्रिवेंशन की शुरुआत मजबूत रिकॉर्ड और उचित नियमों से होती है। एक वॉयडेड ऑर्डर यह सबूत नहीं है कि ग्राहक ने बेईमानी से काम किया।
हो सकता है कि किसी यूज़र की शिकायत वाजिब हो। किसी पेमेंट में गड़बड़ी हो सकती है। आपके ऐप ने गलत आइटम डिलीवर किया हो सकता है।
तथ्यों की जांच करने और एक्सेस में बदलाव लागू करने के लिए इन टूल्स का उपयोग करें। बार-बार दिखने वाले पैटर्न को सही संदर्भ में देखें। एक रिफंड के आधार पर अकाउंट को ऑटोमैटिक रूप से बैन करने से बचें, और ग्राहकों को गलतियों को चैलेंज करने का मौका दें।
न तो RTDN और न ही लिस्ट API यह गारंटी देता है कि आप किसी रिफंड को रोक सकते हैं, खारिज कर सकते हैं, या उलट सकते हैं।
निष्कर्ष
अधिकतर पेड ऐप्स के लिए, RTDN बनाम Voided Purchases API का चुनाव कोई या-तो/या वाला फैसला नहीं है।
तेजी से प्रतिक्रिया देने के लिए RTDN का उपयोग करें। रिकॉर्ड को रीकन्साइल करने के लिए शेड्यूल्ड वॉयडेड-परचेज़ जांच का उपयोग करें। दोनों को एक सुरक्षित हैंडलर से गुजारें, और पेंडिंग रिव्यू को पूरी हो चुकी वॉयड प्रक्रिया से अलग रखें।
एक छोटे टेस्ट से शुरुआत करें: एक वॉयड को दोनों रास्तों से भेजें और पुष्टि करें कि एक्सेस सिर्फ एक बार बदलता है। फिर अपने वर्कर को रोकें और जांचें कि आपका रिकवरी रास्ता उस कमी को पकड़ लेता है।
अक्सर पूछे जाने वाले प्रश्न
RTDN तुरंत इवेंट हैंडलिंग के लिए ज़्यादा उपयुक्त है। API वॉयडेड ऑर्डर की शेड्यूल्ड जांच के लिए ज़्यादा उपयुक्त है। अधिकतर पेड ऐप्स को दोनों से फायदा होता है।
हां। इसमें ऑर्डर और रिफंड-प्रकार की जानकारी के साथ एक वॉयडेड-परचेज़ नोटिफिकेशन शामिल है। इस इवेंट को सब्सक्रिप्शन कैंसलेशन से अलग हैंडल करें।
आप पोलिंग के माध्यम से उपलब्ध वॉयडेड रिकॉर्ड का पता लगा सकते हैं, लेकिन इसका पता लगना आपके अगले सफल स्कैन तक रुका रहता है। इसके साथ ही आप RTDN की व्यापक लाइफसाइकिल इवेंट स्ट्रीम भी मिस कर देते हैं।
Google 30-दिन की अवधि के बारे में बताता है। लंबी अवधि की जांच और सपोर्ट जरूरतों के लिए अपने खुद के रिकॉर्ड रखें।
हां। लिस्ट रिक्वेस्ट में समर्थित आंशिक-रिफंड परिणामों को इनेबल करें। रिफंड की गई मात्रा को ट्रैक करें और एक ही ऑर्डर पर एक से अधिक आंशिक रिफंड की संभावना को ध्यान में रखें।
