BillingMeld: अ‍ॅप्लिकेशनच्या ऐवजी सर्व्हरकडून खरेदीची तपासणी का आवश्यक आहे

मोबाईल अ‍ॅप्लिकेशनमधील खरेदी ही सामान्यतः वापरकर्त्यासाठी सोपी वाटते. तो बटणावर क्लिक करतो, पैसे मान्य करतो, फंक्शन किंवा सदस्यता वापरायला मिळते — आणि नंतर सर्व काही स्वयंचलितपणे चालेल अशी अपेक्षा करतो.

पण विकासकांसाठी ही प्रक्रिया खूपच अधिक जटिल होते. खरेदीची स्वतःची पुष्टी करावी लागते, त्यात वाढी, सदस्यता समाप्ती, परतावा, ऑपरेशन्सचे अभिप्राय, डिव्हाइस बदल, आणि Apple व Google च्या दुकानांमधील फरकांची व्यवस्था करावी लागते.

मुख्य समस्या तेव्हाच उद्भवते जेव्हा सर्व्हर ग्राहक अ‍ॅपला सत्याचा स्रोत मानतो.

जर अ‍ॅपने: "खरेदी पूर्ण झाली" असे सांगितले, तर सर्व्हर access देते आणि एकदा मिळालेल्या स्थितीवरच तो लक्ष केंद्रित करतो. पण खरेदीचा जीवनचक्र येथेच संपत नाही.

सदस्यता वाढवली जाऊ शकते, ऑटो-रेनॉल्ड बंद केली जाऊ शकते, पैसे परत घेता येऊ शकतात, आणि ऑपरेशनला दुकानाने रद्द केले जाऊ शकते.

याच कारणामुळे BillingMeld मध्ये खरेदी हे पुष्टी करत नाही, तर सर्व्हर करतो.

क्लाइंट माहिती देतो, पण निर्णय घेऊ शकत नाही

BillingMeld च्या आर्किटेक्चरमध्ये, मोबाइल अ‍ॅप एक मुख्य माहितीचे स्रोत नाही.

क्लाइंट ऑपरेशनची माहिती देऊ शकतो, पण ही फक्त तपासणीस आधार आहे. अंतिम निर्णय BillingMeld च्या सर्व्हर भागाकडे असतो, जे Apple किंवा Google च्या इन्फ्रास्ट्रक्चरमधून माहिती तपासते.

ही मुख्य तफावत आहे.

फोनवरील अ‍ॅप जुन्या स्थितीसह काम करू शकते, वेळेवर बदल मिळू शकत नाही, किंवा अशी माहिती देऊ शकते जी आता खरेदीच्या सद्य स्थितीशी जुळत नाही.

याव्यतिरिक्त, क्लाइंटला स्वतः निर्णय घेण्याची गरज नाही की वापरकर्त्याला पैसे देणे योग्य समजले पाहिजे का.

BillingMeld तपासते, उदाहरणार्थ:

• असंख्य खरेदी अस्तित्वात आहे का?

• संबंधित अ‍ॅप आणि उत्पादनाशी संबंधित आहे का?

• भरलेला कालावधी सध्या चालू आहे का?

• आणखी एक वाढ झाली का?

• ऑटो-रेनॉल्ड बंद केले का?

• परतावा झाला का?

• ऑपरेशन रद्द केले का?

• भरणा कालावधी संपला का?

म्हणून, ग्राहकाचं संदेश खरेदीचे पुरावे म्हणून नाही, तर त्याची खरी स्थिती तपासण्याचा आधार बनतो.

सर्व्हरांसाठी एकच सत्य स्रोत

संबधित सेवा स्वतःच पूर्ण इंटिग्रेशन राबविण्याची गरज नाही. ते BillingMeld कडे जाऊन्, आधीच सामान्यीकृत खरेदीची स्थिती प्राप्त करतात.

उदाहरणार्थ: प्रवेश सध्या सक्रीय आहे, भरण्याचा कालावधी संपला, पुढील वाढ निश्चित झाली, ऑटो-रेनॉल्ड बंद केले किंवा खरेदी रद्द केलेली आहे.

यामुळे जबाबदारी स्पष्टपणे विभागली जाते.

Apple आणि Google ही खरेदी प्रक्रियेचीच स्त्रोत आहेत. BillingMeld या माहितीची तपासणी करतो, त्यांना सामान्य करू्न ठेवतो, आणि सद्यस्थिती कायम ठेवतो. शेवटी, खात्री झाल्यावर, प्रवेश निर्णय घेतो.

उत्पादनासाठी, हे एक एकसंध करार असतो, ज्यामुळे अनेक स्वतंत्र इंटिग्रेशन टाळता येतात.

आणि याचा फायदा असा की, प्रत्येक सेवा वेगळ्या फॉरमॅट, इव्हेंट्स, आणि स्टेटसची काळजी न करता, एकसंध लॉजिक वापरू शकते.

का ग्राहकावर पूर्ण विश्वास ठेवता येत नाही

ग्राहक अ‍ॅप वापरकर्त्याच्या डिव्हाइसवर चालते.

याला बंद, पुन्हा सुरू, बॅकअपमधून पुनःस्थापित, नंतर अपडेट, किंवा दुसऱ्या डिव्हाइसवर चालवले जाऊ शकते. काही काळ जुनी माहिती वापरू शकते, किंवा त्याने सुरुवातीच्या खरेदीनंतर घडलेल्या घटनांची माहिती मिळू शकत नाही.

वापरकर्त्याने काहीही न करता, ही माहिती अंतिम स्थिती दर्शवण्याचा बरा स्रोत नाही.

उदाहरणार्थ, वापरकर्ता सदस्यता घेतो आणि प्रवेश मिळवतो. नंतर, पुनः खरेदीला परतावा मिळू शकतो किंवा दुकान ऑपरेशन रद्द करू शकते.

जर सर्व्हरला फक्त सुरुवातीच्या संदेशाची माहिती असेल, तर तो खरेदीची अवस्था कायम राहील असे समजून राहील.

दुसऱ्या परिस्थितीत, वापरकर्ता ऑटो-रेनॉल्ड बंद करू शकतो. त्यानंतरही, आधीच दिलेले पैसे असलेल्या कालावधीपर्यंत तो वापर केला जाऊ शकतो.

जर सिस्टम फक्त 'सदस्यता आहे / नाही' असा सोपा स्टेटस वापरते, तर तो देखील खरेदीची खरी स्थिती ओळखण्यास अयोग्य ठरेल, आणि अ‍ॅक्सेस वेळेत बंद होऊ शकतो, किंवा बाकी राहू शकतो जरी अधिकार संपलेला असला तरी.

BillingMeld ची रिती वेगळी आहे — ग्राहक त्यांचे अधिकार स्वतः पुष्टी करत नाही. तो फक्त घटना नोंदवतो, आणि सर्व्हर खरेदीची खरी स्थिती ठरवते.

खरेदी — ही एकक घटना नाही

बिलिंग आर्किटेक्चरमधील मुख्य चुका म्हणजे खरेदीला एक घटनेप्रमाणे मानणे.

खरंतर, त्याचा एक जीवनचक्र आहे.

सुरुवात ऑपरेशनने होते. त्यानंतर ते दुकानद्वारे पुष्टी होते. सदस्यतेसाठी भरण्याचा कालावधी सुरू होतो. नंतर, पुनः वाढ होऊ शकते.

वापरकर्ता ऑटो-रेनॉल्ड बंद करतो, पण त्याचा उपयोग सद्याचा भरणा केलेला कालावधी संपेपर्यंत करू शकतो.

पैसे परत घेता येऊ शकतात, ऑपरेशन रद्द केले जाऊ शकते, किंवा काही परिस्थितीत खरेदी रद्द होऊ शकते.

म्हणून, एकदा का 'खरेदी असे दिसते की पूर्वी अस्तित्वात होती', एवढे पुरेसे नाही.

सर्व्हरला हे समजणे महत्त्वाचे आहे की, आताच काय चालले आहे.

परताव्याची व रद्द करण्याची वेळ दिसते

बिल्डिंग अर्जाछे अजून स्पष्ट उदाहरण म्हणजे परतावे आणि ऑपरेशन रद्द करण्याचे उदाहरण.

प्राथमिक खरेदी बिलकुलच योग्य असू शकते. वापरकर्त्याने खरीपणे पैसे भरले आहेत, आणि प्रवेश देखील प्राप्त झाला आहे.

पण, नंतर ऑपरेशनची अवस्था बदलू शकते.

BillingMeld जर परिवर्तनाची माहिती मिळाली, तर तो खरेदीचे स्टेटस अपडेट करतो, आणि गरज असल्यास, दुकानद्वारे तपास करतो.

संबंधित सेवा नवीन स्टेटससह काम सुरू ठेवते.

अशा प्रकारे, अ‍ॅपची विश्वासार्हता कायम राहत नाही, पण BillingMeld ही माहिती योग्यरित्या दर्शवतो.

सदस्यता रद्द करणे व प्रवेश समाप्त करणे — भिन्न गोष्टी

या मध्ये मुख्य फरक आहे.

जर वापरकर्त्याने ऑटो-रेनॉल्ड बंद केली, तर लगेच प्रवेश बंद होतो असे नाही. सद्याचा भुगतान कालावधी चालू राहू शकतो.

BillingMeld ने त्याची नोंद करावी, की पुढील रिनॉल्ड बंद केले आहे, पण त्या आधीच्या कालावधीचा शेवटीऽ पटवून घ्यावा.

फक्त त्या समाप्तीनंतरच, प्रवेश बंद केला जातो, जर नवीन पुष्टीकरण नसलं.

हे एक कारण आहे की, 'subscription = true' असे simple बूलियन स्टेटस पुरेशा नाही.

सदस्यतेचा स्टेटस वेळ आणि तिच्या जीवनचक्राच्या घटकांवर अवलंबून असतो.

वाढ म्हणजेही एक स्वतंत्र तपासणी

सदस्यता फक्त पहिल्या पेमेंटवर संपत नाही.

सर्व्हरला जाणणे आवश्यक आहे की, पुन्हा वाढ झाली का, आणि पुढील कालावधी खरेदीद्वारे पुष्टी झाली का.

BillingMeld या बदलांना लक्ष ठेवतो आणि सदस्यतेचे स्टेटस अपडेट करतो.

जर वाढ पुष्टी झाली, तर प्रवेश सुरू राहतो.

पुढील पेमेंट न झाल्यास, किंवा दुकान पुढील कालावधीची पुष्टी करत नसेल, तर प्रणाली आपोआप प्रवेश वाढवू नये.

वापरकर्त्यास त्याचा अनुभव असा असतो की, तो जास्तीत जास्त, त्याच्या खरेदी झालेल्या सदस्यतेच्या कालावधीपुरतेच प्रवेश आहे.

आणि, याचा अर्थ हा की, प्रत्येक अ‍ॅपमध्ये पुनः एकच लॉजिक वापरून पुनः तयार कराट पडत नाही.

सामान्य स्थिती कशी दिसते

वापरकर्ता सदस्यता घेतो, अ‍ॅपमधे खरेदीची घोषणा होते, आणि आवश्यक माहिती BillingMeld ला दिली जाते. पण, हीच माहिती खरेदी नंतर कायमच पुष्टी केलेली मानली जात नाही.

BillingMeld ते ऑपरेशन तपासतो, दुकानाची पुष्टी घेतो, जर ते योग्य असेल, तर सक्रिय अधिकार नोंदवतो.

यानंतर, सेवा वापरकर्त्यास भरलेले फिचर्स देते. स्टेटस त्या नंतर, ग्राहकाच्या पहिल्या संदेशापेक्षा स्वतंत्र राहतो. जर सदस्यता वाढली तर, BillingMeld नवीन कालावधी लक्षात घेते. जर ऑटो-रेनॉल्ड बंद करायची असेल, तर, सद्याचा कालावधी अंतिम होईपर्यंत चालू राहतो. जर परतावा किंवा रद्दीकरण झाले, तर स्थिती बदलते. ही सिस्टीम एकच खरेदीची खरी स्थिती दर्शवत नाही, पण BillingMeld च्या पुष्टी केलेल्या स्थितीवर काम करते.

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

सर्व्हरकडील मॉडेल विशेषतः उपयुक्त असते, जेव्हा वापरकर्ता फोन बदलतो किंवा पुन्हा एकदा अॅप इंस्टॉल करतो.

खरेदी हक्क हे फक्त त्या अ‍ॅपच्या यशस्वी ट्रांझेक्शनवर आधारित नाही. पुनः इंस्टॉल केल्यावर, पुष्टी केलेले हक्क नष्ट होऊ नयेत.

जर खरेदीची स्थिती सर्व्हरवर असते, आणि दुकानाशी जोडलेली असेल, तर नवीन डिव्हाइस त्वरित त्याची माहिती घेऊ शकते.

हे आणखी एक कारण आहे की, प्रवेश लॉजिक फक्त मोबाइल क्लायंट मध्ये ठेवू नये.

यामुळे विकसकांना काय मिळते

जर भागीदारी अनेक मोबाइल अ‍ॅप्स विकसित करत असतील, किंवा iOS आणि Android वर एकाच वेळी काम करत असतील, तर बिलिंग ही एक स्वतंत्र अवयव बनते.

त्याला लक्षात ठेवावं लागते:

• Apple व Google च्या डेटा फॉरमॅट्स

• प्राथमिक खरेदीची पुष्टी

• सदस्यता वाढी

• भरलेली समाप्ती

• ऑटो-रेनॉल्ड बंद करणे

• परतावे

• ऑपरेशन रद्द करणे

• पुन्हा अॅप इंस्टॉल करणे

• डिव्हाइस बदला

• खरेदी पुनर्स्थापना

• अप्रत्यक्ष बदल

BillingMeld ही सर्व लॉजिक एक स्वतंत्र स्तरावर नेतो. विविध सर्व्हर ही बातमी एकाच करारावर काम करतात, आणि प्रत्येक दुकानाच्या वैशिष्ट्ये वेगळ्या समजून घेण्याची गरज नाही. त्याने कोडची पुनरावृत्ती कमी केली वात. आणि त्या कंपन्याच्या वेगवेगळ्या अ‍ॅप्सना एकाच पेमेंट सीनारिओ समजण्याची शक्यता कमी करते.

मुख्य गोष्ट केवळ चेक नाही, ती सध्याची अधिकार आहे

मला या आर्किटेक्चरमध्ये सर्वात जास्त आकर्षित केलेले, म्हणजे खरेदीकडे पाहण्यापेक्षा, त्याच्या सद्य स्थितीवर लक्ष केंद्रित करणे.

पेमेंटचा एक इतिहास, स्वयंखालीच, मुख्य प्रश्नावर उत्तरे देत नाही:

वापरकर्त्याकडे सध्या, पैसे देण्याचा अधिकार आहे का?

ऑरिजनल खरेदीवर अधीर नसतानाही, एक अपूर्णकालीन भरणा असू शकतो. सदस्यतेला ऑटो-रेनॉल्ड बंद असू शकते, पण तो आधीच दिलेला कालावधी चालू राहतो. पुष्टीकरण केलेली वाढ संभवते. परतावा होऊ शकतो. दुकान ऑपरेशन रद्द करू शकते. म्हणून, मुख्य घटक हा नाही की, 'हा तपासलेला करार आहे की नाही', किंवा 'या ग्राहकाचा उत्तर काय आहे', तर, विकसीत अधिकाराचा थीट आहे, जो पुष्टी केलेल्या स्थितीनुसार ठरवला जातो.

याच कारणामुळे, BillingMeld ही माहिती इतर सेवेना देते.

BillingMeld ही दुकानं व उत्पादनांमधील सीमा

यामुळे एक स्पष्ट वास्तुकला सीमा तयार होते. एक बाजूला आहे App Store व Google Play, त्यांचे फॉरमॅट्स, इव्हेंट्स, नियम आणि जीवनचक्र. दुसर्‍या बाजूला, अ‍ॅप्स व आंतरिक सेवा, ज्यांना साधं उत्तर हवं असतं — सध्याचे वापरकर्ता अधिकार काय?

त्यांच्यामध्ये आहे BillingMeld. तो दुकानांच्या डेटाची प्रक्रिया करतो, त्यांना सामान्य स्वरूपात आणतो, आणि त्यानंतर तयार केलेली स्थिती बाकीच्या संरचनेला प्रदान करतो. या प्रक्रियेमुळे, उत्पादने प्रत्येक प्लॅटफॉर्मची सर्व अंतर्गत वैशिष्ट्ये जाणण्याची गरज नाही.

महत्व का आहे वापरकर्त्यासाठी

वापरकर्त्यासाठी, ही योग्य बिलिंग आर्किटेक्चर कधीच दिसावं नये. जर खरेदी पुष्टी झाली आणि भरण्याचा कालावधी चालू आहे, तर प्रवेश चालू राहील. जर वापरकर्त्याने पुढील वाढ बंद केली, तर त्याचा कालावधी वेळपूर्वी संपून जाऊ नये. जर नवीन वाढ झाली, तर प्रवेश पुढे चालू राहावा. जर दुकानाने परतावा किंवा रद्दीकरण मान्य केले, तर अधिकार योग्यरित्या प्रतिबिंबित करावा. टचस्क्रीन बदलल्यावर, पुन्हा स्थापित केल्यावर, वापरकर्त्याला प्रत्येक भागासाठी विनंती करावी लागत नाही की, खरेदी खरी आहे हे दाखवा. एक साध्या नियमाने, ग्राहक खरेदीची माहिती देतो, दुकान बाह्य स्त्रोत आहे, BillingMeld तपासतो आणि सामान्य करतो, आणि इतर सेवा पुष्टी केलेल्या डेटावर आधारित निर्णय घेतात. म्हणून, BillingMeld फक्त एक पेमेंट मॉड्यूल नाही, तर विश्वासाचा सर्व्हर स्तर आहे, जो मोबाइल अ‍ॅप, Apple, Google दुकानं व उत्पादनांमधील एक बंधन आहे, जिथे ग्राहकाच्या हक्कांची अचूक माहिती पाहिजे. अधिक माहिती: billingmeld.de.