مشهد مفاتيح المرور للمدفوعات: 4 نماذج أساسية للتكامل

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

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

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

1. النموذج المرتكز على جهة الإصدار (e.g. via SPC): على الرغم من أناقته التقنية، إلا أن هذا النموذج يعوقه نقص حاد في دعم المتصفحات، وأبرزها من Apple، مما يجعله حلاً غير عملي في المستقبل القريب.
2. النموذج المرتكز على التاجر (المصادقة المفوضة): يسمح هذا النموذج القوي لـ التجار الكبار بالاستفادة من علاقاتهم المباشرة مع العملاء، ونقل المصادقة إلى مرحلة مبكرة لإنشاء تجربة دفع سلسة، ولكنه يأتي مع مسؤولية كبيرة ويتطلب ثقة مباشرة من جهة الإصدار.
3. النموذج المرتكز على الشبكة (Click to Pay): خطوة استراتيجية كبرى من شبكات البطاقات مثل Visa و Mastercard للسيطرة على تجربة الدفع للضيوف من خلال تقديم مفتاح مرور محمول على مستوى الشبكة للمستهلكين.
4. النموذج المرتكز على مزود خدمة الدفع (المحافظ الإلكترونية): نموذج مهيمن حيث يستخدم مزودو خدمات الدفع الكبار مثل PayPal مفاتيح المرور لتأمين وتبسيط التجربة داخل أنظمتهم البيئية الواسعة والراسخة للمحافظ الإلكترونية.

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

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

في قلب كل معاملة يوجد خمسة مشاركين أساسيين يشكلون أساس سلسلة القيمة للمدفوعات.

1. العميل / حامل البطاقة:

   • الوصف: الفرد أو المنظمة التي تبدأ عملية الشراء. يحصل حامل البطاقة على بطاقة دفع (ائتمان أو خصم مباشر) من بنك مُصدر ويكون مسؤولاً عن سداد أي رسوم متكبدة.
   • الهدف: تجربة دفع سريعة وبسيطة وآمنة.
   • أمثلة: أي فرد لديه حساب بنكي و/أو بطاقة دفع.

2. التاجر:

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

3. البنك المُصدر (جهة الإصدار):

   • الوصف: بنك حامل البطاقة أو مؤسسته المالية. يوفر جهة الإصدار بطاقة الدفع للعميل، ويتحمل مخاطر الائتمان المرتبطة بها، وهو المسؤول في النهاية عن الموافقة على المعاملة أو رفضها بناءً على حالة حساب حامل البطاقة وتقييم المخاطر.
   • الهدف: استلام طلب التفويض وإرسال رمز استجابة عبر شبكات البطاقات.
   • أمثلة: Bank of America, Chase, Barclays.

4. البنك القابِل (Acquirer):

   • الوصف: بنك التاجر، المعروف أيضًا باسم بنك التاجر. يحتفظ البنك القابل بحساب التاجر ويسهل معالجة معاملات البطاقات نيابة عن التاجر.
   • الهدف: استلام تفاصيل الدفع من التاجر، وتوجيهها عبر شبكة البطاقات إلى جهة الإصدار، وعند الموافقة، تسوية الأموال في حساب التاجر.
   • أمثلة: Wells Fargo Merchant Services, Worldpay (from FIS).

5. شبكات البطاقات (Schemes):

   • الوصف: العمود الفقري التكنولوجي الذي يربط جميع المشاركين الآخرين. شركات مثل Visa، Mastercard، American Express، و Discover تدير هذه الشبكات الواسعة. لا تصدر هذه الشركات بطاقات أو تفتح حسابات تجارية ولكنها توفر البنية التحتية الحيوية، والقواعد، والمعايير التي تحكم المعاملات.
   • الهدف: تسهيل توجيه طلبات التفويض وتصفية وتسوية الأموال بين جهات الإصدار والبنوك القابلة.
   • أمثلة: Visa، Mastercard، American Express.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

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

1. بوابة الدفع (Payment Gateway):

   • الوصف: بوابة الدفع هي التكنولوجيا التي تعمل كبوابة رقمية آمنة للمعاملة. دورها الأساسي هو التقاط تفاصيل الدفع الحساسة للعميل من موقع التاجر أو نظام نقاط البيع (POS)، وتشفيرها، ونقلها بشكل آمن إلى معالج الدفع أو البنك القابل. إنها "الباب الأمامي" للمعاملة، وهي مسؤولة عن النقل الآمن للبيانات ولكن ليس عن حركة الأموال نفسها.
   • الهدف: تزويد التجار بطريقة آمنة وموثوقة لقبول المدفوعات عبر الإنترنت.
   • أمثلة: Authorize.net (حل من Visa)، Braintree، Stripe Payment Gateway.

2. معالج الدفع (Payment Processor):

   • الوصف: معالج الدفع هو الكيان الذي ينفذ رسائل المعاملات بين الأطراف المختلفة. بعد تلقي البيانات الآمنة من بوابة الدفع، يتواصل المعالج مع شبكة البطاقات، وبالتالي، مع البنوك المصدرة والقابلة لتسهيل تفويض وتسوية المعاملة. يمكن اعتبار المعالج المحرك التشغيلي الذي يتعامل مع الاتصالات التقنية المطلوبة لحدوث الدفع، بينما البوابة هي القناة الآمنة لتلك الاتصالات.
   • الهدف: تنفيذ رسائل الدفع بشكل موثوق وفعال، وإدارة تسوية المعاملات، والتعامل مع حل النزاعات بين البنوك المصدرة والقابلة.
   • أمثلة: First Data (now Fiserv), TSYS, Worldpay.

3. مزود خدمة الدفع (PSP):

   • الوصف: مزود خدمة الدفع هو شركة تقدم للتجار حلاً شاملاً ومجمعاً لقبول المدفوعات الإلكترونية. يجمع PSP الحديث عادةً وظائف بوابة الدفع ومعالج الدفع، وغالبًا ما يوفر حساب التاجر أيضًا، كل ذلك بموجب عقد واحد. يبسط هذا النموذج "المتكامل" العملية بشكل كبير للتجار، الذين لم يعودوا بحاجة إلى إقامة علاقات منفصلة مع مزود بوابة وبنك قابل. في بعض السياقات، يُشار أيضًا إلى PSPs التي تجمع طرق دفع مختلفة للتجار باسم مجمعي الدفع (Payment Aggregators).
   • الهدف: تقديم حل شامل لجميع احتياجات الدفع للتجار، وإخفاء التعقيد وتبسيط قبول المدفوعات.
   • أمثلة: Stripe, Adyen, PayPal, Mollie.

4. مزودو الدفع من حساب إلى حساب (A2A) / الخدمات المصرفية المفتوحة (Open Banking):

   • الوصف: هذه فئة سريعة النمو من مزودي الدفع تتجاوز شبكات البطاقات التقليدية تمامًا. تنقل مدفوعات A2A الأموال مباشرة من حساب بنكي للمستهلك إلى حساب بنكي للتاجر. غالبًا ما يتم تمكين ذلك من خلال لوائح "الخدمات المصرفية المفتوحة" (مثل PSD2 في أوروبا) التي تفرض على البنوك توفير وصول آمن عبر واجهة برمجة التطبيقات (API) إلى بيانات حسابات العملاء وخدمات بدء الدفع لمقدمي الخدمات من الأطراف الثالثة المرخصين. يبني هؤلاء المزودون واجهات سهلة الاستخدام فوق واجهات برمجة التطبيقات هذه، مما يسمح للمستهلكين بالمصادقة مع بنكهم والموافقة على الدفع في تدفق سلس.
   • الهدف: تقديم بديل منخفض التكلفة وآمن للغاية لمدفوعات البطاقات عن طريق إلغاء رسوم التبادل وتقليل الاحتيال من خلال المصادقة على مستوى البنك.
   • أمثلة: Trustly, Plaid, Tink, GoCardless, Fintecture.

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

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

يمكن فهم النماذج المعمارية الناشئة لتكامل مفاتيح المرور على أفضل وجه على أنها تفاوض استراتيجي حول من يتصرف كطرف معتمد. في نموذج تأكيد الدفع الآمن (SPC)، تظل جهة الإصدار هي الطرف المعتمد ولكنها تسمح للتاجر بـ استدعاء مراسم المصادقة. في المصادقة المفوضة (DA)، تقوم جهة الإصدار صراحةً بـ تفويض وظيفة الطرف المعتمد إلى التاجر أو مزود خدمة الدفع الخاص به. وفي النموذج المرتكز على الشبكة، تضع Visa و Mastercard نفسيهما كطرف معتمد اتحادي لمعاملات الدفع للضيوف. لذلك، يصبح السؤال المركزي لأي مزود دفع يفكر في تكامل مفاتيح المرور:

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

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

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

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

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

sequenceDiagram
    participant C as Customer
    participant M as Merchant
    participant P as Gateway/Acquirer
    participant N as Card Network
    participant I as Issuer

    C->>M: 1. Submit Payment Details
    M->>P: 2. Securely Transmit Details
    P->>N: 3. Authorization Request
    N->>I: 4. Route to Issuer for Verification
    I-->>N: 5. Approve/Decline Response
    N-->>P: 6. Relay Response
    P-->>M: 7. Relay Response
    M-->>C: 8. Confirm Order or Request New Payment

    M->>P: 9. Submit Batch of Approved Transactions
    P->>N: 10. Clearing Request
    N->>I: 11. Request Funds from Issuer
    I-->>N: 12. Transfer Funds (minus interchange fees)
    N-->>P: 13. Credit Acquirer with Funds
    P-->>M: 14. Deposit Funds to Merchant (minus processing fees)

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

تؤدي كل عملية شراء عبر الإنترنت إلى سلسلة معقدة وعالية السرعة من الأحداث التي يمكن تقسيمها إلى مرحلتين رئيسيتين: التفويض والتسوية. وفوق هذه العملية توجد طبقة بروتوكول أمان حيوية تُعرف باسم 3-D Secure، وهي أساسية لفهم التحديات الحديثة لمصادقة الدفع عبر الإنترنت.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

تتضمن دورة حياة معاملة CNP واحدة تبادلاً شبه فوري للبيانات يليه نقل أبطأ للأموال.

التفويض هو عملية التحقق من أن حامل البطاقة لديه أموال أو ائتمان كافٍ لإتمام عملية الشراء وأن المعاملة مشروعة. تحدث هذه المرحلة في ثوانٍ وتتبع مسارًا دقيقًا متعدد الخطوات (معالجة المدفوعات: كيف تعمل معالجة المدفوعات | Stripe):

1. بدء المعاملة: يختار العميل سلعه، وينتقل إلى الدفع، ويدخل تفاصيل بطاقة الدفع الخاصة به (رقم البطاقة، تاريخ انتهاء الصلاحية، CVV) في نموذج الدفع عبر الإنترنت الخاص بالتاجر.

2. النقل الآمن: يمرر موقع التاجر هذه المعلومات بشكل آمن إلى بوابة الدفع الخاصة به. تقوم البوابة بتشفير البيانات لحمايتها أثناء النقل.

3. التوجيه إلى المعالج/البنك القابل: تقوم البوابة بإعادة توجيه تفاصيل المعاملة المشفرة إلى معالج الدفع و/أو البنك القابل للتاجر.

4. اتصال الشبكة: يرسل البنك القابل طلب التفويض إلى شبكة البطاقات المناسبة (مثل Visa، Mastercard).

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

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

7. الإتمام: إذا تمت الموافقة، يكمل التاجر عملية البيع ويبلغ العميل. إذا تم الرفض، يطلب التاجر من العميل طريقة دفع بديلة.

التسوية هي عملية نقل الأموال فعليًا من جهة الإصدار إلى التاجر. على عكس التفويض، هذه العملية ليست فورية وتحدث عادةً على دفعات. (معالجة المدفوعات: كيف تعمل معالجة المدفوعات | Stripe)

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

فوق كل معاملة CNP توجد طبقة بروتوكول أمان حيوية تُعرف باسم 3-D Secure (3DS). تديرها EMVCo، والغرض منها هو السماح لجهة الإصدار بمصادقة حامل البطاقة، وتقليل الاحتيال، وتحويل المسؤولية عن عمليات رد المبالغ المدفوعة من التاجر إلى جهة الإصدار.

يعمل 3DS الحديث (يُطلق عليه أيضًا 3DS2) عن طريق تبادل مجموعة غنية من البيانات بين التاجر وخادم التحكم في الوصول (ACS) التابع لجهة الإصدار. تسمح هذه البيانات لـ ACS بإجراء تقييم للمخاطر، مما يؤدي إلى نتيجتين:

• التدفق السلس (Frictionless Flow): إذا اعتبرت المعاملة منخفضة المخاطر، تتم الموافقة عليها بصمت في الخلفية دون أي تفاعل من المستخدم. هذا هو الهدف لمعظم المعاملات.
• تدفق التحدي (Challenge Flow): إذا كانت المعاملة عالية المخاطر أو مفروضة بموجب لوائح مثل PSD2، يتم تحدي المستخدم بنشاط لإثبات هويته، عادةً باستخدام كلمة مرور لمرة واحدة (OTP) أو إشعار تطبيق بنكي.

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

graph TD
    A[البداية: العميل يشرع في الدفع] --> B{التاجر يبدأ فحص 3DS};
    B --> C[SDK الخاص بالتاجر يرسل بيانات المعاملة والجهاز الغنية إلى ACS الخاص بجهة الإصدار];
    C --> D{محرك المخاطر في ACS يحلل البيانات};
    D --> E{هل المعاملة عالية المخاطر أو هل SCA إلزامية؟};
    subgraph التدفق السلس
    E -- لا --> F[الموافقة على المصادقة بشكل سلبي - لا يوجد تفاعل من المستخدم];
    end
    subgraph تدفق التحدي
    E -- نعم --> G[يُطلب من المستخدم تحدي مصادقة];
    G --> H{هل يكمل المستخدم التحدي؟ - مثل OTP، إشعار التطبيق، SPC/Passkey};
    H -- نعم --> I[الموافقة على المصادقة];
    H -- لا --> J[فشل المصادقة];
    end
    F --> K[تستمر المعاملة مع تحويل المسؤولية إلى جهة الإصدار];
    I --> K;
    J --> L[يتم حظر المعاملة];

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

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

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

من يملك مفتاح المرور؟ في النموذج المرتكز على جهة الإصدار، جهة الإصدار هي الطرف المعتمد (RP).

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

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

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

sequenceDiagram
    participant U as User
    participant M as Merchant Website
    participant I as Issuer ACS

    Note over M,I: A 3DS check determines a challenge is needed.
    M->>I: Authorization Request (High Risk)
    I-->>M: Initiate SPC Challenge
    Note over U,M: Browser shows a native prompt to the user.
    M->>U: Trigger SPC API for issuer's domain (e.g., bank.com)
    U->>U: User authenticates with device biometrics (Face ID, etc.)
    U-->>M: Browser receives signed assertion for bank.com
    M->>I: Forward the signed assertion for validation
    I-->>M: Authentication Successful

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

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

من يملك مفتاح المرور؟ البنك هو الطرف المعتمد (RP). مفتاح المرور هو الذي أنشأه المستخدم بالفعل لخدماته المصرفية اليومية عبر الإنترنت باستخدام mybank.com.

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

كيف يعمل:

1. عند الدفع، يختار المستخدم مزود A2A (مثل Trustly، Plaid) أو بنكه الخاص.
2. يُطلب من المستخدم تفويض الدفع مع بنكه.
3. يقوم البنك، بصفته الطرف المعتمد، بتشغيل تحدي مصادقة بمفتاح المرور.
4. يقوم المستخدم بالمصادقة باستخدام Face ID أو بصمة الإصبع أو رقم التعريف الشخصي.
5. يؤكد البنك الدفع بشكل آمن، ويتم تحويل الأموال مباشرة إلى حساب التاجر.

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

sequenceDiagram
    participant U as User
    participant M as Merchant Website
    participant A2A as A2A Provider (e.g. Trustly)
    participant B as User's Bank

    U->>M: Selects "Pay from Bank"
    M->>A2A: Initiate A2A Payment
    A2A->>U: Prompt user to select their bank
    U->>A2A: Selects Bank
    A2A->>B: Request Payment Authorization
    Note over B,U: Bank prompts user for passkey authentication
    U->>B: Authenticate with Passkey for mybank.com
    B-->>A2A: Authentication Successful, Payment Authorized
    A2A-->>M: Confirm Payment
    M-->>U: Confirm Order

تمثل المصادقة المفوضة خروجًا أكثر جذرية عن النموذج التقليدي. تم تمكينها بواسطة الإصدار 2.2 من 3DS وبدعم من برامج محددة لشبكات البطاقات، DA هي إطار عمل يمكن لجهة الإصدار من خلاله تفويض مسؤولية إجراء SCA رسميًا إلى طرف ثالث موثوق به، وهو الأكثر شيوعًا تاجر كبير أو مزود خدمة دفع أو مزود محفظة رقمية.

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

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

Subscribe to our Passkeys Substack for the latest news.

Subscribe

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

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

تعمل شبكات البطاقات بنشاط على تعزيز هذا النموذج من خلال برامج مخصصة. إطار عمل Visa's Guide Authentication، على سبيل المثال، مصمم للاستخدام مع DA لتمكين التجار من إجراء SCA نيابة عن جهة الإصدار. وبالمثل، يتيح برنامج Mastercard's Identity Check Express للتجار مصادقة المستهلك ضمن تدفق التاجر الخاص. يعكس هذا النموذج الرؤية الاستراتيجية للتجار الكبار ومقدمي خدمات الدفع:

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

sequenceDiagram
    participant U as User
    participant M as Merchant Website
    participant I as Issuer ACS

    Note over U,M: Step 1: User logs into the merchant's site.
    U->>M: Authenticate with passkey for merchant.com
    M-->>U: Login Successful (SCA has been performed)

    Note over U,I: Step 2: Later, at checkout...
    U->>M: Clicks "Pay"
    M->>I: Authorization Request (including proof of prior SCA)
    I->>I: Verifies the delegated authentication proof
    I-->>M: Approve Transaction (No 3DS challenge needed)

هذا النموذج هو مبادرة استراتيجية كبرى تقودها شبكات البطاقات (Visa، Mastercard) للسيطرة على تجربة الدفع للضيوف وتوحيدها. لقد قاموا ببناء خدمات مفاتيح المرور الخاصة بهم المستندة إلى FIDO، مثل خدمة مفاتيح المرور للدفع من Visa، فوق إطار عمل Click to Pay.

من يملك مفتاح المرور؟ في النموذج المرتكز على الشبكة، شبكة البطاقات هي الطرف المعتمد. يتم إنشاء مفتاح المرور لنطاق الشبكة (على سبيل المثال، visa.com).

حلقة التبني الإيجابية وتأثيرات الشبكة: يمتلك هذا النموذج أقوى تأثير شبكي. يمكن إعادة استخدام مفتاح مرور واحد تم إنشاؤه لشبكة بطاقات على الفور عبر كل تاجر يدعم Click to Pay، مما يخلق قيمة هائلة للمستهلك ويدفع حلقة إيجابية كلاسيكية للسوق ذي الوجهين.

sequenceDiagram
    participant U as User
    participant M as Merchant Website
    participant N as Card Network (Click to Pay)
    participant I as Issuer

    Note over M,U: Guest Checkout Flow
    U->>M: Clicks "Click to Pay" button
    M->>N: Initiate Click to Pay flow
    Note over N,U: User is prompted to authenticate to the Network.
    N->>U: Browser triggers passkey prompt for network.com
    U->>U: User authenticates with device biometrics
    U-->>N: Signed assertion returned to Network
    N->>N: Validates user, retrieves stored card token
    N->>I: Authorization Request with network token
    I-->>N: Approve/Decline
    N-->>M: Send auth response to merchant

يرتكز هذا النموذج على مزودي خدمات الدفع (PSPs) الكبار الذين يديرون محافظهم الخاصة الموجهة للمستهلكين، مثل PayPal أو Stripe (with Link). في هذا النهج، يكون مزود خدمة الدفع هو الطرف المعتمد، ويمتلكون تدفق المصادقة والدفع بأكمله.

من يملك مفتاح المرور؟ في النموذج المرتكز على مزود خدمة الدفع، مزود خدمة الدفع هو الطرف المعتمد (RP). يتم إنشاء مفتاح المرور لنطاق PSP (على سبيل المثال، paypal.com) ويؤمن حساب المستخدم داخل النظام البيئي لـ PSP هذا.

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

sequenceDiagram
    participant U as User
    participant M as Merchant Website
    participant P as PSP / Wallet (e.g. PayPal)

    U->>M: Selects "Pay with PSP" at Checkout
    M->>U: Redirects or shows popup for PSP login
    Note over P,U: User authenticates directly to the PSP
    U->>P: Authenticate with Passkey for psp.com
    P-->>U: Authentication Successful
    P-->>M: Send Payment Guarantee / OK to Merchant
    M-->>U: Confirm Order

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

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

• في نموذج المرتكز على جهة الإصدار (SPC)، يكون RP هو جهة الإصدار (على سبيل المثال، chase.com). يتم تسجيل مفتاح المرور لدى البنك.
• في نموذج المرتكز على التاجر (DA)، يكون RP هو التاجر أو مزود خدمة الدفع الخاص به (على سبيل المثال، amazon.com أو stripe.com). يتم تسجيل مفتاح المرور لدى التاجر لتسجيل الدخول.
• في نموذج المرتكز على الشبكة، يكون RP هو شبكة البطاقات (على سبيل المثال، visa.com). يتم تسجيل مفتاح المرور لدى الشبكة لـ Click to Pay.
• في نموذج المرتكز على مزود خدمة الدفع، يكون RP هو مزود خدمة الدفع (على سبيل المثال، paypal.com). يتم تسجيل مفتاح المرور لدى محفظة أو خدمة PSP.

نظرًا لأن مفتاح المرور مرتبط بشكل مشفر بنطاق RP، لا يمكن التحقق من مفتاح مرور مسجل لدى chase.com بواسطة amazon.com. إنها هويات رقمية متميزة من وجهة نظر فنية. سيحتاج المستخدم إلى إنشاء مفتاح مرور منفصل لكل طرف معتمد يتفاعل معه.

تأتي "قابلية إعادة الاستخدام" و"قابلية النقل" التي تجعل مفاتيح المرور قوية من مجالين:

1. مزامنة مفاتيح المرور: خدمات مثل iCloud Keychain و Google Password Manager تزامن مفاتيح المرور عبر أجهزة المستخدم. لذا، فإن مفتاح المرور الذي تم إنشاؤه لـ chase.com على الهاتف متاح تلقائيًا على كمبيوتر المستخدم المحمول، ولكنه لا يزال لـ chase.com فقط.
2. الاتحاد (Federation): هذا هو النموذج الذي يستخدمه Click to Pay. يمكن للتاجر أن يثق في الشبكة (مثل Visa) لمصادقة المستخدم. يقوم المستخدم بالمصادقة لدى Visa (الطرف المعتمد)، ثم تشير Visa إلى التاجر بأن المستخدم شرعي. هذا يشبه "تسجيل الدخول باستخدام Google"، حيث يثق موقع الويب في Google للتعامل مع تسجيل الدخول. لا يتم إعادة استخدام مفتاح المرور من قبل التاجر؛ بل يتم إعادة استخدام حدث المصادقة.

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

بينما تقدم هذه النماذج طرقًا جديدة قوية للمصادقة، فإنها تقدم أيضًا تحديًا تشغيليًا حاسمًا غالبًا ما يتم تجاهله: استعادة مفاتيح المرور واسترداد الحساب. تخفف مفاتيح المرور المتزامنة، التي تديرها منصات مثل iCloud Keychain و Google Password Manager، من مشكلة فقدان جهاز واحد. ومع ذلك، فإنها لا تحل مشكلة فقدان المستخدم لجميع أجهزته أو التبديل بين الأنظمة البيئية (على سبيل المثال، من iOS إلى Android). في هذه السيناريوهات، تعد العملية الآمنة وسهلة الاستخدام للمستخدم لإثبات هويته من خلال وسائل أخرى وتسجيل مفتاح مرور على جهاز جديد شرطًا أساسيًا غير قابل للتفاوض لأي نشر واسع النطاق. كما تشير وثائق Mastercard الخاصة، سيحتاج المستخدم الذي يغير الأجهزة إلى إنشاء مفتاح مرور جديد، وهي عملية قد تتطلب التحقق من الهوية من قبل بنكه. (Mastercard® payment passkeys – Frequently asked questions) يسلط هذا الضوء على أن الحل الكامل لمفاتيح المرور يجب أن يشمل ليس فقط مراسم المصادقة نفسها ولكن أيضًا دورة حياة إدارة مفاتيح المرور بأكملها، بما في ذلك تدفقات الاسترداد القوية.

تترجم النماذج المعمارية الأربعة - المرتكز على جهة الإصدار (SPC)، المرتكز على التاجر (DA)، المرتكز على الشبكة (Click to Pay)، والمرتكز على PSP - إلى فرص تكامل متميزة للاعبين المختلفين في النظام البيئي للمدفوعات. يقدم كل نهج مجموعة فريدة من المقايضات بين تجربة المستخدم، وتعقيد التنفيذ، والمسؤولية، والتحكم. يقدم هذا القسم تحليلاً عمليًا لنقاط التكامل هذه لتوجيه عملية صنع القرار الاستراتيجي.

• الفرصة: الفرصة الأساسية لجهات الإصدار ومزودي خادم التحكم في الوصول (ACS) الذين يخدمونهم هي تحسين "تدفق التحدي" في 3DS عن طريق استبدال الطرق القديمة مثل كلمات المرور لمرة واحدة (OTPs) وكلمات المرور بـ تأكيد الدفع الآمن (SPC).
• العميل المستهدف: يستهدف هذا التكامل مزودي ACS (مثل Netcetera، CA Technologies/Arcot)، وبائعي التكنولوجيا الذين يخدمون قطاع جهات الإصدار، والبنوك المصدرة الكبيرة التي تدير منصات ACS الداخلية الخاصة بها.
• دور المزود: سيقدم مزود خدمة مفاتيح المرور مثل Corbado خادم FIDO قابل للتضمين أو وحدة برمجية متوافقة تمامًا مع مواصفات SPC. سيتم دمج هذه الوحدة في منصة ACS الأساسية، مما يسمح لـ ACS بتشغيل تدفق SPC عندما يحدد محرك المخاطر الخاص به أن التحدي ضروري.
• الإيجابيات:
  • أمان عالي وامتثال تنظيمي: يوفر استخدام SPC لـ الربط الديناميكي المشفر دليلاً قويًا وقابلاً للتدقيق على موافقة المستخدم على تفاصيل معاملة محددة، مما يعالج مباشرة المتطلبات الرئيسية للوائح مثل PSD2 SCA.
  • تجربة مستخدم محسنة مقارنة بـ OTPs: المصادقة بمسح بيومتري سريع أسرع بكثير وأقل عرضة للخطأ من إدخال رمز تم استلامه عبر الرسائل القصيرة يدويًا، مما قد يؤدي إلى زيادة قابلة للقياس في معدلات تحويل التحدي.
  • نموذج مسؤولية واضح: يتناسب هذا النموذج بسلاسة مع إطار عمل 3DS الحالي. عندما تتم مصادقة معاملة بنجاح عبر SPC، تنتقل المسؤولية عن عمليات رد المبالغ المدفوعة الاحتيالية من التاجر إلى جهة الإصدار، تمامًا كما هو الحال مع طرق تحدي 3DS الأخرى.
• السلبيات:
  • لا يزال تدفق "تحدي": بينما يحسن SPC تجربة التحدي، فإنه لا يلغيه. لا يزال المستخدم يُقاطع عند الدفع بخطوة مصادقة. هذه التجربة، على الرغم من أنها أفضل، إلا أنها أكثر احتكاكًا بطبيعتها من تدفق "سلس" سلبي تمامًا أو تدفق مصادقة مفوضة ناجح.
  • يعتمد على منطق مخاطر جهة الإصدار: يعتمد تبني وتكرار استخدام SPC بالكامل على ACS الخاص بجهة الإصدار ومحرك RBA الخاص به. لا يزال ACS يقرر ما إذا كان و متى يتم تشغيل التحدي.
  • تأخر جاهزية النظام البيئي: يتطلب الاستخدام الواسع النطاق أن يتبنى النظام البيئي إصدار EMV 3DS 2.3 أو أعلى، وأن تدعم متصفحات المستخدمين واجهة برمجة تطبيقات SPC Web API. كما نوقش، يعد نقص الدعم العالمي، خاصة على منصات الهواتف المحمولة مثل iOS، عائقًا كبيرًا.

• الفرصة: لتنفيذ المصادقة المفوضة (DA)، مما يسمح للتاجر أو مزود خدمة الدفع الخاص به بإجراء SCA عند نقطة تسجيل دخول العميل، وبالتالي إنشاء تجربة دفع سلسة تمامًا للمستخدمين العائدين والمصادق عليهم.
• العميل المستهدف: هذا هو الأكثر صلة بتجار التجارة الإلكترونية الكبار، ومقدمي خدمات الدفع المتكاملين (مثل Stripe أو Adyen)، ومقدمي المحافظ الرقمية الذين لديهم علاقة مباشرة مع المستهلك وقد استثمروا بالفعل في نظام حساب وتسجيل دخول آمن.
• دور المزود: سيقوم مزود مفاتيح المرور بتوفير حل مصادقة مفتاح المرور الأساسي لتدفق تسجيل دخول التاجر. بشكل حاسم، يجب أن يوفر الحل أيضًا مخرجات البيانات والأدلة المشفرة اللازمة التي يمكن تجميعها في طلب مصادقة 3DS للإشارة إلى جهة الإصدار بأن SCA متوافقًا قد حدث بالفعل.
• الإيجابيات:
  • تجربة مستخدم مثالية: يقدم هذا النموذج تدفق الدفع الأكثر سلاسة الممكن للمستخدمين المصادق عليهم. ينقل خطوة المصادقة إلى جزء طبيعي ومألوف من رحلة المستخدم (تسجيل الدخول إلى الحساب) ويمكن أن يلغي تحدي 3DS تمامًا، مما يتيح تجربة دفع حقيقية بنقرة واحدة.
  • أعلى إمكانات تحويل: من خلال إزالة نقطة الاحتكاك النهائية عند الدفع، لدى DA القدرة على تحقيق أهم زيادة في معدلات تحويل الدفع. أبلغت تجربة Stripe مع حاملي بطاقات Wise عن زيادة في التحويل بنسبة 7٪ للمعاملات التي تستخدم حل DA الخاص بهم.
  • يقوي علاقة التاجر بالعميل: تظل تجربة المصادقة والدفع بأكملها ضمن بيئة التاجر ذات العلامة التجارية، مما يعزز علاقته المباشرة مع العميل.
• السلبيات:
  • تعقيدات تجارية ومسؤولية: DA ليس مجرد تبديل تقني بسيط. يتطلب اتفاقيات صريحة، غالبًا ثنائية، بين جهات الإصدار والتجار/مقدمي خدمات الدفع الذين يختارون الوثوق بهم. علاوة على ذلك، يتحمل الطرف الذي يقوم بالمصادقة المفوضة المسؤولية عن الاحتيال، ويخضع الترتيب لرقابة تنظيمية صارمة كشكل من أشكال "الاستعانة بمصادر خارجية"، مما يحمل عبء امتثال كبير.
  • يعتمد على ثقة جهة الإصدار: يتوقف النموذج بأكمله على استعداد جهة الإصدار للثقة في عملية مصادقة التاجر. من المرجح أن يتم منح هذه الثقة فقط لأكبر الشركاء وأكثرهم أمانًا واستراتيجية في البداية.
  • تبني مجزأ: على عكس المعيار العالمي، سيتم تبني DA على أساس كل جهة إصدار وكل تاجر، مما يؤدي إلى مشهد مجزأ حيث لا تكون التجربة متسقة لجميع حاملي البطاقات لدى جميع التجار.

• الفرصة: لتمكين تجربة مفتاح المرور ذات العلامة التجارية للشبكة للحجم الهائل من معاملات الدفع للضيوف.
• العميل المستهدف: بوابات الدفع ومقدمو خدمات الدفع الذين يرغبون في تقديم حل دفع حديث وموحد للضيوف لقاعدة عملائهم من التجار.
• دور المزود: يمكن للمزود أن يعمل كشريك تكامل حاسم. نظرًا لأن Visa و Mastercard قد طورتا خدمات مفاتيح مرور منفصلة ومملوكة، يمكن لـ مزود مفاتيح المرور أن يقدم SDK موحدًا أو "طبقة تنسيق" تخفي تعقيدات التكامل مع واجهات برمجة التطبيقات المتميزة لكل شبكة، مما يوفر نقطة تكامل واحدة ومبسطة لـ PSP.
• الإيجابيات:
  • حل موحد للدفع للضيوف: يحل Click to Pay مع مفاتيح المرور نقطة ألم رئيسية في الصناعة: الدفع عالي الاحتكاك وعالي التخلي للضيوف. يقدم تجربة متسقة ومعروفة وموثوقة.
• تبني مدفوع بالشبكة: تضع Visa و Mastercard ثقلهما الكامل وراء هذه المبادرة، مما سيدفع التبني السريع من جهات الإصدار والتجار والمستهلكين. سيواجه مقدمو خدمات الدفع ضغطًا تنافسيًا لدعمه.
• عبء مسؤولية وأمان مبسط: تتحمل شبكة البطاقات، التي تعمل كطرف معتمد اتحادي، العبء الأساسي لبناء وتأمين بنية تحتية لمصادقة FIDO، مما يبسط وضع الأمان والمسؤولية للتاجر.
• السلبيات:
  • فقدان السيطرة والعلامة التجارية: العيب الأساسي هو أن التاجر ومزود خدمة الدفع الخاص به يتنازلان عن السيطرة على تجربة مستخدم الدفع لشبكة البطاقات. يصبح الدفع "دفع Visa" أو "دفع Mastercard"، ويتميز بعلامتهما التجارية وواجهة المستخدم الخاصة بهما.
  • احتمالية إزالة الوساطة: من خلال أن تصبح مزود الهوية المركزي للتجارة الإلكترونية، يمكن للشبكات إضعاف علاقة البيانات والعلامة التجارية المباشرة بين التاجر والعميل بمرور الوقت.
  • تنفيذ "الصندوق الأسود": الأعمال الداخلية لخادم FIDO الخاص بالشبكة، ومحركات المخاطر، ومنطق المصادقة غير شفافة للتاجر ومزود خدمة الدفع. إنهم يتكاملون مع خدمة لا يتحكمون في قواعدها أو تجربة مستخدمها.

إن الانتقال إلى مصادقة الدفع القائمة على مفاتيح المرور ليس تمرينًا نظريًا؛ بل يقوده بنشاط أكبر اللاعبين في الصناعة. توفر استراتيجياتهم وبرامجهم التجريبية وتصريحاتهم العامة رؤية واضحة للديناميكيات التنافسية والمسار المحتمل للتبني.

Become part of our Passkeys Community for updates & support.

Join

• PayPal: كعضو مؤسس في تحالف FIDO ومزود دفع رقمي أصيل، كانت PayPal واحدة من أكثر المتبنين الأوائل لمفاتيح المرور جرأة. بدأوا طرحًا عالميًا مرحليًا في أواخر عام 2022، بدءًا من الولايات المتحدة والتوسع إلى أوروبا ومناطق أخرى. يعد تطبيقهم دراسة حالة في أفضل الممارسات، حيث يستفيدون من ميزات مثل Conditional UI لإنشاء تجربة تسجيل دخول بنقرة واحدة تطالب تلقائيًا بمفتاح مرور عندما يتفاعل المستخدم مع حقل تسجيل الدخول. أبلغت PayPal عن نجاح مبكر كبير، بما في ذلك زيادة معدلات نجاح تسجيل الدخول وانخفاض كبير في الاحتيال في الاستيلاء على الحسابات (ATO). تشمل استراتيجيتهم أيضًا الدعوة بنشاط للتطور التنظيمي في أوروبا، والدفع من أجل نهج قائم على النتائج لـ SCA يعترف بالأمان المتأصل في مفاتيح المرور المتزامنة.

• Visa: تتركز استراتيجية Visa على خدمة مفاتيح المرور للدفع من Visa، وهي منصة شاملة مبنية على بنية تحتية لخادم FIDO خاصة بها. تم تصميم هذه الخدمة كنموذج اتحادي، حيث تتعامل Visa مع تعقيد المصادقة نيابة عن شركائها المصدرين. الأداة الأساسية لهذه الخدمة هي Click to Pay، مما يضع Visa في موقع للسيطرة على تجربة الدفع للضيوف. تمتد رسائل Visa إلى ما هو أبعد من المدفوعات البسيطة، حيث تضع خدمة مفاتيح المرور الخاصة بها كعنصر أساسي لحل هوية رقمية أوسع يمكن استخدامه عبر النظام البيئي للتجارة. إنهم يختبرون التكنولوجيا بنشاط، بما في ذلك SPC، ويبلغون أن المصادقة البيومترية يمكن أن تخفض معدلات الاحتيال بنسبة 50٪ مقارنة بـ OTPs عبر الرسائل القصيرة.

• Mastercard: عكست Mastercard التركيز الاستراتيجي لـ Visa على خدمة على مستوى الشبكة، حيث أطلقت خدمة مفاتيح المرور للدفع الخاصة بها المبنية على خدمة مصادقة الرمز المميز (TAS) الحالية. تميزت استراتيجيتها للوصول إلى السوق بسلسلة من التجارب العالمية البارزة. في أغسطس 2024، أعلنوا عن تجربة كبرى في الهند، بالشراكة مع أكبر مجمعي الدفع في البلاد (Juspay، Razorpay، PayU)، وتاجر كبير عبر الإنترنت (bigbasket)، وبنك رائد (Axis Bank). تبع ذلك إطلاقات في أسواق رئيسية أخرى، بما في ذلك أمريكا اللاتينية مع الشركاء Sympla و Yuno و الإمارات العربية المتحدة مع Tap Payments. يكشف هذا النهج عن استراتيجية واضحة: الشراكة مع مجمعي النظام البيئي (PSPs، البوابات) لتحقيق النطاق بسرعة. قدمت Mastercard التزامًا عامًا جريئًا بالتخلص التدريجي من إدخال البطاقة اليدوي في أوروبا بحلول عام 2030، والانتقال بالكامل إلى المعاملات المرمزة والمصادق عليها بمفاتيح المرور.

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

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

• الزوال الحتمي لـ OTPs: تشير الدفعة على مستوى الصناعة لمفاتيح المرور إلى بداية نهاية كلمات المرور لمرة واحدة المستندة إلى الرسائل القصيرة كطريقة مصادقة أساسية. يُنظر إلى OTPs بشكل متزايد على أنها مسؤولية بسبب تجربة المستخدم عالية الاحتكاك وضعفها المتزايد للهجمات مثل تبديل بطاقة SIM وحملات التصيد الاحتيالي المتطورة. مع انتشار مفاتيح المرور، سيتم relegated الاعتماد على OTPs إلى آلية احتياطية أو استرداد، بدلاً من طريقة تحدي أساسية.

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

• صعود هوية الدفع الموحدة: إن التحركات الاستراتيجية من قبل Visa و Mastercard هي أكثر من مجرد تأمين المدفوعات؛ إنها تتعلق بإنشاء نموذج جديد للهوية الرقمية. من خلال بناء خدمات مفاتيح مرور موحدة، فإنهم يضعون أنفسهم كمزودي هوية مركزيين وموثوقين للنظام البيئي للتجارة الرقمية بأكمله. يمكن اعتبار هذا استجابة استراتيجية مباشرة لمنصات الهوية القوية التي تسيطر عليها شركات التكنولوجيا الكبرى (مثل Apple ID، حساب Google). يرتبط مستقبل المدفوعات عبر الإنترنت ارتباطًا وثيقًا بهذه المعركة الأكبر حول من سيملك ويدير هوية المستهلك على الويب.

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

• توفير المحفظة الرقمية: غالبًا ما تتطلب عملية إضافة بطاقة ائتمان أو خصم مباشر إلى محفظة رقمية مثل Apple Pay أو Google Pay خطوة تحقق، مثل OTP عبر الرسائل القصيرة يتم إرسالها من قبل جهة الإصدار. هذه نقطة احتكاك يمكن استبدالها بتدفق مفتاح مرور.
• الخدمات المصرفية المفتوحة وربط الحسابات: أساس الخدمات المصرفية المفتوحة هو السماح لتطبيقات الطرف الثالث (مثل تطبيقات الميزانية أو خدمات التكنولوجيا المالية الأخرى) بالوصول إلى بيانات حساب المستخدم البنكي. يتطلب هذا من المستخدم المصادقة مع بنكه، وهي عملية غالبًا ما تكون مرهقة. توفر مفاتيح المرور طريقة أكثر سلاسة وأمانًا لمنح هذه الموافقة، واستبدال عمليات إعادة التوجيه المحرجة وإدخال كلمة المرور اليدوي بـ مصادقة بيومترية بسيطة.
• تأمين الرموز المميزة للبطاقة المحفوظة (CoF): بالإضافة إلى تأمين تسجيل الدخول لحساب ببطاقة محفوظة، يمكن استخدام مفاتيح المرور لتأمين الفعل الأولي لـ حفظ البطاقة. يوفر التحدي في اللحظة التي يضيف فيها المستخدم بطاقته دليلاً قويًا على وجود حامل البطاقة الشرعي، مما يقلل من الاحتيال الناتج عن استخدام أرقام بطاقات الائتمان المسروقة لإنشاء ملفات تعريف CoF لإساءة استخدامها لاحقًا.
• اشتر الآن وادفع لاحقًا (BNPL) والإقراض الفوري: تتضمن خدمات اشتر الآن وادفع لاحقًا وأشكال أخرى من الائتمان الفوري كلاً من الإعداد الأولي وتقييمات المخاطر لكل معاملة. تُستخدم مفاتيح المرور بالفعل من قبل رواد مثل Klarna لاستبدال كلمات المرور لتسجيل الدخول. يمكن استخدامها أيضًا كطريقة مصادقة تصعيدية للمشتريات عالية القيمة أو عندما يتقدم المستخدم بطلب للحصول على خط ائتمان جديد، مما يوفر إشارة أقوى وأقل احتكاكًا لنوايا المستخدم من الطرق التقليدية.

يمثل صعود العملات المستقرة (مثل USDC أو EURC) مسار دفع جديد قائم على البلوك تشين. ومع ذلك، كان العائق الرئيسي أمام التبني السائد هو تجربة المستخدم السيئة وأمان محافظ العملات المشفرة. تقليديًا، يتم تأمين هذه المحافظ بـ "عبارة أولية" (قائمة من 12-24 كلمة) يجب على المستخدم كتابتها وحمايتها. هذا غير سهل الاستخدام بشكل لا يصدق ويجعل استرداد الحساب كابوسًا.

من المقرر أن تغير مفاتيح المرور هذه التجربة تمامًا. تتجه الصناعة نحو نموذج يتم فيه تأمين المفتاح الخاص الذي يتحكم في الأصول على السلسلة بواسطة مفتاح مرور الجهاز.

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

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

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

• الهدف: تحديث تدفق تحدي 3DS، واستبدال OTPs عالية الاحتكاك لزيادة معدلات التحويل، وتعزيز الأمان، والامتثال لـ PSD2/PSD3 بشكل مباشر.
• كيف يساعد Corbado: نحن نقدم وحدة مصادقة بمفاتيح المرور قابلة للتضمين مصممة للتكامل المباشر في منصات خادم التحكم في الوصول (ACS) الحالية. نحن نساعد بائعي ACS على تقديم تجربة تحدي هي الأفضل في فئتها ومنخفضة الاحتكاك تفيد شبكتهم الكاملة من البنوك والتجار.

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

• الهدف: تقديم أحدث الميزات التي تفرضها الشبكة بسهولة مثل Click to Pay والحفاظ على قدرة المنصات على المنافسة دون جهود تطوير مكلفة ومكررة.
• كيف يساعد Corbado: يقدم Corbado طبقة "تنسيق مفاتيح المرور". نحن نساعد في تكامل خدمات كل من Visa و Mastercard ونوفر أيضًا طرقًا يمكن للتجار من خلالها تقديم حل مفتاح المرور الخاص بهم في نفس الوقت لتقديم تجربة دفع حديثة للضيوف.

• الهدف: تأمين النظام البيئي للمحفظة بأكمله، وإنشاء تجربة تسجيل دخول ودفع سلسة وآمنة قابلة للنقل عبر شبكة تجار PSP بأكملها.
• كيف يساعد Corbado: نحن نوفر البنية التحتية الأساسية لمفاتيح المرور التي تسمح لمقدمي خدمات الدفع الكبار ومقدمي المحافظ بأن يصبحوا الطرف المعتمد المركزي لمستخدميهم. من خلال دمج حلنا، يمكنهم استبدال كلمات المرور لتسجيلات الدخول إلى محافظهم (على سبيل المثال، لـ PayPal، Stripe Link، أو Klarna). هذا لا يؤمن الحساب ضد الاستيلاء فحسب، بل يبسط أيضًا تفويض الدفع إلى خطوة بيومترية بنقرة واحدة، مما يخلق تجربة مصادقة قوية وذات علامة تجارية تجذب المستخدمين وتجذب التجار.

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

• المشكلة الأساسية: يؤدي الاحتكاك العالي في تدفق تحدي 3DS إلى التخلي عن عربات التسوق وفقدان الإيرادات للتجار، مما يجعل بطاقة جهة الإصدار أقل قدرة على المنافسة.
• كيف يساعد التبني: يترجم التبني الأعلى لمفاتيح المرور مباشرة إلى تحديات أكثر نجاحًا ومنخفضة الاحتكاك. هذا يحسن معدلات التحويل، ويعزز الأمان، ويجعل بيانات اعتماد الدفع الخاصة بجهة الإصدار أكثر قيمة لكل من التجار والمستهلكين.
• المرشحون الرئيسيون: البنوك المصدرة الكبرى (Bank of America, Chase, Barclays)، ومزودو ACS الذين يزودون تقنية 3DS الخاصة بهم (Netcetera, CA Technologies).

• المشكلة الأساسية: غالبًا ما يتم إعاقة الرغبة في امتلاك رحلة العميل وإزالة احتكاك الدفع بسبب الحاجة إلى تحدي 3DS.
• كيف يساعد التبني: يعتمد نموذج المصادقة المفوضة (DA) بأكمله على قدرة التاجر على مصادقة المستخدم بقوة عند تسجيل الدخول. إن تبني مفاتيح المرور العالي ليس مجرد تحسين ولكنه شرط أساسي لاستراتيجية DA ناجحة. يعد تمكين DA لغالبية المستخدمين ميزة تنافسية قوية.
• المرشحون الرئيسيون: قادة التجارة الإلكترونية العالميون (Amazon, Walmart)، وخدمات الاشتراك الرقمي (Netflix, Spotify)، ومقدمو خدمات الدفع المتكاملون الذين يخدمونهم (Stripe, Adyen, Checkout.com).

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

• المشكلة الأساسية: ترتبط قيمة المحفظة (مثل PayPal، Stripe Link، Klarna) ارتباطًا مباشرًا بعدد المستخدمين النشطين والمتفاعلين. الاحتكاك عند تسجيل الدخول أو الدفع يضعف النظام البيئي.
• كيف يساعد التبني: يعد دفع التبني الجماعي لمفاتيح المرور لنطاق المحفظة الخاص (paypal.com، إلخ) هدفًا استراتيجيًا أساسيًا. إنه يقلل من الاحتيال، ويحسن تجربة المستخدم، ويقوي تأثير الشبكة، مما يجعل المحفظة أكثر جاذبية لكل من المستهلكين والتجار.
• المرشحون الرئيسيون: مقدمو خدمات الدفع العالميون الذين لديهم عروض محافظ (PayPal, Stripe Link, Klarna)، واللاعبون الإقليميون الكبار (Mercado Pago, Block).

• المشكلة الأساسية: تواجه خطط الدفع الوطنية ضغوطًا لتحديث بنيتها التحتية وتوفير حلول هوية رقمية لتظل قادرة على المنافسة ضد شركات التكنولوجيا العالمية.
• كيف يساعد التبني: يجب على هذه الشبكات ضمان أن خدمات الدفع والهوية الرقمية الجديدة الخاصة بها تشهد استخدامًا واسع النطاق. بالنسبة للاعب مثل Australian Payments Plus (AP+)، يعد دفع التبني لخدمات مثل PayTo (للمدفوعات في الوقت الفعلي) و ConnectID (للهوية الرقمية) هدفًا استراتيجيًا أساسيًا. إن الحل الذي يعزز تسجيل مفاتيح المرور هو عامل تمكين مباشر لهذه الاستراتيجية.
• المرشحون الرئيسيون: Australian Payments Plus (AP+) وهيئات البنية التحتية للدفع الوطنية الأخرى.

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

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

• الموقع في النظام البيئي: تعمل كـ "حاوية" آمنة لبطاقات المستخدم. عندما يدفع المستخدم عبر الإنترنت، بدلاً من إدخال تفاصيل بطاقته، يختار Apple Pay أو Google Pay. ثم تمرر المحفظة رمزًا آمنًا للاستخدام مرة واحدة إلى بوابة الدفع الخاصة بالتاجر. لا تزال المعاملة تتدفق عبر البنك القابل والشبكة وجهة الإصدار كالمعتاد.
• كيف يستفيدون من مفاتيح المرور: يقومون بمصادقة المستخدم باستخدام مسح الوجه أو بصمة الإصبع للمحفظة، مما يسمح لها بإصدار رمز الدفع. هذا حدث مصادقة قوي ومنخفض الاحتكاك، ولكنه متميز عن مصادقة 3DS/SCA التي تكون جهة إصدار البطاقة مسؤولة عنها. لا يزال بإمكان جهة الإصدار تقنيًا تشغيل تحدي 3DS على معاملة تم بدؤها عبر Apple Pay، على الرغم من أن المصادقة القوية على مستوى الجهاز تجعل هذا أقل احتمالًا.
• الفرص وكيف يستفيدون من التبني:
  • تبسيط توفير المحفظة: غالبًا ما تتطلب عملية إضافة بطاقة إلى محفظة OTP من جهة الإصدار. هذه نقطة احتكاك رئيسية. يمكن لـ Apple و Google العمل مع جهات الإصدار لاستبدال هذا بتدفق مفتاح مرور داخل التطبيق، باستخدام مفتاح مرور للتحقق من المستخدم على الفور. إن حل التبني لشركائهم المصدرين سيجعل محافظهم أسهل في التحميل والاستخدام.
  • أن تصبح سلطة مفوضة: هدفهم الاستراتيجي النهائي هو الاستفادة من مصادقة منصتهم القوية ليصبحوا المصادق النهائي والموثوق للمدفوعات. إذا اعترفت جهات الإصدار رسميًا بمصادقة Apple Pay أو Google Pay على أنها تفي بمتطلبات SCA، فيمكن أن تصبح سلطات مفوضة، مما يلغي تحدي 3DS تمامًا. يعد التبني العالي لمفاتيح مرور منصتهم الخاصة أمرًا بالغ الأهمية لجعل هذا عرضًا مقنعًا لجهات الإصدار.

تعمل Amazon Pay و Meta Pay بشكل أشبه بتاجر تقليدي لديه محفظة كبيرة جدًا من البطاقات المحفوظة (CoF) يمكن استخدامها على مواقع الطرف الثالث وداخل أنظمتها البيئية الخاصة (على سبيل المثال، للتجارة الاجتماعية على Instagram).

• الموقع في النظام البيئي: إنها مثال كلاسيكي لنموذج المرتكز على التاجر. يقوم المستخدمون بتخزين بطاقات الدفع الخاصة بهم مباشرة في حساب Amazon أو Meta الخاص بهم. عندما يستخدمون Amazon Pay أو Meta Pay للدفع، فإنهم يقومون بالمصادقة على حسابهم الرئيسي، وتقوم تلك المنصة بمعالجة الدفع نيابة عنهم.
• كيف يستفيدون من مفاتيح المرور: استخدامهم الأساسي لمفاتيح المرور هو تأمين تسجيل الدخول إلى حساب المستخدم الرئيسي (على سبيل المثال، مفتاح المرور لـ Amazon.com). من خلال نقل قواعد المستخدمين الضخمة من كلمات المرور إلى مفاتيح المرور لتسجيل الدخول إلى الحساب، فإنهم يقللون بشكل كبير من مخاطر الاحتيال في الاستيلاء على الحسابات ويحمون بيانات اعتماد الدفع المخزنة القيمة.
• الفرص وكيف يستفيدون من التبني: فائدتهم مباشرة وفورية. إن الحل الذي يدفع تبني مفاتيح المرور لحسابات المستخدمين الأساسية الخاصة بهم:
  1. يقلل من الاحتيال: يقلل بشكل كبير من سطح الهجوم للاستيلاء على الحسابات، وهو مصدر رئيسي للخسارة المالية وعدم رضا العملاء.
  2. يقلل من الاحتكاك: يخلق تجربة تسجيل دخول ودفع سلسة وآمنة، والتي ثبت أنها تزيد من معدلات التحويل. بالنسبة لهؤلاء اللاعبين، يعد الحل الذي يعزز تبني مفاتيح المرور استثمارًا مباشرًا في أمان وأداء أعمالهم التجارية الأساسية. لذلك فهم مرشحون رئيسيون لمثل هذا الحل.

تقف صناعة المدفوعات على أعتاب حقبة جديدة من المصادقة. يتم أخيرًا حل التسوية طويلة الأمد بين الأمان والراحة من خلال نضج واعتماد تقنية مفاتيح المرور. يوضح التحليل المقدم في هذا التقرير أن هذا ليس تحولًا متجانسًا ولكنه انتقال معقد مع رؤى متنافسة متعددة للمستقبل. تسعى جهات الإصدار إلى تعزيز إطار عمل 3DS الحالي باستخدام SPC؛ ويهدف التجار الكبار ومقدمو خدمات الدفع إلى السيطرة على التجربة من خلال المصادقة المفوضة أو عن طريق بناء أنظمة محافظهم البيئية الخاصة؛ وتقوم شبكات البطاقات بإنشاء طبقة هوية موحدة جديدة باستخدام Click to Pay. يتنافس كل نموذج ليصبح المعيار الجديد لثقة المستخدم والراحة.