आपका ऐप इन-ऐप रिफ़ंड रिक्वेस्ट शीट दिखा सकता है, और ग्राहक के सबमिट दबाने के बाद Apple क्या करता है

Apple ग्राहक को आपका ऐप छोड़े बिना रिफ़ंड माँगने देता है. एक StoreKit कॉल, beginRefundRequest, आपके इंटरफ़ेस के ठीक अंदर Apple की अपनी रिफ़ंड शीट दिखाता है, ग्राहक एक कारण चुनता है, और रिक्वेस्ट समीक्षा के लिए Apple के पास चली जाती है. न तो आप फ़ॉर्म बनाते हैं, न पैसे को छूते हैं, और न ही नतीजा तय करते हैं. आपको जो मिलता है वह है एक रिफ़ंड का रास्ता वहाँ रखने का तरीक़ा जहाँ नाख़ुश ग्राहक पहले से मौजूद है, बजाय उसे उसके बैंक के हाथों खोने के. यह इन-ऐप रिफ़ंड रिक्वेस्ट है, और बटन शिप करने का फ़ैसला करने से पहले इसे समझना ज़रूरी है.

यहाँ वह हिस्सा है जो आपकी कमाई के लिए मायने रखता है. यह बटन अपने आप कुछ भी रिफ़ंड नहीं करता. यह एक रिक्वेस्ट खोलता है, Apple उसे मंज़ूर या अस्वीकार करने में 48 घंटे तक लेता है, और उपभोग्य ख़रीद के लिए यह पहले आपके सर्वर पर एक CONSUMPTION_REQUEST भेजता है. तो यह शीट कोई मुफ़्त उपहार नहीं है. यह ठीक उसी रिफ़ंड समीक्षा में एक फ़नल है जिसे आप पहले से प्रभावित कर सकते हैं, और यह किसी विवाद को कार्ड नेटवर्क से वापस खींच सकती है इससे पहले कि वह एक ऐसा चार्जबैक बन जाए जिसका आप विरोध नहीं कर सकते.

इन-ऐप रिफ़ंड रिक्वेस्ट शीट असल में क्या है

beginRefundRequest एक StoreKit 2 मेथड है जो किसी विंडो सीन में एक transaction के लिए रिफ़ंड रिक्वेस्ट शीट दिखाता है. इसका सिग्नेचर छोटा है: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. जब आप इसे कॉल करते हैं, तो सिस्टम ग्राहक की ख़रीद के विवरण और चुनने के लिए कारण कोड की सूची वाली एक शीट दिखाता है. Apple उस UI को बनाता और नियंत्रित करता है. आप scene और transaction देते हैं, और कुछ नहीं.

Apple की सलाह कि इसे कहाँ रखना है, स्पष्ट है. इस फ़ंक्शन को अकाउंट सेटिंग्स या हेल्प मेन्यू से कॉल करें, ताकि रिफ़ंड चाहने वाला ग्राहक इसे वहाँ पाए जहाँ वह सपोर्ट ढूँढेगा. यह iOS 15 और iPadOS 15, Mac Catalyst 15, और visionOS 1 में आया, इसलिए उन वर्ज़न को टारगेट करने वाला कोई भी ऐप इसे आज दिखा सकता है.

शीट खोलने के दो तरीक़े

दो एंट्री पॉइंट हैं. आप किसी ऐसे specific transaction पर beginRefundRequest(in:) कॉल कर सकते हैं जो आपके पास पहले से है, जो शीट को उसी एक ख़रीद तक सीमित करता है. आप शीट को प्रोडक्ट आइडेंटिफ़ायर से भी खोल सकते हैं जब आप चाहते हों कि ग्राहक किसी दिए गए प्रोडक्ट की ख़रीद रिफ़ंड करे. दोनों ही तरीक़ों में शीट, कारणों की सूची, और फ़ैसला Apple के हैं. आपका काम इसे दिखाने और नतीजा पढ़ने पर ख़त्म हो जाता है.

कॉल क्या लौटाता है, और क्या ग़लत हो सकता है

यह मेथड async throws है, इसलिए यह या तो एक स्टेटस लौटाता है या एक एरर फेंकता है. दोनों ही छोटी सूचियाँ हैं, और दोनों को संभालना ज़रूरी है ताकि शीट बंद होने के बाद आपका UI कुछ सच कहे.

ग्राहक के सबमिट दबाने के बाद आपके सर्वर पर क्या होता है

शीट का बंद होना प्रक्रिया की शुरुआत है, अंत नहीं. Apple रिक्वेस्ट की समीक्षा करता है और उसे मंज़ूर या अस्वीकार करने में 48 घंटे तक लेता है. किसी उपभोग्य इन-ऐप ख़रीद के लिए, फ़ैसला करने से पहले, App Store आपके सर्वर पर उपयोग डेटा माँगते हुए एक CONSUMPTION_REQUEST नोटिफ़िकेशन भेजता है. अगर ग्राहक ने वह डेटा साझा करने की सहमति दी हो, तो आप Send Consumption Information एंडपॉइंट के ज़रिए जवाब देते हैं. अगर उन्होंने सहमति नहीं दी, तो Apple का अपना निर्देश है कि नोटिफ़िकेशन का बिल्कुल जवाब न दें.

एक बार Apple फ़ैसला कर ले, तो नतीजा आपके सर्वर पर एक App Store Server Notification के रूप में आता है. यह वही फ़ीड है जो आप पहले से पाते हैं, और इन-ऐप रिक्वेस्ट उसमें ठीक वैसे ही जाती है जैसे Apple के reportaproblem पेज पर ग्राहक द्वारा शुरू किया गया रिफ़ंड. रिक्वेस्ट आपके ऐप के अंदर शुरू हुई, सिर्फ़ इस वजह से हैंडलिंग में कुछ नहीं बदलता.

यह बटन आपको क्या क़ीमत देता है, और क्या बचा सकता है

एक ऐसा रिफ़ंड जिसका आप विरोध कर सकते हैं, उस चार्जबैक से बेहतर है जिसका आप नहीं कर सकते

जो ग्राहक आपके ऐप के अंदर रिफ़ंड का रास्ता नहीं ढूँढ पाता, वह हार नहीं मानता. वह अपने बैंक के पास जाता है. एक कार्ड चार्जबैक बैंक के साथ अंतिम होता है, उस पर विवाद शुल्क लगता है, और यह फ़ैसला आपके और Apple, दोनों के हाथों से निकाल लेता है. एक इन-ऐप रिफ़ंड रिक्वेस्ट उसी ग्राहक को Apple के सिस्टम के अंदर रखती है, जहाँ एक उपभोग्य ख़रीद एक CONSUMPTION_REQUEST शुरू करती है जिसका आप जवाब दे सकते हैं और एक फ़ैसला जिसे आप प्रभावित कर सकते हैं. एक न-विरोध-योग्य चार्जबैक को एक विरोध-योग्य Apple समीक्षा से बदलना ही इस बटन का पूरा आर्थिक तर्क है.

आप रिफ़ंड पर घर्षण कम कर रहे हैं

ईमानदार दूसरा पहलू यह है कि एक दिखने वाला, एक-टैप रिफ़ंड रास्ता एक छिपे हुए सपोर्ट ईमेल से ज़्यादा रिफ़ंड रिक्वेस्ट पैदा करता है. उनमें से कुछ कभी हुई ही नहीं होतीं. यह एक असली क़ीमत है, और यही वजह है कि Apple आपको एंट्री पॉइंट ख़रीद स्क्रीन के बजाय अकाउंट सेटिंग्स या हेल्प मेन्यू में रखने को कहता है. आप चाहते हैं कि वह ग्राहक इसे ढूँढे जो पहले से नाख़ुश है, न कि वह ग्राहक जो सिर्फ़ जिज्ञासु है.

जो क़ीमत पूरे समय चलती रहती है वह है एक रिफ़ंड किए गए अकाउंट को सेवा देना

फ़ैसला चाहे जिस भी तरफ़ जाए, डिलीवरी का मीटर तब तक चलता रहता है जब तक आप नतीजे पर कार्रवाई नहीं करते. हर घंटा जब एक रिफ़ंड किया गया एंटाइटलमेंट चालू रहता है, आप उसके पीछे की असली क़ीमतें चुकाते रहते हैं: कंप्यूट, मॉडल API कॉल, स्टोरेज, और उस ग्राहक के उपयोग से जुड़ा कोई भी क्रिएटर या पार्टनर भुगतान. इन-ऐप रिक्वेस्ट इसे नहीं बदलती. REFUND नोटिफ़िकेशन पर तुरंत रद्द करना बदलता है. यह बटन उतना ही सस्ता है जितनी आपकी उस नोटिफ़िकेशन की हैंडलिंग जो यह आख़िरकार पैदा करता है.

क्या आपको इन-ऐप रिफ़ंड रिक्वेस्ट शिप करनी चाहिए

इसे वहाँ रखें जहाँ सपोर्ट रहता है, वहाँ नहीं जहाँ सेल्स रहती है

Apple की प्लेसमेंट सलाह का पालन करें. अकाउंट सेटिंग्स और एक हेल्प मेन्यू सही ठिकाने हैं. पेवॉल के बगल में एक रिफ़ंड लिंक लोगों को अपने पैसे वापस पाने की उम्मीद करना सिखाता है, और यह उस जिज्ञासा-रिफ़ंड को न्योता देता है जिसे देने की आपको कभी ज़रूरत नहीं थी.

इस पर भरोसा करने से पहले सैंडबॉक्स में पूरे फ़्लो का परीक्षण करें

आप पूरे रास्ते का सैंडबॉक्स में और Xcode की StoreKit टेस्टिंग में सिमुलेशन कर सकते हैं, एक रिक्वेस्ट को पेंडिंग से मंज़ूर या अस्वीकृत की ओर ले जाते हुए. एक मंज़ूरी आपके सर्वर पर एक REFUND नोटिफ़िकेशन पहुँचाती है, और एक अस्वीकृति REFUND_DECLINED पहुँचाती है, इसलिए किसी असली ग्राहक के सबमिट दबाने से पहले ही आप साबित कर सकते हैं कि आपका हैंडलर सही प्रतिक्रिया देता है.

हर नतीजे को संभालें, और कभी ज़्यादा दावा न करें

success पर पेंडिंग दिखाएँ, failed पर दोबारा कोशिश की पेशकश करें, userCancelled पर कहें कि कुछ नहीं बदला, और duplicateRequest को एक शांत नोट की तरह लें कि ग्राहक की पहले वाली रिक्वेस्ट अब भी क़ायम है. जो एक ग़लती नुक़सान पहुँचाती है वह है ग्राहक को यह बताना कि उसका रिफ़ंड हो गया जबकि आपके पास सिर्फ़ एक सबमिट की गई रिक्वेस्ट है.

RefundHalt बाद के मामलों को कैसे संभालता है

इन-ऐप शीट Apple की है. उसके बाद जो आता है वह आपका है, और वही हिस्सा RefundHalt चलाता है. जब कोई ग्राहक आपके ऐप के अंदर से रिफ़ंड सबमिट करता है, तो RefundHalt उपभोग्य ख़रीद के लिए CONSUMPTION_REQUEST पकड़ता है और उस उपयोग साक्ष्य के साथ 12 घंटे की विंडो के अंदर उसका जवाब देता है जो Apple को फ़ैसला करने में मदद करता है. जब Apple फ़ैसला करता है, तो यह REFUND पर रद्द कर देता है और REFUND_DECLINED पर एक्सेस को अछूता रखता है, हर एक ठीक उसी transaction से जुड़ा. आप बिना समीक्षा, साक्ष्य, या रद्दीकरण को किसी मैनुअल आपाधापी पर छोड़े, ज़्यादा अनुकूल इन-ऐप रिफ़ंड रास्ता दे पाते हैं.