الطبقة الأساسية للهوية في التجارة الذكية: مقارنة بين Visa TAP وGoogle AP2 وMastercard Agent Pay

النقاط الرئيسية

• تعمل بروتوكول Visa Trusted Agent Protocol (TAP) وGoogle Agent Payments Protocol (AP2) وMastercard Agent Pay جميعها على جعل عمليات الشراء التي تتم بواسطة الوكلاء أكثر أمانًا، ولكنها تحل أجزاء مختلفة من مشكلة الثقة.
• يساعد TAP التجار على التعرف على الوكلاء المعتمدين والتحقق من نية التجارة الموقعة. ينشئ AP2 دليلًا على ما وافق عليه المستخدم. يجمع Agent Pay بين الوكلاء المسجلين، وبيانات اعتماد الدفع الرمزية، والموافقة، ورؤية الشبكة.
• لا تلغي أي من هذه الآليات الحاجة إلى إثبات هوية الشخص أو العمل، وفحص المخاطر، وتطبيق ضوابط خاصة بالولاية القضائية، والحفاظ على مسار تدقيق.
• Didit هي بنية تحتية محايدة للهوية والاحتيال، وليست شبكة بطاقات أو شركة دفع. يوفر خادم بروتوكول سياق النموذج (MCP) المستضاف 115 أداة عبر 11 فئة، بينما تدعم واجهة برمجة تطبيقات REST (Representational State Transfer) تدفقات الإنتاج المضمنة.
• تبلغ تكلفة حزمة KYC الكاملة (معرفة عميلك) 0.33 دولار، ويتضمن كل حساب 500 عملية تحقق مجانية شهريًا، وخادم MCP نفسه مجاني.

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

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

ثلاثة معايير، ثلاث حدود للثقة

Visa TAP: هل يمكن للتاجر التعرف على هذا الوكيل والثقة به؟

بروتوكول Visa Trusted Agent Protocol موجه للتجار. وظيفته الأساسية هي مساعدة التاجر على التمييز بين وكيل تجاري معتمد وعن زاحف عادي، أو روبوت مسيء، أو أتمتة غير معروفة. يوقع الوكيل طلبًا ببيانات اعتماد محددة الغرض ومحددة المدة. يتحقق التاجر أو مزود الحماية الخاص به من التوقيع ويمكنه تحديد ما إذا كان سيسمح بالتصفح أو الدفع أو إجراء أضيق.

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

إشارة المستهلك هذه لا تعادل تلقائيًا إثبات هوية جديدًا. يتضمن نموذج Visa دور مزود الهوية في المراحل الأولية، ولكن التاجر لا يزال بحاجة إلى سياسة لعميل جديد أو عالي المخاطر: ما هو الدليل الذي تم فحصه، ومدى قوة التأكيد، وما إذا كانت KYC مطلوبة، ومتى يكون إعادة التحقق ضروريًا. يمكن لـ TAP حمل معلومات هوية موثوقة دون تحديد كل قرار إلحاق متعلق بالولاية القضائية.

Google AP2: ما الذي أذن به المستخدم للوكيل لشرائه؟

يركز بروتوكول Google Agent Payments Protocol على الترخيص والأدلة. يستخدم تفويضات موقعة لربط نية المستخدم ومحتويات الدفع والدفع. يمكن أن يمنح التفويض المفتوح الوكيل تقديرًا محدودًا، مثل قيود التاجر أو حدود الإنفاق. يربط التفويض المغلق الموافقة بسلة تسوق ومبلغ محددين. تكمل الإيصالات سلسلة الأدلة.

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

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

Mastercard Agent Pay: هل يمكن للشبكة التعرف على الدفع الوكيلي وحوكمته؟

تعتمد Mastercard Agent Pay على ترميز الدفع. يقوم إطار قبول Mastercard بتسجيل الوكلاء والتحقق منهم، وتعيين هوية وكيل فريدة، ويستخدم Agentic Tokens بحيث يمكن تتبع المعاملات وتظل بيانات اعتماد الدفع محمية. يمكن أن يعمل التعرف الموجه للتاجر مع البنية التحتية الحالية للدفع، بينما تدعم التكاملات الأعمق تبادل البيانات الأكثر ثراءً.

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

تتمتع Agent Pay بأقوى قدرة في أمان بيانات اعتماد الدفع، ورؤية الوكيل، وضوابط الشبكة. لا تلغي التزام التاجر بتحديد متى ينطبق التحقق من الهوية، ومعرفة عملك (KYB)، وفحص مكافحة غسل الأموال (AML)، وفحوصات العمر، أو المراجعة المعززة. تعتمد هذه القرارات على المنتج، والعميل، والمعاملة، والولاية القضائية — وليس فقط على مسار الدفع.

حيث تتداخل المعايير — وحيث لا تزال الهوية مناسبة

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

• TAP: التعرف على الوكيل والنية الموقعة عند حدود التاجر، مع إشارات مستهلك ودفع مرتبطة اختيارية.
• AP2: عناصر ترخيص تشفيرية تربط نية المستخدم بنتائج الدفع والدفع.
• Agent Pay: وكلاء مسجلون، وبيانات اعتماد دفع رمزية، وموافقة، ومصادقة، ورؤية عبر شبكة البطاقات.

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

تجيب هوية الوكيل على سؤال "ما هو البرنامج الذي عمل؟" يجيب الترخيص على سؤال "ماذا سُمح له أن يفعل؟" يجيب التحقق من الهوية على سؤال "من يقف وراءه؟" تجيب ضوابط الاحتيال والامتثال على سؤال "هل يجب أن يستمر هذا الإجراء؟"

ما يتعين على المطورين بناؤه بغض النظر عن النهج الفائز

• التسجيل والتحقق. تحقق من هوية الشخص أو العمل قبل منح بيانات اعتماد قابلة لإعادة الاستخدام أو سلطة إنفاق مفوضة. طبق فحوصات KYC، KYB، التحقق من الحياة، الوثائق، قاعدة البيانات، أو البيومترية وفقًا للمخاطر.
• ربط بيانات الاعتماد. اربط الموضوع المتحقق منه بحساب، أو جهاز، أو مفتاح مرور، أو محفظة، أو أي بيانات اعتماد أخرى يمكنها المشاركة في التدفق الوكيلي.
• الترخيص المحدود. التقاط الحدود مثل التاجر، الفئة، المبلغ، التكرار، تاريخ انتهاء الصلاحية، وما إذا كان يجب على الإنسان العودة للموافقة.
• قرارات المخاطر في وقت التشغيل. افحص الشخص، العمل، المحفظة، والمعاملة لحظة الإجراء. تظل ضوابط معرفة معاملتك (KYT) وفحوصات مكافحة غسل الأموال ذات صلة حتى عندما تكون النية موقعة.
• الإلغاء والاسترداد. إيقاف السلطة المفوضة عند اختراق بيانات الاعتماد، أو سحب المستخدم للموافقة، أو تغير المخاطر.
• القدرة على التدقيق. احتفظ بنتيجة التحقق، وعنصر الترخيص، وهوية الوكيل، وقرار المعاملة، والطوابع الزمنية، وإجراءات المراجعة اللاحقة كأدلة منفصلة.

هذا التصميم الطبقي محايد للمعايير عمدًا. يمكن للفريق اعتماد TAP عند حافة التاجر، أو تفويضات AP2 في سير عمل الوكيل، أو Agent Pay لتسوية البطاقات، أو مزيج. يظل قرار الهوية والاحتيال قابلاً للنقل لأنه غير مضمن في شبكة دفع واحدة.

كيف يغطي Didit نصف الهوية اليوم

يوفر Didit بنية تحتية للهوية والاحتيال تستخدمها أكثر من 2000 شركة في الإنتاج. تتوفر نفس الإمكانيات من خلال خادم MCP مستضاف للعمليات التي يقودها الوكيل وواجهة برمجة تطبيقات REST للتدفقات التي يتحكم فيها التطبيق. للحصول على نظرة عامة أوسع على البنية، انظر كيف يتعامل خادم MCP مع التحقق من الهوية وكيف يربط MCP الهوية وفحوصات الاحتيال لوكلاء الذكاء الاصطناعي.

نقطة نهاية MCP المستضافة هي https://mcp.didit.me/mcp. تستخدم بروتوكول HTTP القابل للتدفق (Streamable Hypertext Transfer Protocol)، مع Open Authorization (OAuth) 2.1، وProof Key for Code Exchange (PKCE)، والتسجيل الديناميكي للعميل. يسجل المستخدم الدخول عبر لوحة تحكم Didit Business ويمنح وصولًا محدودًا؛ لا تستخدم نقطة نهاية MCP المستضافة مصادقة مفتاح واجهة برمجة التطبيقات.

بعد التفويض، يمكن للوكيل استدعاء 115 أداة عبر 11 فئة. يمكن لتسلسل تحقق عملي استخدام:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

يمكن لهذه الأدوات إنشاء جلسة تحقق، وتشغيل الفحوصات المحددة، واسترداد قرار منظم. تتضمن الأدوات الحقيقية الأخرى didit_verify_aml، didit_verify_kyb_search، didit_verify_kyb_select، وdidit_transaction_screen_wallet. تظل عمليات الكتابة عالية التأثير خاضعة لأذونات المستخدم المتصل وسلوك التأكيد.

تغطي واجهة برمجة تطبيقات REST مسار التطبيق: إنشاء جلسات من الواجهة الخلفية الخاصة بك، وإرسال المستخدمين عبر التحقق المستضاف أو المضمن، واستهلاك webhooks، وتخزين القرارات في نظامك الخاص. تستخدم طلبات REST من خادم إلى خادم رأس x-api-key؛ هذا منفصل عن اتصال MCP المستضاف المعتمد بواسطة OAuth. اقرأ نظرة عامة على MCP، ودليل المصادقة، ومرجع الأداة للحصول على تفاصيل التنفيذ.

التسعير مستقل عن معيار الدفع الوكيلي. خادم MCP مجاني. تبلغ تكلفة حزمة KYC الكاملة — التحقق من الهوية، والتحقق من الحياة السلبية، ومطابقة الوجه، وتحليل IP — 0.33 دولارًا، ويتضمن كل حساب 500 عملية تحقق مجانية شهريًا.

مسار تنفيذ محايد للمعايير

ابدأ بتحديد التأكيد المطلوب لكل إجراء، وليس باختيار شعار شبكة. قد يتطلب التصفح منخفض المخاطر التعرف على الوكيل فقط. قد يتطلب إنشاء الحساب هوية موثقة. قد تتطلب عملية شراء منظمة KYC أو KYB بالإضافة إلى فحص AML. قد يضيف تحويل العملات المشفرة فحص المحفظة. يمكن أن تعيد المبالغ الأعلى أو المخاطر المتغيرة الإنسان إلى الحلقة.

ثم اربط عنصر الدفع بقرار الهوية باستخدام معرفات داخلية ثابتة. احتفظ بتوقيع الوكيل، وترخيص المستخدم، ودليل التحقق، ونتيجة الدفع مميزة بحيث يمكن إلغاء كل منها ومراجعتها وترقيتها بشكل مستقل مع تطور المعايير.

استكشف صفحة مطوري Didit MCP أو افحص مستودع GitHub العام المرخص بشكل متساهل. يمكن لمستخدمي Claude إضافة موصل Didit وإكمال تسجيل الدخول عبر OAuth.

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