الدفع الوكيلي

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

ما هو الدفع الوكيلي؟

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

الكلمة المفتاحية هي الخطوة. الدفع الوكيلي ليس منتجاً أو شركة مستقلة، بل قدرة إتمام المعاملة داخل معياري التجارة الوكيلة ACP من OpenAI وStripe وUCP من Google وShopify. تشرح الصفحات الشقيقة البروتوكولين؛ أما هنا فالمحور هو آليات إتمام الدفع.

ثلاثة أمور يخطئ الناس في فهمها

• «يشتري الذكاء الاصطناعي بلا إنسان». ليس تماماً؛ فكلا البروتوكولين يوقف العملية ويطلب تدخلاً لتسجيل الدخول أو تحقق البطاقة أو التأكيد.
• «يرى الذكاء الاصطناعي بطاقتي». لا؛ تمر بيانات الدفع في رمز مقيّد بتاجر ومبلغ ومدة واستعمال واحد، ولا يصل رقم البطاقة الخام إلى الوكيل.
• «أصبح ذلك عادياً في معظم المتاجر». لا؛ في منتصف 2026 كان الانتشار مبكراً، ولم يتجاوز التجار الذين أطلقوا دفع ChatGPT نحو اثني عشر متجراً قبل التحول في مارس 2026.

من المسؤول إذا حدث خطأ؟

يبقى المتجر الذي اشتريت منه هو التاجر المسجل. فهو يتولى الطلب والاسترداد والنزاعات كما في الشراء المعتاد. الجزء غير المحسوم هو كيفية التعامل مع عملية متنازع عليها عندما يكون «المشتري» وكيلاً للذكاء الاصطناعي؛ وتفصيل ذلك في علامة التبويب المتقدمة.

هل تريد آلة الحالات الفعلية، ونطاق رموز الدفع، ونقاط تدخل الإنسان، والاختبارات المطلوبة قبل التفعيل؟ انتقل إلى علامة Advanced.

الخلاصة — الدفع الوكيلي قدرة لإتمام المعاملة: إنشاء جلسة الدفع وتحديثها وإكمالها أو إلغاؤها، وتفويض الدفع، ثم تأكيد الطلب. وهو لبنة في ACP وUCP وليس بروتوكولاً مستقلاً. تعمل الجلسة بآلة حالات: not_ready_for_payment → ready_for_payment → requires_escalation أو authentication_required → completed، وبمسار UCP الموازي incomplete → requires_escalation → ready_for_complete. حالات التصعيد هي نقطة تدخل الإنسان. تستخدم المدفوعات رموزاً مقيّدة بالتاجر والمبلغ والمدة والاستعمال الواحد، وتصل تأكيدات الطلب عبر Webhooks موقعة بـHMAC وكائن كامل. يبقى التاجر هو التاجر المسجل، لكن إطار أدلة رد المبالغ لشراء ينفذه وكيل ما زال غير محسوم. اختبر إعادة المحاولة الآمنة، وتحقق التوقيع، ومسارات التصعيد قبل التفعيل.

النطاق: هذه خطوة المعاملة وليست البروتوكول كله

الدفع الوكيلي قدرة واحدة. في ACP هو لبنة Agentic Checkout ضمن خمس لبنات مع Product Feed وDelegate Payment وDelegate Authentication وOrders/Webhooks. وفي UCP هو قدرة دفع داخل مواصفة تفاوضية أوسع. تغطي المقالات الشقيقة جودة الخلاصة وملف /.well-known/ucp وآثار تحول مارس 2026؛ أما هذه الصفحة فتركز على دورة الجلسة، وتفويض الدفع، والتدخل البشري، وتأكيد الطلب والمسؤولية.

تذكّر من مقال ACP أن الوكلاء يتعاملون مع الخلاصات وواجهات API لا مع HTML الذي تزحفه محركات البحث. لذلك يجري تحسين موثوقية الدفع لا نص الصفحة.

آلة حالات جلسة الدفع

أهم ما يميز الدفع الوكيلي أن عملية الدفع جلسة ذات حالة، وأن الحالة تتحرك عبر آلة محددة بدلاً من طلب شراء واحد غامض.

تسرد مرجعية ACP الحالات incomplete وnot_ready_for_payment وrequires_escalation وauthentication_required وready_for_payment وpending_approval وcomplete_in_progress وcompleted وcanceled وin_progress وexpired. المسار السعيد هو not_ready_for_payment → ready_for_payment → in_progress → completed، مع canceled كنهاية أخرى. يؤدي اختيار طريقة تنفيذ مطلوبة إلى نقل الجلسة من not_ready_for_payment إلى ready_for_payment؛ وقد تعيد الدفعة الفاشلة الجلسة إلى حالة الدفع لإعادة المحاولة.

الحالات المثيرة للاهتمام هي تلك التي لا تمثل المسار السعيد:

• requires_escalation / authentication_required — لا يستطيع الوكيل المتابعة وحده؛ يلزم إنسان أو تحقق إضافي.
• pending_approval — انتظار موافقة مثل اعتماد أمر شراء في B2B.
• expired — انتهت مهلة الجلسة، وتحمل CheckoutSession الحقل expires_at.

تستخدم UCP التصميم نفسه: incomplete → requires_escalation → ready_for_complete، وتسلم requires_escalation التحكم إلى الإنسان عبر continue_url. بروتوكولان مختلفان لكن النمط متقارب: لا يمكن لجلسة الدفع أن تنتهي دائماً دون سؤال الإنسان. هذه ليست رقعة لاحقة، بل شكل التصميم الأساسي.

عند بناء تكامل ACP، يعيد الطلب المشوه كائن خطأ على مستوى HTTP بنوع invalid_request أو request_not_idempotent أو processing_error أو service_unavailable. أما مشكلة منطق الأعمال داخل جلسة صالحة فتظهر ككائن MessageError في مصفوفة messages[]، لا كخطأ HTTP؛ لذا يجب معالجة المسارين معاً. مصطلح تقني: type

كيف يعمل تفويض الدفع؟

الغاية من طبقة تفويض الدفع أن بيانات البطاقة الخام لا تصل إلى الوكيل. تُحوَّل تفاصيل دفع المشتري إلى رمز مقيّد بدلاً من تسليم رقم البطاقة.

وفق مواصفة الدفع المفوض من OpenAI، يرسل التاجر أو خزينة الدفع الحمولة مباشرة إلى PSP، ويعيد PSP رمزاً خارج نطاق PCI ومقيداً بالدفعة المفوضة. ويُقيد الرمز على أربعة محاور.

• reason — قيمته الحالية "one_time" للاستعمال الواحد.
• max_amount — يحدد سقف المبلغ ولا يسمح بزيادة الخصم.
• expires_at (RFC 3339) — وقت انتهاء صارم.
• merchant_id + checkout_session_id — ربط بتاجر وجلسة واحدة.

إذن فالرمز المفوض مقيد بالتاجر، وسقفه محدد، ومدته محدودة، واستعماله واحد. هكذا ينفق الوكيل دون امتلاك اعتماد بطاقة قابل لإعادة الاستخدام. وتعرض Stripe Shared Payment Token كتطبيق متوافق أولي في ACP، بينما يفصل UCP بين أدوات الدفع ومعالجاتها.

نطاق PCI قرار معماري حقيقي. توضح مواصفة OpenAI أن التكامل المباشر يتعامل مع بيانات حامل البطاقة وقد يوسع نطاق PCI، وأنه يتطلب PCI DSS Level 1. المسار المرمّز عبر PSP أو رموز الشبكة يبقي بيانات البطاقة خارج بيئتك؛ وقرار «معالجة CHD مباشرة أم ترك PSP يرمّزها» هو أول قرار في البنية.

أين يجب أن يتدخل الإنسان؟

عبارة «المشتري ما زال يصرّح» صحيحة لكنها عامة. محفزات البروتوكول محددة، وتسميتها تساعدك على تصميم التسليم بدلاً من الوصول إلى نهاية صامتة.

• 3-D Secure / step-up. يستخدم ACP InterventionCapabilities مع 3ds وaddress_verification ومستويات always وconditional وoptional وسياقات native وwebview وmodal وredirect. وتعود نتيجة التحقق كـAuthenticationResult مثل authenticated وdenied وrejected وabandoned وcanceled وnot_supported.
• حالات requires_escalation / authentication_required تعني أن الإنسان أو الفحص الإضافي مطلوب.
• يحمل B2B في PaymentData حقول purchase_order_number وpayment_terms وdue_date وapproval_required.
• يعرض UCP تسليم continue_url لتسجيل الدخول أو التأكيد أو فحص العمر. مصطلح تقني: enforcement مصطلح تقني: display_context

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

تأكيد الطلب دفعٌ من التاجر لا سحبٌ من المنصة

بعد الشراء لا تظل منصة الوكيل تستطلع API التاجر لمعرفة حالة الطلب؛ التاجر يدفع Webhooks موقعة إلى المنصة.

ترسل المتاجر أحداث الطلب وفق مرجعية ACP كي تبقى المنصة متزامنة مع حقيقة التنفيذ. يحمل order_create الطلب الجديد ويحمل order_update تغير الحالة، ومن الحالات created وmanual_review وconfirmed وcanceled وshipped وfulfilled.

• التوقيع إلزامي عبر HMAC في ترويسة Merchant-Signature؛ والطلب غير الموقع يعيد 401.
• يجب أن يحمل حقل data كائن Order كاملاً لا فروقاً جزئية.
• عالج الرموز 200 للنجاح و401 للتوقيع غير الصالح و429 لتحديد المعدل.

إذن فالإجابة عن «كيف تعرف المنصة أن الطلب تم؟» هي: أخبرها عبر POST موقع يحمل الكائن الكامل، وتعامل مع ضغط المنصة الخلفي 429.

الاحتيال وعمليات ردّ المبالغ والمسؤولية: ما حُسم وما لم يُحسم

هذا القسم يوضح بصرامة الحد بين ما حُسم وما بقي مفتوحاً في مسؤولية الدفع الوكيلي.

المحسوم: التاجر المسجل. تنص مواصفة الدفع في OpenAI على أن OpenAI ليست التاجر المسجل؛ يجلب تاجر ACP مزود الدفع الخاص به، وتبقى التسوية والاسترداد ورد المبالغ والامتثال لدى التاجر وPSP. ويؤكد ذلك مصدر مستقل من Rye.

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

الأطر الناشئة لم تكتمل. يصف Visa Trusted Agent Protocol إطاراً للتحقق من هوية الوكيل ونيته، وتستخدم Mastercard Agent Pay رموز Agentic Tokens. أما توزيع مسؤولية الاحتيال المنسوب إلى تقارير الصناعة فمعلومة «مبلّغ عنها لا مؤكدة» حتى توثقها Mastercard؛ كما أن ضمان Visa للمستهلك لا يحل سؤال نزاع التاجر.

ما يجب على التجار تنفيذه واختباره

تقدم المقالات الأخرى التحضير الاستراتيجي؛ وهنا طبقة التشغيل: ما الذي تبنيه وتتحقق منه قبل التفعيل؟

• حدد وضع PCI. اختر مسار الرموز أو معالجة CHD مباشرة (Level 1)، وغالباً يفضل التاجر أن يحتفظ PSP بالتفويض.
• اجعل الإعادة آمنة بالتجزئة. استخدم request_not_idempotent ومفتاحاً ثابتاً حتى لا تنشئ إعادة المحاولة طلبين أو تخصم مرتين.
• تحقق من توقيع Webhook. افحص HMAC في Merchant-Signature وارفض عدم التطابق وأعد 200 أو 429 الصحيحين.
• حاكِ التصعيد في بيئة الاختبار. اختبر requires_escalation وauthentication_required و3DS وكل نتائج AuthenticationResult.
• طابق سعر الخلاصة والدفع. اختلاف السعر يهدم الثقة سريعاً.
• أنشئ إسناداً لطلبات الوكلاء. قد يصل الدفع بلا جلسة GA4؛ سجله عند مستوى الطلب أو OMS. مصطلح تقني: denied مصطلح تقني: rejected مصطلح تقني: abandoned مصطلح تقني: authenticated

تحول علامتا Testing SOP وCheat Sheet هذه المبادئ إلى جولة تنفيذية قابلة للتطبيق.

الوضع في منتصف 2026

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

هذا لا يعني أن الدفع الوكيلي وهم؛ فالقدرة البروتوكولية — إنشاء الجلسة وتحديثها وإكمالها برمز مفوض وWebhooks موقعة — حقيقية. لكن الجاهزية التجارية والانتشار والنتائج المتعلقة بالنزاعات ما زالت مبكرة، لذا يجب اختبار الواقع لا الاكتفاء بالعرض التسويقي.

ملخص الذكاء الاصطناعي

خلاصة مركزة للنسخة المتقدمة:

• الدفع الوكيلي هو خطوة إتمام المعاملة في التجارة الوكيلة، لا بروتوكول مستقل.
• ACP وUCP يوقفان الجلسة عند الحاجة إلى إنسان عبر requires_escalation أو authentication_required.
• رمز الدفع مقيد بالتاجر والمبلغ والمدة والاستعمال الواحد، ولا يحمل الوكيل بطاقة خاماً.
• يؤكد التاجر الطلب عبر Webhooks كاملة وموقعة، ويبقى التاجر المسجل مسؤولاً عن التسوية والاسترداد ورد المبالغ.
• إطار أدلة النزاعات لشراء الوكيل ما زال مفتوحاً، كما أن الانتشار التجاري في منتصف 2026 محدود. مصطلح تقني: not_ready_for_payment مصطلح تقني: ready_for_payment مصطلح تقني: completed مصطلح تقني: canceled مصطلح تقني: expired مصطلح تقني: pending_approval مصطلح تقني: incomplete مصطلح تقني: ready_for_complete مصطلح تقني: approval_required مصطلح تقني: continue_url مصطلح تقني: merchant_id مصطلح تقني: checkout_session_id مصطلح تقني: max_amount مصطلح تقني: expires_at مصطلح تقني: reason: one_time مصطلح تقني: Merchant-Signature مصطلح تقني: order_create مصطلح تقني: order_update مصطلح تقني: 200 مصطلح تقني: 401 مصطلح تقني: 429 مصطلح تقني: request_not_idempotent

الوثائق الرسمية

هذه مراجع المصدر الأول لميكانيكا الدفع الوكيلي.

ACP — الدفع ودورة الحياة وWebhooks مصطلح تقني: CheckoutSession مصطلح تقني: MessageError مصطلح تقني: RiskSignals مصطلح تقني: AuthenticationResult مصطلح تقني: InterventionCapabilities مصطلح تقني: ready_for_payment مصطلح تقني: order_create مصطلح تقني: order_update مصطلح تقني: Merchant-Signature المصدر المصدر المصدر المصدر

OpenAI وStripe — تفويض الدفع مصطلح تقني: max_amount مصطلح تقني: expires_at مصطلح تقني: merchant_id مصطلح تقني: checkout_session_id مصطلح تقني: reason المصدر المصدر المصدر المصدر

UCP — آلة دفع موازية المصدر

المنصة وشبكات الدفع المصدر المصدر

اقتباسات من المصدر

تصريحات موثقة تشرح عمل الدفع الوكيلي والأسئلة المفتوحة؛ تقود الروابط إلى موضع الاقتباس عندما يدعم المصدر ذلك.

ACP / OpenAI — المواصفة

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (ترجمة) «يحافظ التاجر على التحكم الكامل في المخزون والأسعار وحساب الضرائب ومعالجة الدفع.» — مرجع ACP. الانتقال إلى الاقتباس
• تعداد الحالات حرفياً: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (ترجمة) «تسرد مرجعية ACP حالات الجلسة المذكورة.» — مرجع ACP. الانتقال إلى الاقتباس
• “OpenAI is not the merchant of record.” (ترجمة) «ليست OpenAI التاجر المسجل.» وتبقى التسوية والاسترداد ورد المبالغ والامتثال لدى التاجر وPSP. الانتقال إلى الاقتباس
• حول الرمز: يعيد PSP أو الخزينة “payment token scoped to the delegated payment” (ترجمة) «رمز دفع مقيد بالدفعة المفوضة» خارج نطاق PCI. الانتقال إلى الاقتباس

أصوات الصناعة — سؤال المسؤولية

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (ترجمة) «تجلب التجارة الوكيلة الكفاءة، لكنها تضيف طبقة جديدة من الاحتيال والالتباس لا تستطيع الأنظمة القديمة تفسيرها.» — Ben Herut من Chargeflow. قراءة التغطية
• حول حسم القواعد: “there are no clean answers yet” (ترجمة) «لا توجد إجابات واضحة بعد»؛ فما زالت الشبكات والمصدّرون والمنصات تدرس الأسئلة. قراءة التغطية
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (ترجمة) «يبقي البروتوكولان التاجر تاجراً مسجلاً مسؤولاً عن التنفيذ ورد المبالغ والنزاعات.» — Arjun Bhargava من Rye. قراءة التغطية

شبكات الدفع — أطر ناشئة

• حول Visa: يصف Trusted Agent Protocol بأنه “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (ترجمة) «إطار قائم على المعايير يمكّن التجار من التحقق من هوية الوكيل ونيته آنياً ومنع الانتحال دون إضعاف تجربة المستخدم.» الانتقال إلى الاقتباس

واقع الانتشار

• عن سبب بطء الدفع الذاتي الكامل مقارنة بالضجة: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (ترجمة) «تطبيع كتالوج لحظي لعشرات الملايين من رموز SKU مشكلة تمتد عقداً، بينما يفضل المستهلكون تدفقات دفع يثقون بها مثل Apple Pay وGoogle Wallet وAmazon بنقرة واحدة.» — Leigh McKenzie عبر Search Engine Land. قراءة التغطية

أي مسار لتكامل الدفع تختار؟

أول قرار معماري هو كيفية تفويض الدفع، لأنه يحدد نطاق PCI وحجم البناء المطلوب. استخدم شجرة القرار التالية.

جولة اختبار ما قبل الإطلاق للدفع الوكيلي

نفذ هذه الخطوات في بيئة sandbox أو الاختبار قبل تفعيل الدفع الوكيلي في الإنتاج؛ فهي طبقة التشغيل التي لا تغطيها النصائح الاستراتيجية عن الخلاصات.

1. أنشئ جلسة دفع واختبر المسار السعيد. نفذ POST /checkout_sessions وتحقق من 201 وحالة not_ready_for_payment أو incomplete، ثم أضف خيار التنفيذ وأكمل الدفع.
2. اختبر إعادة المحاولة. أعد الطلب نفسه بمفتاح Idempotency وتأكد من جلسة وطلب واحد.
3. اختبر التصعيد. شغّل تسجيل الدخول و3DS والموافقة وتحقق من كل نتائج المصادقة.
4. اختبر Webhooks. أرسل أحداثاً موقعة بكائن كامل وجرّب 401 و429.
5. طابق البيانات. تحقق من أن السعر والمخزون والهوية في الخلاصة يساوي ما تعيده جلسة الدفع. مصطلح تقني: ready_for_payment مصطلح تقني: totals[] مصطلح تقني: POST /checkout_sessions/{id}/complete مصطلح تقني: completed مصطلح تقني: POST /checkout_sessions/{id}/cancel مصطلح تقني: requires_escalation مصطلح تقني: authentication_required مصطلح تقني: AuthenticationResult مصطلح تقني: denied مصطلح تقني: rejected مصطلح تقني: abandoned مصطلح تقني: canceled مصطلح تقني: not_supported مصطلح تقني: authenticated مصطلح تقني: request_not_idempotent مصطلح تقني: MessageError مصطلح تقني: messages[] مصطلح تقني: order_create مصطلح تقني: Merchant-Signature مصطلح تقني: 200

أخطاء شائعة وما ينبغي فعله بدلاً منها

افتراض أن الدفع الوكيلي شراء ذاتي بلا إنسان. الخطأ أن المواصفات تحتفظ بتصعيد وتفويض بشري؛ صمّم المسار بدلاً من إخفائه. مصطلح تقني: requires_escalation مصطلح تقني: authentication_required مصطلح تقني: approval_required مصطلح تقني: continue_url

اعتباره عادياً لأن العناوين مرتفعة. الواقع أن الانتشار محدود وأن تحول مارس 2026 غيّر شكل Instant Checkout؛ تحقق من التوفر الحالي.

اعتقاد أن مسؤولية الاحتيال حُسمت لأن التاجر المسجل معروف. حُسمت جهة التسوية، لا طريقة كسب نزاع نفذه وكيل.

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

الاعتقاد أن الوكيل يتعامل مع رقم البطاقة. التصميم يستخدم رموزاً مفوضة ومحدودة، فلا تسلّم بيانات البطاقة الخام.

إعادة محاولة غير آمنة بالتجزئة. الشبكات والوكلاء يعيدون الطلب؛ استخدم request_not_idempotent ومفتاحاً ثابتاً حتى لا يتكرر الخصم أو الطلب.

ورقة غش للدفع الوكيلي

تعداد حالات جلسة ACP

آلة UCP الموازية: incomplete → requires_escalation (إنسان عبر continue_url) → ready_for_complete.

نقاط نهاية الدفع (ACP) مصطلح تقني: POST /checkout_sessions مصطلح تقني: 201 مصطلح تقني: GET /checkout_sessions/{id} مصطلح تقني: POST /checkout_sessions/{id} مصطلح تقني: POST /checkout_sessions/{id}/complete مصطلح تقني: POST /checkout_sessions/{id}/cancel

رمز الدفع المقيّد — الحدود الأربعة مصطلح تقني: merchant_id مصطلح تقني: checkout_session_id مصطلح تقني: max_amount مصطلح تقني: expires_at مصطلح تقني: reason: "one_time"

Webhooks الطلب (ACP) مصطلح تقني: order_create مصطلح تقني: order_update مصطلح تقني: Merchant-Signature مصطلح تقني: 200 مصطلح تقني: 401 مصطلح تقني: 429 مصطلح تقني: created مصطلح تقني: manual_review مصطلح تقني: confirmed مصطلح تقني: canceled مصطلح تقني: shipped مصطلح تقني: fulfilled

محفزات تدخل الإنسان مصطلح تقني: requires_escalation مصطلح تقني: authentication_required مصطلح تقني: InterventionCapabilities مصطلح تقني: 3ds مصطلح تقني: address_verification مصطلح تقني: always مصطلح تقني: conditional مصطلح تقني: optional مصطلح تقني: AuthenticationResult مصطلح تقني: authenticated مصطلح تقني: denied مصطلح تقني: rejected مصطلح تقني: abandoned مصطلح تقني: approval_required مصطلح تقني: continue_url

المسؤولية باختصار

مقاطع للعمل مع الدفع الوكيلي

هذه المقاطع لفحص تكاملك واختباره، لا لقيادة عمليات شراء حية؛ استخدم بيانات اعتماد sandbox أو الاختبار.

التحقق من توقيع Webhook (Node.js وHMAC)

ارفض أي طلب لا يطابق توقيع Merchant-Signature، وقارن القيم في زمن ثابت.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

استطلاع حالة جلسة الدفع (shell)

راقب جلسة اختبار وهي تمر بآلة الحالات أثناء الاختبار.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

إرسال طلب إنشاء بمفتاح Idempotency (Python)

أثبت أن إعادة المحاولة بالمفتاح نفسه تنتج طلباً واحداً لا طلبين.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

مقطع Console لفحص ملف UCP في .well-known

فحص سريع في DevTools لمعرفة ما إذا كان التاجر يعرض اكتشاف UCP؛ الصقه في Console على أصل التاجر.

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet للانتقال إلى تعداد حالات ACP

ضع هذا السطر في إشارة مرجعية لفتح مرجع Checkout عند قائمة الحالات.

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

أعطال الدفع الوكيلي الشائعة

إعادة المحاولة تنشئ طلبين أو تخصمين

العَرَض: تنتج جلسة واحدة طلبين بعد مهلة أو إعادة شبكة. السبب المرجح: استدعاءات الإنشاء أو الإكمال غير مميزة بمفتاح آمن للإعادة. الإصلاح: أرسل مفتاح Idempotency، وأعد النتيجة الأصلية للمفتاح نفسه، وتحقق من أن استدعاءين في sandbox ينشئان جلسة وطلباً واحداً.

لا تصبح الجلسة جاهزة للدفع

العَرَض: تبقى الجلسة في not_ready_for_payment أو incomplete. السبب المرجح: خيار تنفيذ أو عنوان أو قاعدة عمل مطلوبة لم تُحل. الإصلاح: افحص الحقول المطلوبة وmessages[]، ثم أكد الانتقال إلى ready_for_payment أو ready_for_complete.

ينجح الطلب الصالح ظاهرياً لكن لا تكتمل السلة

العَرَض: ينجح طلب HTTP بينما تحمل الجلسة خطأ مخزون أو منطق أعمال. السبب المرجح: العميل يعالج أخطاء HTTP فقط ويتجاهل MessageError. الإصلاح: عالج أخطاء النقل ورسائل الجلسة معاً وأظهر الفشل القابل للتنفيذ للمستخدم أو الوكيل.

ينتهي التحقق البشري إلى طريق مسدود

العَرَض: تدخل الجلسة requires_escalation أو authentication_required ولا تعود. السبب المرجح: عومل تسليم 3DS أو تسجيل الدخول أو الموافقة أو continue_url كخطأ استثنائي. الإصلاح: احفظ الجلسة عبر التسليم، وعالج كل نتائج المصادقة، واختبر التدفق الناجح والمتروك.

يتوقف تحديث حالة الطلب بعد الدفع

العَرَض: يملك التاجر الطلب لكن سطح الوكيل عالق أو قديم. السبب المرجح: فشل توقيع Webhook أو إرسال فرق جزئي أو إسقاط 429. الإصلاح: وقّع الحمولة الدقيقة، وأرسل Order كاملاً، وأعد المحاولات مع backoff، وتحقق من قبول المستقبل للحدث.

نماذج ذهنية للدفع الوكيلي

الدفع آلة حالات لا استدعاء API واحد

يجب أن تنقل كل استجابة الجلسة إلى حالة معروفة أو تكشف سبباً معروفاً يمنع الانتقال. صمّم العميل حول الانتقالات والحالات النهائية وإعادة المحاولة والتصعيد لا حول طلب «شراء» واحد.

تبقى السلطة لدى التاجر

يعبر الوكيل عن النية، لكن التاجر هو المرجع للسعر والمخزون والضريبة والتنفيذ وحالة الطلب والتزام التاجر المسجل. اعتبر سلة الوكيل مدخلاً وسلة التاجر المعادة حقيقة.

التفويض يضيّق الصلاحية

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

التصعيد فرع ناجح

تدخل الإنسان ليس فشل الدفع الذاتي؛ فتسليم 3DS أو تسجيل الدخول أو العنوان أو موافقة B2B النظيفة هو عمل البروتوكول كما صُمّم.

التسليم غير متزامن بعد الإكمال

لا ينتهي التكامل عند إتمام الدفع. تنقل Webhooks الموقعة والكاملة حقيقة الطلب بعد الدفع، لذلك فحص التوقيع وأمان إعادة التشغيل ومعالجة إعادة المحاولة جزء من الموثوقية.

مقاييس الدفع الوكيلي

إتمام الدفع حسب الحالة النهائية

• المقياس: الجلسات المكتملة أو الملغاة أو المنتهية كنسبة من الجلسات المبدوءة.
• ما يخبرك به: أين تنتهي آلة الحالات وكم نية تضيع قبل إنشاء الطلب.
• السحب: اجمع تغيرات الحالة من API التجارة أو منصة الطلب وقسمها حسب البروتوكول والسطح.
• الخط الأساس: أنشئ خطاً أساسياً لمنتجك؛ لا يوجد معدل عالمي صالح في مرحلة التبني الحالية.
• الدورية: مراقبة يومية ومراجعة اتجاه أسبوعية.

معدل التعافي بعد التصعيد

• المقياس: الجلسات التي عادت وأكملت بعد 3DS أو تسجيل الدخول أو العنوان أو الموافقة.
• ما يخبرك به: هل التسليم البشري مسار قابل للاستخدام أم نهاية مسدودة.
• السحب: اربط أحداث التصعيد بالانتقالات اللاحقة عبر معرّف الجلسة.
• الخط الأساس: قس كل نوع تدخل منفصلاً لاختلاف احتكاك المصادقة وموافقة B2B.
• الدورية: أسبوعياً وبعد أي تغيير في التدفق.

معدل الطلبات المكررة وفشل Webhooks

• المقياس: الطلبات المكررة من إعادة المحاولة بالمفتاح نفسه مع عمليات Webhook المرفوضة أو المستنفدة.
• ما يخبرك به: هل التجزئة والمزامنة غير المتزامنة آمنتان أثناء الفشل.
• السحب: قارن مفاتيح التجزئة ومعرّفات الطلب وتوقيعات الفشل و401 و429 وإعادات المحاولة وأحداث dead-letter في السجلات.
• الخط الأساس: يجب أن تكون الطلبات المكررة صفراً؛ أنشئ خطاً أساسياً لإعادات المحاولة العابرة وابحث عن الانحراف المستمر.
• الدورية: تنبيه فوري وملخص أسبوعي.

موارد تستحق وقتك

كتاباتي ذات الصلة

• يغطي موقعنا ACP وUCP اللذين يقع الدفع الوكيلي داخلهما؛ هذه الصفحة هي الغوص في ميكانيكا الدفع تحت كليهما.
• دليل المبتدئين إلى SEO للتجارة الإلكترونية — موضع الدفع الموجه للوكلاء في الصورة الأوسع. المصدر المصدر

حديثي

• كيف يعمل البحث — جولة في الاكتشاف والفهرسة والترتيب وخلفية عن طبقة المعاملات التي يديرها الوكيل. رموز الحالة ذات الصلة: 100

من الصناعة

• مراجع ACP وOpenAI للدفع وWebhooks، وتحليل Chargeflow للنزاعات، وإطار Visa Trusted Agent Protocol، وتقارير تحول Instant Checkout؛ هذه روابط مرجعية لا ضمانات للتوفر. المصدر المصدر المصدر المصدر المصدر المصدر المصدر المصدر

إحصاءات جديرة بالاقتباس

تؤطر الأرقام التالية واقع الدفع الوكيلي؛ تعامل مع الأرقام المنقولة من التجار كاتجاهية وتحقق منها قبل الاعتماد عليها.

• نحو اثني عشر تاجراً من Shopify استخدموا أدوات الدفع بالذكاء الاصطناعي وفق تغطية تحول مارس 2026.
• نقلت OpenAI Instant Checkout من إتمام كامل داخل المحادثة إلى الاكتشاف ثم إعادة التوجيه.
• نطاق الرمز أربعة حدود: max_amount وexpires_at وmerchant_id/checkout_session_id وreason: one_time.
• تشترط ACP حمولة Order كاملة وموقعة بـHMAC في كل Webhook. مصطلح تقني: data المصدر المصدر المصدر

اختبر نفسك: الدفع الوكيلي

خمسة أسئلة سريعة عن ميكانيكا الدفع؛ اختر إجابة لكل سؤال ثم تحقق منها.

سجل التغييرات