الخلاصة

  • ربط RFC 3538 القيم 20 و40 و60 و80 و100 بإنشاء رسائل SET متتابعة أو معالجتها داخل جسر IOTP. كانت هذه معالم تقدم للواجهة، لا نسباً من النتيجة التجارية.
  • عند 100 كان PRes قد يعني تفويضاً مقبولاً أو تحصيلاً ناجحاً. وكان من الممكن أن تتحول CompletedOK لاحقاً إلى Failed بعد الإلغاء، بينما ظلت التسوية والتسليم خارج نطاق الإثبات.

تظهر لوحة التشغيل شريطاً ممتلئاً. ماذا يعرف المشغّل فعلاً؟ هل قُبل التفويض، أم تم التحصيل، أم أُنجزت التسوية بين المؤسسات، أم خرجت السلعة من المخزن، أم صار الإلغاء مستحيلاً؟ تميل الواجهات الحديثة إلى ضغط هذه الأسئلة في كلمة «اكتمل». أما RFC 3538، المنشور في يونيو 2003 بصفة Informational، فأجاب بدقة أضيق: عالج الجسر بين SET وIOTP آخر رسالة في خريطته الخاصة.

سعى IOTP إلى توفير هيكل مشترك للتجارة الإلكترونية مع إبقاء وسائل الدفع المحددة داخل Payment API. وشرح الملحق كيف تمر رسائل Secure Electronic Transaction عبر IOTP 1.0. لا تثبت المصادر المجمدة انتشاراً مقاساً ولا معاملة مسماة ولا حادثة فعلية. الأهمية التاريخية هي أن الملاحظة المحلية لم تتحول إلى حكم على الصفقة كلها.

يعرض القسم 8.12 خمس محطات. بعد إنشاء أول SET Initiation Response أو معالجتها تصبح PercentComplete مساوية لـ20. تقابل PinitReq القيمة 40، وPinitRes القيمة 60، وPReq القيمة 80، وPRes القيمة 100. يرى Consumer وPayment Handler الإنشاء والمعالجة من جهتين متقابلتين. وقد يتغير عدد رسائل البدء، ومع ذلك تظل أول استجابة عند 20. لذلك لا يقيس السلم أجزاء متساوية من العمل ولا الوقت الباقي؛ إنه خريطة اصطلاحية للواجهة.

للمحطة الأخيرة معنيان تجاريان. قد يتضمن PRes الناجح authorizationPerformed مع AuthCode مقبول، أو capturePerformed مع CapCode ناجح. يسمح التفويض بالمتابعة، أما التحصيل فهو لحظة أخرى. اشتراك الحدثين في الغلاف نفسه والقيمة نفسها لا يجعلهما حقيقة واحدة. لا يبيّن الشريط ما وقع ما لم يُحفظ الرمز.

وتحد آلة الحالات أيضاً من وهم النهاية. على جهة Payment Handler يمكن أن تبلغ المعاملة CompletedOK. لكن إذا أُلغي الدفع يسمح ChangeProcessState أو CancelPayment بالانتقال CompletedOK -> Failed. تعبّر الحالة عن رؤية مكوّن في وقت محدد. حذف مسار الانتقال يصنع نهائية لم تكن موجودة.

يكشف فحص الإيصال حداً أوضح. لا تفحص CheckPayReceipt معلومات Payment Receipt Information على نحو خاص؛ بل تعيد استجابة عامة إذا كان الطلب صالحاً. قد يكون هذا تقسيم المسؤولية الصحيح للواجهة. لكنه يصبح مضللاً إذا عُرضت سلامة البنية بوصفها تحققاً من الواقع التجاري. الغلاف الصالح، والإيصال المعروف، والادعاء المؤيد ثلاث بينات مختلفة.

يبقى التسليم خارج جسر الدفع. بالنسبة إلى السلع المادية يوصي RFC بحذف IOTP Delivery Exchanges. يمكن تحديد موضع للاستعلام، ويمكن التحقق من التفويض بين المعالجين خارج IOTP. وبالنسبة إلى السلع الرقمية يوصى بالتفويض الفوري. اكتمال رسائل الدفع لا يحرك طرداً ولا يثبت وصول المحتوى.

تحافظ الاستعلامات والأخطاء على الفصل ذاته. يُحذف SET Inquiry Initiation، وتوضع رسائل الاستعلام داخل بيانات IOTP. يستخدم الخطأ التقني للجسر HardError، بينما يسلك الفشل التجاري مساراً آخر. إذا ضاع المصدر بدا الرفض المنقول بصورة صحيحة عطلاً، أو بدا الجسر السليم بيعاً ناجحاً.

يمتلك المقال السابق عن RFC 3354 متطلبات IOTP v2 والفصل بين تركيب البروتوكول والتفويض التجاري. ويمتلك مقال RFC 3504 التصحيحات والهوية والاستعلام والفصل العام بين الدفع والتسوية والتسليم. أما مادة RFC 3538 الخاصة فهي لوحة محددة: خمس قيم، ومعنيان لـPRes، وفحص إيصال محدود، وإلغاء بعد «الاكتمال».

القاعدة الدائمة هي تسمية مقام كل تقدم. يجب حفظ الرسالة الدقيقة، ومن أنشأها أو عالجها، وcompletion code، وكل انتقال تالٍ. عندها تصبح 100 دليلاً مفيداً. ومن دون المصدر تكون رمزاً يستعير اليقين من أحداث لم يقسها قط.

المصادر