الخلاصة

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

مرّ الظرف المختوم عبر المتجر

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

ظهرت المسودة العامة الأولى في 8 يوليو 1995، ونُشر الوصف بوصفه RFC معلوماتيًا في فبراير 1996. تناول الإصدار 0.8 مدفوعات بطاقات الائتمان التي قال مؤلفوه إنها كانت تعمل بالفعل. أما النقد الإلكتروني فكان مشروعًا لاحقًا. فتح الإنترنت بابًا جديدًا إلى شبكة قبول البطاقات القائمة؛ لم ينقل وظيفة البنك إلى صفحة الدفع.

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

باب ثانٍ عند الاعتراض

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

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

المصادر