وثّقت AWS وAnchor Browser عملية تكامل تتيح لوكيل المتصفح دفع رسوم صفحة أو واجهة API محمية بـx402 ضمن جلسته الحالية. يستطيع المتصفح الرد على تحدي دفع HTTP 402، والحصول على إثبات دفع موقّع من Amazon Bedrock AgentCore payments، ثم إعادة الطلب. بالنسبة إلى المطوّر، يكمن التغيير المهم في موضع تنفيذ العمل: يتولى المتصفح التحدي وإعادة المحاولة، بينما تتحقق خدمة دفع مهيأة بشكل منفصل من صلاحية الإنفاق.

التغيير الأبرز

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

ما الذي يفعله المتصفح في صفحة مدفوعة

يشرح دليل AWS وAnchor التدفق الخاص بتحميل مستند، أو fetch أو XMLHttpRequest داخل جلسة Anchor Browser. يعيد التاجر HTTP 402 Payment Required متضمناً تحدي دفع. يقرأ Anchor الشروط ويبحث عن طريقة متوافقة مع وسيلة الدفع المرتبطة بالجلسة. ويتحقق AgentCore من الميزانية المتبقية للجلسة ويستخدم مزود المحفظة المهيأ لتوقيع إثبات. يضيف المتصفح هذا الإثبات إلى الطلب الأصلي ويعيد المحاولة مرة واحدة، مستخدماً PAYMENT-SIGNATURE في x402 v2 أو X-PAYMENT في v1. ويتحقق التاجر من الدفع ويسويه قبل إعادة المورد.

هذا تسلسل موثق، وليس اختباراً أجرته BIG CHANGE لنقطة نهاية مدفوعة. وتقول AWS إن المتصفح يحتفظ بسياق الجلسة أثناء الدفع وإعادة المحاولة. ويمكن لسير العمل الحالي باستخدام Playwright وPuppeteer وChrome DevTools Protocol مواصلة التنقل أو استدعاء واجهات API عبر المتصفح من دون إنشاء ترويسات الدفع يدوياً. ولا يعني نجاح الدفع أن كل حاجز مدفوع أصبح مقروءاً: يجب أن يعرض الموقع تحدي x402 مدعوماً، ويظل قرار قبول الإثبات وتسليم الاستجابة بيد التاجر.

ما الذي يتعين على المطوّر تفعيله

مفتاح المتصفح صريح. في طلب الجلسة الوارد في الدليل تكون قيمة session.x402 الافتراضية false؛ ويتيح ضبطها على true إجراء مدفوعات حقيقية من وسيلة الدفع المهيأة. كما يلزم مفتاح Anchor API لإنشاء جلسة المتصفح. ويمثل هذا الخيار الصلة الأخيرة بصلاحية الدفع، لا بديلاً عن إعداد تلك الصلاحية.

يشرح دليل AWS لمدفوعات AgentCore الموارد الأساسية. يحدد Payment Manager إعداد الدفع لحساب AWS ويستخدم دور IAM ومخوّلاً. ويربط Payment Connector الخدمة بـCoinbase Developer Platform أو Stripe Privy. ويحفظ Payment Credential Provider بيانات اعتماد المزود عبر AgentCore Identity. وتحدد Payment Instrument المحفظة والشبكة المستخدمتين في الشراء. وترتبط جلسة المتصفح بـAgentCore Payment Session لها حد إنفاق ووقت انتهاء. كما يتطلب دليل البدء السريع من AWS تمويل وسيلة الدفع ومنح المستخدم الوكيل صلاحية توقيع مفوضة قبل أن يتمكن من الدفع.

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

أين يتوقف التدفق الآلي

سلوك الإخفاق الذي توثقه Anchor محدد: إذا كان تحدي 402 مشوهاً، أو لم تُعرض شبكة متوافقة، أو نفدت الميزانية، أو رفض AgentCore الدفع، يعيد المتصفح استجابة 402 الأصلية إلى الصفحة دون تغيير. لذلك ينبغي للأتمتة توقع احتمال ظهور 402 حتى مع تفعيل الجلسة. ويحدد دليل استكشاف الأخطاء لدى AWS أعطال إعداد أخرى، منها غياب إذن IAM، وعدم تفعيل تفويض التوقيع المفوض، وبطلان بيانات اعتماد المزود، وغياب اشتراك Marketplace في حالة Coinbase.

ينطبق المفتاح session.x402 على مدفوعات موارد الجهات الخارجية. وتقول AWS إنه لا يدفع رسوم جلسة Anchor Browser ولا يحل محل أرصدة Anchor. ويذكر الدليل حدود إنفاق الجلسة والوقت، لكنه يحيل التفاصيل المحددة إلى وثائق Anchor التقنية؛ ولم تكن هذه التفاصيل متاحة لهذا المقال. وتعتمد تكلفة طلب معين إلى جهة خارجية على تحدي التاجر والتسوية الفعلية. لم نتحقق من فاتورة أو معاملة من البداية إلى النهاية، لذا لا يمكن للمقال تحديد سعر عام لجلسة مفعّلة.

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

المصادر وقراءات إضافية

  • AWS وAnchor Browser، “Building agents that transact with Anchor Browser and AgentCore payments” (13 أكتوبر 2026). يوثق دليل التكامل تفعيل المتصفح اختيارياً، وتحدي x402، وترويسات الدفع الخاصة بكل إصدار، وسلوك إعادة 402 الأصلية عند الإخفاق. إنه يصف التدفق المقصود؛ ولم نختبر جلسة مدفوعة.
  • AWS، “How AgentCore payments works” (دليل المطوّرين، اطّلعنا عليه في 14 أكتوبر 2026). يشرح Payment Manager وموصلات المزودين وبيانات اعتماد الهوية ووسائل الدفع وجلسات الإنفاق والمراقبة. وهو تصميم عام للخدمة إلى جانب دليل المتصفح المحدد.
  • AWS، “AgentCore payments quick start” (دليل المطوّرين، اطّلعنا عليه في 14 أكتوبر 2026). يقدم خطوات إعداد بيانات اعتماد المزود ووسيلة دفع ممولة ومصرّح بها وجلسة دفع. الميزانيات والمدد المذكورة أمثلة توضيحية وليست قيماً افتراضية مؤكدة لـAnchor.
  • AWS، “Troubleshooting AgentCore payments” (دليل المطوّرين، اطّلعنا عليه في 14 أكتوبر 2026). يسرد أخطاء IAM والمزود وتفويض المحفظة والاشتراك وبيانات x402 التي قد تمنع الدفع. لم نكرر هذه الأخطاء.