الشهادات الرقمية والمدفوعات: استراتيجية محافظ Apple وGoogle

المدفوعات الرقمية تتغير باستمرار. نريدها أن تكون أسرع وأكثر أمانًا وأسهل في الاستخدام. في الوقت نفسه، تتحسن أدوات الهوية الرقمية، مثل الشهادات القابلة للتحقق (Verifiable Credentials - VCs) ووثائق الهوية المحمولة (mdocs). إنها تقدم طرقًا جديدة للناس لإثبات هويتهم. لذا، السؤال الكبير هو: هل يمكن لهذه الهويات الرقمية الجديدة أن تجعل المدفوعات الرقمية أفضل أو أبسط بكثير؟

يبحث هذا المقال في كيفية ارتباط الشهادات الرقمية (بما في ذلك ISO mdocs و VCs المرسلة باستخدام OpenID4VC) بعالم المدفوعات. سنغطي ما يلي:

• كيف تتعامل محافظ الهواتف الحالية (Apple Wallet، Google Wallet) مع معلومات الهوية مقابل بطاقات الدفع.
• لماذا معايير الهوية الرقمية الحالية مثل ISO 18013-5/7 mdocs غير مناسبة حقًا كأدوات دفع مباشرة.
• ما هو الدور الذي يمكن أن تلعبه بروتوكولات مثل OpenID4VC في طرق الدفع المستقبلية.
• كيف يمكن لتطبيقات المحافظ الأخرى (التابعة لجهات خارجية) التعامل مع ميزات الدفع.
• المشاكل الرئيسية وما يمكن أن يحدث في المستقبل عند محاولة استخدام الشهادات القابلة للتحقق في أنظمة الدفع.

يضيف هذا النص إلى مناقشتنا الأخرى حول الشهادات الرقمية ومفاتيح المرور من خلال التركيز فقط على المدفوعات.

لمعرفة كيف يمكن استخدام الشهادات الرقمية في المدفوعات، نحتاج أولاً إلى فهم كيف تحافظ المنصات المحمولة الرئيسية اليوم ومحافظها المدمجة (Apple Wallet، Google Wallet) على فصل معلومات الهوية عن كيفية معالجة المدفوعات.

أصبحت محافظ المنصات الأصلية مراكز متطورة للمستخدمين، لكنها عادةً ما تحافظ على تمييز واضح بين شهادات الهوية وأدوات الدفع:

• شهادات الهوية (مثل mDLs):
  • Apple Wallet: تدعم بشكل أساسي رخص القيادة المحمولة (mDLs) وبطاقات الهوية الحكومية المتوافقة مع ISO/IEC 18013-5. اعتبارًا من مؤتمر WWDC25، أكدت Apple أن Safari 26 (في iOS 26) سيدعم W3C Digital Credentials API للعرض عبر الإنترنت، مع التركيز الحصري على بروتوكول org.iso.mdoc. هذا مخصص للتحقق من سمات الهوية (مثل الاسم والعمر والعنوان)، وليس للمدفوعات.
  • Google Wallet و Android Credential Manager: يدعم Google Wallet أيضًا mDLs المستندة إلى ISO 18013-5. يوفر Android Credential Manager الأساسي إطارًا أكثر مرونة. في حين أن تنفيذه لـ Digital Credentials API محايد من حيث البروتوكول، يوفر Android تنفيذًا افتراضيًا يستخدم OpenID4VP كآلية نقل.
• أدوات الدفع (مثل بطاقات الائتمان/الخصم):
  • يستخدم كل من Apple Pay (داخل Apple Wallet) و Google Pay (داخل Google Wallet) تقنيات دفع راسخة ومنظمة للغاية. تعتمد هذه بشكل أساسي على معايير EMV (Europay، Mastercard، Visa)، والتي تتضمن الترميز (استبدال أرقام البطاقات الفعلية بـ Device PANs أو DPANs للمعاملات)، والعناصر الآمنة أو الأمان المدعوم بالأجهزة لتخزين رموز الدفع، والتشفيرات الديناميكية لأمان المعاملات.
  • تتفاعل أنظمة الدفع هذه مباشرة مع شبكات الدفع الحالية (Visa، Mastercard، Amex، إلخ) والبنوك المستحوذة.

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

يحدد معيار ISO/IEC 18013-5 بنية البيانات لـ mDLs وغيرها من الهويات المحمولة (mdocs). على الرغم من كونه ممتازًا للتحقق من الهوية، إلا أن تصميمه غير مناسب للاستخدام المباشر كأداة دفع:

حتى لو كان من الممكن نظريًا إضافة حقول بيانات مخصصة إلى mdoc للاحتفاظ بـ PAN أو رمز دفع (كما يسمح ISO 18013-5 بمساحات الأسماء المخصصة)، فإن معيار mdoc نفسه لا يحدد:

• كيفية توليد أو معالجة تشفيرات الدفع الديناميكية.
• كيفية إجراء التفويض عبر الإنترنت مع شبكة دفع.
• آليات الأمان اللازمة الخاصة بمعاملات الدفع (بخلاف سلامة بيانات الهوية).

وبالتالي، لا توجد حاليًا طريقة لاستخدام ISO 18013-5 mdoc كأداة دفع مباشرة.

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

1. المصادقة الأولية: يقوم المستخدم بتسجيل الدخول إلى خدمة، غالبًا بطريقة منخفضة الاحتكاك مثل مفتاح المرور.
2. محفز التصعيد: لإجراء عالي الضمان (مثل تحويل بنكي كبير، تحديث التفاصيل الشخصية)، تتطلب الخدمة فحص هوية صريح.
3. عرض mdoc: تطلب الخدمة عرض mdoc الخاص بالمستخدم (مثل رخصة القيادة). يقدم المستخدم السمات المطلوبة من محفظته.
4. التحقق: تتحقق الخدمة بشكل مشفر من بيانات mdoc مقابل مصدر موثوق أو هوية مسجلة مسبقًا.

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

بينما لا تعتبر mdocs أدوات دفع بحد ذاتها، فإن بروتوكولات مثل OpenID for Verifiable Credentials (OpenID4VC) - التي تشمل OpenID4VP للعرض و OpenID4VCI للإصدار - توفر طبقة نقل أكثر مرونة.

الخصائص الرئيسية لـ OpenID4VC:

• بروتوكول، وليس حمولة: يحدد OID4VC كيفية طلب وتقديم الشهادات القابلة للتحقق (VCs) ولكنه محايد إلى حد كبير بشأن تنسيق حمولة VC نفسها. يمكنه نقل mdocs، وشهادات VC القياسية من W3C (على سبيل المثال، بتنسيق JWT أو SD-JWT)، أو أنواع شهادات مخصصة أخرى.
• اتساع حالات الاستخدام: تسمح هذه المرونة لمنصات مثل Android (عبر Credential Manager) بدعم طلبات أنواع مختلفة من الشهادات من خلال آلية مشتركة.
• التوافق المستقبلي لشهادات الدفع القابلة للتحقق: إذا قامت صناعة المدفوعات بتوحيد تنسيق شهادة "رمز دفع" أو "تفويض دفع" قابل للتحقق، يمكن لـ OID4VC نظريًا نقل مثل هذه الشهادة بين محفظة المستخدم والتاجر/مزود خدمة الدفع (PSP).

ومع ذلك، فإن OID4VC بحد ذاته ليس حلاً للدفع:

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

بالإضافة إلى محافظ المنصات الأصلية، يظهر نظام بيئي متنامٍ من محافظ الطرف الثالث (مثل EUDI Wallet، والمحافظ التي تقدمها البنوك، والمحافظ الصناعية المتخصصة). يجب على هذه المحافظ التنقل في الفرق الأساسي بين المصادقة السريعة منخفضة الاحتكاك والتحقق من السمات عالية الضمان، خاصة في سياقات الدفع.

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

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

• الربط العميق بين التطبيقات (App-to-App Deep Linking): هذه طريقة عالمية حيث يقوم تطبيق التاجر (أصلي أو ويب) بإعادة توجيه المستخدم إلى تطبيق محفظة الطرف الثالث باستخدام مخطط URL مخصص (على سبيل المثال، eudi-wallet://...). يتم تمرير تفاصيل المعاملة كمعلمات في عنوان URL. بعد أن يؤكد المستخدم الدفع في تطبيق المحفظة، يعيد توجيهه مرة أخرى إلى تطبيق التاجر باستخدام رابط عميق آخر. يعمل هذا على كل من iOS و Android ولكنه يتضمن تبديل سياق مرئي بين التطبيقات.
• محدد المحفظة الأصلي (Native Wallet Selection): مع محدد المحفظة الأصلي، يمكن للتطبيق استدعاء خدمة نظام عامة تعرض جميع معالجات الدفع أو المحافظ المسجلة. يمكن للمستخدم بعد ذلك تحديد محفظته المفضلة من واجهة مستخدم يوفرها النظام. يوفر هذا إحساسًا أكثر تكاملاً من الربط العميق البسيط (Digital Credentials API).
• المدفوعات البسيطة المستندة إلى رمز الاستجابة السريعة (QR code): هذا النموذج مثالي لتدفقات سطح المكتب إلى الهاتف المحمول. يعرض موقع التاجر رمز QR يحتوي على تفاصيل المعاملة أو عنوان URL. يقوم المستخدم بمسح هذا الرمز باستخدام تطبيق محفظته المحمولة، والذي يتعامل بعد ذلك بشكل مستقل مع التأكيد على الهاتف. ثم يقوم النظام الخلفي للمحفظة بإبلاغ الموافقة مرة أخرى إلى نظام التاجر.
• تدفقات الأجهزة المتقاطعة الموحدة (FIDO CTAP): تطور لطريقة رمز QR، يستخدم هذا بروتوكولات مثل بروتوكول العميل إلى المصادق (CTAP) من FIDO لإنشاء قناة مباشرة وآمنة ومشفرة بين متصفح سطح المكتب (العميل) والمحفظة المحمولة (التي تعمل كمصادق). هذا أكثر أمانًا من رموز QR البسيطة حيث يتواصل المتصفح والهاتف مباشرة، وهو نموذج تدعمه Google بشدة لكل من مفاتيح المرور والشهادات الرقمية.
• التكامل المباشر مع الواجهة الخلفية: في بعض الأنظمة المغلقة، قد يتفاعل تطبيق محفظة الطرف الثالث مباشرة مع مزود خدمة الدفع (PSP) أو الواجهة الخلفية لمؤسسة مالية لمعالجة المدفوعات، غالبًا باستخدام واجهات برمجة تطبيقات خاصة.

توفر هذه النماذج "طبقة النقل" لبدء تأكيد الدفع، والتي يمكن من خلالها إجراء تدفق تشفير (مثل ذلك المفصل لمحفظة EUDI Wallet).

مع الإعلانات في WWDC25، أصبح المشهد لكيفية تعامل المتصفحات مع الشهادات الرقمية أكثر وضوحًا، مما يعزز الفصل بين التحقق من الهوية ومعالجة الدفع. تمكّن المنصات محافظ الطرف الثالث من التفاعل مع المتصفحات من أجل التحقق من الهوية عبر W3C Digital Credentials API، لكن الأساليب تتباعد:

• موقف Apple (تم تأكيده في WWDC25): أعلنت Apple رسميًا عن دعم Digital Credentials API في Safari 26 (الذي سيصدر مع iOS 26). كما هو مفصل في جلستهم "Verify identity documents on the web"، يدعم التنفيذ حصريًا بروتوكول org.iso.mdoc. يسمح هذا لمواقع الويب بطلب معلومات يمكن التحقق منها من mdocs في Apple Wallet أو تطبيقات مزود المستندات الأخرى التابعة لجهات خارجية مسجلة، لكنه لا يدعم بروتوكول OpenID4VP الأكثر عمومية. مع زيادة الدعم للشهادات الرقمية وتكاملات الويب المحسنة، يصبح الحفاظ على أداء النظام وأمانه أكثر أهمية - تساعد أدوات مثل CleanMyMac على ضمان تشغيل جهاز Mac الخاص بك بسلاسة مع تطور هذه التقنيات.
• موقف Google: يسمح Credential Manager في Android لمحافظ الطرف الثالث بالتسجيل كمعالجات لطلبات الشهادات. يركز تنفيذه لـ Digital Credentials API في Chrome على استخدام OpenID4VP كبروتوكول نقل أساسي. بينما يمكن لـ OpenID4VP حمل mdoc كحمولة، فإن البروتوكول نفسه يختلف عن نهج Apple المباشر org.iso.mdoc.

بشكل حاسم، هذه التكاملات مع المتصفح مخصصة لسمات الهوية، وليس لمعاملة mDoc أو VC المقدم كأداة دفع.

إذا قدم مستخدم mDL من محفظته إلى موقع ويب عبر Digital Credentials API للمتصفح، فقد يستخدم هذا الموقع المعلومات للملء المسبق للعنوان أو التحقق من العمر أثناء الدفع. ومع ذلك، ستظل خطوة الدفع الفعلية تتطلب تفاعلًا منفصلاً مع طريقة دفع (على سبيل المثال، Apple Pay، Google Pay، أو إدخال تفاصيل البطاقة). لم يتم تصميم واجهة برمجة تطبيقات المتصفح نفسها لبدء أو معالجة معاملة مالية باستخدام شهادة هوية.

تعتبر محفظة الهوية الرقمية للاتحاد الأوروبي (EUDI) دراسة حالة ممتازة لكيفية تعامل محفظة طرف ثالث مع المشهد المعقد والواقعي لأنظمة التشغيل وتوافر واجهات برمجة التطبيقات. من بين وظائفها العديدة، هناك حالتان من أبرز حالات الاستخدام وهما التحقق من الهوية وتأكيد الدفع، والمسارات التقنية لإنجاز هاتين المهمتين مختلفة، خاصة عند مقارنة إطار عمل Android المرن بتنفيذ Apple الأكثر صرامة.

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

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

• Digital Credentials API: هذا المعيار الناشئ من W3C محايد من حيث البروتوكول ومدعوم جيدًا للهوية على كلا المنصتين. لتنفيذه، يوفر Android تدفقًا افتراضيًا باستخدام بروتوكول OpenID4VP المرن، والذي يمكنه حمل تنسيقات شهادات مختلفة. في المقابل، يقتصر تنفيذ Apple بشكل صارم على تنسيق org.iso.mdoc. بشكل حاسم، تخصص المتصفحات هذه الواجهة لحالات استخدام الهوية، وليس لبدء المدفوعات.
• محدد المحفظة الأصلي: يوفر كلا نظامي التشغيل واجهة مستخدم أصلية لتحديد محفظة، ولكن مع قيود مختلفة. يقدم Android محددًا لكل من تطبيقات الهوية والدفع. يوفر iOS محددًا لتطبيقات "مزود المستندات" المسجلة للهوية ولكنه لا يقدم واحدًا لتطبيقات الدفع التابعة لجهات خارجية.
• الربط العميق بين التطبيقات: هذا هو الحل الشامل، ويعمل بشكل موثوق لكل من حالات استخدام الهوية والدفع على كلا المنصتين. يظل الطريقة الأساسية لاستدعاء محفظة طرف ثالث للمدفوعات على iOS.
• الأجهزة المتقاطعة الموحدة: هذا التدفق المستند إلى FIDO CTAP هو حاليًا ميزة في نظام Google/Android البيئي وغير مدعوم على iOS.

(*) ملاحظة حول المدفوعات عبر DC API: بينما يجعل استخدام Android لـ OpenID4VP تدفق الدفع ممكنًا تقنيًا من خلال Digital Credentials API، فإن هذا ليس محور تصميمه الأساسي. لا يزال التكامل السلس للمدفوعات عبر هذه الواجهة المحددة، على عكس الطرق الأصلية الأخرى، غير مؤكد وسيتطلب دعمًا صريحًا من موردي المتصفحات.

توضح هذه المقارنة أنه بينما يتم توحيد التحقق من الهوية بشكل متزايد من خلال Digital Credentials API، لا يزال تفويض الدفع لمحافظ الطرف الثالث مثل محفظة EUDI يعتمد بشكل كبير على أنماط التكامل الأصلية الأكثر تقليدية مثل الربط العميق بين التطبيقات، خاصة على iOS.

بغض النظر عن نموذج تكامل الدفع المستخدم لاستدعاء المحفظة، يعتمد جوهر تأكيد الدفع في محفظة EUDI على تدفق تشفير موحد مفصل في EWC RFC008.

فيما يلي شرح عالي المستوى لهذه العملية:

هذا مثال غير معياري لكائن payment_data الذي يتم إرساله إلى المحفظة، ويفصل المعاملة ليؤكدها المستخدم.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

بعد موافقة المستخدم، تنشئ المحفظة JWT لربط المفتاح. تثبت مطالباته أن المستخدم أكد بيانات المعاملة المحددة.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

بينما تتطور المعايير التقنية، لا تقف صناعة المدفوعات مكتوفة الأيدي. يستكشف اللاعبون الرئيسيون بنشاط كيفية دمج أمان الشهادات الرقمية مع وظائف المدفوعات.

طريقة قوية لفهم إمكانات الشهادات القابلة للتحقق (VCs) هي مقارنتها بأنظمة ترميز مدفوعات الشبكة الناجحة (مثل Visa Token Service أو Mastercard MDES).

• ترميز المدفوعات استبدل رقم الحساب الأساسي الحساس (PAN) برمز آمن وتشفير لمرة واحدة. هذا يحمي الأصل الأساسي - رقم البطاقة - أثناء المعاملات.
• الشهادات القابلة للتحقق تهدف إلى أن تفعل للبيانات الشخصية ما فعله الترميز لـ PANs. بدلاً من مشاركة البيانات الأولية (الاسم، تاريخ الميلاد، العنوان)، يقدم المستخدم شهادة موقعة بشكل مشفر من جهة إصدار موثوقة.

في جوهرها، الشهادة القابلة للتحقق (VC) للبيانات الشخصية هي مثل رمز الدفع والتشفير لبيانات البطاقة: بديل آمن وقابل للتحقق يقلل من المخاطر ويعزز الخصوصية.

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

• EMVCo، هيئة المعايير للمدفوعات الآمنة، تدمج بنشاط معايير FIDO في بروتوكول EMV 3-D Secure. يسمح هذا باستخدام مصادقات مفاتيح المرور السابقة كإشارة قوية للموافقات السلسة، مع الاستعداد أيضًا لـ Secure Payment Confirmation (SPC) لتكون بمثابة بديل حديث ومقاوم للتصيد الاحتيالي لتحديات OTP التقليدية. هناك أيضًا مناقشات جارية حول كيفية دمج الشهادات القابلة للتحقق في هذه التدفقات في المستقبل.
• Visa أعلنت عن Visa Payment Passkey Service، والتي تربط بشكل آمن مصادق FIDO بشهادات الدفع. تم تصميم هذه الخدمة لتأكيد الهوية وتفويض المدفوعات في خطوة واحدة سلسة دون مقاطعة تجربة الدفع.
• Mastercard تتبع استراتيجية موازية مع Mastercard Payment Passkey Service، والتي تستفيد من خدمة مصادقة الرمز (TAS) الخاصة بها لاستبدال كلمات المرور و OTPs بالمصادقة البيومترية القائمة على مفاتيح المرور، والمتكاملة بإحكام مع خدمات الترميز الخاصة بها (MDES).

يُظهر هذا اتجاهًا واضحًا: تتجه الصناعة نحو مستقبل يمكن فيه للمحفظة تقديم إثبات قابل للتحقق بشكل مشفر لكل من الهوية وتفويض الدفع في تدفق واحد موحد.

يتم تسريع الكثير من هذا الابتكار من خلال رياح تنظيمية قوية، لا سيما من الاتحاد الأوروبي.

لائحة eIDAS 2.0 للاتحاد الأوروبي لا تتعلق فقط بتزويد المواطنين بهوية رقمية؛ بل تتصور صراحةً محفظة EUDI كطريقة لإجراء SCA للمدفوعات عبر الإنترنت. هذا يعني أنه في المستقبل، قد يُطلب من البنوك ومقدمي خدمات الدفع في الاتحاد الأوروبي قبول محفظة EUDI كطريقة للمستخدمين لتأكيد المعاملات عبر الإنترنت، مما يوفر بديلاً قائمًا على المعايير لتطبيقات البنوك الخاصة أو رموز الرسائل القصيرة.

أجبرت تسوية تاريخية لمكافحة الاحتكار في الاتحاد الأوروبي شركة Apple بالفعل على فتح واجهة NFC المغلقة سابقًا على أجهزة iPhone. اعتبارًا من iOS 17.4 (الذي تم إصداره في 5 مارس 2024)، نفذت Apple واجهات برمجة التطبيقات اللازمة وسمحت للمستخدمين بتحديد تطبيق دفع افتراضي بدون تلامس، لتلبية الموعد النهائي الملزم للمفوضية الأوروبية في 25 يوليو 2024. لم يعد هذا احتمالًا مستقبليًا؛ بل هو الواقع الحالي في المنطقة الاقتصادية الأوروبية (EEA).

يعني هذا التحول أن تطبيقات المحافظ التابعة لجهات خارجية يمكنها الآن تقديم حلول الدفع بالنقر الخاصة بها على iOS، مما ينهي احتكار Apple Pay طويل الأمد. تشمل القدرات الرئيسية المتاحة الآن للمطورين ما يلي:

• اختيار المحفظة الافتراضية: يمكن للمستخدمين في المنطقة الاقتصادية الأوروبية تعيين تطبيق طرف ثالث مؤهل كتطبيق دفع افتراضي بدون تلامس، والذي يمكن استدعاؤه عبر نقرة مزدوجة على الزر الجانبي.
• التكامل الكامل: يمكن لهذه المحافظ استخدام ميزات الأمان الأصلية في iPhone، بما في ذلك Face ID و Touch ID، لتفويض الدفع.
• التبني في العالم الحقيقي: أطلقت العديد من الشركات الكبرى بالفعل حلولها، بما في ذلك Vipps MobilePay في النرويج و PayPal في ألمانيا.

إن تداعيات هذا الانفتاح كبيرة وتتكشف بالفعل:

• زيادة المنافسة: يمكن للبنوك وشركات التكنولوجيا المالية الآن التنافس مباشرة مع Apple Pay على منصتها الخاصة، مما من المتوقع أن يؤدي إلى خفض رسوم جهات الإصدار وتحفيز الابتكار.
• استخدام أوسع للشهادات: يمكن استخدام نفس واجهات برمجة التطبيقات لأكثر من مجرد المدفوعات، بما في ذلك شارات الشركات وبطاقات النقل ومفاتيح الفنادق، دون الحاجة إلى أن تكون في Apple Wallet.
• سابقة للمسار الموحد للشهادات: هذا يضع سابقة حاسمة. يمكن في النهاية استخدام نفس المنطق التنظيمي الذي فتح واجهة NFC لتطبيقات الدفع لفرض دعم "شهادات الدفع القابلة للتحقق" الموحدة والمحايدة (مثل تلك التي يتم تجريبها لمحفظة EUDI)، مما يسمح لها بالعمل جنبًا إلى جنب مع الحلول الخاصة.
• سابقة عالمية: بينما يقتصر التغيير حاليًا على المنطقة الاقتصادية الأوروبية، فإنه يضع سابقة عالمية قوية. يراقب المنظمون في مناطق أخرى، بما في ذلك الولايات المتحدة، عن كثب، وقد يؤدي هذا إلى تسريع فتحات مماثلة في جميع أنحاء العالم.

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

أساس أي استراتيجية محفظة مستقبلية هو تطبيق أصلي آمن ومعتمد على نطاق واسع. الأولوية الفورية هي زيادة وصول تطبيقك إلى أقصى حد وتحصين مصادقته لكل من تسجيل الدخول والمدفوعات.

1. عزز تبني التطبيق الأصلي: تطبيقك المحمول هو محفظتك المستقبلية. الهدف الأساسي هو جعله أداة لا غنى عنها لعملائك. هذا التوزيع والمشاركة هو الأساس الحاسم لأي إصدار شهادات أو وظائف محفظة مستقبلية.

2. استخدم مفاتيح المرور للمدفوعات، باتباع نموذج PayPal: انشر مفاتيح المرور على الفور، ليس فقط لتسجيل الدخول، ولكن لتفويض الدفع. استهدف تجربة تضاهي بشكل وثيق حلول المنصات الأصلية مثل Apple Pay. بالنسبة للبيئات التنظيمية التي تتطلب المصادقة القوية للعملاء (SCA)، اعتمد نهج PayPal العملي:

   • استفد من مفاتيح المرور كعامل مصادقة أساسي.
   • ادمجها مع إشارات الأجهزة الموثوقة (على سبيل المثال، "الأجهزة المتذكرة" التي تتم إدارتها عبر تطبيقك أو ملفات تعريف الارتباط الآمنة) لتلبية عامل "الحيازة" في SCA.
   • يسمح لك هذا المزيج بتوفير تجربة تأكيد دفع سلسة ومنخفضة الاحتكاك وآمنة للغاية ومتوافقة، دون انتظار دعم VC العالمي.

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

3. راقب صعود شهادات الدفع القابلة للتحقق: مفهوم VC الذي يحمل رمز دفع قوي ولكنه لم يتم توحيده بعد. دورك هنا هو أن تكون مراقبًا ومشاركًا نشطًا.

   • الإجراء: تتبع عن كثب التقدم المحرز في هيئات المعايير مثل EMVCo و W3C. كن مستعدًا للاستفادة من شهادات الدفع القابلة للتحقق الموحدة إذا ومتى قدمت ميزة واضحة على التدفقات الحالية القائمة على مفاتيح المرور.

4. ادمج الشهادات الرقمية لحالات استخدام الهوية: مع اكتساب محافظ الهوية الرقمية (مثل محفظة EUDI) زخمًا، ادمج Digital Credentials API للمهام المتعلقة بالهوية، وليس المدفوعات.

   • الإجراء: استخدم عروض VC للعمليات عالية الضمان حيث تتفوق:
     • الإعداد و KYC: تبسيط إعداد الحساب الجديد.
     • المصادقة التصعيدية: التحقق من الهوية للإجراءات عالية المخاطر.
     • استعادة الحساب: توفير مسار آمن للمستخدمين الذين فقدوا أجهزتهم.

العائق النهائي أمام تبني أي تقنية دفع جديدة هو احتكاك المستخدم. قبل استبدال تدفق مفتاح مرور بسيط، يجب أن يثبت البديل القائم على VC أنه ليس فقط أكثر أمانًا ولكن أيضًا سلسًا بنفس القدر.

5. قارن بلا هوادة بتجربة النقرة الواحدة: يتم تحديد معيار تجربة الدفع الحديثة من قبل رواد مثل Apple Pay وتابعه المقرب على الويب، PayPal. يجب أن ينافس أي تدفق جديد تقدمه تأكيدهم الفوري بنقرة واحدة تقريبًا. تشير جميع الإشارات الحالية إلى أنه بالنسبة للغالبية العظمى من المعاملات، توفر مقاومة التصيد الاحتيالي لمفاتيح المرور مستوى كافيًا من الحماية وتجربة مستخدم متفوقة. لا تضف خطوة عرض VC إلى تدفق الدفع إذا كانت تقدم أي احتكاك ملحوظ.

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

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

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

1. توحيد الشهادات القابلة للتحقق الخاصة بالدفع: يجب تطوير تنسيق شهادة قابلة للتحقق مخصص وآمن ومقبول على نطاق واسع للمدفوعات. سيحتاج هذا إلى تغليف رموز الدفع والبيانات الخاصة بالمعاملات وربما عناصر الأمان الديناميكية، مما يتجاوز بكثير نطاق mdocs الحالية التي تركز على الهوية أو VCs العامة.
2. التكامل مع شبكات الدفع: يجب أن يتكامل أي حل دفع قائم على VC بسلاسة مع شبكات الدفع العالمية الحالية (Visa، Mastercard، إلخ) أو يقترح مسارات جديدة قابلة للتطبيق. يتضمن هذا مواءمات فنية وأمنية ونماذج أعمال معقدة.
3. الامتثال التنظيمي: تخضع المدفوعات لتنظيم شديد (على سبيل المثال، PSD2/SCA في أوروبا، PCI DSS عالميًا). سيحتاج نظام الدفع القائم على VC إلى تلبية جميع اللوائح المالية ذات الصلة، بما في ذلك تلك المتعلقة بالأمان وحماية المستهلك ومكافحة الاحتيال.
4. تبني جهات الإصدار والمستحوذين: ستحتاج البنوك والمؤسسات المالية (كجهات إصدار لشهادات الدفع القابلة للتحقق) ومستحوذو التجار إلى الاستثمار في البنية التحتية لدعم مثل هذا النظام.
5. نموذج الأمان: سيكون نموذج الأمان القوي الخاص بشهادات الدفع القابلة للتحقق ضروريًا، ويغطي الإصدار والتخزين (يفضل أن يكون في عناصر آمنة مدعومة بالأجهزة) والعرض والإلغاء في سياق مالي.
6. تجربة المستخدم: بينما يمكن أن توفر VCs تحكمًا للمستخدم، يجب أن تظل تجربة الدفع سريعة وبديهية وموثوقة لكسب تبني واسع النطاق.

الإمكانيات المستقبلية:

• VCs لإيصالات تفويض الدفع: يمكن أن تمثل VCs "تفويضًا" موقعًا بشكل مشفر للدفع من حساب مرتبط، يتم تقديمه عبر OpenID4VP، مع استمرار حدوث تحويل الأموال الفعلي من خلال المسارات التقليدية.
• VCs تحتوي على رموز دفع: يمكن تحديد VC موحد للاحتفاظ بشكل آمن برمز دفع (على غرار EMV DPAN)، والذي تتم معالجته بعد ذلك بواسطة البنى التحتية للدفع الحالية.
• VCs للدفع في حلقة مغلقة: قد تنشئ جهات إصدار أو مجتمعات معينة VCs للمدفوعات داخل أنظمتها المغلقة.

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

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

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

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

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