تغيير باقة الاشتراك أثناء الفترة: ماذا يرى العميل قبل التأكيد؟

عند تغيير باقة اشتراك، لا يكفي عرض السعر الشهري الجديد. يحتاج العميل إلى معرفة موعد بدء الباقة، ومصير الجزء غير المستخدم من الفترة السابقة، وما سيدفعه الآن وما سيظهر لاحقا. اتفق على هذه النتائج قبل تكليف المطور ببناء شاشة الترقية.

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

افصل سعر الباقة المقبلة عن تكلفة الانتقال

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

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

حدد أيضا موعد تغيير الوصول إلى الوظائف. هل تبدأ المزايا بعد تأكيد التغيير، أم نجاح الدفع، أم موعد التجديد؟ على تطبيقك وتكامله تنفيذ هذه القاعدة. حساب مبلغ متوقع لا يمنح العميل صلاحية جديدة بحد ذاته.

اعرض حساب المزود بدلا من تقدير يومي مستقل

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

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

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

الرصيد لا يعني بالضرورة إعادة المال

ينص Stripe على أن التسويات السالبة لا تسترد تلقائيا، وأن التسويات الموجبة لا تصدر بها فاتورة فورا، مع إمكان تنفيذ الإجراءين بشكل منفصل. لذلك لا يكفي ظهور مبلغ تسوية لتقول «أرسلنا الاسترداد» أو «خصمنا المبلغ الآن».

اطلب تسمية النتيجة الفعلية: تسوية تنتظر فاتورة لاحقة، أو فاتورة أصدرت الآن، أو دفع مؤكد، أو إجراء استرداد مستقل. اختر السلوك المدعوم مع مسؤول الفوترة، ثم طابق نص التأكيد معه. ولا تصف رصيدا في الحساب بطريقة توحي بأن المال سيصل إلى حساب العميل البنكي إذا لم يكن ذلك هو الإجراء الفعلي.

توقف للمراجعة إذا لم تدفع فاتورة الفترة الحالية

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

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

اختبر الانتقال في الاتجاهين

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

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

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