مقارنة بين ACP وUCP وAP2: بروتوكولات التجارة الوكيلية في أكتوبر 2026، وأيها يحتاجه متجرك

تصف ثلاثة بروتوكولات مفتوحة الآن كيف يشتري وكيل ذكاء اصطناعي من متجر. يأتي Agentic Commerce Protocol (ACP) من OpenAI وStripe. ويأتي Universal Commerce Protocol (UCP) من Google وShopify. أما Agent Payments Protocol (AP2)، الذي بدأته Google ثم سلّمته إلى تحالف FIDO في أبريل، فليس بروتوكولاً لإتمام الشراء أصلاً: إنه يعرّف إثباتاً موقَّعاً على أن المستخدم أذن بعملية دفع، وهو مصمَّم ليعمل داخل UCP. والبروتوكولات الثلاثة كلها مرخّصة بموجب Apache 2.0.

في 22 أكتوبر 2026 تتباين أوضاعها كثيراً. فبروتوكول ACP مصنَّف نسخةً تجريبية (beta)، وآخر إصدار له هو 2026-04-17، ولم يُضَف إليه أي تعديل منذ 17 يوليو. وChatGPT، أبرز من يستخدمه، ابتعد في مارس عن إتمام الشراء المستقل، وصار يستخدم ACP في الغالب لاستقبال بيانات المنتجات. ونشر UCP في أغسطس إصداراً غير متوافق مع سابقه، هو 2026-08-25، في حين لا تزال واجهات Google نفسها تعمل بالإصدار 2026-04-08، وإتمام الشراء لديها في مرحلة الوصول المبكر وفي الولايات المتحدة فقط. أما AP2 فقد بلغ الإصدار v0.2، ولا يوجد منتج من Google يوثّق استخدامه.

هذا المقال موجّه إلى مديري التقنية (CTO) وكبار المطوّرين في المتاجر ومنصات التجارة الإلكترونية الذين يقررون ما يجب تنفيذه. أما ما تطلبه كل منصة ذكاء اصطناعي من المتجر بوصفه نشاطاً تجارياً، فابدأ بقراءة نظرتنا العامة إلى التجارة الوكيلية (agentic commerce).

جنباً إلى جنب

ACP: بروتوكول Agentic Commerce Protocol

الحوكمة والإصدارات

يقول مستودع المواصفات إن OpenAI وStripe تتوليان صيانة ACP، ويصنّفه نسخةً تجريبية (beta). وتجعل وثيقة الحوكمة الخاصة به من الشركتين المشرفَين المؤسسَين (Founding Maintainers): فهما تعيّنان أعضاء اللجنة التوجيهية (حتى سبعة مقاعد) وتحتفظان بحق نقض يُستخدم «كملاذ أخير». وانضمت Meta في 24 أبريل 2026 بصفتها المشرف الرئيسي الثالث وعضواً في اللجنة. وتصف وثائق Stripe بروتوكول ACP بأنه «من إنشاء Stripe وOpenAI وMeta»، لكن ملف الإشعار (notice) في المستودع لا ينسبه إلا إلى OpenAI وStripe. أما نقله إلى مؤسسة محايدة فليس سوى مسار مستقبلي معلن.

هناك خمسة إصدارات مؤرخة: 2025-09-29 (إتمام الشراء والدفع المفوَّض)، و2025-12-12 (تغييرات غير متوافقة مع ما سبق استُخلصت من محوّلات URBN وEtsy)، و2026-01-16 (مزوّد 3DS يختاره التاجر)، و2026-01-30 (التفاوض على القدرات، والامتدادات، وإطار لمعالجات الدفع غير متوافق مع ما سبق)، و2026-04-17 (السلة، والخلاصة، والطلبات، والمصادقة المفوَّضة، والاكتشاف، وMCP)، الذي أعلن إيقاف 2026-01-30 (deprecated). ولم يصدر أي إصدار في الأشهر الستة التي تلته. ويضم المجلد unreleased/ تغييرات أصغر مؤرخة حتى 17 يوليو، مثل معرّف لتحديث الخلاصة ورابط منتج اختياري في عناصر إتمام الشراء.

ما الذي ينفّذه التاجر في الإصدار 2026-04-17

يستضيف التاجر واجهة API لإتمام الشراء، ويستدعيها الوكيل:

• POST /checkout_sessions ينشئ جلسة، وPOST /checkout_sessions/{checkout_session_id} يحدّثها (بطلب POST لا PUT)، وGET على المسار نفسه يسترجعها، و.../complete و.../cancel ينهيانها.
• تحمل الطلبات مفتاح API من نوع bearer وheader إلزامياً باسم API-Version. ومنذ 2026-04-17 صار Idempotency-Key إلزامياً في كل طلب POST، مع أخطاء محددة: 400 idempotency_key_required، و409 idempotency_in_flight، و422 idempotency_conflict.
• يحمل طلب الإنشاء كائن capabilities. يعلن الوكيل ما يدعمه، ويعيد البائع التقاطع بين الطرفين، فيظهر أي عدم توافق قبل الدفع.
• يرسل التاجر أحداث الطلبات بطلبات POST إلى مستقبِل تستضيفه OpenAI على /agentic_checkout/webhooks/order_events، موقَّعة بـ HMAC-SHA256 في header باسم Merchant-Signature. وتمتد الحالات من created إلى delivered أو canceled، ويحمل adjustments[] المبالغ المستردة والمرتجعات والنزاعات وعمليات رد المبالغ المدفوعة (chargebacks).

كما أضاف إصدار 2026-04-17 ملفاً ثابتاً وعاماً هو /.well-known/acp.json، يحدد الحقل transports فيه ما إذا كان المتجر يتحدث rest أو mcp أو كليهما. وأضاف ربطاً (binding) بـ MCP عبر Streamable HTTP بخمس أدوات (create_checkout_session، get_checkout_session، update_checkout_session، complete_checkout_session، cancel_checkout_session)، تتم المصادقة فيه ضمن إعدادات الخادم لا في كل طلب. وأضاف كذلك Feed API يستضيفه الوكيل ويرسل إليه التاجر (POST /feeds، PATCH /feeds/{id}/products)، وسلة لبائع واحد من دون بيانات دفع (POST /carts، PUT /carts/{id})، ومصادقة 3DS2 مفوَّضة (POST /delegate_authentication). ولا توجد اشتراكات: فوثيقة RFC الخاصة بالامتدادات تدرج subscription على أنه «دعم الفوترة المتكررة (مستقبلاً)».

كيف يعمل الدفع في ACP

جواب ACP الأصلي هو الدفع المفوَّض (delegated payment). ينفّذ مزوّد الدفع (PSP) أو خزنة البطاقات (card vault) الطلب POST /agentic_commerce/delegate_payment، الذي يحوّل البطاقة (نوع بيانات الاعتماد الوحيد) إلى رمز لا يجوز لمزوّد الدفع لدى التاجر استخدامه إلا ضمن حدود مسموح بها: reason (القيمة one_time فقط)، وmax_amount، وcurrency، وcheckout_session_id، وmerchant_id، وexpires_at. وبعبارة وثيقة RFC: «تبقى المدفوعات والتسوية والامتثال على قنوات الدفع الخاصة بالتاجر». وتوثّق Worldpay نسختها الخاصة من هذا الطلب، وتدعم PayPal بروتوكول ACP عبر رموز مفوَّضة في Braintree.

منذ 2026-01-30 تُعلَن طرق الدفع المقبولة في صورة معالجات (handlers) ضمن capabilities.payment.handlers. وهذا مثال بيانات الدفع الوارد في سجل التغييرات:

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

أما spt فهو Shared Payment Token من Stripe، المتاح «في الولايات المتحدة وكندا ودول أوروبية مختارة». ويحصّل البائع الذي يعمل مع Stripe قيمته عبر payment_method_data[shared_payment_granted_token] على إصدار معاينة من API؛ أما البائع الذي يعمل مع معالج دفع آخر فيمكنه تحويله مرة واحدة إلى بيانات اعتماد الشبكة. ويتناول مقالنا عن المدفوعات الوكيلية مسألة من يتحمل المخاطر.

ما الذي غيّرته خطوة OpenAI في مارس

في 24 مارس 2026 كتبت OpenAI: «لم تقدّم النسخة الأولى من Instant Checkout مستوى المرونة الذي نطمح إلى توفيره»، وأتاحت للتجار استخدام صفحات الدفع الخاصة بهم، وقالت إنها «توسّع ACP ليصبح طبقة الربط بين التجار والمستخدمين طوال مرحلة الاكتشاف». وكانت Target وSephora وNordstrom وLowe's وBest Buy وThe Home Depot وWayfair قد أتمّت تكامل ACP لأغراض الاكتشاف، وتصل كتالوجات Shopify عبر Shopify Catalog. وما يعنيه ذلك للمطوّر:

• الخلاصة هي الجزء الذي يعمل فعلياً. تقول صفحة التجار لدى OpenAI إن عمليات الشراء «تكتمل على مواقع أو تطبيقات يملكها التاجر»، وإن التسوق متاح لمستخدمي الولايات المتحدة. والانضمام عبر الخلاصة متاح للشركاء المعتمدين من قائمة انتظار: ملف كامل يومياً عبر SFTP يتضمن تسعة حقول إلزامية، وتحديثات عبر API خلال اليوم، والعروض الترويجية عبر API فقط. والرفع القياسي «يستهدف الولايات المتحدة حالياً».
• إتمام الشراء بوابة منفصلة. تقول مواصفات الخلاصة إن إتمام الشراء «يتطلب تكاملاً يُفعَّل بشكل منفصل». وبالنسبة إلى تطبيقات ChatGPT، فالمسار المتاح إتاحة عامة هو إتمام الشراء الخارجي على نطاق المطوّر نفسه. أما واجهة الدفع داخل المحادثة (payment sheet) فهي نسخة تجريبية خاصة (private beta) «مقتصرة على أسواق إلكترونية مختارة»، تسلّم رمز دفع إلى خادم MCP الخاص بالتطبيق في استدعاء للأداة complete_checkout.
• صفحات OpenAI متأخرة عن المواصفات. فلا يزال مرجع إتمام الشراء لديها يعرض API-Version بالقيمة 2025-09-12، وقائمة قيم provider (enum) تضم stripe وadyen وbraintree. ابنِ وفق المستودع، وتأكد من OpenAI أي إصدار تقبله.

صفحات مزوّدي الدفع التي لا تزال تعرض Instant Checkout على أنه متاح فعلياً صفحات قديمة.

UCP: بروتوكول Universal Commerce Protocol

الحوكمة والإصدارات

أطلقت Google بروتوكول UCP في 11 يناير 2026، بعد تطويره بالاشتراك مع Shopify وEtsy وWayfair وTarget وWalmart. وتمنح قواعد الحوكمة كلاً من Google وShopify صوتاً دائماً واحداً في المجلس الحاكم (Governing Council)، الذي انضمت إليه Stripe في 28 أبريل 2026، وتنص على أن «Google تملك التصويت بالوكالة عن جميع المقاعد الشاغرة حتى ديسمبر 2028». وفي 24 أبريل توسّع Shopping Tech Council إلى 16 مقعداً بانضمام Amazon وMeta وMicrosoft وSalesforce وStripe، فصارت Meta وStripe عضوين في لجنة ACP ومجلس UCP معاً.

ويضم المستودع أربعة إصدارات. أضاف 2026-04-08 قدرات السلة والكتالوج، وتوقيع الطلبات والاستجابات، وGet Order. أما 2026-08-25 فغير متوافق مع ما سبقه: حلّت JWK Set في keys[] محل signing_keys[]، وانتقلت امتدادات الدفع من dev.ucp.shopping.* إلى dev.ucp.common.payment.*، وانتقلت المخططات المشتركة (schemas) وتغيّرت عناوين $id الخاصة بها، وصار رقم البطاقة (PAN) ورموز الشبكة نوعين منفصلين من بيانات الاعتماد. كما أضاف 3DS2 غير مرتبط بمورّد بعينه، والمدفوعات المجزّأة (split payments)، وشروط الدفع، والتوافق مع Web Bot Auth.

وهنا يكمن الفخ: دليل ملف التعريف من Google لا يغطي إلا 2026-04-08 و2026-01-23، وملف تعريف الوكيل الخاص بـ Google على ucp.goog يعلن "version": "2026-04-08"، ويقدّم Salesforce B2C Commerce 26.9 الإصدارين نفسيهما. في المقابل، يشير Checkout MCP من Shopify إلى 2026-08-25. فإذا بنيت وفق أحدث إصدار، فأنت تبني إصداراً لا توثّقه Google. وجواب المواصفات هو كائن supported_versions يربط كل إصدار أقدم بعنوان URI لملف التعريف الخاص به.

الاكتشاف ووسائل النقل والمصادقة

ينشر كل تاجر ملف تعريف على /.well-known/ucp يتضمن ucp.version وucp.services وucp.payment_handlers، وتشترط Google أن يكون عاماً ومن دون مصادقة. وتنشر منصة الوكيل ملف تعريف خاصاً بها أيضاً، ويحمل كل طلب عنوان URI الخاص به في header باسم UCP-Agent، عبر HTTPS مع TLS 1.3 كحد أدنى. والمصادقة متروكة لاختيار التاجر: من دون مصادقة، أو X-API-Key، أو OAuth 2.0، أو mutual TLS، أو HTTP Message Signatures وفق RFC 9421. وترسل Google رمز bearer، وتعرض الأسئلة الشائعة لديها أيضاً mTLS. أما Idempotency-Key فليس إلا «SHOULD» (أي مستحسن)؛ والخادم الذي يقبله يحتفظ به 24 ساعة على الأقل ويردّ بالرمز 409 عند إعادة استخدامه مع محتوى مختلف.

يُعدّ REST وسيلة النقل الأساسية، إلى جانب MCP وامتداد A2A ووضع مضمَّن (embedded) يُوصَل إليه عبر continue_url. أما الطلبات (orders) فتتم عبر GET /orders/{id} إضافة إلى webhook من التاجر إلى المنصة موقَّع وفق RFC 9421. ومسارات السلة هي نفسها في ACP. أما عمليات إتمام الشراء فتبدو متشابهة لكنها غير قابلة للتبادل:

يمكن لنواة واحدة لإتمام الشراء أن تخدم البروتوكولين. أما جدول مسارات واحد فلا.

كيف يعمل الدفع في UCP

لا ينقل UCP الأموال. فمعالج الدفع (payment handler) مواصفات يكتبها مزوّد بيانات اعتماد، مثل com.google.pay لـ Google Pay أو dev.shopify.shop_pay لـ Shop Pay. يدرج التاجر المعالجات التي يقبلها، وتشغّل المنصة أحدها، وعند complete يتلقى التاجر رمزاً معتماً (opaque) يحصّل قيمته عبر مزوّد الدفع الخاص به.

على واجهات Google، المعالج الوحيد هو Google Pay، وPAN_ONLY هي طريقة المصادقة الوحيدة المستخدمة، ويجب أن يكون مزوّد الدفع لديك «قادراً على معالجة رموزنا». وتنشر Stripe المعالج com.stripe.payments للبطاقات وApple Pay: «يرسل الوكيل رمز دفع مشتركاً (SPT) في طلب Complete Checkout، ويحصّل البائع قيمته». ويبقى Google Pay على معالجه الخاص. وتتعامل PayPal مع معالج Google Pay عبر Braintree أو عبر واجهة Orders v2 API الخاصة بها.

ما الذي تشترطه Google قبل أن تستدعيك

يطلب دليل إتمام الشراء المدمج من Google واجهة API لإتمام الشراء عبر REST، ويُبقي خطوة الدفع لدى Google: يُدخل المتسوق البيانات الحساسة «فقط عبر واجهة Google». ومستويات الخدمة لديها: نسبة توفّر لا تقل عن 95% لكل نقطة نهاية (endpoint)، وزمن استجابة عند p50 وp95 يبلغ 1 و4 ثوانٍ للإنشاء، و1 و5 للتحديث، و6 و10 للإتمام. وبعد الطلب، ترسل تحديثات الحالة إلى webhook لدى Google باستخدام معرّف شريك ومفتاح يُصدَران عند الانضمام. وفي Merchant Center، يجب ضبط native_commerce(checkout_eligibility) على true لكل منتج (إذ إن «قيمتها الافتراضية FALSE»)، وسياسة الإرجاع وجهة اتصال الدعم إلزاميتان، وتُستثنى الاشتراكات والدفع بالتقسيط والسلع المخصصة حسب الطلب والمنتجات المستعملة والمجدَّدة والطلبات المسبقة والسلع المقيدة بالعمر.

الخيار الأخف، منذ 2026-04-08، هو نقل السلة (cart transfer): تنفّذ إنشاء السلة فقط، وتسلّم Google السلة إلى موقعك، ولا حاجة إلى معالج دفع ولا إلى webhook للطلبات.

الوصول هو القيد الحقيقي. فإتمام الشراء «متاح لتجار مختارين» عبر نموذج إبداء الاهتمام الخاص بالوصول المبكر، وفيه تتعهد بالبدء خلال 30 يوماً وتقبل بأن الوصول «قد يُسحب» إن لم تحرز تقدماً. وشروط UCP Checkout تنطبق «على الولايات المتحدة فقط». ومن المقرر أن يصل مركز Merchant Center (hub) إلى أستراليا وكندا «مطلع العام المقبل»؛ ولا تعطي Google موعداً لإتمام الشراء في أي دولة أخرى.

UCP خارج Google

يقبل Microsoft Merchant Center الخلاصات الجاهزة لـ UCP في الولايات المتحدة منذ 21 أبريل 2026. ويحتاج Copilot Checkout إلى خلاصة متوافقة مع UCP، ويقبل التجار الذين يعملون باللغة الإنجليزية ويبيعون لمشترين في الولايات المتحدة بالدولار، مع مزوّد دفع واحد لكل منهم، وإعداده في المتجر موسوم بعبارة «تجربة محدودة لعملاء مختارين فقط». وتتيح Shopify بروتوكول UCP عبر MCP على https://{shop}/api/ucp/mcp، وقد أزالت أدواتها الأقدم للكتالوج والسلة. ودُمجت قدرة لحجز أماكن الإقامة في صورة مسودة في 24 سبتمبر 2026، وهي غير موجودة في أي إصدار.

AP2: بروتوكول Agent Payments Protocol

ليس AP2 طريقة ثالثة لإتمام الشراء. تقول مواصفاته إنه «يعمل كميزة أمنية داخل بروتوكول تجارة» وإنه «مصمَّم صراحةً ليكون متوافقاً مع Universal Commerce Protocol (UCP)». صدر الإصدار 0.1.0 في 16 سبتمبر 2025، والإصدار v0.2 في 28 أبريل 2026، وهو اليوم الذي سلّمت فيه Google بروتوكول AP2 إلى تحالف FIDO. ويسمّي إعلان FIDO مجموعة عمل Agentic Authentication ومجموعة عمل Payments يرأسهما أعضاء من Mastercard وVisa، ويقول إن المساهمات «ستُراجَع ويُواصَل تطويرها». ولم ينشر FIDO أي مواصفات لـ AP2. ولم يعد مستودع GitHub يقبل إلا العينات وتغييرات SDK، وكان آخر تعديل فيه في 29 أبريل.

يعرّف الإصدار 0.2 Checkout Mandate (ما يُشترى) وPayment Mandate (الدفع، مع قيود مثل payment.amount_range وpayment.budget وpayment.allowed_payees). وكل منهما SD-JWT في صيغة مغلقة وصيغة مفتوحة (mandate.payment.1 وmandate.payment.open.1 مثلاً). في وضع Human Present (بحضور الإنسان) يوافق المستخدم على التفويضات المغلقة. وفي وضع Human Not Present (بغياب الإنسان) يوافق المستخدم على تفويضات مفتوحة تضع القيود، وتحمل المفتاح العام للوكيل في المطالبة cnf (claim)، ثم يجمّع الوكيل التفويضات المغلقة ضمن تلك الحدود. أما الدروس التعليمية التي تتحدث عن Intent Mandate وCart Mandate فتصف الإصدار v0.1؛ وقد اختفى هذان المصطلحان من v0.2.

داخل UCP، يأخذ AP2 شكل الامتداد dev.ucp.common.payment.ap2_mandate (وdev.ucp.shopping.ap2_mandate قبل 2026-08-25). وما إن يُتفاوض عليه حتى يوقّع التاجر استجاباته الخاصة بإتمام الشراء، وتقدّم المنصة checkout_mandate وpayment_mandate عند complete، وتصبح الجلسة «مقفلة أمنياً» (Security Locked): لا يجوز لأي من الطرفين العودة إلى إتمام شراء عادي.

لا أحد يطلبه بعد. تصف الأسئلة الشائعة من Google بروتوكول AP2 بأنه «مفيد بشكل خاص للسيناريوهات المستقبلية التي تتضمن معاملات مستقلة يُجريها وكلاء الذكاء الاصطناعي». ولا يدرج ملف تعريف الوكيل الخاص بـ Google إلا Google Pay معالجاً وحيداً للدفع، ولا يعلن أي قدرة لـ AP2، ولا يتضمن ملف تعريفه للإصدار 2026-08-25 أي مدخل لـ AP2 أيضاً. ولا يوجد منتج من Google يوثّق استخدام AP2، لذا لا يوجد ما يبنيه التاجر حتى تتفاوض عليه منصة ما.

البروتوكولات المجاورة

MCP

يمكن تشغيل ACP وUCP كليهما عبر MCP. ومواصفاتها الحالية، 2026-07-28، تحذف الجلسات وheader باسم Mcp-Session-Id، وتتخلى عن مصافحة initialize، وتشترط server/discover، وتلزم العميل بإعادة إصدار الطلب بمعرّف جديد عندما ينقطع تدفقه (stream). ولا يزال الربط الخاص بـ ACP يشير إلى وسيلة النقل في 2025-11-25. ومعرّف جلسة إتمام الشراء هو بالضبط المعرّف الذي يُصدره الخادم وتتوقعه المواصفات الجديدة، وطلب complete الذي يضيع في منتصف التدفق يعود في صورة طلب جديد: تعامَل مع مفاتيح منع التكرار على أنها إلزامية في البروتوكولين كليهما.

WebMCP

WebMCP معيار ويب مقترح لإتاحة وظائف الصفحة نفسها لوكلاء المتصفح. وتقدّم Shopify إتمام الشراء عبر UCP في صورة Checkout MCP وفي صورة Checkout WebMCP معاً، بكائن إتمام الشراء نفسه، وتوصي بـ Checkout MCP. ويتناول دليلنا عن WebMCP وضعه الحالي.

x402 وMPP

يفرض x402 وMachine Payments Protocol، الذي صممته Tempo وStripe، رسوماً على الوكيل لكل طلب HTTP مقابل API أو بيانات أو محتوى. وهما ليسا بروتوكولين لإتمام الشراء في المتاجر. راجع مقالنا عن x402.

Visa Trusted Agent Protocol وMastercard Agent Pay

لا يحلّ هذان البرنامجان محل ACP وUCP، بل يعملان إلى جانبهما. يمنح Trusted Agent Protocol من Visa الوكيل «طريقة تشفيرية موحّدة» لإثبات هويته وتفويضه أمام التجار، وMastercard Agent Pay برنامج ترميز (tokenisation) للتجارة الوكيلية. ويضع دليل التجار من Mastercard بروتوكولي UCP وACP في أعلى مستويات الجاهزية لديه، ويشير إلى أن «المتبنّين الأوائل يجرون التكامل حالياً»، وينصح التجار بالبدء بالمستويين الأبسط. ويتناول مقالنا عن المدفوعات الوكيلية البرنامجين كليهما.

Personal Agent Protocol

تقول Sierra إنها أعلنت Personal Agent Protocol («Poppy») مع Meta في 6 أكتوبر 2026، ونشرت مسودة في 9 أكتوبر. تنشر الشركة ملفاً واحداً على /.well-known/poppy.json؛ ويستخدم البروتوكول OAuth وJWT وHTTPS وOpenAPI وMCP ليتيح للوكيل الشخصي تعريف نفسه والحصول على إذن العميل لأي نوع من المهام، وتصفه Sierra بأنه مكمّل لـ UCP. ويعرض موقع البروتوكول الإصدار 0.2 ويقول: «إنها مسودة». ولم نجد أي منشور عنه في غرفة الأخبار الخاصة بـ Meta.

أيها تحتاج؟

على Shopify

لا شيء لتبنيه. واجهات المتاجر الوكيلية (agentic storefronts) في Shopify «مفعّلة افتراضياً للمتاجر المؤهلة». يتلقى ChatGPT كتالوجك عبر Shopify Catalog ويرسل المتسوقين إلى متجرك. وإتمام الشراء المباشر لدى Google مفعّل افتراضياً للمتاجر الموجودة في الولايات المتحدة والتي تبيع فيها، وقد سجّل Copilot تجار Shopify تلقائياً. وقراراتك هي بيانات المنتجات، وما إذا كنت ستُبقي إتمام الشراء المباشر مفعّلاً، مع العلم أن وحدات البكسل المخصصة (custom pixels) لا تعمل في إتمام الشراء لدى Google.

على Salesforce أو commercetools أو منصة أخرى

يقدّم Salesforce B2C Commerce 26.9 بروتوكول UCP بالإصدارين 2026-01-23 و2026-04-08: الملف /.well-known/ucp مع خريطة supported_versions، ونقاط نهاية جلسات إتمام الشراء خلف رمز SLAS. وتدرج Salesforce إتمام الشراء عبر UCP على Google بوصفه متاحاً إتاحة عامة في أكتوبر 2026. والجلسة عرض headless لسلة التسوق (basket)، ويحذّر دليل التدقيق من Salesforce من أن وحدات التحكم (controllers) في SFRA وSiteGenesis و«موارد SCAPI الأخرى التي تستخدمها اليوم لا تعمل في هذا المسار»، لذا يجب نسخ المنطق المرتبط بها إلى خطافات (hooks) جلسات إتمام الشراء في UCP أو ربطه بها. ويجب أن تستهدف الخلاصة en-US، وSalesforce «لا تتجاوز قائمة انتظار Google». وبالنسبة إلى ChatGPT، فإن Salesforce أحد مسارات التسليم التي تسمّيها OpenAI لخلاصات ACP.

وعلى commercetools أو منصة أخرى، اسأل المورّد عن إصدارات UCP وقدراته التي يقدّمها، وأي خطافاتك تعمل في إتمام شراء يُجريه وكيل، وما إذا كان يرسل الخلاصات إلى OpenAI.

على برمجياتك الخاصة

1. الخلاصات أولاً. خلاصة Google Merchant Center، وخلاصة المنتجات لدى OpenAI حين تقبلك. والاستخدام التجاري لـ ACP في ChatGPT اليوم هو هذا بالضبط.
2. UCP لـ Google، إذا كنت تبيع في الولايات المتحدة وقبلتك Google. ابنِ وفق 2026-04-08: ملف التعريف مع com.google.pay، وعمليات إتمام الشراء ضمن أهداف زمن الاستجابة لدى Google، ومزوّد دفع يعالج رموز Google Pay، وwebhook الطلبات، وسمة الخلاصة. أو ابدأ بنقل السلة وحده.
3. إتمام الشراء عبر ACP فقط إذا كان لديك سبب، مثل تطبيق ChatGPT قُبل في النسخة التجريبية لواجهة الدفع. ابنِ وفق الإصدار 2026-04-17 من المستودع.
4. AP2: لا شيء بعد.
5. نواة واحدة لإتمام الشراء. يريد البروتوكولان كلاهما جلسة يمكن إنشاؤها وتحديثها وإتمامها وإلغاؤها عبر API، وإعادة محاولتها بأمان. ابنها مرة واحدة فوق منطق الطلبات والضرائب والدفع لديك، مع محوّلات رقيقة لـ ACP وUCP فوقها، وMCP حيث يحتاجه الوكلاء.

لا يمنح أي من البروتوكولين النشاطَ القائم على الاشتراكات إتمام شراء مدمجاً عبر الوكلاء اليوم.

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

لا يمنحك أي من البروتوكولات الثلاثة إتمام شراء عبر الوكلاء اليوم. فالتسوق في ChatGPT والرفع القياسي لخلاصات OpenAI مقتصران على الولايات المتحدة؛ وشروط UCP Checkout من Google للولايات المتحدة فقط؛ وCopilot Checkout يخدم المشترين في الولايات المتحدة بالدولار. والخطوة التالية المعلنة من Google هي مركز Merchant Center في أستراليا وكندا «مطلع العام المقبل»، من دون موعد للمملكة المتحدة أو الاتحاد الأوروبي.

حافظ على اكتمال خلاصة Merchant Center، وإذا كنت ستعيد بناء إتمام الشراء على أي حال، فابنِ النواة القائمة على API الموصوفة أعلاه، ليصبح المحوّل مهمة صغيرة حين تنفتح سوقك. هل تبيع في السوق الأمريكية من الخارج؟ تحقق من المكان الذي يشترط كل برنامج أن يكون التاجر مقيماً فيه؛ فإتمام الشراء المباشر لدى Google عبر Shopify، على سبيل المثال، يتطلب متجراً في الولايات المتحدة.

أين تحصل على المساعدة

نبني طبقة البروتوكولات للمتاجر التي لا تعمل على Shopify: ملف تعريف /.well-known/ucp ونقاط نهاية جلسات إتمام الشراء فوق منطق الطلبات والضرائب والدفع الموجود لديك، وwebhooks الطلبات إلى Google، وخلاصات المنتجات لـ Google Merchant Center وOpenAI، وخوادم MCP تتيح إتمام الشراء نفسه للوكلاء. ويبدأ هذا العمل من خدمة تطوير وكلاء الذكاء الاصطناعي وتكامل خوادم MCP.

راسلنا على office@c9group.dev مع ذكر منصتك ومزوّد الدفع لديك والدول التي تبيع فيها، وسنخبرك بالبروتوكول الذي ينطبق عليك وما يتطلبه تنفيذه. وشروط برامج Google وOpenAI عقود: نحن مهندسون لا محامون، لذا اطلب من مستشار قانوني قراءتها قبل أن توقّع.