مفاتيح المرور لمزودي الدفع: كيف تبني حزمة تطوير برمجيات (SDK) لجهة خارجية

تبرز مفاتيح المرور (Passkeys) كأكثر الطرق فعالية لتأمين وتفويض المعاملات عبر الإنترنت، حيث تحسن بشكل كبير من الأمان والراحة مقارنة بـ المصادقة متعددة العوامل (MFA) التقليدية. مؤخراً، اعتمدت PayPal مفاتيح المرور كحلها الأساسي المستقل للمصادقة متعددة العوامل، مما يضع اتجاهاً واضحاً لمزودي الدفع في جميع أنحاء العالم.

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

1. ما هي القيود الحالية لاستخدام مفاتيح المرور ضمن سياقات الطرف الثالث لمزودي الدفع؟ 2. كيف يمكن لمزودي الدفع التغلب على هذه القيود لتنفيذ تكاملات مفاتيح المرور للطرف الثالث بنجاح؟

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

تجلب مفاتيح المرور (Passkeys) تسجيلاً للدخول مقاوماً للتصيد الاحتيالي وقائماً على المقاييس الحيوية إلى كل طبقة من طبقات الدفع. فيما يلي تفصيل لكيفية استفادة كل لاعب في سلسلة قيمة الدفع من دمج مصادقة Passkey.

التأثير: إتمام أسرع لعمليات الدفع، معدل تحويل أعلى، عدد أقل من عربات التسوق المهجورة. الفرصة: يمكن للتجار الذين يقدمون مفاتيح المرور عبر حزم SDK أو تدفقات إعادة التوجيه محاكاة تجربة مستخدم على مستوى Apple Pay وتقليل الاعتماد على كلمات المرور أو رموز OTP - مما يؤدي إلى زيادة الثقة والمبيعات.

التأثير: مصادقة سلسة وبدون كلمة مرور عبر الأجهزة. الفرصة: توفر مفاتيح المرور تجربة مستخدم أفضل من رموز OTP أو رسائل SMS وتقضي على مخاطر التصيد الاحتيالي. يمكن أن يؤدي التبني الواسع إلى تحويل مفاتيح المرور إلى المعيار الجديد للتحقق من حامل البطاقة.

التأثير: منع أقوى للاحتيال. الفرصة: يمكن للمُصدرين تقديم مصادقة معززة قائمة على مفاتيح المرور في تدفقات 3DS، مما يقلل من تكاليف OTP ويحسن رضا المستخدمين.

التأثير: قبول أعلى للمعاملات وعدد أقل من المصادقات الفاشلة. الفرصة: يمكن أن يؤدي دعم مفاتيح المرور من خلال مزودي خدمات الدفع (PSPs) إلى تحسين نتائج التاجر وتقليل الاحتكاك أثناء الدفع أو تدفقات الفوترة المتكررة.

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

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

التأثير: تخزين آمن لبيانات الاعتماد وإعادة مصادقة سلسة. الفرصة: تستخدم محافظ مثل Apple Pay و Google Pay بالفعل تدفقات شبيهة بمفاتيح المرور.

فيما يلي، نلقي نظرة سريعة على كبار مزودي الدفع وبطاقات الائتمان ونحلل ما إذا كانوا قد طبقوا مفاتيح المرور وكيف فعلوا ذلك:

أطلقت Mastercard رسمياً خدمة Payment Passkey، التي توفر تجربة مصادقة بدون كلمة مرور مدمجة في تدفقات EMV 3DS. يمكن للمستخدمين إنشاء واستخدام مفاتيح مرور مرتبطة بنطاق مصادقة Mastercard (مثل verify.mastercard.com)، مما يتيح تسجيل دخول آمن بالمقاييس الحيوية عبر التجار المشاركين. يمثل هذا الإطلاق خطوة كبيرة نحو مصادقة مقاومة للتصيد الاحتيالي ومتوافقة مع PSD2 في صناعة الدفع. اقرأ المزيد: Mastercard Passkeys

قدمت Visa خدمة Visa Payment Passkey، حيث دمجت مفاتيح المرور في تدفق "Click to Pay". من خلال السماح للمستخدمين بالمصادقة بسلاسة باستخدام المقاييس الحيوية بدلاً من كلمات المرور أو رموز OTP، تهدف Visa إلى تحديث تجربة الدفع عبر الإنترنت بأمان معزز وراحة للمستخدم. اقرأ المزيد: VISA Passkeys

لم تطلق American Express عرضاً لمفاتيح المرور بشكل علني بعد. ومع ذلك، كعضو على مستوى مجلس الإدارة في FIDO Alliance، من المرجح أن تطرح American Express حلاً للمصادقة قائماً على مفاتيح المرور في المستقبل القريب، تماشياً مع الاتجاهات الأوسع في الصناعة.

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

لم تقدم Klarna دعماً رسمياً لمفاتيح المرور بعد. من ملاحظاتنا، تعتمد Klarna بشكل كبير على عروض الويب المدمجة (WebViews) في تطبيقها وحزم SDK للدفع. نظراً لأن Safari و iOS يقيدان إنشاء مفاتيح المرور في iframes / WebViews، فقد يكون هذا سبباً لعدم طرح Klarna لمفاتيح المرور حتى الآن.

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

طرحت Stripe تسجيل الدخول بمفاتيح المرور للوحة التحكم الخاصة بها، مما يمكّن المطورين من المصادقة باستخدام المقاييس الحيوية. مفاتيح المرور لـ Stripe Checkout أو Elements غير متاحة بعد. نظراً لدفاع Stripe القوي عن التدفقات القائمة على إعادة التوجيه، فمن المرجح أن تتبع مفاتيح المرور - إذا تم تنفيذها في المدفوعات - نفس بنية إعادة التوجيه.

حتى الآن، لم تصدر BILL أي إعلانات عامة أو تحديثات للمنتج تتعلق بمفاتيح المرور للمصادقة.

لم تكشف Remitly عن أي خطط أو معلومات عامة حول تنفيذ مصادقة Passkey في خدماتها.

لا توجد تقارير عامة أو وثائق منتج تشير إلى أن Payoneer قد تبنت أو تختبر تسجيل الدخول أو تدفقات المعاملات القائمة على مفاتيح المرور.

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

لم تعلن Worldpay عن أي دعم لمفاتيح المرور حتى الآن. لا تزال مجموعة المصادقة الخاصة بها تعتمد على الطرق التقليدية مثل كلمات المرور ورموز OTP والتدفقات القائمة على 3DS.

لم تطرح Checkout.com دعماً لمفاتيح المرور بشكل علني. لا توجد تحديثات للمطورين أو منشورات مدونة أو إعلانات رسمية بخصوص تبني مفاتيح المرور.

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

لم تصدر Mollie أي بيانات عامة أو تحديثات للمنتج بخصوص تبني مفاتيح المرور في أنظمة المصادقة أو الدفع الخاصة بها.

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

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

Link، حل الدفع بنقرة واحدة من Stripe، قد طرحت مفاتيح المرور التي قد تكون بمثابة الأساس لاستراتيجية Passkey الخاصة بـ Stripe في مدفوعات المستهلكين. ومع ذلك، لم تعلن Stripe رسمياً عن دعم مفاتيح المرور لـ Link أو أي خطط محددة للطرح.

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

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

• تأكيد الدفع الآمن (SPC)
• إنشاء مفاتيح المرور للطرف الثالث في Iframes

يمثل تأكيد الدفع الآمن (SPC) أهم جهد في الصناعة - مدفوع بشكل أساسي من قبل Google - لتمكين الاستخدام السلس لمفاتيح المرور متعددة المصادر المصممة خصيصاً لتفويضات الدفع الآمنة. يوحد SPC كيفية مصادقة مزودي الدفع للمستخدمين عبر مواقع تجار متعددة دون المساس بالأمان أو تجربة المستخدم. ومع ذلك، امتنعت Apple باستمرار عن دعم SPC داخل Safari، ومن المرجح أن يكون ذلك خطوة استراتيجية لضمان بقاء Apple Pay حل الدفع المفضل والأكثر سلاسة داخل نظامها البيئي. لا يحد رفض Apple لتبني SPC من النشر الواسع لمفاتيح المرور في سياقات الطرف الثالث فحسب، بل يؤخر أيضاً بشكل فعال التبني الأوسع في الصناعة لمصادقة الدفع الموحدة.

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

هناك حاجز حاسم آخر يتمثل في تقييد Apple المتعمد لإنشاء مفاتيح المرور داخل iframes متعددة المصادر. بينما يسمح Safari باستخدام مفاتيح المرور الحالية للمصادقة (navigator.credentials.get()) في iframe لطرف ثالث، فإنه يمنع صراحة تسجيل مفتاح المرور (navigator.credentials.create()) في مثل هذه السياقات.

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

في هذا النهج، يقوم التاجر بتضمين نموذج الدفع الخاص بك في <iframe> يتم تقديمه من نطاق مزود الدفع الخاص بك - على سبيل المثال، https://pay.provider.com. يبقى المستخدم على نطاق التاجر (مثل https://www.mystore.com)، ويرى واجهة الدفع الخاصة بك في iframe المدمج ويصادق باستخدام مفتاح مرور مرتبط بمعرف الطرف المعتمد pay.provider.com.

نقاط رئيسية:

• متعدد المصادر: لأن iframe موجود على نطاق مختلف، يجب عليك تكوين سياسات الأذونات لـ publickey-credentials-get و publickey-credentials-create للسماح بعمليات مفاتيح المرور داخل iframe.

• قيود الإنشاء: بعض المتصفحات (خاصة الإصدارات القديمة و Safari) لا تزال لا تسمح بإنشاء مفاتيح المرور في iframes متعددة المصادر. المصادقة (navigator.credentials.get()) مدعومة على نطاق أوسع، لكن التسجيل (navigator.credentials.create()) قد يفشل في بيئات معينة، خاصة في Safari.

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

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

مع تدفق قائم على إعادة التوجيه، ترسل المستخدم من نطاق التاجر إلى نطاق الدفع الخاص بك، أو تفتح علامة تبويب/نافذة جديدة تشير إلى شيء مثل https://pay.provider.com/checkout. يتم بعد ذلك إنشاء مفاتيح المرور أو استخدامها مباشرة على نطاقك في سياق الطرف الأول.

نقاط رئيسية:

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

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

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

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

ترتبط مفاتيح المرور بطبيعتها بنطاق معين (معرف "الطرف المعتمد")، وهو مبدأ أمان أساسي يضمن عدم إساءة استخدام بيانات الاعتماد عبر مواقع الويب أو التطبيقات غير ذات الصلة. عندما يقوم مزود الدفع بإنشاء مفاتيح مرور تحت نطاقه الخاص - على سبيل المثال، pay.provider.com - يتم تحديد نطاق مفاتيح المرور هذه بشكل صارم لهذا النطاق في كل من iOS و Android. نتيجة لذلك، لا يمكن لتطبيق التاجر الأصلي (الذي يعمل بشكل طبيعي تحت معرف التطبيق والنطاق الخاص بالتاجر) استدعاء مفاتيح مرور المزود مباشرة كبيانات اعتماد "للطرف الأول". يتطلب القيام بذلك مشاركة المفاتيح الخاصة عبر المصادر، وهو ما تمنعه أنظمة التشغيل ومواصفات WebAuthn صراحة لمنع التصيد الاحتيالي وسرقة بيانات الاعتماد.

من منظور الجهاز، يعد تطبيق التاجر الأصلي "مصدرًا" مختلفًا عن نطاق مزود الدفع. إن محاولة المصادقة محليًا مقابل بيانات الاعتماد المسجلة لمصدر منفصل من شأنها أن تكسر نموذج الأمان الأساسي المرتبط بالمصدر لمفاتيح المرور. هذا هو السبب الدقيق الذي يجعل استخدام مفاتيح المرور للطرف الثالث في سياق التاجر يعتمد على متصفح النظام أو WebView قائم على النظام (مثل ASWebAuthenticationSession على iOS أو Chrome Custom Tabs على Android). تحافظ هذه التدفقات الخاصة على سياق نطاق المزود الأصلي - مما يضمن بقاء مفاتيح المرور مرتبطة بالمصدر بشكل آمن - مع السماح للمستخدمين بالمصادقة مع مزود الدفع داخل تطبيق التاجر. في الأقسام التالية، سنستكشف كيف يعمل هذا.

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

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

• قيود أمان المنصة: قامت كل من Apple (iOS) و Google (Android) بتقييد قدرات WebViews المدمجة للمصادقة بشكل تدريجي، خاصة عند التعامل مع بيانات الاعتماد الآمنة. تم تصميم هذه القيود لحماية خصوصية المستخدم وأمانه ولكنها تجعل تنفيذ مفاتيح المرور للطرف الثالث أكثر تعقيداً بشكل ملحوظ.

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

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

iOS (ASWebAuthenticationSession):

توفر Apple ASWebAuthenticationSession كبيئة آمنة تشبه المتصفح خارج سياق التطبيق المضيف. تشارك تخزين ملفات تعريف الارتباط مع متصفح Safari الافتراضي وتدعم مفاتيح المرور للطرف الثالث بشكل موثوق لأن بيانات الاعتماد تتوافق مع نطاق أصل مزود الدفع.

يوضح المثال التالي وظيفة "الدفع باستخدام PayPal" داخل تطبيق BOSS الأصلي. يوضح كيف يتم فتح System WebView من نوع ASWebAuthenticationSession، والذي يشارك حالته مع ملفات تعريف الارتباط في Safari، مما يسمح ببدء حوار مفتاح المرور على الفور.

Android (Chrome Custom Tabs):

بالمثل، توفر Custom Tabs في Android بيئة قريبة من المتصفح تسمح بإنشاء ومصادقة مفاتيح المرور بشكل متسق. مثل ASWebAuthenticationSession، تعمل Custom Tabs بشكل منفصل عن سياق تطبيق التاجر، مما يضمن سلامة النطاق وبيانات الاعتماد.

شاهد نفس المثال من تطبيق BOSS الأصلي على Android هنا:

نهج آخر يتضمن إعادة توجيه المستخدمين من التطبيق الأصلي إلى متصفح الويب الافتراضي للجهاز المحمول (Safari على iOS، Chrome على Android). يضمن هذا أن تدفق الدفع - وبالتالي إدارة مفاتيح المرور - يحدث بالكامل في سياق طرف أول موثوق به مرتبط بنطاق مزود الدفع. يعود المستخدمون بعد ذلك إلى تطبيق التاجر بعد إتمام المصادقة أو الدفع بنجاح. هذا الخيار غير مريح للغاية للعملاء لأنهم يضطرون إلى مغادرة التطبيق.

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

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

يتضمن الاختيار بين نهج مدمج (iframe) ونهج قائم على إعادة التوجيه لدمج مفاتيح المرور للطرف الثالث في حزم SDK للدفع تقييم المقايضات عبر تجربة المستخدم وتوافق المتصفح والتعقيد الفني وتفضيلات التاجر.

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

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

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

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

يتضمن تنفيذ حزمة SDK لمدفوعات Passkeys للطرف الثالث الموازنة بين تجربة المستخدم وتوافق المتصفح وقيود التطبيقات الأصلية والتحليلات والأمان - خاصة بالنظر إلى العقبات الخاصة بـ Apple (مثل حظر إنشاء مفاتيح المرور متعددة المصادر، وغياب دعم SPC). فيما يلي توصيات رئيسية لضمان أفضل نتيجة ممكنة عند دمج مفاتيح المرور في تدفقات الدفع على الويب أو التطبيقات الأصلية.

بسبب دعم المتصفح المتغير وسلوكيات Apple غير المتسقة، يعد دعم كل من النهج المدمج (القائم على iframe) ونهج إعادة التوجيه أمراً بالغ الأهمية:

• الدفع عبر Iframe (مدمج)

  • يوفر تجربة سلسة على الصفحة للمتصفحات الحديثة التي تسمح بعمليات مفاتيح المرور متعددة المصادر (بشكل أساسي للمصادقة).

  • يجب تعيين Permissions-Policy الصحيحة لـ publickey-credentials-get/publickey-credentials-create.

  • لاحظ أن Safari وبعض المتصفحات القديمة تمنع إنشاء مفاتيح المرور متعددة المصادر في iframes.

• تدفق إعادة التوجيه

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

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

  • حل بديل مثالي لـ Safari، الذي لا يسمح حالياً بإنشاء مفاتيح المرور للطرف الثالث في iframes.

من خلال تقديم كلا النهجين، يمكنك أن تقرر ديناميكياً - أو تدع التجار يقررون - أيهما تستخدم، مما يزيد من التوافق لجميع بيئات المستخدم.

لا يزال اكتشاف قدرات المتصفح بدقة يمثل تحدياً بسبب انخفاض تفاصيل User-Agent والدعم غير المتسق لـ Client Hints عبر المنصات.

أصبح التحليل التقليدي غير موثوق به بشكل متزايد حيث تقلل المتصفحات من التفاصيل في سلاسل User-Agent لحماية خصوصية المستخدم. أصبح التمييز بين التفاصيل الأساسية - مثل Windows 10 مقابل Windows 11، وإصدارات macOS الدقيقة، أو معماريات وحدة المعالجة المركزية - صعباً أو مستحيلاً الآن باستخدام User-Agent وحده.

بينما توفر Client Hints بيانات عالية الإنتروبيا بطريقة تحترم الخصوصية، فإن المتصفحات القائمة على Chromium فقط هي التي تدعمها بالكامل. لا يقدم Safari و Firefox أي دعم لـ Client Hint، مما يقيد بشدة اكتشاف الميزات الدقيقة على أجهزة Apple.

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

بالنظر إلى هذه القيود، يتطلب اكتشاف دعم مفاتيح المرور متعددة المصادر بشكل موثوق - خاصة في حزم SDK للدفع للطرف الثالث - مزيجاً دقيقاً من استعلامات Client Hint الديناميكية (حيثما كانت متاحة)، واستدلالات User-Agent البديلة، وسلوكيات افتراضية محافظة للمتصفحات مثل Safari و Firefox.

غالباً ما تقوم تطبيقات التجار الأصلية بتضمين محتوى الويب في WKWebView (iOS) أو Android WebView، وهي مقيدة جداً لمفاتيح المرور. تشمل الاستراتيجيات الشائعة ما يلي:

• جلسات متصفح النظام: استخدم ASWebAuthenticationSession (iOS) أو Custom Tabs (Android) لنقل إنشاء/تسجيل الدخول بمفتاح المرور إلى سياق متصفح "طرف أول" آمن.

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

كمزود دفع، يعد الأمان القوي والامتثال التنظيمي (PCI، PSD2 SCA، إلخ) أمراً أساسياً:

• الترويسات وأمان المحتوى: نفذ ترويسات Permissions-Policy صارمة وقواعد CSP قوية للتدفقات متعددة المصادر.

• التسجيل والمراقبة: سجل أحداث إنشاء واستخدام مفاتيح المرور بدقة لمنع الاحتيال وتدقيقات الامتثال.

• الحد الأدنى من تخزين PII: اربط المستخدمين بمفاتيح المرور باستخدام معرفات مجزأة، مما يقلل من التعرض بموجب GDPR أو قوانين حماية البيانات المماثلة.

• مسارات التدقيق: سجل كل حدث إنشاء ومصادقة لمفتاح المرور لاكتشاف الحالات الشاذة وتلبية تدقيقات الامتثال.

لا تزال مفاتيح المرور تتطور، لذلك ستحتاج إلى فحوصات مستمرة:

• الاختبار عبر المتصفحات وأنظمة التشغيل: أتمتة الاختبارات في Safari و Chrome و Edge و Firefox وإصدارات أنظمة تشغيل الهواتف المحمولة الرئيسية.

• تحديثات متكررة: تتبع التغييرات في مواصفات W3C WebAuthn، وإرشادات FIDO Alliance، أو مقترحات SPC.

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

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

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

• لماذا هو مهم: يعني معدل الإنشاء المرتفع أن تدفق التأهيل/التنبيه الخاص بك لمفاتيح المرور مقنع وخالٍ من الاحتكاك.

• الهدف: يجب أن تستهدف معدلاً يتراوح بين 50-80٪.

• التعريف: من بين المستخدمين الذين يبدأون مراسم الإنشاء (ينقرون على "إنشاء Passkey")، كم منهم يكملها دون إحباط أو خطأ؟

• لماذا هو مهم: يشير إلى مدى جودة عمل تدفقك متعدد المصادر أو القائم على إعادة التوجيه.

• الهدف: من الناحية المثالية، يجب أن يكون لديك رقم يقارب 95-100٪ بمجرد موافقة المستخدم.

• التعريف: النسبة المئوية لإجمالي تفويضات الدفع (أو عمليات تسجيل الدخول) التي تتم عبر مفاتيح المرور، بدلاً من الطرق البديلة.

• لماذا هو مهم: الإنشاء لا معنى له إذا عاد المستخدمون إلى الطرق القديمة.

• الهدف: يشير معدل 50-80٪ إلى تبني قوي لمفاتيح المرور.

• التعريف: النسبة المئوية لمحاولات تسجيل الدخول بـ Passkey التي تنجح دون خطأ أو تراجع.

• لماذا هو مهم: انعكاس لقابلية الاستخدام في العالم الحقيقي.

• الهدف: عادةً ما يجب أن تتجاوز 90-95٪ لاعتبار مفاتيح المرور "سلسة".

• التعريف: كم مرة يفشل المستخدمون في استخدام مفاتيح المرور في منتصف المراسم ويتحولون إلى كلمة مرور أو OTP؟

• لماذا هو مهم: يشير الاستخدام المرتفع للحلول البديلة إلى وجود عقبات فنية أو في تجربة المستخدم تمنع مفاتيح المرور من استبدال الطرق القديمة.

• الهدف: من الناحية المثالية، يجب أن يكون استخدام الحلول البديلة أقل من 1-5٪.

بالنسبة لمزودي الدفع، قم بقياس ما إذا كانت مفاتيح المرور تقلل من الاحتيال، أو تسرع عملية الدفع، أو تقلل من التخلي عن عربة التسوق. اجمع بين بيانات استخدام مفاتيح المرور ومقاييس تحويل الدفع أو نجاح 3-D Secure للحصول على رؤية شاملة.

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

أحد أهم التحديات في بناء SDK لـ Passkeys للطرف الثالث هو تنظيم تدفق إنشاء سلس ومتسق - حيث يقوم المستخدمون بالفعل بتسجيل مفاتيح المرور الخاصة بهم. سواء حدث هذا في بوابة البنك، أو ضمن إعدادات حساب مزود الدفع، أو مباشرة على صفحة الدفع الخاصة بالتاجر، فإن خطوات تسجيل Passkey الأساسية متشابهة جدًا. وبالتالي، فإن نهج إنشاء Passkey لا يتغير بشكل أساسي بناءً على ما إذا كنت تدمج التدفق في iframe أو تعيد توجيه المستخدم إلى صفحة طرف أول؛ ما يهم أكثر هو توفير شاشات واضحة وسهلة الاستخدام، وإدارة القيود متعددة المصادر، وتتبع المقاييس الأساسية التي توضح مدى فعالية تبني المستخدمين لـ Passkeys. فيما يلي الجوانب الرئيسية لتدفق إنشاء Passkey بأفضل الممارسات وكيف يدعمها Corbado:

بغض النظر عن المكان الذي يُطلب فيه من المستخدم إنشاء Passkey - سواء كان ذلك في بيئة الخدمات المصرفية عبر الإنترنت للبنك، أو موقع/تطبيق مزود الدفع، أو صفحة الدفع الخاصة بالتاجر - يوفر Corbado مكونات مسبقة الصنع وقابلة للتخصيص لمطالبات المستخدم، وتأكيدات النجاح، ومعالجة الأخطاء.

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

شاهد مكون واجهة المستخدم التالي لشاشة إنشاء Passkey التي تحمل علامة VicRoads التجارية:

يجمع Corbado ويوحد البيانات من جميع نقاط نهاية الإنشاء:

• مواقع أو تطبيقات البنوك حيث يتم عرض Passkeys في البداية.

• إعدادات الحساب الشخصي لمزود الدفع (حيث يمكن للمستخدمين إدارة بيانات الاعتماد).

• صفحات الدفع الخاصة بالتاجر التي تسمح اختيارياً بإنشاء Passkey "أثناء التنقل".

يسهل هذا النهج الموحد قياس معدل إنشاء Passkey، ومعدل نجاح الإنشاء، ونقاط انسحاب المستخدم، وأي أخطاء فنية - بغض النظر عن القناة التي تبدأ تسجيل Passkey.

يقدم Corbado ميزات اختبار A/B لضبط التعليمات التي تظهر على الشاشة، ونص الأزرار، وتوقيت المطالبات. غالباً ما تؤدي التغييرات الطفيفة في الصياغة (على سبيل المثال، "أنشئ Passkey الآن - لا مزيد من كلمات المرور!" مقابل "أمّن دفعتك التالية باستخدام Passkey!") إلى اختلافات كبيرة في قبول المستخدم.

بناءً على نتائج اختبار A/B، يمكن تحسين مؤشرات الأداء الرئيسية التالية:

• معدل الإنشاء: النسبة المئوية للمستخدمين الذين يقومون، بمجرد مطالبتهم، بإعداد Passkey بنجاح.

• معدل نجاح الإنشاء: حصة المستخدمين الذين ينهون المراسم دون إحباط أو خطأ.

• استخدام الحلول البديلة: المعدل الذي يتخطى به المستخدمون إنشاء Passkey لصالح طرق تسجيل الدخول القديمة.

• تأثير التحويل: بالنسبة للتجار، قم بقياس ما إذا كان إنشاء Passkey عند الدفع يقلل من التخلي عن عربة التسوق.

يمكن للمستخدمين إنشاء Passkeys في السياقات التالية:

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

• إعدادات حساب مزود الدفع: يقوم المستخدمون بإعداد Passkeys مباشرة في إعدادات "ملفي الشخصي" أو "الأمان" الخاصة بنطاق مزود الدفع.

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

في كل سيناريو، تتبع مراسم Passkey الأساسية نفس الخطوات - تأكيد المستخدم، المطالبة بالمقاييس الحيوية/رقم التعريف الشخصي، وتسجيل بيانات الاعتماد. يضمن SDK الخاص بـ Corbado التعامل مع قيود تعدد المصادر (إذا كانت مدمجة) أو سياق نطاق الطرف الأول (إذا تمت إعادة التوجيه) بسلاسة في الخلفية.

يربط Corbado كل Passkey جديد بمعرف المستخدم المناسب - سواء كان ذلك "bankPrefix_userId" أو مرجع مستخدم داخلي في نظام مزود الدفع - بحيث يمكن تتبع كل استخدام لاحق إلى حساب المستخدم الصحيح.

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

يمكن لنفس منطق SDK الخاص بـ Corbado التكيف مع ما إذا كان إنشاء Passkey متعدد المصادر مسموحاً به (في Chrome أو Edge الحديثين) أو يجب التحول برشاقة إلى إعادة توجيه لـ Safari.

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

أجرى فريقنا تجارب إنشاء Passkey واسعة النطاق مع عملاء من الشركات، وتعلمنا أي العبارات ومواضع الأزرار والتوقيت تحقق أفضل معدلات التبني.

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

بشكل عام، يعد إنشاء Passkey أهم مرحلة لضمان التبني العالي: حتى أكثر تدفقات تسجيل الدخول بـ Passkey أناقة لن تهم إذا لم يقم المستخدمون بتسجيل بيانات الاعتماد في المقام الأول. من خلال تقديم شاشات إنشاء موحدة وقابلة للتتبع عبر جميع القنوات الممكنة - البنك، نطاق مزود الدفع، أو الدفع لدى التاجر - وتزويدها بتحليلات مؤشرات الأداء الرئيسية واختبار A/B، يساعد Corbado مزودي الدفع على تحقيق تبني Passkey قابل للتطوير حقاً، مما يعكس تجربة المستخدم للحلول الأصلية مثل Apple Pay.

بمجرد أن ينشئ المستخدم Passkey، فإن الخطوة التالية هي التأكد من أنه يستخدم بالفعل هذا الـ Passkey لمدفوعات سريعة وسلسة مثلما يقدم Apple Pay تدفق دفع Apple Pay.

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

عند التعرف على مستخدم عائد، تعرض واجهة Corbado الأمامية زراً مخصصاً (مثل "الدفع باستخدام Passkey") بدلاً من إجباره على إدخال بيانات اعتماد بديلة.

نقرة واحدة على هذا الزر تبدأ تدفق WebAuthn get() (أو مطالبة Passkey الأصلية)، مما يتيح للمستخدم المصادقة على الفور عبر المقاييس الحيوية/رقم التعريف الشخصي - لا توجد خطوات إضافية أو إدخالات نماذج مطلوبة.

يجمع SDK الخاص بـ Corbado إشارات (مثل ملفات تعريف الارتباط للتخزين المحلي، والاستخدام الناجح السابق لـ Passkey، واكتشافات البيئة) للتنبؤ بما إذا كان الجهاز + المتصفح الحالي من المحتمل أن يحتوي على Passkey صالح لهذا المستخدم.

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

إذا لم تشير الأدلة الكافية إلى وجود Passkey، فإن واجهة المستخدم تقدم برشاقة تدفقات بديلة أو تطالب المستخدم بتأكيد أن لديه Passkey.

لا يقوم Corbado بتخزين معلومات التعريف الشخصية (PII) مثل رسائل البريد الإلكتروني الكاملة أو الأسماء.

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

يضمن هذا خصوصية المستخدم مع السماح بمطابقة البيئة بدقة عالية.

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

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

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

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

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

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

ملخص

باختصار، يعد استخدام Passkey بنقرة واحدة هو المكافأة النهائية لإنشاء Passkeys في المقام الأول. من خلال الاستفادة من ذكاء Passkey - وهو مزيج من اكتشاف البيئة، والحد الأدنى من استخدام المعلومات الشخصية، ومنطق الحلول البديلة - يضمن Corbado تقديم مصادقة Passkey للمستخدمين فقط عندما يكون من المرجح حقاً أن تنجح. هذا يقلل بشكل كبير من المحاولات الفاشلة، ويتجنب إحباط المستخدم، ويعزز استخدام Passkey الذي يشكل عادة، ويتوج بتدفق دفع بنقرة واحدة ينافس راحة Apple Pay أو تجارب الدفع الأصلية الأخرى.

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

فيما يلي أبرز النقاط.

ينظم Corbado جميع أحداث Passkey في مسار: من اللحظة التي يُطلب فيها من المستخدم إنشاء Passkey، مروراً بالتسجيل الناجح، إلى عمليات تسجيل الدخول/المدفوعات اللاحقة (استخدام Passkey).

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

بناءً على خبرتنا الواسعة في مساعدة الشركات على تنفيذ Passkeys، نركز على المقاييس التي تؤثر بشكل مباشر على عائد الاستثمار ورضا المستخدم:

• معدل قبول Passkey: كم عدد المستخدمين الذين يرون مطالبة إنشاء ويكملون بالفعل تسجيل Passkey؟

• معدل نجاح إنشاء Passkey: من بين أولئك الذين يبدأون المراسم (ينقرون على "إنشاء Passkey")، ما هي النسبة المئوية التي تنهيها دون خطأ أو تخلي؟

• معدل استخدام Passkey: كم مرة يختار المستخدمون العائدون بالفعل Passkeys للمصادقة أو الدفع اليومي، بدلاً من كلمات المرور أو OTP؟

• معدل نجاح تسجيل الدخول بـ Passkey: النسبة المئوية لمحاولات Passkey التي تنجح دون تراجع أو إحباط للمستخدم.

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

يقوم Corbado تلقائياً بتمييز كل حدث بنظام التشغيل (Windows، macOS، iOS، Android) والمتصفح (Chrome، Safari، Edge، Firefox، إلخ).

باستخدام هذا التقسيم، يمكنك أن ترى ما إذا كان، على سبيل المثال، لدى iOS Safari معدل تخلي أعلى عن Passkey، أو ما إذا كان Windows Chrome يحقق تبنياً أفضل لـ Passkey.

تساعدك هذه البيانات أيضاً على ضبط استراتيجيات الحلول البديلة - خاصة إذا كانت قيود Apple متعددة المصادر تؤثر على قاعدة المستخدمين لديك أكثر من المتوقع.

نوفر عروض لوحة معلومات لكل مرحلة من مراحل مسار Passkey: مطالبات الإنشاء، التسجيلات الناجحة، عمليات تسجيل دخول المستخدم، استخدام الحلول البديلة.

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

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

يتم تسجيل كل تدفق Passkey (من الإنشاء إلى تسجيل الدخول) بأحداث خطوة بخطوة مختومة بالوقت، مما يسمح بتحليل جنائي عميق.

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

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

تدعم منصة تحليلات Corbado اختبار A/B المدمج في مسار Passkey: اختبر نصوص CTA مختلفة، ومطالبات الإنشاء، ورسائل الحلول البديلة، أو موضع أزرار "إنشاء Passkey" في تدفق الدفع.

يمكن قياس مقاييس مثل "معدل قبول Passkey" أو "معدل الحلول البديلة" جنباً إلى جنب لكل متغير.

يضمن هذا النهج التحسين المستمر، مما يعكس نجاح كبار متبني Passkey الذين يحسنون التدفقات بمرور الوقت.

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

يسمح هذا لمزودي الدفع بدمج مؤشرات الأداء الرئيسية لـ Passkey في مجموعات تحليلات أوسع - تتبع عائد الاستثمار من Passkeys إلى جانب مقاييس الأمان أو التسويق أو التشغيل الأخرى.

ملخص

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

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

فيما يلي كيف يساعد Corbado في الحفاظ على التغطية متعددة الأجهزة طوال دورة حياة المستخدم.

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

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

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

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

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

من خلال الإشارات عبر الأجهزة و"ذكاء Passkey" من Corbado، يمكن للنظام اكتشاف متى تحول مستخدم لديه Passkey موجود إلى جهاز غير مسجل.

إذا كانت استراتيجية تجربة المستخدم الخاصة بك تهدف إلى أقصى تغطية، يمكن لـ Corbado أن يطالب تلقائياً: "هل ترغب في إضافة Passkey على هذا الجهاز حتى لا تضطر إلى استخدام الحلول البديلة في المرة القادمة؟"

يمكن للمستخدمين تخطي هذا إذا كانوا على جهاز لمرة واحدة، لكنهم عادة ما يقدرون راحة تسجيل الدخول البيومتري القائم على Passkey بمجرد شرحه.

يوفر SDK الخاص بـ Corbado تدفقات شاشة مميزة لـ "إنشاء Passkey لأول مرة" (أي، المرة الأولى التي يسجل فيها المستخدم بيانات اعتماد) وإنشاء "جهاز ثانوي".

يمكن أن تختلف الرسائل: على سبيل المثال، "أمّن هذا الجهاز الجديد باستخدام Passkey" مقابل "قم بإعداد أول Passkey لك".

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

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

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

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

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

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

ملخص: لماذا تهم التغطية متعددة الأجهزة

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

أحد أكبر المفاهيم الخاطئة عند بناء SDK لـ Passkeys للطرف الثالث هو أن الجزء الأصعب هو تنفيذ استدعاءات WebAuthn (على سبيل المثال، navigator.credentials.create() أو navigator.credentials.get()).

في الواقع، هذا هو الجزء "السهل" - استدعاء API أو اثنين لبدء المراسم الأساسية. يكمن التعقيد الحقيقي والمحدد الحقيقي للنجاح في ضمان التبني واسع النطاق وبناء نظام بيئي كامل حول استدعاءات API هذه.

فيما يلي النقاط الرئيسية - التي يعززها دليل شراء مقابل بناء Passkey - والتي تسلط الضوء على سبب فشل التطبيقات الدنيا التي تقتصر على المراسم فقط في تحقيق نتائج واقعية.

• تنفيذ المراسم: يتضمن إنشاء أو مصادقة Passkey عادةً بضعة أسطر فقط من JavaScript لاستدعاء navigator.credentials.create() أو navigator.credentials.get().

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

• المزالق غير المتوقعة: بمجرد تجاوز "العرض التقني" لـ Passkeys، تكتشف حالات حافة مثل الحظر متعدد المصادر، وقيود WebView المدمجة، وتعقيدات المزامنة متعددة الأجهزة. هذه هي المجهولات غير المعروفة التي تعرقل عمليات البناء الداخلية الساذجة.

• المراسم مقابل التبني: حتى لو كان لديك مراسم WebAuthn مثالية، فإن التبني المنخفض من قبل المستخدم (على سبيل المثال، معدل استخدام Passkey أقل من 5٪) سيحقق فوائد أمنية أو تجربة مستخدم ضئيلة.

• النهج الشامل: يتطلب طرح Passkey ناجح كل شيء بدءاً من مطالبات المستخدم المقنعة وكتابة الإعلانات المختبرة بـ A/B إلى تدفقات تغطية الأجهزة المتعددة، ومعالجة الحلول البديلة، والتحليلات المستمرة - أبعد بكثير من استدعاءات المراسم الأساسية.

• رؤى من دليل الشراء مقابل البناء: يؤكد الدليل على أن دفع تبني Passkey - وليس مجرد تمكين Passkeys - يحدد في النهاية عائد الاستثمار. إذا لم يقم المستخدمون بالتسجيل واستخدام Passkeys بنشاط، فإن المشروع يتوقف فعلياً عند "MFA 2.0" دون تحسين معدل التحويل.

• حلول بديلة ومعالجة أخطاء غير مكتملة: يمكن أن يؤدي فقدان منطق الحلول البديلة المتقدم أو تصحيح الأخطاء في الوقت الفعلي إلى إغلاق حسابات المستخدمين وارتفاع تكاليف الدعم.

• تغطية مجزأة متعددة الأجهزة: بدون خطة لمزامنة الأجهزة الإضافية أو "إصلاح" فجوات Passkey، يعود المستخدمون إلى كلمات المرور كلما قاموا بتبديل المنصات.

• تحليلات محدودة واختبار A/B: يعني نقص البيانات حول مسارات إنشاء Passkey أو استخدام البيئة أنه لا يمكنك تحسين التبني بشكل منهجي أو استكشاف أخطاء المتصفح الجديدة وإصلاحها بسرعة.

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

• الذكاء التكيفي والتسجيل: الكشف التلقائي عن وجود Passkey محتمل، وتوجيه المستخدمين لإنشاء أو إصلاح Passkeys المفقودة، والتقاط سجلات أحداث دقيقة.

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

• الغوص أعمق في استراتيجية التبني: يسلط دليل شراء مقابل بناء Passkey الضوء على كيفية الموازنة بين التكلفة ووقت الوصول إلى السوق والتعقيدات الخفية لحل Passkey قوي.

• معايير واقعية: تعلم كيف تغلبت عمليات الطرح واسعة النطاق من البنوك الكبرى ومقدمي التجارة الإلكترونية على المجهولات غير المعروفة التي تظهر بعد أن تكون قد قمت ببرمجة منطق المراسم "البسيط".

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

باختصار

مجرد توصيل مراسم WebAuthn لا يكفي لتحقيق تبني Passkey ذي معنى. يعتمد النجاح الحقيقي على تنظيم تدفقات شاملة - مثل الحلول البديلة، والتحليلات، والتوسعات متعددة الأجهزة، ورحلات المستخدم المختبرة بـ A/B. من خلال معالجة التعقيدات الدقيقة التي تتجاوز "مجرد المراسم"، يمكنك تحويل مشروع Passkey الخاص بك من فضول تقني إلى حل مصادقة سلس حقاً، ومستخدم على نطاق واسع، وموفر للتكاليف.

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

للامتثال لسيادة البيانات أو الأطر التنظيمية (مثل GDPR في أوروبا، أو PIPEDA في كندا، أو NIST/HIPAA في الولايات المتحدة)، يجب على بعض المزودين الاحتفاظ بالبيانات داخل حدود جغرافية محددة.

تضمن البنية المستقلة عن المنطقة إمكانية نشر خدمة Passkey في أي منطقة AWS مرغوبة، مما يلبي تفويضات الامتثال المحلية دون التضحية بالأداء أو قابلية التوسع.

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

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

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

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

يفضل بعض مزودي الدفع مجموعة مخصصة خاصة - سواء لعزل بيانات أكثر إحكاماً، أو فحوصات امتثال مخصصة، أو تحكم أعمق في التصحيحات والتحديثات.

يمكن للحل المرن أن يدعم كلا الطرفين:

• SaaS / متعدد المستأجرين: سريع التنفيذ، تكلفة أقل، مناسب تماماً للعديد من عمليات النشر متوسطة الحجم.

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

يجب أن تتعامل Passkeys مع أعباء العمل المتقلبة: يمكن أن تطغى الزيادات الهائلة في حركة المرور (على سبيل المثال، ذروات التسوق في العطلات أو مبيعات تذاكر الأحداث) على الأنظمة ذات السعة الثابتة.

تتوسع الواجهة الخلفية الحديثة لـ Passkey أفقياً في الوقت الفعلي، مضيفة أو مزيلة مثيلات الحوسبة بناءً على أنماط الاستخدام. يضمن هذا التوسع التلقائي أداءً متسقاً دون تدخل يدوي.

غالباً ما تنطبق معايير الصناعة مثل PCI-DSS، أو PSD2 SCA، أو ISO 27001 على مزودي الدفع. عادةً ما يتكامل مزود Passkey القوي مع أطر الامتثال المعروفة بشكل جاهز:

• التشفير في حالة السكون وأثناء النقل: تأمين البيانات باستخدام TLS قوي وتشفير من جانب الخادم أو العميل لبيانات الاعتماد المخزنة.

• التسجيل ومسارات التدقيق: سجلات مفصلة لكل عملية Passkey، مناسبة للجهات التنظيمية أو التحقيقات في الحوادث.

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

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

يمكن للتكرار الجغرافي نسخ بيانات Passkey في منطقة أو قارة مختلفة، مما يضمن أن توقف منطقة بأكملها لا يوقف تدفقات المصادقة.

ملخص: متعدد مناطق التوفر ومستقل عن المنطقة

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

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

1. رفض Safari السماح بإنشاء Passkey متعدد المصادر (خاصة في iframes)، مما يفرض إما نهجاً قائماً على إعادة التوجيه أو الاعتماد على Passkeys تم إنشاؤها مسبقاً.

2. عدم دعم Apple لـ Secure Payment Confirmation (SPC)، مما يمنع تدفق دفع موحد وسلس عبر المتصفحات والمنصات.

ومع ذلك، تظل Passkeys ضرورية لمزودي الدفع الذين يتطلعون إلى تقديم تجربة دفع شبيهة بـ Apple Pay: مبسطة وآمنة وبسيطة بشكل مبهج للمستخدمين النهائيين. فيما يلي كيفية معالجة هذه التحديات وكيف يساعد Corbado.

1. ما هي القيود الحالية لاستخدام Passkeys ضمن سياقات الطرف الثالث لمزودي الدفع؟

• قيود تعدد المصادر: يمنع Safari (وبعض المتصفحات القديمة) navigator.credentials.create() عند تضمينه عبر iframe. هذا يعني أنه لا يمكنك إنشاء Passkeys جديدة بسلاسة في تدفق مدمج لدى التاجر على تلك المتصفحات.

• غياب دعم SPC: يحد رفض Apple لتبني SPC من القدرة على توحيد تأكيدات الدفع متعددة المصادر، مما يجبر المزودين على الحفاظ على نهج منفصل لـ Safari مقابل Chrome/Edge.

• قيود WebView والتطبيقات الأصلية: غالباً ما تعطل WebViews المدمجة تدفقات Passkey، مما يتطلب جلسات متصفح النظام أو نهج متخصصة أخرى لإدارة محاذاة أصل النطاق.

• تغطية مجزأة للأجهزة: حتى لو أنشأ المستخدم Passkey على جهاز أو متصفح واحد، فقد يفتقر إلى التغطية على أجهزة أخرى، مما يتسبب في استخدام الحلول البديلة.

2. كيف يمكن لمزودي الدفع التغلب على هذه القيود لتنفيذ تكاملات Passkey للطرف الثالث بنجاح؟

• الاستفادة من استراتيجية هجينة (Iframe + إعادة التوجيه):

  • Iframe للمتصفحات التي تدعم Passkeys متعددة المصادر بالكامل، مما يوفر واجهة مستخدم مدمجة سلسة.

  • إعادة التوجيه كحل بديل لـ Safari أو الإعدادات غير المتوافقة، مما يضمن أن إنشاء Passkey قوي ممكن دائماً.

• System WebView أو إعادة توجيه المتصفح في التطبيقات الأصلية:

  • بدلاً من تضمين iframes في تطبيقات التجار، انتقل إلى ASWebAuthenticationSession (iOS) أو Chrome Custom Tabs (Android) للحفاظ على استمرارية النطاق.

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

  • تحليلات متقدمة واختبار A/B:

    • قم بقياس معدلات نجاح/فشل Passkey باستمرار، وتغطية البيئة، وملاحظات المستخدم لتحسين تدفقاتك.

    • استخدم ذكاء Passkey لتقديم Passkeys تلقائياً فقط عندما يكون النجاح محتملاً.

خلال هذا الدليل، سلطنا الضوء على أن مجرد توصيل navigator.credentials.create() لا يكفي. يتوقف النجاح الحقيقي على التبني العالي لـ Passkey، وتجربة المستخدم المتسقة، والتغطية المرنة متعددة الأجهزة. هذا هو المكان الذي يتفوق فيه Corbado:

• دعم موحد لـ Iframe وإعادة التوجيه: يكتشف SDK الخاص بـ Corbado تلقائياً ما إذا كان تدفق Passkey المدمج ممكناً (على سبيل المثال، على Chrome أو Edge) أو إذا كانت إعادة التوجيه ضرورية (على سبيل المثال، Safari). هذا يزيد من التوافق دون مطالبة التجار بالحفاظ على مسارات تعليمات برمجية متعددة.

  • تجربة دفع بنقرة واحدة: باستخدام ذكاء Passkey، يكتشف Corbado على الفور ما إذا كان من المحتمل أن تحتوي بيئة المستخدم على Passkey صالح - مما يؤدي إلى تدفق "الدفع باستخدام Passkey" السلس. يوازي هذا النهج parallels الدفع بنقرة واحدة في Apple Pay، مما يعزز استخدام Passkey اليومي بدلاً من إحالته إلى خطوة MFA نادراً ما تستخدم.

  • تغطية قوية متعددة الأجهزة: يوفر Corbado تدفقات خاصة لإنشاء Passkey الأولي مقابل توسعات Passkey الثانوية، بحيث يمكن لكل مستخدم إضافة تغطية للأجهزة الجديدة بسرعة بعد تسجيل الدخول عبر الحلول البديلة أو QR عبر الأجهزة.

  • تركيز شامل على التبني: من خلال التحليلات المتكاملة، واختبار A/B، ومعالجة الأخطاء، يساعد Corbado المزودين على تحديد نقاط الاحتكاك وتحسين قبول Passkey بشكل منهجي. يمتد هذا من مطالبات Passkey الأولى للبنوك إلى تجارب الدفع لدى التجار.

  • استضافة مرنة ومتوافقة: تتماشى عمليات نشر Corbado متعددة مناطق التوفر والمستقلة عن المنطقة مع امتثال صناعة الدفع الصارم (PCI DSS، PSD2 SCA، إلخ)، مما يضمن وقت التشغيل والالتزام بقواعد إقامة البيانات في جميع أنحاء العالم.

بينما تخلق سياسات Apple التقييدية احتكاكاً لا مفر منه، لا يزال بإمكان مزودي الدفع تنفيذ Passkeys للطرف الثالث بنجاح من خلال:

1. الجمع بين النهج المدمج (iframe) مع الحل البديل لإعادة التوجيه.

2. تبني عروض ويب النظام المتخصصة أو تدفقات المتصفح الخارجية للتطبيقات الأصلية.

3. التركيز على استراتيجيات التبني القوية: تغطية متعددة الأجهزة، "إصلاح" الحلول البديلة، التحليلات المتقدمة، واختبار A/B.

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