BillingMeld: क्यों खरीदारी को सत्यापित करने के लिए सर्वर की आवश्यकता है, न कि एप्लिकेशन की

मोबाइल ऐप के भीतर खरीदारी आमतौर पर उपयोगकर्ताओं के लिए सरल प्रतीत होती है। वे बटन दबाते हैं, भुगतान की पुष्टि करते हैं, कुछ फ़ीचर या सब्सक्रिप्शन का उपयोग शुरू करते हैं — और उम्मीद करते हैं कि सब कुछ स्वचालित रूप से चलता रहेगा।

डेवलपर के लिए, इस बटन के पीछे बहुत अधिक जटिल प्रक्रिया शुरू होती है। इसे स्वयं खरीदारी की पुष्टि करनी होती है, रीन्यूअल, सदस्यता समाप्ति, रिटर्न, लेनदेन की समीक्षा, डिवाइस परिवर्तन और Apple एवं Google के बीच भिन्नताओं का ध्यान रखना होता है।

मुख्य समस्या तब उत्पन्न होती है जब सर्वर क्लाइंट एप्लिकेशन को सत्य का स्रोत मानने लगते हैं।

यदि ऐप कहता है: "खरीद पूरी हुई," तो सर्वर पहुँच प्रदान कर देता है और एक बार प्राप्त स्थिति पर भरोसा करता रहता है। लेकिन खरीदारी का जीवन चक्र यही समाप्त नहीं होता।

सदस्यता का नवीनीकरण हो सकता है, अपने आप पूर्ववत् किया जा सकता है, भुगतान वापस किया जा सकता है, या ऑपरेशन को रद्द किया जा सकता है।

इसे ही कारण है कि BillingMeld में खरीदारी को एप्लिकेशन नहीं, बल्कि सर्वर पुष्टि करता है।

ग्राहक जानकारी देता है, निर्णय नहीं करता

BillingMeld की वास्तुकला में, मोबाइल ऐप मुख्य जानकारी स्रोत नहीं है।

ग्राहक पूरी किए गए ऑपरेशन का डेटा दे सकता है, लेकिन यह बस एक जांच का आधार है। अंतिम निर्णय BillingMeld का सर्वर पक्ष लेता है, जो जानकारी को Apple या Google की अवसंरचना के माध्यम से सत्यापित करता है।

यह मौलिक अंतर है।

फोन का ऐप पुराने स्टेट के साथ काम कर सकता है, नए बदलाव समय पर प्राप्त नहीं कर सकता, या ऐसी जानकारी भेज सकता है जो अब खरीदारी की वर्तमान स्थिति से मेल नहीं खाती।

साथ ही, ग्राहक को स्वयं तय करने का अधिकार नहीं होना चाहिए कि उपयोगकर्ता को भुगतान योग्य पहुँच मिलनी चाहिए या नहीं।

BillingMeld उदाहरण के तौर पर यह जाँचता है:

• क्या ऐसी कोई खरीदारी वास्तव में मौजूद है;

• क्या यह आवश्यक ऐप और उत्पाद से संबंधित है;

• क्या भुगतान ली गई अवधि अभी मान्य है;

• क्या रीन्यूअल हुआ है;

• क्या ऑटो-नवीनीकरण बंद कर दिया गया है;

• क्या रिटर्न हुआ है;

• क्या ऑपरेशन रद्द किया गया है;

• क्या भुगतान अवधि समाप्त नहीं हुई है।

इस तरह, ग्राहक का संदेश खरीदारी का सबूत नहीं, बल्कि उसकी वास्तविक स्थिति जांचने का कारण बन जाता है।

सर्वरों के लिए एकमात्र सत्य का स्रोत

संबंधित सेवाओं को पूरी तरह से Apple और Google के साथ एक ही समय में व्यापक इंटरग्रेशन स्थापित करने की आवश्यकता नहीं है।

वे BillingMeld से संपर्क करते हैं और पहले से ही सामान्यीकृत खरीदारी स्थिति प्राप्त करते हैं।

उदाहरण के लिए: पहुँच सक्रिय है, भुगतान की गई अवधि समाप्त हो गई है, रीन्यूअल पुष्टि हो चुकी है, ऑटो-नवीनीकरण बंद है या खरीदारी रद्द कर दी गई है।

यह जिम्मेदारी को स्पष्ट रूप से विभाजित करने की अनुमति देता है।

Apple और Google स्वयं ऑपरेशনের स्थिति का स्रोत हैं। BillingMeld इन डेटा को सत्यापित करता है, उन्हें सामान्य मॉडल में लाता है, और वर्तमान स्थिति को संग्रहीत करता है। अंतिम उत्पाद इस स्थिति के आधार पर पहुँच का निर्णय लेता है।

यह उत्पादों के लिए एक सिंगल कॉन्ट्रैक्ट बनाता है, बजाय अलग-अलग इंटीग्रेशन के।

हर सेवा में Apple या Google Store नियम अलग-अलग लागू करने की आवश्यकता नहीं है; एक सामान्य लॉजिक से सब कुछ मेल किया जा सकता है।

किसी भी परिस्थिति में ग्राहक पर भरोसा क्यों नहीं किया जा सकता

ग्राहक का ऐप उपयोगकर्ता की डिवाइस पर चलता है।

इसे बंद किया जा सकता है, पुनः शुरू किया जा सकता है, बैकअप से पुनः स्थापित किया जा सकता है, बाद में अपडेट किया जा सकता है या दूसरे डिवाइस पर चलाया जा सकता है।

यह पुरानी स्थिति के साथ काम कर सकता है या वह घटना मिस कर सकता है, जो पहली खरीद के बाद हुई थी।

यह बिना किसी उपयोगकर्ता हस्तक्षेप के भी, ग्राहक को अंतिम स्थिति का विश्वसनीय स्रोत नहीं बनाता।

मान लीजिए, उपयोगकर्ता ने सदस्यता ली है और toegang प्राप्त की है। बाद में, रिटर्न हो सकता है या ऑपरेशन को रद्द किया जा सकता है।

यदि सर्वर केवल ग्राहक का प्रारंभिक संदेश जानता है, तो वह खरीदारी को सक्रिय मानना जारी रखेगा।

एक अन्य स्थिति में, यदि यूजर ऑटो-नवीनीकरण बंद कर देता है, तो भुगतान की गई अवधि अभी भी समाप्त होने तक सक्रिय रहनी चाहिए।

यदि सिस्टम केवल सरल स्थिति "सदस्यता है / नहीं है" पर आधारित हो, तो यह जल्दी ही पहुँच को बहुत पहले बंद कर सकता है या उपयोग का अधिकार समाप्त होने के बाद भी अनुमति दे सकता है।

BillingMeld किसी और लॉजिक पर आधारित है: ग्राहक अपने अधिकार की पुष्टि नहीं करता। वह घटना का सूचनापत्र भेजता है, और सर्वर वास्तविक स्थिति का निर्धारण करता है।

खरीदारी — यह एक घटना नहीं है

बिलिंग वास्तुकला में मुख्य त्रुटि यह है कि खरीदारी को एकल घटना मानना।

वास्तव में, इसका जीवन चक्र होता है।

शुरुआत में ऑपरेशन होती है। फिर यह स्टोर द्वारा पुष्टि की जाती है। सदस्यता की भुगतान वाली अवधि शुरू होती है। बाद में, रीन्यूअल हो सकता है।

उपयोगकर्ता ऑटो-नवीनीकरण बंद कर सकता है, लेकिन भुगतान वाली अवधि खत्म होने तक इस्तेमाल कर सकता है।

अगली बार रीन्यूआल फेल हो सकता है।

रिटर्न किया जा सकता है।

कुछ मामलों में, खरीदारी रद्द भी हो सकती है।

इसलिए, सिर्फ इतना कहना कि "यह खरीदारी कभी थी" पर्याप्त नहीं है।

सर्वर को यह समझना जरूरी है कि वर्तमान में उसकी स्थिति क्या है।

रद्दीकरण किसी भी समय नज़रअंदाज नहीं किया जाता

यह विशेष रूप से रिटर्न और रद्दीकरण मामलों में स्पष्ट होता है।

प्रारंभिक खरीदारी पूरी तरह सही हो सकती है। उपयोगकर्ता ने भुगतान किया और पहुंच प्राप्त की।

लेकिन बाद में, ऑपरेशन की स्थिति बदल सकती है।

BillingMeld परिवर्तन की जानकारी प्राप्त करता है, अपनी स्थिति अपडेट करता है, और आवश्यकतानुसार दुकान के माध्यम से सत्यापित करता है।

इसके बाद, संबंधित सेवा नई स्थिति के साथ काम करने लगती है।

इस तरह, ऐप लगातार यह भरोसा नहीं करता कि प्रति सप्ताह या महीनों पहले, ग्राहक ने सफल खरीदारी की रिपोर्ट की थी।

यदि स्टोर उस अधिकार को अभी नहीं मानता, तो BillingMeld इसे अपने स्टेट में दर्शाता है।

सदस्यता रद्द करने और पहुँच समाप्त होने में फर्क

यहां एक महत्वपूर्ण अंतर है।

यदि उपयोगकर्ता ऑटो-नवीनीकरण बंद कर देता है, तो इसका अर्थ यह नहीं कि तुरंत पहुंच बंद होनी चाहिए।

वर्तमान भुगतान वाली अवधि जारी रह सकती है।

BillingMeld को यह जानकारी रखना चाहिए कि आगे का नवीनीकरण बंद है, और साथ ही, भुगतान वाली अवधि की समाप्ति तारीख को भी।

सिर्फ उसकी समाप्ति के बाद ही पहुंच निष्क्रिय मानी जाएगी, यदि नया पुष्टि वाला नवीनीकरण नहीं हुआ है।

यह दर्शाता है कि क्यों एक सामान्य boolean "subscription = true" पर्याप्त नहीं है।

सदस्यता की स्थिति समय और जीवन चक्र की घटनाओं के साथ जुड़ी रहती है।

रेन्यूअल भी एक अलग सत्यापन है

सदस्यता पहली भुगतान पर समाप्त नहीं होती।

सर्वर को यह समझना चाहिए कि क्या कोई रीन्यूअल हुआ है और क्या अगली भुगतान की अवधि स्टोर द्वारा पुष्टि की गई है।

BillingMeld इन परिवर्तनों को ट्रैक करता है और स्थिति अपडेट करता है।

यदि पुष्टि हो जाती है, तो पहुँच का अधिकार बनी रहती है।

अगर अगली बार भुगतान नहीं हुआ या स्टोर अगली अवधि की पुष्टि नहीं करता, तो सिस्टम को स्वतः आगे बढ़ाकर पहुंच नहीं बढ़ानी चाहिए।

उपयोगकर्ता इसके बीच स्वाभाविक रूप से मानता है कि उसकी सदस्यता जितनी देर तक सक्रिय है, उतनी ही देर तक उसकी पहुंच रहेगी।

यह डेवलपर्स के लिए भी फायदेमंद है, क्योंकि उन्हें हर ऐप में रीन्यूअल लॉजिक को फिर से लिखने की आवश्यकता नहीं है।

सामान्य परिदृश्य कैसा दिखता है

यूजर मोबाइल ऐप में सदस्यता लेता है।

ग्राहक खरीदारी की जानकारी प्राप्त करता है और BillingMeld को आवश्यक डेटा भेजता है। लेकिन यह संदेश स्वयंसिद्ध नहीं है कि खरीदारी पूरी तरह से पुष्टि हो चुकी है।

BillingMeld संबंधित स्टोर से ऑपरेशन की पुष्टि करता है।

यदि App Store या Google Play खरीदारी की पुष्टि करते हैं और स्थिति उत्पाद की नियमों के अनुरूप है, तो BillingMeld सक्रिय अधिकार सुनिश्चित करता है।

इसके बाद, जुड़े हुए सेवा उपयोगकर्ता को भुगतान किए गए सुविधाएं प्रदान करता है।

स्थिति इस बात से स्वतंत्र रहती है कि ग्राहक ने पहली बार क्या किया था।

यदि सदस्यता रीन्यू होती है, तो BillingMeld नए भुगतान वाले अवधि को ध्यान में रखता है।

यदि ग्राहक ऑटो-नवीनीकरण बंद करता है, तो वर्तमान अवधि उसकी समाप्ति तक सक्रिय रहती है।

अगर ऑपरेशन रिटर्न या रद्द किया जाए, तो स्थिति फिर से बदल जाती है।

इस प्रणाली में, ऐप अपने स्वयं का "सत्य" नहीं रखता, बल्कि वह स्थिति का उपयोग करता है, जो BillingMeld द्वारा पुष्टि और संग्रहित की गई है।

डिवाइस बदलने पर क्या होता है

सर्वर-संबंधित मॉडल विशेष रूप से उपयोगी है जब उपयोगकर्ता फोन बदलता है या ऐप को फिर से इंस्टॉल करता है।

किसी विशिष्ट ऐप इंस्टेंस को कभी भी सफल लेनदेन देखने का अधिकार नहीं होना चाहिए।

और, फिर से इंस्टॉल करने पर पुष्टि प्राप्त अधिकार समाप्त नहीं होना चाहिए।

यदि खरीदारी की स्थिति सर्वर पर रहती है और उसे स्टोर की पुष्टि से जोड़ा गया है, तो नया डिवाइस वर्तमान स्थिति प्राप्त कर सकता है।

यह भी कारण है कि पहुंच नियम केवल मोबाइल क्लाइंट के अंदर ही नहीं, बल्कि सर्वर पर भी होना चाहिए।

डेवलपर्स के लिए क्या लाभ

उन टीमों के लिए जिनके पास कई मोबाइल ऐप हैं या जो iOS एवं Android दोनों पर काम कर रहे हैं, बिलिंग एक स्वायत्त अवसंरचना बन जाती है।

उन्हें ध्यान देना चाहिए:

• Apple और Google के डेटा फॉर्मेट का अंतर;

• प्रारंभिक खरीद की पुष्टि;

• सदस्यता का नवीनीकरण;

• भुगतान वाली अवधि का समाप्ति;

• ऑटो-नवीनीकरण बंद करना;

• रिटर्न;

• ऑपरेशन की समीक्षा;

• ऐप पुनः इंस्टॉलेशन;

• डिवाइस परिवर्तन;

• खरीद पुनः प्राप्ति;

• अंतर्निहित परिवर्तन बिना ग्राहक की भागीदारी के।

BillingMeld इसे एक विशेषीकृत परत में स्थानांतरित करता है।

प्रोडक्ट सर्वर इसे एक कॉन्ट्रैक्ट के तहत संचालन करते हैं और प्रत्येक स्टोर की जटिलताओं को स्वयं समझने की आवश्यकता नहीं है।

यह कोड की अनावश्यक नकल को कम करता है और, सबसे महत्वपूर्ण, किसी भी कंपनी के अलग-अलग ऐप्स को एक ही भुगतान परिदृश्य को अलग-अलग समझने से रोकता है।

मुख्य बात अब केवल सत्यापन नहीं, बल्कि अधिकार का सच होना है

मुझे इस वास्तुकला में सबसे अधिक यह विचार प्रेरित करता है कि खरीदारी की जाँच से आगे बढ़कर, वर्तमान स्थिति की जाँच पर जाना ज्यादा महत्वपूर्ण है।

भुगतान का ऐतिहासिक तथ्य अपना उत्तर नहीं देता कि क्या उपयोगकर्ता अभी भी भुगतान योग्य फ़ंक्शन का अधिकार रखता है।

ऑपरेशनों में शुरुआती खरीद हो सकती है, लेकिन अवधि समाप्त हो चुकी हो।

सदस्यता ऑटो-नवीनीकरण बंद हो सकता है, लेकिन भुगतान वाली अवधि अभी भी चल रही हो।

पुष्टि का नवीनीकरण हो सकता है।

रिटर्न किया गया हो।

स्टोर ऑपरेशन को रद्द कर सकता है।

इसलिए, मुख्य वस्तु कोई चेक या ग्राहक का प्रारंभिक जवाब नहीं, बल्कि अधिकार का वर्तमान सत्य है, जो पुष्टि की स्थिति पर आधारित है।

यही स्थिति BillingMeld अन्य सेवाओं को भी भेजता है।

BillingMeld और स्टोर व उत्पादों के बीच सीमा रेखा

इस स्थिति में एक बहुत स्पष्ट वास्तुकला सीमा उभर कर आती है।

एक तरफ है App Store और Google Play, उनके फॉर्मेट, इवेंट्स, नियम और खरीद के जीवन चक्र।

दूसरी तरफ — ऐप्स और आंतरिक सेवाएं, जिनके लिए आमतौर पर अधिक सरल जवाब चाहिए: वर्तमान में उपयोगकर्ता के पास क्या अधिकार हैं।

इनके बीच है BillingMeld।

यह स्टोर डेटा को ग्रहण करता है, उसकी जांच करता है, उसे अपने मॉडल में लाता है, और सामान्यीकृत परिणाम अन्य अवसंरचनाओं को प्रदान करता है।

इससे उत्पादकोड को प्रत्येक भुगतान प्लेटफ़ॉर्म की जटिलताएँ जानने की आवश्यकता नहीं पड़ती।

उपयोगकर्ता के लिए क्यों यह महत्वपूर्ण है

उपयोगकर्ता के लिए, सही बिलिंग वास्तुकला संभवतः पूरी तरह से दिखाई नहीं देनी चाहिए।

यदि खरीद पुष्टि हो गई है और भुगतान की गई अवधि चल रही है, तो पहुँच काम करनी चाहिए।

यदि उपयोगकर्ता ने आगे का नवीनीकरण बंद कर दिया है, तो पूर्व भुगतान की गई अवधि जल्दी समाप्त नहीं होनी चाहिए।

यदि नया सफल नवीनीकरण हुआ है, तो पहुँच जारी रहनी चाहिए।

यदि स्टोर ने रिटर्न या रद्दीकरण की पुष्टि की है, तो अधिकार में बदलाव को सही ढंग से दर्शाना चाहिए।

डिवाइस बदलने या ऐप को पुनः इंस्टॉल करने पर, किसी को भी बार-बार यह साबित करने की जरूरत नहीं कि खरीदारी वास्तव में मौजूद है।

अंत में, नियम इतना सरल हो जाता है:

ग्राहक खरीदारी की जानकारी देता है, स्टोर उसकी स्थिति का बाहरी स्रोत है, BillingMeld इसे सत्यापित और सामान्यीकृत करता है, और बाकी सेवाएं सत्यापित किए गए डेटा के आधार पर निर्णय लेती हैं।

इसी कारण से, BillingMeld केवल एक भुगतान मोड्यूल नहीं है।

यह मोबाइल ऐप, Apple और Google की दुकानों और उन उत्पादों के बीच भरोसे का सर्वर साइड परत है, जिन्हें आप सुनिश्चित करना चाहते हैं कि उपयोगकर्ता को अब कौन से भुगतान अधिकार प्राप्त हैं।

अधिक जानकारी: billingmeld.de.