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

ما الذي تغيّر عندما فُتح الدفع أمام الوكلاء

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

أما التاجر، فيرى جلسة. يرى سلسلة وكيل المستخدم، وملف تعريف ارتباط، وبصمة جهاز، ورمز دفع. لا يرى موكّلًا. ويرى المستخدم نتيجة: تأكيد طلب، وخصمًا، وتقدير توصيل. لا يرى المستخدم العقد الذي أُبرم لإنتاج تلك النتيجة. والشروط التي قبلها الوكيل في منتصف المسار — شروط الخدمة الحالية للتاجر، وسياسة الإرجاع، وشرط التحكيم، وشروط تجديد الاشتراك — لا يراها أحد سوى نافذة سياق الوكيل، التي تُهمَل عند انتهاء التشغيل.

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

لماذا لا يكفي مفتاح الإعدادات

الاستجابة المؤسسية الشائعة هي مفتاح إعدادات: زر في منصة الوكيل يقول ما إذا كان يجوز للوكيل إجراء معاملات، ربما مع قائمة تجار مسموحين. هذا ليس نموذج موافقة. إنه علامة قدرة.

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

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

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

مخطط لسجل الموافقة

الآلية التي تعالج هذا هي سجل الموافقة: سجل إضافي فقط، قابل للاستعلام، لكل تفويض بسلطة الإنفاق، يُكتب لحظة ممارسة التفويض.

يجب أن يحمل كل قيد على الأقل الحقول التالية:

entry_id        unique, monotonic
principal       the human or organisation granting authority
agent_id        the software identity exercising it
merchant_id     the counterparty
scope           e.g. one-time purchase, subscription renewal, return
amount_ceiling  maximum total the agent may commit
currency        ISO code
expiry          timestamp after which the grant is void
terms_hash      digest of the terms presented at acceptance
terms_uri       location of the terms document
timestamp       when the entry was written
parent_entry    for revocations and amendments

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

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

يجب أن يكون السجل قابلًا للاستعلام من طرفين ذوي مصالح مختلفة. يحتاج المستخدم إلى رؤية، في عرض واحد، كل تفويض مارسه وكلاؤه، مع السقوف ومواعيد الانتهاء، وإلى إلغاء أي منها لا يزال ساريًا. ويحتاج مسار نزاع التاجر إلى استرجاع تجزئة الشروط والنطاق لمعاملة محددة، دون اكتساب رؤية إلى تفويضات المستخدم الأخرى. هذه مشكلة تفويض قراءة، لا مشكلة تخزين، وهي الجزء الأرجح أk-network-cables-f7a795-35eb46.jpg)

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

المقايضة الصادقة

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

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

التفاعل مع مخاطر التجارة

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

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

تحديث الشروط ليس الجواب. السجل هو الجواب.