BillingMeld: لماذا يجب أن يتحقق الخادم من الشراء بدلًا من التطبيق

عادةً ما تبدو عملية الشراء داخل التطبيق المحمول بسيطة للمستخدم. يضغط على الزر، يؤكد الدفع، يحصل على وصول لميزة أو اشتراك — ويتوقع أن يعمل كل شيء تلقائيًا بعد ذلك.

لكن بالنسبة للمطور، يبدأ عملية أكثر تعقيدًا بكثير خلف هذا الزر. يحتاج إلى تأكيد الشراء نفسه، مراقبة عمليات التمديد، انتهاء الاشتراك، عمليات الإرجاع، مراجعات العمليات، تغيير الجهاز والفروق بين متجري Apple وGoogle.

المشكلة الرئيسية تظهر عندما يبدأ الخادم في اعتبار التطبيق العميل كمصدر للحقيقة.

إذا أبلغ التطبيق: «تم الشراء»، يفتح الخادم الوصول ويواصل الاعتماد على الحالة التي تم استلامها مرة واحدة. لكن دورة حياة الشراء لا تنتهي عند ذلك.

قد يتم تمديد الاشتراك، وقد يتم إيقاف التمديد التلقائي، وقد يتم استرداد الدفع، وقد يتم سحب العملية من قبل المتجر.

لهذا السبب، في BillingMeld، يؤكد الخادم الشراء، وليس التطبيق.

العميل يبلغ لكنه لا يقرر

في بنية BillingMeld، لا يُعد التطبيق المحمول المصدر الرئيسي لمعلومات الشراء.

يمكن للعميل إرسال بيانات العملية التي أتمها، لكنها تكون فقط أساسًا للتحقق. يتخذ الجزء النهائي من القرار الخادم، الذي يتحقق من المعلومات عبر بنية تحتية لـ Apple أو Google.

هذه اختلاف جوهري.

يمكن للتطبيق على الهاتف العمل مع حالة قديمة، أو عدم استلام التحديث الجديد في الوقت المناسب، أو إرسال بيانات لا تتطابق مع الحالة الحالية للشراء.

بالإضافة إلى ذلك، لا ينبغي أن يكون لدى العميل إمكانية اتخاذ قرار مستقل بشأن منح المستخدم وصولًا مدفوعًا.

يتحقق BillingMeld من أمثلة، مثل:

• هل يوجد شراء محدد بالفعل;

• هل ينتمي إلى التطبيق والمنتج المطلوب؛

• هل لا يزال فترة الدفع سارية؛

• هل تم التمديد مرة أخرى؛

• هل تم إيقاف التمديد التلقائي؛

• هل تم إجراء عملية استرداد؛

• هل تم سحب العملية؛

• هل لم تنته مدة الدفع؛

وبالتالي، يصبح رسالة العميل ليست دليلاً على الشراء، بل سببًا للتحقق من الحالة الفعلية له.

مصدر موثوق واحد للحقيقة للخوادم

لا تحتاج الخدمات المربوطة إلى تنفيذ مجموعة كاملة من تكاملات لـ Apple وGoogle في آن واحد.

يطلبون من BillingMeld ويحصلون على الحالة الموحدة للشراء بالفعل.

على سبيل المثال: الوصول فعال، انتهت فترة الدفع، تم تأكيد التمديد، التمديد التلقائي متوقف، أو تم سحب الشراء.

هذا يسمح بتقسيم المسؤولية بوضوح.

تعتبر Apple وGoogle مصدر الحالة لعملية المتجر نفسها. يتحقق منهما BillingMeld، ويقوم بتوحيد البيانات ويحفظ الحالة الحالية. وتقرر المنتج النهائي عن الوصول بناءً على حالة BillingMeld.

بالنسبة لخوادم المنتجات، هذا يعني عقدًا موحدًا بدلًا من عدة تكاملات مستقلة.

لا حاجة لكل خدمة على حدة لتنفيذ قواعد متجر التطبيقات، منفصلة عن Google Play، ثم محاولة توحيد التنسيقات والأحداث والأوضاع المختلفة في منطق واحد.

لماذا لا يمكن الاعتماد كليًا على العميل

التطبيق على الجهاز يعمل على جهاز المستخدم.

يمكن إغلاقه، إعادة تشغيله، استعادته من النسخ الاحتياطية، تحديثه لاحقًا، أو تشغيله على جهاز آخر. يمكن أن يعمل بعض الوقت بمعلومات قديمة أو لا يتلقى حدثًا حدث بعد العملية الأصلية.

حتى بدون أي تدخل من المستخدم، يجعل ذلك العميل مصدرًا ضعيفًا للحالة النهائية للاشتراك.

على سبيل المثال، قام المستخدم بالاشتراك وحصل على الوصول. فيما بعد، تم إرجاع الشراء أو سحب العملية من قبل المتجر.

إذا كان الخادم يعلم فقط عن الرسالة الأولية من العميل، فسوف يظل يعتبر أن الشراء لا يزال فعالًا.

في حالة أخرى، قد يعطل المستخدم التمديد التلقائي. ومع ذلك، يجب أن تظل الفترة المدفوعة سارية حتى تاريخ انتهائها.

إذا كانت الحالة تعتمد فقط على حالة بدائية مثل «الاشتراك موجود / غير موجود»، فقد تؤدي إلى إغلاق الوصول مبكرًا جدًا أو إبقائه بعد انتهاء الحق في الاستخدام.

تم بناء BillingMeld على منطق آخر: العميل لا يؤكد حقوقه بنفسه. هو يبلغ عن حدث، والخادم يحدد الحالة الفعلية للشراء.

الشراء ليس حدثًا واحدًا

واحدة من الأخطاء الرئيسية في بنية النظام هو اعتبار الشراء حدثًا واحدًا فقط.

في الواقع، لديه دورة حياة.

في البداية، توجد عملية. ثم يتم تأكيدها بواسطة المتجر. يبدأ فترة الدفع المدفوعة للاشتراك. فيما بعد، يمكن أن يحدث تمديد مرة أخرى.

يمكن للمستخدم تعطيل التمديد التلقائي، لكنه لا يزال يمكنه استخدام الاشتراك حتى نهاية الفترة المدفوعة بالفعل.

قد يفشل الدفع في التمديد التالي.

قد يتم إجراء استرداد.

أحيانًا، يمكن سحب الشراء.

وبالتالي، فإن وجود مجرد حقيقة «هذه العملية كانت موجودة في وقت ما» غير كافٍ.

من المهم للخادم أن يفهم ما يحدث حاليًا مع هذا الشراء.

السحب لا يمر دون ملاحظة

هذه الحاجة تكون واضحة جدًا خاصة عند عمليات الاسترداد والسحب.

قد يكون الشراء الأولي صالحًا تمامًا. قام المستخدم بدفع المنتج وحصل على الوصول.

لكن فيما بعد، تغيرت حالة العملية.

إذا تلقى BillingMeld معلومات عن التغيير، يقوم بتحديث حالته الخاصة ويقوم، إذا لزم الأمر، بالتحقق من البيانات عبر المتجر.

بعد ذلك، يعمل الخدمة المربوطة بالحالة الجديدة.

وهكذا، لا يواصل التطبيق الاعتماد بشكل غير محدود على حقيقة أن العميل أبلغ عن شراء ناجح قبل أسابيع أو شهور.

إذا لم يعُد المتجر يعتبر هذا الحق فعالًا، يعكس BillingMeld ذلك في حالته.

إلغاء الاشتراك وانتهاء الوصول — ليسا الشيء نفسه

هنا يوجد فرق مهم.

إذا قام المستخدم بإيقاف التمديد التلقائي، فذلك لا يعني بالضرورة أن الوصول يجب أن يُغلق فورًا.

قد تستمر الفترة المدفوعة الحالية في العمل.

في هذه الحالة، يجب أن يحتفظ BillingMeld بمعلومات حول إيقاف التمديد التلقائي، مع فهم تاريخ انتهاء الفترة المدفوعة بالفعل.

وعند نهايتها، يُعتبر الوصول غير نشط إلا إذا تم تأكيد تمديد جديد.

هذه واحدة من الأسباب التي تجعل من غير الكافي ببساطة أن يكون هناك قيمة بوليانية subscription = true لعملية الشراء الصحيحة.

حالة الاشتراك دائمًا مرتبطة بالوقت والأحداث المرتبطة بدورة حياتها.

التمديد هو أيضًا فحص منفصل

الاشتراك لا ينتهي عند الدفع الأول فقط.

يجب على الخادم أن يتأكد من حدوث التمديد التالي، وأنه تم تأكيد الفترة المدفوعة التالية بواسطة المتجر بالفعل.

يتابع BillingMeld هذه التغييرات ويحدث الحالة.

إذا تم تأكيد التمديد، يستمر الحق في الوصول.

إذا لم يحدث خصم آخر، أو لم يعُد المتجر يؤكد الفترة التالية، فلا ينبغي للنظام أن يمدد الوصول تلقائيًا استنادًا إلى افتراضات.

يبدو هذا للمستخدم طبيعيًا: الوصول موجود طوال مدة الاشتراك المدفوعة فعليًا.

بالنسبة للمطورين، هذا يعني عدم الحاجة إلى تكرار منطق التمديد نفسه في كل تطبيق.

كيف يظهر السيناريو العادي

يقوم المستخدم باشتراك عبر التطبيق المحمول.

يحصل العميل على معلومات حول الشراء وينقل البيانات الضرورية إلى BillingMeld. لكن هذه الرسالة نفسها ليست بعد سببًا لاعتبار الشراء مؤكدًا نهائيًا.

يتحقق BillingMeld من العملية عبر المتجر المختص.

إذا أكد متجر التطبيقات أو Google Play عملية الشراء وحالتها تتوافق مع قواعد المنتج، يسجل BillingMeld الحق النشط.

بعد ذلك، توفر الخدمة المربوطة للمستخدم الامتيازات المدفوعة.

تستمر الحالة في الحياة بشكل مستقل عن رسالة العميل الأولى.

عند التمديد، يأخذ BillingMeld في الاعتبار الفترة المدفوعة الجديدة.

عند إلغاء التمديد التلقائي، تستمر الفترة الحالية حتى نهاية مدتها.

عند إجراء استرداد أو سحب العملية، تتغير الحالة مرة أخرى.

في هذا النموذج، لا يحتفظ التطبيق بحقيقة فردية منفصلة عن الشراء. إنه يعمل مع الحالة التي تؤكدها وتحفظها BillingMeld.

ماذا يحدث عند تغيير الجهاز

النموذج الخادم مفيد بشكل خاص عندما يغير المستخدم هاتفه أو يعيد تثبيت التطبيق.

لا ينبغي أن يكون الحق في الشراء موجودًا فقط لأن نسخة التطبيق المحددة شهدت عملية ناجحة سابقًا.

وبالعكس، إعادة تثبيت التطبيق لا ينبغي أن تلغي الحق المؤكد للمستخدم.

إذا كانت حالة الشراء موجودة على الجانب الخادم ومرتبطة بعملية تم التحقق منها من المتجر، يمكن للجهاز الجديد أن يحصل على الحالة الحالية عبر الخادم.

هذه سبب آخر لعدم خزن منطق الوصول داخل العميل المحمول فقط.

ماذا يفيد ذلك للمطورين

بالنسبة للفريق الذي يصدر عدة تطبيقات محمولة أو يعمل على iOS وAndroid في وقت واحد، يتحول نظام الفوترة بسرعة إلى مهمة بنية تحتية مستقلة.

عليهم أخذ في الاعتبار:

• تنسيقات البيانات المختلفة بين Apple وGoogle;

• التحقق من الشراء الأولي;

• تمديد الاشتراكات;

• انتهاء الفترة المدفوعة;

• إيقاف التمديد التلقائي;

• الاسترجاعات;

• سحب العمليات؛

• تثبيت التطبيق مرة أخرى;

• تغيير الجهاز;

• استعادة المشتريات;

• تغيّر الحالة التي حدثت بدون تدخل العميل.

ينقل كل ذلك منطق الفوترة إلى طبقة متخصصة منفصلة.

تعمل خوادم المنتجات معه وفق عقد موحد، ويجب ألا تفسّر بشكل مستقل كل خصائص المتجر.

هذا يقلل من تكرار الكود، والأهم أنه يقلل من إمكانية اختلاف فهم سيناريو الدفع ذاته بين تطبيقات شركة واحدة.

المفتاح ليس الأذن، بل الحالة الحالية

ما جذبني أكثر في هذه البنية هو الانتقال من التحقق من عملية شراء واحدة إلى مراقبة الحالة الفعلية.

الحقيقة التاريخية للدفع لا تجيب على السؤال الأهم لمنتجك:

هل يحق للمستخدم الآن الوصول إلى الوظيفة المدفوعة؟

حتى لو كانت هناك عملية شراء أولية ناجحة، قد تنتهي الفترة.

يمكن أن يكون التمديد التلقائي غير متصل، لكن الحصة المدفوعة لا تزال سارية.

يمكن أن يكون هناك تمديد مؤكد.

يمكن أن يكون هناك استرجاع.

وأحيانًا، يمكن سحب العملية.

لذلك، فإن الشيء الأكثر أهمية هو الحالة الفعلية للمستخدم، والتي تُحسب بناءً على حالة الشراء المؤكدة.

وهذا هو الحالة التي تنقلها BillingMeld إلى باقي الخدمات.

BillingMeld كحدود بين المتاجر والمنتجات

بفضل ذلك، تظهر حدود معمارية واضحة للغاية.

من جهة، هناك App Store وGoogle Play مع تنسيقاتهم، وأحداثهم، وقواعدهم، ودورات حياة عمليات الشراء الخاصة بهم.

ومن جهة أخرى، هناك التطبيقات والخدمات الداخلية، والتي عادةً ما تحتاج إلى إجابة أبسط بكثير: ما هي الحقوق التي يملكها المستخدم الآن؟

بينهما تقع BillingMeld.

يستقبل بيانات المتجر، يتحقق منها، يوحّدها وفق نموذج خاص به، ويوفرها للبنية التحتية الأخرى بنتيجة موحدة بالفعل.

بذلك، لا تحتاج المنتجات إلى المعرفة بكافة الخصائص الداخلية لكل منصة دفع.

لماذا هذا مهم للمستخدم

بالنسبة للمستخدم، من المثالي أن تبقى بنية الفوترة الصحيحة غير ملحوظة بشكل أساسي.

إذا تأكد الشراء وكانت الفترة المدفوعة سارية، فيجب أن يعمل الوصول.

إذا أوقف المستخدم التمديد التلقائي، فلا يجب أن تختفي الفترة المدفوعة قبل موعد انتهائها.

إذا تم التمديد بنجاح، يجب أن يستمر الوصول.

إذا أكد المتجر استرجاع أو سحب، يجب أن يتم تحديث الحقوق بشكل صحيح.

عند تغيير الجهاز أو إعادة تثبيت التطبيق، لا يجب أن يُطلب من المستخدم أن يثبت لكل جزء من البنية التحتية أن الشراء لا بد أن موجود فعليًا.

بالتالي، يصبح المبدأ بسيطًا إلى حد كافٍ:

العميل يبلغ عن الشراء، والمتجر هو المصدر الخارجي لحالة الشراء، وBillingMeld يتحقق ويقنّن هذه الحالة، وتدعم باقي الخدمات القرار استنادًا إلى البيانات المؤكدة من قبلها.

لهذا السبب، تعتبر BillingMeld أكثر من مجرد وحدة دفع إضافية.

إنها الطبقة الموثوقة بين التطبيق المحمول، والمتاجر Apple وGoogle، والمنتجات التي تحتاج إلى فهم دقيق للأذونات المدفوعة التي يحق للمستخدم امتلاكها حاليًا.

مزيد من المعلومات عن المشروع: billingmeld.de.