IOSOR المعرفة

إرسال المستخدم النهائي لا يزال يخصم من دفتر حسابات مسبق الدفع واحد

المراسلة المضمنة خصمًا من محفظة ISV مسبقة الدفع. لا تبتكر دفتر حسابات ثانيًا لا يموله المنتج - يجب أن تظل عمليات الحجز وإعادة المحاولة واللادورية صادقة.

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

المحاسبة الوهمية هي نمط الفشل الشائع: عداد رصيد داخل التطبيق غير مدعوم بمحفظة IOSOR، أو استرداد الأموال في SaaS بينما يحترق دفتر الحسابات مسبق الدفع، أو إعادة المحاولة بدون لادورية مما يترتب عليه خصم مزدوج لرمز OTP واحد. يخفي التضمين لوحة التحكم، لكن ISV يظل الطرف الممول.

قاعدة الهندسة المعمارية: إرسال المستخدم النهائي ≡ خصم مسبق الدفع لـ ISV. كل مراجعة تصميم تبدأ من هناك.

دفتر حسابات واحد، حتى عندما تعرض واجهة المستخدم رصيد المنتج

حزم الرسائل المباعة للمستأجرين هي طبقة تجارية لـ ISV. يجب أن ترتبط بحجوزات وخصومات مسبقة الدفع على محفظة IOSOR الوحيدة التي يمولها ISV. رصيد المستأجر الذي لا يتوافق أبدًا مع صفوف دفتر الحسابات هو قنبلة ديون على الدعم الفني. قم بتصدير استخدام المستأجر أسبوعيًا مقابل خطوط المحفظة حتى ترى المالية نفس الاستهلاك الذي يراه المنتج.

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

الحجز واللادورية لا يزالان ملزمين في المسارات المضمنة

يجب أن يستخدم الإرسال من جانب الخادم مفاتيح اللادورية لرسائل OTP والرسائل النصية المعاملاتية. النقرة المزدوجة في واجهة SaaS يجب ألا تنشئ خصمين لإجراء مستخدم واحد. تتبع إعادة المحاولة بعد انتهاء المهلة نفس المفتاح حتى تقرير التسليم النهائي DLR أو الفشل المخطط.

عندما تعجز المحفظة عن الحجز، أعد حالة عدم كفاية الأموال أو إيقاف الإرسال الخاصة بالمنتج. لا ترجع أبدًا HTTP 200 بدلالات التسليم عندما يفشل الحجز.

رسم خرائط أخطاء المنتج لحقيقة دفتر الحسابات

إشارة واجهة SaaS حقيقة دفتر الحسابات الخطوة التالية المسموح بها
تم الإرسال / تم التسليم الخصم + مسار DLR موجود عرض معرف الإيصال
في الانتظار الحجز مفتوح أو التقديم مقبول الاستعلام عن الحالة
فشل / متوقف الحجز مرفوض أو بوابة الإيقاف إعادة المحاولة فقط بنية جديدة
نجاح مزيف لا يوجد خصم / لا يوجد حجز ممنوع تمامًا

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

تسليم القنوات يظل على المحفظة نفسها

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

مسارات العمليات ذات الصلة

ابدأ مع IOSOR

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

خلاصة IOSOR

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

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

هل كان هذا الدليل مفيداً؟

أدلة ذات صلة