نسخة Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# مدفوعات Anchor Browser وAgentCore: كيف يجتاز الوكيل حاجز x402 للدفع

> يمكن لـAnchor Browser إعادة محاولة صفحة أو استدعاء API مدفوع عبر x402 باستخدام AgentCore payments عندما يفعّل المطوّر الجلسة ويضبط وسيلة دفع مصرّحاً بها وذات ميزانية محددة.

By BIG CHANGE Editorial

Published: 2026-10-14T05:55:23.177Z
Updated: 2026-10-14T05:55:23.177Z
Canonical: https://bigchange.ai/blog/anchor-browser-agentcore-x402-payments

![A payment card and blank purchase order sit on a track beside an adjustable mechanical stop with an orange knob.](https://bigchange.ai/api/media/file/payment-authority-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. Delegating a purchase still requires a boundary around payment authority. The intact card, order and adjustable stop are a conceptual illustration, not a depiction of a specific product.

وثّقت AWS وAnchor Browser [عملية تكامل](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) تتيح لوكيل المتصفح دفع رسوم صفحة أو واجهة API محمية بـx402 ضمن جلسته الحالية. يستطيع المتصفح الرد على تحدي دفع HTTP 402، والحصول على إثبات دفع موقّع من Amazon Bedrock AgentCore payments، ثم إعادة الطلب. بالنسبة إلى المطوّر، يكمن التغيير المهم في موضع تنفيذ العمل: يتولى المتصفح التحدي وإعادة المحاولة، بينما تتحقق خدمة دفع مهيأة بشكل منفصل من صلاحية الإنفاق.

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

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

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

يشرح [دليل AWS وAnchor](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) التدفق الخاص بتحميل مستند، أو `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 مدعوماً، ويظل قرار قبول الإثبات وتسليم الاستجابة بيد التاجر.

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

مفتاح المتصفح صريح. في [طلب الجلسة الوارد في الدليل](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) تكون قيمة `session.x402` الافتراضية `false`؛ ويتيح ضبطها على `true` إجراء **مدفوعات حقيقية** من وسيلة الدفع المهيأة. كما يلزم مفتاح Anchor API لإنشاء جلسة المتصفح. ويمثل هذا الخيار الصلة الأخيرة بصلاحية الدفع، لا بديلاً عن إعداد تلك الصلاحية.

يشرح [دليل AWS لمدفوعات AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) الموارد الأساسية. يحدد Payment Manager إعداد الدفع لحساب AWS ويستخدم دور IAM ومخوّلاً. ويربط Payment Connector الخدمة بـCoinbase Developer Platform أو Stripe Privy. ويحفظ Payment Credential Provider بيانات اعتماد المزود عبر AgentCore Identity. وتحدد Payment Instrument المحفظة والشبكة المستخدمتين في الشراء. وترتبط جلسة المتصفح بـAgentCore Payment Session لها حد إنفاق ووقت انتهاء. كما يتطلب [دليل البدء السريع](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) من AWS تمويل وسيلة الدفع ومنح المستخدم الوكيل صلاحية توقيع مفوضة قبل أن يتمكن من الدفع.

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

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

سلوك الإخفاق الذي توثقه Anchor محدد: إذا كان تحدي 402 مشوهاً، أو لم تُعرض شبكة متوافقة، أو نفدت الميزانية، أو رفض AgentCore الدفع، يعيد المتصفح **استجابة 402 الأصلية** إلى الصفحة دون تغيير. لذلك ينبغي للأتمتة توقع احتمال ظهور 402 حتى مع تفعيل الجلسة. ويحدد [دليل استكشاف الأخطاء لدى AWS](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) أعطال إعداد أخرى، منها غياب إذن IAM، وعدم تفعيل تفويض التوقيع المفوض، وبطلان بيانات اعتماد المزود، وغياب اشتراك Marketplace في حالة Coinbase.

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

بالنسبة إلى المطوّرين، يأتي القرار العملي قبل وصول الوكيل إلى عنوان URL مدفوع: ربط وسيلة دفع ممولة ومصرّح بها، وتحديد ميزانية لجلسة المتصفح، ثم تفعيل x402 فقط عند نية الشراء. يستطيع المتصفح إزالة شيفرة بروتوكول الدفع من مسار التنقل. لكنه لا يزيل مسؤولية المشغّل عن صلاحية الإنفاق والطلبات الفاشلة والتحقق مما حصّله التاجر فعلياً. ويظهر سؤال الصلاحية أيضاً في [تحليلنا الأوسع لخيارات دفع وكلاء الذكاء الاصطناعي](https://bigchange.ai/blog/ai-agent-payments-stablecoins-bank-deposits).

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

- [AWS وAnchor Browser، “Building agents that transact with Anchor Browser and AgentCore payments”](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) (13 أكتوبر 2026). يوثق دليل التكامل تفعيل المتصفح اختيارياً، وتحدي x402، وترويسات الدفع الخاصة بكل إصدار، وسلوك إعادة 402 الأصلية عند الإخفاق. إنه يصف التدفق المقصود؛ ولم نختبر جلسة مدفوعة.
- [AWS، “How AgentCore payments works”](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) (دليل المطوّرين، اطّلعنا عليه في 14 أكتوبر 2026). يشرح Payment Manager وموصلات المزودين وبيانات اعتماد الهوية ووسائل الدفع وجلسات الإنفاق والمراقبة. وهو تصميم عام للخدمة إلى جانب دليل المتصفح المحدد.
- [AWS، “AgentCore payments quick start”](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) (دليل المطوّرين، اطّلعنا عليه في 14 أكتوبر 2026). يقدم خطوات إعداد بيانات اعتماد المزود ووسيلة دفع ممولة ومصرّح بها وجلسة دفع. الميزانيات والمدد المذكورة أمثلة توضيحية وليست قيماً افتراضية مؤكدة لـAnchor.
- [AWS، “Troubleshooting AgentCore payments”](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) (دليل المطوّرين، اطّلعنا عليه في 14 أكتوبر 2026). يسرد أخطاء IAM والمزود وتفويض المحفظة والاشتراك وبيانات x402 التي قد تمنع الدفع. لم نكرر هذه الأخطاء.

## Sources

- [AWS Machine Learning Blog، Building agents that transact with Anchor Browser and AgentCore payments](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) — دليل التكامل الرئيسي. يوثق القيمة الافتراضية لـsession.x402 وتفعيل المدفوعات الحقيقية وتسلسل المتصفح وAgentCore وإعادة المحاولة مرة واحدة وإرجاع 402 الأصلية دون تغيير عند الإخفاقات المذكورة. هذا سلوك يصفه المورد؛ ولم تشغّل BIG CHANGE جلسة مدفوعة. ولم تتم مطابقة ادعائه المنفصل عن دمج أرصدة Anchor وفوترتها بصورة مستقلة مع وثائق تمويل محفظة AgentCore، لذا لا نكرره كنموذج فوترة عام.
- [AWS، How AgentCore payments works](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) — مرجع محدث لبنية الخدمة وضوابطها. يعرّف Payment Manager والموصل ومزود بيانات اعتماد الهوية ووسيلة الدفع وحدود الجلسة وانتهائها وتفويض محفظة المستخدم وتدفق الدفع والمراقبة. يستخدم تدفق x402 العام X-PAYMENT؛ بينما يميز دليل Anchor المحدد ترويسة PAYMENT-SIGNATURE في x402 v2.
- [AWS، AgentCore payments quick start](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) — مسار الإعداد والمتطلبات المسبقة، ومنها الربط بـCoinbase أو Stripe Privy وتمويل وسيلة الدفع وتفويض التوقيع المفوض وجلسة دفع محددة المدة. المبالغ والمدد المثالّية ليست قيماً افتراضية أو حدوداً لـAnchor.
- [AWS، Troubleshooting AgentCore payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) — يوثق مشكلات الأذونات والاشتراك وتفويض المحفظة وبيانات الاعتماد وبيانات x402. وتكمل أخطاء الخدمة سلوك إعادة 402 الأصلية المذكور في دليل Anchor Browser؛ ولم يُختبر هنا أي مسار إخفاق.