صفحة دفع جاهزة للوكلاء: المدفوعات والرموز والثقة حين يشتري الذكاء الاصطناعي نيابةً عن العميل

في الساعة 9:12 صباح يوم ثلاثاء يصل إلى صاحبة متجر صغير للإلكترونيات طلب من مساعد ذكاء اصطناعي يتسوق نيابةً عن عميل: شاحن حاسوب محمول واحد بـ 49 دولارًا، مدفوع برمز أصدره بنك العميل لهذا المتجر وحده، وصالح لمدة 30 دقيقة. لا رقم بطاقة ولا حساب ولا جلسة متصفح.

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

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

سألنا في الجزء الأول من هذه السلسلة: هل يستطيع وكيل ذكاء اصطناعي أن يجد متجرك ويفهمه؟ وسألنا في الثاني: هل سيوصي به المساعد؟ أما هذا الجزء فيجيب عن السؤال الذي يحسم من يقبض المال: حين يصبح الوكيل جاهزًا للشراء، هل يستطيع الدفع عندك أن يقول «نعم» بأمان؟ كل برنامج جادّ في 2026 يستبدل بالبطاقة بيانات اعتماد محدودة يمكن إلغاؤها، مع سجلّ موقّع بما أذن به المشتري. وستجد أدناه أين كان كل برنامج في مطلع سبتمبر 2026، وقائمة بما ينبغي إصلاحه في صفحة الدفع لديك الآن.

هذا هو الجزء 3 من 3 في سلسلة «البيع لوكلاء الذكاء الاصطناعي». الجزء الأول: التجارة الوكيلية: كيف تبيع حين يكون عميلك القادم وكيل ذكاء اصطناعي. الجزء الثاني: تحسين المتاجر الإلكترونية لمحركات الذكاء الاصطناعي التوليدي.

كيف يدفع الوكيل دون أن يرى البطاقة

حين تدفع عبر الإنترنت تكتب رقمًا من 16 خانة في نموذج. ولو فعل الوكيل الشيء نفسه لبقي هذا الرقم في أنظمة مزوّد النموذج وسجلاته وذاكرته. وجواب القطاع هو أن نعطي الوكيل بديلًا عن البطاقة.

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

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

أين كانت البرامج في سبتمبر 2026

تتداخل عدة برامج، وهي ليست متنافسة كما تتنافس المتصفحات. بعضها يحدد كيف يتحدث الوكيل مع المتجر، وبعضها كيف يُثبَت الإذن، وبعضها كيف يُعتمد الدفع. وهذا ما يظهر في السجل العلني حتى مطلع سبتمبر 2026:

البرنامج	ما يغطيه	الحالة، سبتمبر 2026
Agentic Commerce Protocol (من OpenAI وStripe)	كيف يبدأ الوكيل عملية الدفع ويسلّم التاجر رمز الدفع	معيار مفتوح صدر في سبتمبر 2025. أُفيد بإنهاء Instant Checkout داخل ChatGPT في مارس 2026، لكن البروتوكول مستمر، وآخر مراجعة للمواصفة في أبريل 2026
Stripe Shared Payment Tokens وAgentic Commerce Suite	رموز مقيّدة ببائع ومبلغ ومدة	أُطلقت في ديسمبر 2025؛ ويمكن لمزوّدي دفع آخرين المشاركة عبر مواصفة الدفع المفوَّض في البروتوكول
Agent Payments Protocol, AP2 (من Google)	تفويضات موقّعة تثبت ما أذن به المشتري	أُعلن في سبتمبر 2025؛ وسُلِّم إلى FIDO Alliance للتقييس في أبريل 2026
Universal Commerce Protocol وUniversal Cart (من Google)	معيار للكتالوج والدفع، مع سلة موحدة عبر البحث وGemini	أُعلن المعيار في يناير 2026؛ وأُعلنت السلة في مايو 2026 على أن تُطرح في الولايات المتحدة خلال الصيف. تحقّق من التوافر الحالي قبل أن تبني خطتك عليها
Visa Intelligent Commerce وTrusted Agent Protocol	رموز للوكلاء، وطلبات موقّعة تعرّف بالوكيل الموثوق	أُعلنا في أكتوبر 2025 مع شركاء من التجار والمعالِجين؛ وبيئة التجربة للمطورين مفتوحة
Mastercard Agent Pay	رموز وكيلية فوق ترميز البطاقات القائم	أُفيد بأولى المدفوعات الوكيلية الحية في آسيا والمحيط الهادئ منذ مارس 2026؛ وقُدِّم إطار Verifiable Intent التابع له إلى FIDO Alliance

أمران يهمّان أكثر من أي صف منفرد. الأول: البرنامج الوحيد الذي حاول وضع عملية الشراء كلها داخل نافذة محادثة تراجع، بينما واصلت البنية التحتية تحته التقدم. الثاني: دخلت جهات التقييس على الخط، ففي أبريل 2026 أعلنت FIDO Alliance تشكيل مجموعات عمل لمصادقة الوكلاء وللتجارة التي يبدؤها الوكلاء، انطلاقًا من مساهمتَي Google وMastercard. وهذا يعني عادةً أن المجال يتجه نحو التوحّد.

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

التفويض: السجل الموقّع بما أُذن به

الرمز يقول «يجوز التحصيل عبر بيانات الاعتماد هذه»، لكنه لا يقول لماذا. ويسدّ هذه الثغرة التفويض (mandate)، وهو سجل موقّع بإذن المشتري، ويقسمه AP2 إلى ثلاثة أجزاء:

• Intent mandate: ما طلبه المشتري وحدوده، مثل «حذاء جري بأقل من 120 دولارًا ويصل قبل الجمعة».
• Cart mandate: السلة بالضبط كما جهّزها الوكيل، بأسعارها، وموقّعة حتى لا يغيّر أحد سطرًا منها بعد ذلك.
• Payment mandate: التفويض المرسَل إلى شبكة الدفع، ويبيّن أن وكيلًا شارك في العملية.

تخيّله أمر شراء موقّعًا. يعتمد المشتري ميزانية، ويملأ الوكيل الطلب، وتربط التواقيع بينهما. وعندما يصل نزاع بعد أشهر، يكون وراء سؤال «هل وافق العميل فعلًا؟» مستند.

ما معنى ذلك لصفحة الدفع لديك

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

من يتحمل الخسارة عند الخطأ

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

الشبكات تعمل على ذلك. فهوية الوكيل الموقّعة والتفويضات موجودة ليميّز المُصدِر بين «مأذون به من حامل البطاقة عبر وكيل» و«احتيال». اعتبر ذلك اتجاهًا لا ضمانًا، واقرأ شروط مزوّد الدفع الخاصة بمعاملات الوكلاء قبل تفعيلها.

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

إشارات الاحتيال والنزاعات في عالم الوكلاء

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

حدّث قواعدك بأربع طرق:

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

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

رحّب بالوكلاء الجيدين وامنع البوتات السيئة

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

الأسلوب العملي هو الفرز. اسأل أولًا: هل يحمل الطلب هوية يمكن التحقق منها؟ كلٌّ من Trusted Agent Protocol من Visa ومقترح Web Bot Auth يستخدم توقيعات رسائل HTTP: يوقّع الوكيل كل طلب بمفتاح خاص، وتطابق أنت التوقيع مع مفتاح عام منشور. وأعلنت Cloudflare دعم هذا النهج مع Visa وMastercard في أكتوبر 2025.

ثلاثة مسارات

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

راجع أيضًا قواعد robots وإعدادات الحماية من البوتات. فقاعدة تحظر «كل ما ليس متصفحًا» عند الدفع ربما ترفض الآن وكلاء مشروعين.

التأكيدات والإيصالات والإرجاع

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

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

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

ما ينبغي إصلاحه في صفحة الدفع الآن

لا يتطلب شيء من هذا اعتماد كل البروتوكولات هذا الربع. المطلوب صفحة دفع نظيفة بما يكفي ليصبح اعتماد أحدها مشروعًا صغيرًا. امضِ في القائمة بالترتيب.

1. وفّر واجهة API نظيفة للطلبات. إنشاء السلة وتحديثها وتسعير الشحن والضريبة وإتمام الطلب وقراءة حالته، لكلٍّ منها نقطة اتصال ثابتة ورسائل خطأ مقروءة.
2. اجعل عروض الأسعار ملزمة. السعر والضريبة والشحن التي تعرضها تساوي ما تحصّله، وتنتهي صلاحيتها بعد مدة معلنة.
3. اسمح بالدفع كضيف. فرض إنشاء حساب يوقف وكيلًا يعمل لحساب مشترٍ لم يزر متجرك قط.
4. اختر مزوّد دفع يدعم المدفوعات المُرمَّزة والمفوَّضة. اسأله أي برامج الوكلاء يدعم وكيف يعالج نزاعاتها.
5. سجّل مصدر الطلب. صنّف الطلبات بحسب القناة، ومنها مصدر الوكيل، واحتفظ بمرجع الرمز أو التفويض.
6. انشر سياسات دقيقة. مدد التسليم ومدة الإرجاع وطريقة الاسترداد، مكتوبة كقواعد لا كشعارات.
7. افصل الحركة الجيدة عن السيئة. تحقّق من الوكلاء الموقّعين، وحدّد معدل البقية أو اطرح عليهم تحدّيًا بدل حظر الجميع.
8. أرسل تأكيدات وتحديثات حالة منظّمة. البيانات نفسها بنسخة للبشر وأخرى للآلات.
9. اختبر في بيئات التجربة. تقدّم Visa وStripe وغيرهما بيئات اختبار؛ شغّل شراءً كاملًا عبر وكيل، ثم استردادًا ونزاعًا، قبل أن يتحرك مال حقيقي.
10. حدّد موعدًا للمراجعة. تغيّر هذا المجال عدة مرات خلال اثني عشر شهرًا؛ راجع حالة البرامج كل ربع سنة.

أين تتركك هذه السلسلة

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

نعود إلى صاحبة المتجر في الساعة 9:12. بعد تطبيق الفحوص الثلاثة يسلك طلب الشاحن بـ 49 دولارًا مسارًا مختلفًا. يتحقق التوقيع، ويغطي التفويض (شاحن واحد بحد أقصى 60 دولارًا) السلة، ويعمل التفويض الصالح لصالح درجة الخطورة. يمر التحصيل عبر مزوّد الدفع لديها، ويصل التأكيد إلى مساعد العميل وبريده خلال ثوانٍ.

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

أهم النقاط

• يدفع الوكلاء برموز مقيّدة يمكن إلغاؤها لا بأرقام بطاقات، ويسجّل التفويض الموقّع ما أذن به المشتري.
• حتى سبتمبر 2026 يتجه المجال نحو معايير مشتركة عبر FIDO Alliance، بينما أُفيد بإنهاء Instant Checkout من OpenAI داخل المحادثة في مارس 2026 واستمر البروتوكول الأساسي.
• المسؤولية عن مشتريات الوكلاء لم تُحسم، فاحتفظ بأدلة قوية: السلة كما سُعِّرت، ومرجع الرمز أو التفويض، والسياسات، وإثبات التسليم.
• افرز الحركة الآلية بحسب الهوية الموثَّقة: مرّر الوكلاء الموثَّقين، وحدّد معدل جامعي البيانات، واحظر الاحتيال.
• عروض الأسعار الملزمة، والدفع كضيف، وواجهة طلبات نظيفة، وحالة منظّمة، كلها إصلاحات تنفع أيًّا كان البروتوكول المنتصر.
• أعد فحص حالة البرامج كل ربع سنة، واختبر في بيئات التجربة قبل الإطلاق.

Anichur Rahaman مهندس برمجيات معماري ومؤسس StoreConsole، يصمّم أنظمة التجارة وERP للشركات النامية، ويهتم خصوصًا بالبنية القائمة على الأحداث وسلامة البيانات وتشغيل الأنظمة على خوادم الشركة نفسها.