Passkeys cho Nhà cung cấp Thanh toán: Cách Xây dựng SDK của Bên thứ ba

Passkeys đang nổi lên như một phương pháp hiệu quả nhất để bảo mật và ủy quyền các giao dịch trực tuyến, cải thiện đáng kể tính bảo mật và sự tiện lợi so với xác thực đa yếu tố (MFA) truyền thống. Gần đây, PayPal đã áp dụng passkeys làm giải pháp MFA độc lập chính của họ, tạo ra một xu hướng rõ ràng cho các nhà cung cấp thanh toán trên toàn thế giới.

Tuy nhiên, passkeys ban đầu được thiết kế cho bối cảnh bên thứ nhất, nghĩa là chúng hoạt động tối ưu khi người dùng xác thực trực tiếp trên trang web hoặc ứng dụng sở hữu thông tin đăng nhập. Ngược lại, các nhà cung cấp thanh toán thường hoạt động trong bối cảnh bên thứ ba, nơi các dịch vụ của họ (như biểu mẫu thanh toán hoặc SDK) được nhúng vào trang web và ứng dụng của bên bán. Sự không tương thích cơ bản giữa thiết kế của passkey và mô hình hoạt động của các nhà cung cấp thanh toán này đặt ra những hạn chế quan trọng cho việc tích hợp liền mạch. Để giải quyết những thách thức này, chúng ta phải khám phá hai câu hỏi quan trọng:

1. Những hạn chế hiện tại của việc sử dụng passkeys trong bối cảnh bên thứ ba đối với các nhà cung cấp thanh toán là gì? 2. Làm thế nào các nhà cung cấp thanh toán có thể vượt qua những hạn chế này để triển khai thành công việc tích hợp passkey của bên thứ ba?

Bằng cách xem xét những câu hỏi này, chúng ta sẽ thấy rằng những nỗ lực không ngừng của ngành công nghiệp để điều chỉnh passkeys cho bối cảnh bên thứ ba - đặc biệt thông qua các tiêu chuẩn web như Secure Payment Confirmation (SPC) - đang bị chặn bởi các rào cản chiến lược do Apple ngầm áp đặt. Cụ thể, việc Apple hỗ trợ hạn chế cho việc tạo passkey cross-origin trong Safari và thiếu hỗ trợ từ Tiêu chuẩn Secure Payment Confirmation là một trở ngại đáng kể, làm phức tạp việc áp dụng liền mạch xác thực dựa trên passkey của các nhà cung cấp thanh toán bên thứ ba. Hiểu và vượt qua những rào cản này là điều cần thiết cho bất kỳ nhà cung cấp nào muốn mang lại trải nghiệm thanh toán an toàn và không ma sát.

Passkeys mang lại khả năng đăng nhập chống phishing và dựa trên sinh trắc học cho mọi lớp của chuỗi thanh toán. Dưới đây là phân tích về cách mỗi bên tham gia trong chuỗi giá trị thanh toán có thể hưởng lợi từ việc tích hợp xác thực bằng passkey.

Tác động: Thanh toán nhanh hơn, tỷ lệ chuyển đổi cao hơn, giảm tình trạng bỏ giỏ hàng. Cơ hội: Các bên bán cung cấp passkeys qua SDK hoặc luồng chuyển hướng có thể mô phỏng trải nghiệm người dùng ngang tầm Apple Pay và giảm sự phụ thuộc vào mật khẩu hoặc OTP - dẫn đến sự tin tưởng và doanh số cao hơn.

Tác động: Xác thực không mật khẩu liền mạch trên các thiết bị. Cơ hội: Passkeys mang lại trải nghiệm người dùng tốt hơn so với mã OTP hoặc SMS và loại bỏ nguy cơ phishing. Việc áp dụng rộng rãi có thể biến passkeys thành tiêu chuẩn mới cho việc xác minh chủ thẻ.

Tác động: Ngăn chặn gian lận mạnh mẽ hơn. Cơ hội: Các bên phát hành có thể cung cấp xác thực tăng cường dựa trên passkey trong các luồng 3DS, giảm chi phí OTP và cải thiện sự hài lòng của người dùng.

Tác động: Tỷ lệ chấp nhận giao dịch cao hơn và ít xác thực thất bại hơn. Cơ hội: Hỗ trợ passkeys thông qua các PSP có thể cải thiện kết quả cho bên bán và giảm ma sát trong quá trình thanh toán hoặc các luồng thanh toán định kỳ.

Tác động: Giảm gian lận, trải nghiệm người dùng tốt hơn cho bên bán và cải thiện tuân thủ. Cơ hội: Bằng cách nhúng hoặc chuyển hướng các luồng passkey, các PSP có thể cung cấp xác thực thế hệ tiếp theo trong khi vẫn duy trì khả năng tương thích trên các trình duyệt và ứng dụng gốc.

Tác động: Hợp lý hóa việc phê duyệt giao dịch với ít thanh toán bị từ chối hơn. Cơ hội: Các công ty xử lý thanh toán có thể tích hợp xác minh passkey vào API của họ để giảm rủi ro và hỗ trợ các phương án SCA sinh trắc học cho các luồng tuân thủ.

Tác động: Lưu trữ thông tin xác thực an toàn và tái xác thực không ma sát. Cơ hội: Các nhà cung cấp ví điện tử như Apple Pay và Google Pay đã sử dụng các luồng tương tự passkey.

Sau đây, chúng ta sẽ xem xét ngắn gọn các nhà cung cấp thanh toán và thẻ tín dụng lớn và phân tích xem họ đã triển khai passkeys hay chưa và bằng cách nào:

Mastercard đã chính thức ra mắt Dịch vụ Payment Passkey, cung cấp trải nghiệm xác thực không mật khẩu được nhúng vào các luồng EMV 3DS. Người dùng có thể tạo và sử dụng passkeys được liên kết với tên miền xác thực của Mastercard (ví dụ: verify.mastercard.com), cho phép đăng nhập sinh trắc học an toàn trên các bên bán tham gia. Việc triển khai này là một bước tiến lớn hướng tới xác thực chống phishing và tuân thủ PSD2 trong ngành thanh toán. Đọc thêm: Mastercard Passkeys

Visa đã giới thiệu Dịch vụ Visa Payment Passkey, tích hợp passkeys vào luồng “Click to Pay”. Bằng cách cho phép người dùng xác thực liền mạch bằng sinh trắc học thay vì mật khẩu hoặc OTP, Visa đang hướng tới việc hiện đại hóa trải nghiệm thanh toán trực tuyến với bảo mật nâng cao và sự tiện lợi cho người dùng. Đọc thêm: VISA Passkeys

American Express chưa công khai ra mắt sản phẩm passkey. Tuy nhiên, với tư cách là thành viên cấp hội đồng của FIDO Alliance, có khả năng American Express sẽ triển khai một giải pháp xác thực dựa trên passkey trong tương lai gần, phù hợp với xu hướng chung của ngành.

PayPal là một trong những nhà cung cấp thanh toán đầu tiên áp dụng passkeys. Việc triển khai của họ hỗ trợ đăng nhập sinh trắc học liền mạch cho các tài khoản cá nhân và doanh nghiệp trên các thiết bị. Passkey được liên kết với tên miền của PayPal và đã có sẵn ở nhiều khu vực. Tuy nhiên, việc triển khai của họ vẫn còn có thể cải thiện, đặc biệt là về các luồng đa thiết bị và phát hiện nền tảng. Đọc thêm: PayPal Passkeys

Klarna chưa chính thức giới thiệu hỗ trợ passkey. Theo quan sát của chúng tôi, Klarna phụ thuộc nhiều vào WebView nhúng trong ứng dụng và SDK thanh toán của họ. Vì Safari và iOS hạn chế việc tạo passkey trong iframes / WebViews, đây có thể là lý do tại sao Klarna chưa triển khai passkeys cho đến nay.

Square đã giới thiệu đăng nhập bằng passkey cho bảng điều khiển dành cho nhà phát triển và bảng điều khiển quản lý của họ, cho phép truy cập an toàn, không mật khẩu vào các công cụ nội bộ. Tuy nhiên, chưa có thông báo nào về việc hỗ trợ passkey trong các luồng thanh toán hoặc API cho người dùng cuối hoặc bên bán.

Stripe đã triển khai đăng nhập bằng passkey cho bảng điều khiển của họ, cho phép các nhà phát triển xác thực bằng sinh trắc học. Passkeys cho Stripe Checkout hoặc Elements chưa có sẵn. Với sự ủng hộ mạnh mẽ của Stripe cho các luồng dựa trên chuyển hướng, có khả năng passkeys - nếu được triển khai trong thanh toán - sẽ tuân theo kiến trúc chuyển hướng tương tự.

Tính đến nay, BILL chưa có bất kỳ thông báo công khai hoặc cập nhật sản phẩm nào liên quan đến passkeys để xác thực.

Remitly chưa tiết lộ bất kỳ kế hoạch hoặc thông tin công khai nào về việc triển khai xác thực bằng passkey trong các dịch vụ của họ.

Không có báo cáo công khai hoặc tài liệu sản phẩm nào cho thấy Payoneer đã áp dụng hoặc đang thử nghiệm đăng nhập hoặc luồng giao dịch dựa trên passkey.

Adyen chưa giới thiệu passkeys vào các luồng xác thực hoặc thanh toán của họ. Không có tuyên bố công khai hoặc tài liệu dành cho nhà phát triển nào đề cập đến việc hỗ trợ passkey.

Worldpay chưa công bố bất kỳ hỗ trợ nào cho passkeys tính đến thời điểm hiện tại. Hệ thống xác thực của họ vẫn dựa vào các phương pháp truyền thống như mật khẩu, OTP và các luồng dựa trên 3DS.

Checkout.com chưa công khai triển khai hỗ trợ passkey. Không có cập nhật dành cho nhà phát triển, bài đăng blog hoặc thông báo chính thức nào về việc áp dụng passkey.

AliPay chưa chính thức ra mắt passkeys. Với xu hướng ngày càng tăng của xác thực sinh trắc học trong hệ sinh thái thanh toán của Trung Quốc, việc triển khai có thể xảy ra trong tương lai, nhưng không có tài liệu hiện tại nào xác nhận điều này.

Mollie chưa đưa ra bất kỳ tuyên bố công khai hoặc cập nhật sản phẩm nào về việc áp dụng passkeys trong hệ thống xác thực hoặc thanh toán của mình.

Amazon đã triển khai hỗ trợ passkey cho việc đăng nhập của người dùng trên nền tảng chính của mình. Mở rộng công nghệ này sang Amazon Pay sẽ là một bước đi tự nhiên tiếp theo, đặc biệt là vì nhiều người dùng đã có passkey đăng ký với Amazon, điều này sẽ đơn giản hóa đáng kể việc giới thiệu người dùng trong quá trình thanh toán.

Braintree, một công ty của PayPal, chưa chính thức áp dụng xác thực bằng passkey. Tài liệu hiện tại của họ không đề cập đến passkeys trong bối cảnh đăng nhập người dùng hoặc API của bên bán.

Link, giải pháp thanh toán một cú nhấp chuột của Stripe, đã triển khai passkeys và có thể đóng vai trò là nền tảng cho chiến lược passkey của Stripe trong thanh toán tiêu dùng. Tuy nhiên, Stripe chưa chính thức công bố hỗ trợ passkey cho Link hoặc bất kỳ kế hoạch cụ thể nào cho việc triển khai.

Afterpay chưa đưa ra bất kỳ tuyên bố hoặc tính năng nào liên quan đến hỗ trợ passkey. Giống như Klarna, việc tích hợp thanh toán của họ chủ yếu dựa trên ứng dụng, điều này có thể gây ra những rào cản kỹ thuật cho việc áp dụng passkey do các hạn chế của WebView nhúng.

Việc áp dụng passkeys của các nhà cung cấp thanh toán bên thứ ba phải đối mặt với những trở ngại chiến lược, chủ yếu do các chính sách hạn chế của Apple trong Safari. Hai nỗ lực tiêu chuẩn hóa quan trọng đã liên tục bị cản trở:

• Secure Payment Confirmation (SPC)

• Tạo Passkey của bên thứ ba trong Iframes

Secure Payment Confirmation (SPC) đại diện cho nỗ lực quan trọng nhất của ngành - chủ yếu do Google thúc đẩy - để cho phép sử dụng passkeys cross-origin một cách liền mạch, được thiết kế riêng cho việc ủy quyền thanh toán an toàn. SPC tiêu chuẩn hóa cách các nhà cung cấp thanh toán xác thực người dùng trên nhiều trang web của bên bán mà không ảnh hưởng đến bảo mật hoặc trải nghiệm người dùng. Tuy nhiên, Apple đã liên tục từ chối hỗ trợ SPC trong Safari, có khả năng đây là một động thái chiến lược để đảm bảo rằng Apple Pay vẫn là giải pháp thanh toán ưu tiên, không ma sát nhất trong hệ sinh thái của mình. Việc Apple từ chối áp dụng SPC không chỉ giới hạn việc triển khai rộng rãi passkeys trong bối cảnh bên thứ ba mà còn trì hoãn hiệu quả việc áp dụng rộng rãi hơn trong ngành về xác thực thanh toán được tiêu chuẩn hóa.

Hãy đọc bài đăng blog này về SPC nếu bạn muốn tìm hiểu thêm chi tiết.

Một rào cản quan trọng khác liên quan đến việc Apple cố tình hạn chế việc tạo passkey trong iframes cross-origin. Trong khi Safari cho phép sử dụng passkeys hiện có để xác thực (navigator.credentials.get()) trong một iframe của bên thứ ba, nó lại chặn một cách rõ ràng việc đăng ký passkey (navigator.credentials.create()) trong các bối cảnh như vậy.

Hạn chế này gây khó khăn nghiêm trọng cho các nhà cung cấp thanh toán phụ thuộc vào việc tạo passkeys mới một cách liền mạch trong luồng thanh toán của bên bán. Do đó, các nhà cung cấp buộc phải sử dụng các phương pháp dựa trên chuyển hướng hoặc phải dựa vào các passkeys hiện có đã được thiết lập trực tiếp trên tên miền của riêng họ. Quyết định này của Apple ảnh hưởng trực tiếp đến tính thực tiễn và sự trôi chảy của việc tích hợp với bên bán, tạo ra một điểm ma sát đáng kể cho cả người tiêu dùng và nhà cung cấp.

Trong phương pháp này, bên bán bao gồm biểu mẫu thanh toán của bạn trong một <iframe> được phục vụ từ tên miền của nhà cung cấp thanh toán của bạn - ví dụ: https://pay.provider.com. Người dùng vẫn ở trên tên miền của bên bán (ví dụ: https://www.mystore.com), thấy giao diện người dùng thanh toán của bạn trong iframe nhúng và xác thực bằng passkey được liên kết với ID Relying Party pay.provider.com.

Những điểm chính:

• Cross-Origin: Vì iframe nằm trên một tên miền khác, bạn phải cấu hình các chính sách quyền cho publickey-credentials-get và publickey-credentials-create để cho phép các hoạt động passkey bên trong iframe.

• Hạn chế tạo: Một số trình duyệt (đặc biệt là các phiên bản cũ hơn và Safari) vẫn không cho phép tạo passkey trong iframe cross-origin. Việc xác thực (navigator.credentials.get()) được hỗ trợ rộng rãi hơn, nhưng việc đăng ký (navigator.credentials.create()) có thể thất bại trong một số môi trường nhất định, đặc biệt là trong Safari.

• Kích hoạt bởi người dùng: Các luồng passkey thường yêu cầu “kích hoạt tạm thời” (ví dụ: một cú nhấp chuột trực tiếp từ người dùng). Đảm bảo rằng giao diện iframe của bạn kích hoạt quy trình passkey trong một sự kiện do người dùng khởi xướng.

• Bảo mật & UX: Phương pháp iframe cung cấp trải nghiệm thanh toán nội tuyến, mượt mà, nhưng nếu trình duyệt của người dùng chặn hoặc hạn chế cookie của bên thứ ba hoặc bộ nhớ cục bộ, nó có thể làm gián đoạn luồng passkey.

Với luồng dựa trên chuyển hướng, bạn gửi người dùng từ tên miền của bên bán đến tên miền thanh toán của bạn, hoặc mở một tab/cửa sổ mới trỏ đến một địa chỉ như https://pay.provider.com/checkout. Passkeys sau đó được tạo hoặc sử dụng trực tiếp trên tên miền của bạn trong bối cảnh bên thứ nhất.

Những điểm chính:

• Đơn giản của bên thứ nhất: Toàn bộ quy trình làm việc của passkey (tạo, xác thực) diễn ra trên tên miền của nhà cung cấp thanh toán, vì vậy không có hạn chế cross-origin. Tất cả các trình duyệt chính đều hỗ trợ tạo và đăng nhập bằng passkey trong bối cảnh bên thứ nhất.

• UX chuyển hướng: Người dùng rời khỏi trang của bên bán (hoặc thấy một cửa sổ bật lên) để hoàn tất xác thực. Điều này có thể kém liền mạch hơn, nhưng nó đơn giản hóa kiến trúc passkey và giảm sự phức tạp của cross-origin.

• Phương án dự phòng cho các trình duyệt không tương thích: Bạn có thể giảm cấp một cách duyên dáng nếu passkeys không khả dụng (ví dụ: các trình duyệt cũ hơn) bằng cách cung cấp các phương thức đăng nhập thay thế trên tên miền thanh toán của bạn mà không cần xử lý quyền cross-origin bổ sung.

Việc tích hợp passkeys trong các ứng dụng di động gốc đặt ra những thách thức riêng so với các kịch bản dựa trên web. Các ứng dụng gốc dành cho bên bán (trên cả iOS và Android) thường nhúng các luồng thanh toán vào bên trong ứng dụng bằng cách sử dụng WebViews nhúng để duy trì trải nghiệm người dùng liền mạch. Tuy nhiên, việc triển khai xác thực passkey của bên thứ ba trong các bối cảnh nhúng này có thể gặp vấn đề do các chính sách nghiêm ngặt về nguồn gốc trình duyệt và các hạn chế cụ thể của nền tảng.

Passkeys vốn được liên kết với một tên miền cụ thể (ID “Relying Party”), đây là một nguyên tắc bảo mật cốt lõi đảm bảo rằng thông tin xác thực không thể bị lạm dụng trên các trang web hoặc ứng dụng không liên quan. Khi một nhà cung cấp thanh toán tạo passkeys dưới tên miền của riêng mình - ví dụ: pay.provider.com - những passkeys đó được giới hạn nghiêm ngặt trong tên miền đó trên cả iOS và Android. Do đó, một ứng dụng gốc của bên bán (hoạt động tự nhiên dưới định danh ứng dụng và tên miền riêng của bên bán) không thể trực tiếp gọi passkeys của nhà cung cấp như một thông tin xác thực “bên thứ nhất”. Làm như vậy sẽ yêu cầu chia sẻ khóa riêng tư cross-origin, điều mà các hệ điều hành và thông số kỹ thuật WebAuthn cấm một cách rõ ràng để ngăn chặn phishing và đánh cắp thông tin xác thực.

Từ góc độ của thiết bị, ứng dụng gốc của bên bán là một “nguồn gốc” khác với tên miền của nhà cung cấp thanh toán. Việc cố gắng xác thực nguyên bản đối với các thông tin xác thực đã đăng ký cho một nguồn gốc riêng biệt sẽ phá vỡ mô hình bảo mật cơ bản dựa trên nguồn gốc của passkeys. Đây chính là lý do tại sao việc sử dụng passkey của bên thứ ba trong bối cảnh của bên bán phụ thuộc vào trình duyệt hệ thống hoặc WebView dựa trên hệ thống (như ASWebAuthenticationSession trên iOS hoặc Chrome Custom Tabs trên Android). Các luồng đặc biệt này bảo tồn bối cảnh tên miền ban đầu của nhà cung cấp - đảm bảo passkeys vẫn được liên kết an toàn với nguồn gốc - trong khi vẫn cho phép người dùng xác thực với nhà cung cấp thanh toán bên trong ứng dụng của bên bán. Trong các phần tiếp theo, chúng ta sẽ khám phá cách thức hoạt động này.

WebViews nhúng (ví dụ: WKWebView trên iOS hoặc WebView của Android) được ưa chuộng rộng rãi vì chúng cho phép các ứng dụng nhúng nội dung web trực tiếp vào giao diện gốc của chúng, mang lại sự tích hợp chặt chẽ và tính nhất quán về UX. Tuy nhiên, các môi trường nhúng này bị hạn chế đáng kể khi xử lý passkeys của bên thứ ba do các chính sách về nguồn gốc và bảo mật:

• Không khớp nguồn gốc: Passkeys phụ thuộc nghiêm ngặt vào nguồn gốc tên miền để xử lý thông tin xác thực an toàn. Một WebView nhúng hoạt động dưới tên miền của nội dung mà nó hiển thị (thường là của bên bán), làm cho việc tạo hoặc xác thực passkeys được liên kết rõ ràng với tên miền của nhà cung cấp thanh toán bên thứ ba trở nên khó khăn hoặc không thể.

• Hạn chế bảo mật nền tảng: Cả Apple (iOS) và Google (Android) đã dần dần hạn chế khả năng xác thực của WebView nhúng, đặc biệt là khi xử lý các thông tin xác thực an toàn. Những hạn chế này được thiết kế để bảo vệ quyền riêng tư của người dùng và bảo mật nhưng làm cho việc triển khai passkey của bên thứ ba trở nên phức tạp hơn đáng kể.

Nhìn chung, trong khi WebView nhúng hấp dẫn đối với các bên bán từ góc độ UX, chúng lại đưa ra những hạn chế thực tế đáng kể cho việc triển khai các luồng xác thực passkey của bên thứ ba một cách mạnh mẽ.

Với những hạn chế liên quan đến WebView nhúng, các nhà cung cấp thanh toán thường áp dụng một trong hai chiến lược thay thế để triển khai passkeys của bên thứ ba một cách đáng tin cậy trong các ứng dụng di động gốc:

iOS (ASWebAuthenticationSession):

Apple cung cấp ASWebAuthenticationSession như một môi trường giống trình duyệt, an toàn bên ngoài bối cảnh của ứng dụng chủ. Nó chia sẻ bộ nhớ cookie với trình duyệt Safari mặc định và hỗ trợ passkeys của bên thứ ba một cách đáng tin cậy vì thông tin xác thực phù hợp với tên miền gốc của nhà cung cấp thanh toán.

Ví dụ sau đây minh họa chức năng “Thanh toán bằng PayPal” trong ứng dụng gốc BOSS. Nó cho thấy cách một webview hệ thống ASWebAuthenticationSession được mở, chia sẻ trạng thái của nó với cookie Safari, cho phép hộp thoại passkey bắt đầu ngay lập tức.

Android (Chrome Custom Tabs):

Tương tự, Custom Tabs của Android cung cấp một môi trường gần giống trình duyệt cho phép tạo và xác thực passkey một cách nhất quán. Giống như ASWebAuthenticationSession, Custom Tabs chạy riêng biệt với bối cảnh ứng dụng của bên bán, đảm bảo tính toàn vẹn của tên miền và thông tin xác thực.

Xem cùng một ví dụ từ ứng dụng gốc BOSS trên Android tại đây:

Một phương pháp khác liên quan đến việc chuyển hướng người dùng ra khỏi ứng dụng gốc vào trình duyệt web mặc định của thiết bị di động (Safari trên iOS, Chrome trên Android). Điều này đảm bảo luồng thanh toán - và do đó là quản lý passkey - diễn ra hoàn toàn trong một bối cảnh bên thứ nhất đáng tin cậy được liên kết với tên miền của nhà cung cấp thanh toán. Người dùng sau đó quay trở lại ứng dụng của bên bán sau khi xác thực hoặc hoàn tất thanh toán thành công. Tùy chọn này rất bất tiện cho khách hàng vì họ phải rời khỏi ứng dụng.

Cả hai giải pháp đều yêu cầu tạm thời chuyển người dùng ra khỏi môi trường ứng dụng gốc của bên bán. Mặc dù kém liền mạch hơn một chút so với các giải pháp nhúng, những phương pháp này cải thiện đáng kể khả năng tương thích, bảo mật và độ tin cậy của các hoạt động passkey của bên thứ ba.

Cuối cùng, các nhà cung cấp thanh toán phát triển SDK gốc phải cân bằng cẩn thận giữa các cân nhắc về trải nghiệm người dùng và các ràng buộc kỹ thuật thực tế. Mặc dù các bên bán ưa thích trải nghiệm nhúng hoàn toàn, việc tận dụng WebView hệ thống hoặc chuyển hướng trình duyệt bên ngoài vẫn là phương pháp tốt nhất để đảm bảo xác thực passkey của bên thứ ba an toàn, đáng tin cậy trong các ứng dụng gốc.

Việc lựa chọn giữa phương pháp nhúng (iframe) và phương pháp dựa trên chuyển hướng để tích hợp passkeys của bên thứ ba vào SDK thanh toán liên quan đến việc đánh giá các đánh đổi về trải nghiệm người dùng, khả năng tương thích với trình duyệt, độ phức tạp kỹ thuật và sở thích của bên bán.

Cả hai giải pháp đều có những ưu và nhược điểm riêng biệt, mà các nhà cung cấp thanh toán nên xem xét cẩn thận dựa trên thị trường mục tiêu, trải nghiệm người dùng mong muốn và cơ sở hạ tầng kỹ thuật của họ.

Phương pháp nhúng (iframe) mang lại trải nghiệm người dùng liền mạch, mang thương hiệu của bên bán, rất hấp dẫn đối với các bên bán, nhưng bị cản trở bởi khả năng tương thích trình duyệt hạn chế, đặc biệt là việc Safari từ chối cho phép tạo passkey cross-origin. Hạn chế này buộc các bên bán và nhà cung cấp phải sử dụng các giải pháp phức tạp, dựa trên cách giải quyết tạm thời mà thường làm ảnh hưởng đến chức năng hoặc dẫn đến hỗ trợ không đầy đủ cho việc đăng ký passkey.

Ngược lại, phương pháp chuyển hướng cung cấp khả năng tương thích toàn diện trên các trình duyệt và nền tảng di động gốc bằng cách hoạt động trong bối cảnh tên miền của bên thứ nhất. Nó đơn giản hóa đáng kể việc tích hợp, cải thiện độ tin cậy và đảm bảo hỗ trợ đầy đủ cho việc tạo và xác thực passkey. Nhược điểm chính là ma sát tiềm ẩn được tạo ra bởi việc chuyển hướng người dùng ra khỏi trang web hoặc ứng dụng của bên bán, mặc dù điều này có thể được giảm thiểu bằng thiết kế UX cẩn thận, truyền đạt kỳ vọng rõ ràng hoặc tích hợp với các nền tảng đáng tin cậy như Corbado.

Với những cân nhắc này, một phương pháp kết hợp thường là lý tưởng, cho phép các nhà cung cấp thanh toán tận dụng mô hình iframe nhúng khi trình duyệt của người dùng hỗ trợ nó và chuyển sang phương pháp chuyển hướng một cách duyên dáng nếu không. Chiến lược kết hợp này tối đa hóa khả năng tương thích, sức hấp dẫn đối với bên bán và sự hài lòng của khách hàng trên các môi trường đa dạng.

Việc triển khai SDK thanh toán passkeys của bên thứ ba liên quan đến việc cân bằng giữa trải nghiệm người dùng, khả năng tương thích với trình duyệt, các ràng buộc của ứng dụng gốc, phân tích và bảo mật - đặc biệt là với những rào cản cụ thể từ Apple (ví dụ: chặn tạo passkey cross-origin, thiếu hỗ trợ SPC). Dưới đây là các khuyến nghị chính để đảm bảo kết quả tốt nhất có thể khi tích hợp passkeys vào các luồng thanh toán trên web hoặc gốc.

Do sự hỗ trợ khác nhau của trình duyệt và các hành vi không nhất quán của Apple, việc hỗ trợ cả phương pháp nhúng (dựa trên iframe) và phương pháp chuyển hướng là rất quan trọng:

• Thanh toán bằng Iframe (Nhúng)

  • Cung cấp trải nghiệm liền mạch, ngay trên trang cho các trình duyệt hiện đại cho phép các hoạt động passkey cross-origin (chủ yếu để xác thực).

  • Phải đặt đúng Permissions-Policy cho publickey-credentials-get/publickey-credentials-create.

  • Lưu ý rằng Safari và một số trình duyệt cũ hơn chặn việc tạo passkey cross-origin trong iframes.

• Luồng chuyển hướng

  • Hỗ trợ đáng tin cậy cả việc đăng ký và đăng nhập bằng passkey trong bối cảnh bên thứ nhất.

  • Gây ra ma sát nhiều hơn một chút do việc chuyển hướng hoặc cửa sổ bật lên, nhưng an toàn hơn về mặt tương thích trên các trình duyệt.

  • Là phương án dự phòng lý tưởng cho Safari, hiện không cho phép tạo passkey của bên thứ ba trong iframes.

Bằng cách cung cấp cả hai phương pháp, bạn có thể quyết định một cách linh hoạt - hoặc để các bên bán quyết định - nên sử dụng phương pháp nào, tối đa hóa khả năng tương thích cho tất cả các môi trường người dùng.

Việc phát hiện chính xác khả năng của trình duyệt vẫn còn nhiều thách thức do độ chi tiết của User-Agent bị giảm và sự hỗ trợ không nhất quán cho Client Hints trên các nền tảng.

Việc phân tích truyền thống ngày càng không đáng tin cậy khi các trình duyệt giảm chi tiết trong chuỗi User-Agent để bảo vệ quyền riêng tư của người dùng. Việc phân biệt các chi tiết cần thiết - như Windows 10 và Windows 11, các phiên bản macOS chính xác hoặc kiến trúc CPU - hiện rất khó hoặc không thể chỉ bằng User-Agent.

Trong khi Client Hints cung cấp dữ liệu có độ entropy cao một cách tôn trọng quyền riêng tư, chỉ các trình duyệt dựa trên Chromium mới hỗ trợ đầy đủ. Safari và Firefox không hỗ trợ Client Hint, hạn chế nghiêm trọng việc phát hiện tính năng chính xác trên các thiết bị của Apple.

WebView nhúng thường hạn chế quyền truy cập vào thông tin chi tiết của thiết bị và hiếm khi hỗ trợ Client Hints. Hạn chế này làm cho việc phát hiện khả năng của passkey trở nên đặc biệt khó khăn trong bối cảnh ứng dụng gốc.

Với những ràng buộc này, việc phát hiện đáng tin cậy hỗ trợ passkey cross-origin - đặc biệt trong các SDK thanh toán của bên thứ ba - đòi hỏi sự kết hợp cẩn thận giữa các truy vấn Client Hint động (nếu có), các phương pháp phỏng đoán User-Agent dự phòng và các hành vi mặc định thận trọng cho các trình duyệt như Safari và Firefox.

Các ứng dụng gốc của bên bán thường nhúng nội dung web trong WKWebView (iOS) hoặc Android WebView, rất hạn chế đối với passkeys. Các chiến lược phổ biến bao gồm:

• Phiên trình duyệt hệ thống: Sử dụng ASWebAuthenticationSession (iOS) hoặc Custom Tabs (Android) để chuyển việc tạo/đăng nhập passkey sang một bối cảnh trình duyệt “bên thứ nhất” an toàn.

• Chuyển hướng đến trình duyệt mặc định: Một phương pháp kém liền mạch hơn nhưng rất đáng tin cậy để đảm bảo tính toàn vẹn của tên miền cho các hoạt động passkey.

Là một nhà cung cấp thanh toán, an ninh mạnh mẽ và tuân thủ quy định (PCI, PSD2 SCA, v.v.) là chìa khóa:

• Headers & Bảo mật nội dung: Triển khai các header Permissions-Policy nghiêm ngặt và các quy tắc CSP mạnh mẽ cho các luồng cross-origin.

• Ghi nhật ký & Giám sát: Ghi nhật ký kỹ lưỡng các sự kiện tạo và sử dụng passkey để ngăn chặn gian lận và kiểm toán tuân thủ.

• Lưu trữ PII tối thiểu: Ánh xạ người dùng với passkeys bằng các định danh đã được băm, giảm thiểu rủi ro theo GDPR hoặc các luật bảo vệ dữ liệu tương tự.

• Dấu vết kiểm toán: Ghi nhật ký mỗi sự kiện tạo và xác thực passkey để phát hiện các bất thường và đáp ứng các cuộc kiểm toán tuân thủ.

Passkeys vẫn đang phát triển, vì vậy bạn sẽ cần kiểm tra liên tục:

• Kiểm tra trên nhiều trình duyệt & hệ điều hành: Tự động hóa các bài kiểm tra trên Safari, Chrome, Edge, Firefox và các phiên bản hệ điều hành di động chính.

• Cập nhật thường xuyên: Theo dõi các thay đổi trong thông số kỹ thuật W3C WebAuthn, hướng dẫn của FIDO Alliance hoặc các đề xuất SPC.

• Phản hồi của người dùng & Tỷ lệ lỗi: Ghi nhật ký các lỗi passkey (tạo hoặc đăng nhập) để nhanh chóng khắc phục sự cố, đặc biệt đối với người dùng trên nền tảng Apple.

Một khung KPI mạnh mẽ giúp bạn theo dõi xem việc tích hợp passkey của bên thứ ba có thực sự cải thiện bảo mật và trải nghiệm người dùng hay không. Mặc dù bài viết này nói về việc triển khai SDK, điều quan trọng cần nhớ là việc áp dụng passkey cũng là chìa khóa trong trường hợp sử dụng này. Tỷ lệ tạo và tỷ lệ sử dụng passkeys cần được phân tích và tối ưu hóa cẩn thận.

• Định nghĩa: Tỷ lệ phần trăm người dùng tạo thành công một passkey khi được nhắc (ví dụ: tại trang thanh toán hoặc thiết lập tài khoản).

• Tại sao nó quan trọng: Tỷ lệ tạo cao có nghĩa là luồng giới thiệu/thúc đẩy của bạn cho passkeys hấp dẫn và không gây ma sát.

• Mục tiêu: Bạn nên nhắm đến tỷ lệ 50-80%

• Định nghĩa: Trong số những người dùng bắt đầu quy trình tạo (nhấp vào “Tạo Passkey”), có bao nhiêu người hoàn thành mà không hủy bỏ hoặc gặp lỗi?

• Tại sao nó quan trọng: Cho biết luồng cross-origin hoặc chuyển hướng của bạn hoạt động tốt như thế nào.

• Mục tiêu: Lý tưởng nhất, bạn có một con số khoảng 95–100% sau khi người dùng chọn tham gia.

• Định nghĩa: Tỷ lệ phần trăm tổng số lần ủy quyền thanh toán (hoặc đăng nhập) được thực hiện qua passkeys, so với các phương pháp dự phòng.

• Tại sao nó quan trọng: Việc tạo ra là vô nghĩa nếu người dùng quay lại các phương pháp cũ hơn.

• Mục tiêu: Tỷ lệ 50–80% báo hiệu sự chấp nhận passkey mạnh mẽ.

• Định nghĩa: Tỷ lệ phần trăm các lần thử đăng nhập bằng passkey thành công mà không có lỗi hoặc phải dùng phương án dự phòng.

• Tại sao nó quan trọng: Phản ánh khả năng sử dụng trong thực tế của bạn.

• Mục tiêu: Thông thường bạn nên vượt quá 90–95% để coi passkeys là “không ma sát”.

• Định nghĩa: Người dùng thất bại với passkeys giữa chừng và chuyển sang mật khẩu hoặc OTP thường xuyên như thế nào?

• Tại sao nó quan trọng: Việc sử dụng phương án dự phòng cao cho thấy các rào cản kỹ thuật hoặc UX đang ngăn cản passkeys thay thế các phương pháp cũ.

• Mục tiêu: Lý tưởng nhất, việc sử dụng phương án dự phòng là dưới 1-5%

Đối với các nhà cung cấp thanh toán, hãy đo lường xem passkeys có giảm gian lận, tăng tốc thanh toán hoặc giảm tỷ lệ bỏ giỏ hàng hay không. Kết hợp dữ liệu sử dụng passkey với chuyển đổi thanh toán hoặc các chỉ số thành công của 3-D Secure để có một cái nhìn toàn diện.

Việc giám sát các KPI này giúp bạn xác định môi trường hoặc hành trình người dùng nào cần cải thiện - ví dụ: nếu Safari trên iOS có tỷ lệ bỏ ngang cao hơn do các khối cross-origin, bạn có thể chuyển hướng những người dùng đó đến một luồng chuyển hướng một cách có hệ thống.

Một trong những thách thức quan trọng nhất trong việc xây dựng SDK passkeys của bên thứ ba là điều phối một luồng tạo mượt mà và nhất quán - nơi người dùng thực sự đăng ký passkeys của họ. Cho dù điều này xảy ra trong cổng thông tin của ngân hàng, trong cài đặt tài khoản của chính nhà cung cấp thanh toán hay ngay trên trang thanh toán của bên bán, các bước đăng ký passkey cốt lõi đều rất giống nhau. Do đó, phương pháp tạo passkey không thay đổi cơ bản dựa trên việc bạn nhúng luồng vào iframe hay chuyển hướng người dùng đến một trang của bên thứ nhất; điều quan trọng nhất là cung cấp các màn hình rõ ràng, thân thiện với người dùng, quản lý các ràng buộc cross-origin và theo dõi các chỉ số thiết yếu cho thấy người dùng áp dụng passkeys hiệu quả như thế nào. Dưới đây là các khía cạnh chính của một luồng tạo passkey theo phương pháp tốt nhất và cách Corbado hỗ trợ chúng:

Bất kể người dùng được nhắc tạo passkey ở đâu - dù là trong môi trường ngân hàng trực tuyến của ngân hàng, trang web/ứng dụng của chính nhà cung cấp thanh toán hay trang thanh toán của bên bán - Corbado cung cấp các thành phần được xây dựng sẵn, có thể tùy chỉnh cho các lời nhắc người dùng, xác nhận thành công và xử lý lỗi.

Các thành phần này đảm bảo giao diện nhất quán trong khi cho phép tùy chỉnh thương hiệu (white-label) để mỗi ngân hàng hoặc bên bán có thể giữ lại các yếu tố thiết kế độc đáo của mình nếu cần.

Xem thành phần UI sau cho màn hình tạo passkey được thiết kế theo thương hiệu của VicRoads:

Corbado thu thập và hợp nhất dữ liệu từ tất cả các điểm cuối tạo:

• Các trang web hoặc ứng dụng của ngân hàng nơi passkeys được cung cấp ban đầu.

• Cài đặt tài khoản cá nhân của nhà cung cấp thanh toán (nơi người dùng có thể quản lý thông tin xác thực).

• Các trang thanh toán của bên bán cho phép tùy chọn tạo passkey “ngay lập tức”.

Phương pháp hợp nhất này giúp dễ dàng đo lường tỷ lệ tạo passkey, tỷ lệ tạo thành công, các điểm người dùng bỏ ngang và bất kỳ lỗi kỹ thuật nào - bất kể kênh nào khởi xướng việc đăng ký passkey.

Corbado cung cấp các tính năng A/B testing để tinh chỉnh các hướng dẫn trên màn hình, văn bản nút và thời điểm của các lời nhắc. Những thay đổi tinh tế trong cách diễn đạt (ví dụ: “Tạo passkey ngay - không còn mật khẩu!” so với “Bảo mật thanh toán tiếp theo của bạn bằng passkey!”) thường mang lại sự khác biệt đáng kể trong việc chấp nhận của người dùng.

Dựa trên kết quả của A/B test, các KPI sau có thể được tối ưu hóa:

• Tỷ lệ tạo: Tỷ lệ phần trăm người dùng, sau khi được nhắc, đã thiết lập thành công một passkey.

• Tỷ lệ tạo thành công: Tỷ lệ người dùng hoàn thành quy trình mà không hủy bỏ hoặc gặp lỗi.

• Sử dụng phương án dự phòng: Tỷ lệ người dùng bỏ qua việc tạo passkey để chuyển sang các phương thức đăng nhập cũ hơn.

• Tác động chuyển đổi: Đối với các bên bán, đo lường xem việc tạo passkey tại trang thanh toán có làm giảm tỷ lệ bỏ giỏ hàng hay không.

Người dùng có thể tạo passkeys trong các bối cảnh sau:

• Bối cảnh ngân hàng: Các luồng tạo được kích hoạt sau khi người dùng đăng nhập vào ngân hàng của họ, tận dụng sự tin cậy và quen thuộc của môi trường ngân hàng.

• Cài đặt tài khoản nhà cung cấp thanh toán: Người dùng thiết lập passkeys trực tiếp trong cài đặt “Hồ sơ của tôi” hoặc “Bảo mật” trên tên miền của nhà cung cấp thanh toán.

• Thanh toán của bên bán: Nhắc ở bước thanh toán cuối cùng, đặc biệt nếu người dùng chưa từng tạo passkey trước đó. Điều này có thể được nhúng (iframe) hoặc thông qua chuyển hướng.

Trong mỗi kịch bản, quy trình passkey cơ bản tuân theo các bước tương tự - xác nhận của người dùng, nhắc sinh trắc học/PIN và đăng ký thông tin xác thực. SDK của Corbado đảm bảo rằng các ràng buộc cross-origin (nếu được nhúng) hoặc bối cảnh tên miền của bên thứ nhất (nếu được chuyển hướng) được xử lý liền mạch ở chế độ nền.

Corbado đính kèm mỗi passkey mới vào định danh người dùng thích hợp - cho dù đó là “bankPrefix_userId” hay một tham chiếu người dùng nội bộ trong hệ thống của nhà cung cấp thanh toán - để tất cả việc sử dụng sau đó có thể được truy vết đến đúng tài khoản người dùng.

Siêu dữ liệu này cũng rất quan trọng cho các phân tích nâng cao: ví dụ, xem các chiến dịch tạo passkey của RBC hoạt động như thế nào so với của TD, hoặc tỷ lệ tạo khác nhau như thế nào giữa các lần thanh toán của bên bán và các luồng “cài đặt tài khoản” trực tiếp.

Logic SDK của Corbado có thể thích ứng với việc liệu việc tạo passkey cross-origin có được phép hay không (trong Chrome hoặc Edge hiện đại) hoặc phải chuyển sang chuyển hướng một cách duyên dáng cho Safari.

Báo cáo lỗi tích hợp giúp xác định xem có bất kỳ nhóm người dùng nào liên tục thất bại trong việc tạo passkey (ví dụ: các phiên bản iOS cũ hơn, các thiết bị Windows của công ty), để nhóm sản phẩm có thể tinh chỉnh hướng dẫn hoặc các chiến lược dự phòng.

Đội ngũ của chúng tôi đã thực hiện các thử nghiệm tạo passkey sâu rộng với các khách hàng doanh nghiệp, tìm hiểu xem những cụm từ, vị trí nút và thời điểm nào mang lại tỷ lệ chấp nhận tốt nhất.

Chúng tôi kết hợp những phương pháp tốt nhất này vào mỗi màn hình tạo, trong khi vẫn cho phép tùy chỉnh hoàn toàn cho nhu cầu thương hiệu và tuân thủ.

Nhìn chung, việc tạo passkey là giai đoạn quan trọng nhất để đảm bảo tỷ lệ chấp nhận cao: ngay cả luồng đăng nhập passkey thanh lịch nhất cũng sẽ không có ý nghĩa nếu người dùng không bao giờ đăng ký thông tin xác thực ngay từ đầu. Bằng cách cung cấp các màn hình tạo đồng nhất, có thể theo dõi trên tất cả các kênh có thể - ngân hàng, tên miền của nhà cung cấp thanh toán hoặc trang thanh toán của bên bán - và trang bị cho chúng các phân tích KPI và A/B testing, Corbado giúp các nhà cung cấp thanh toán thúc đẩy việc áp dụng passkey có thể mở rộng thực sự, phản ánh trải nghiệm người dùng của các giải pháp gốc như Apple Pay.

Khi người dùng đã tạo một passkey, bước tiếp theo là đảm bảo họ thực sự sử dụng passkey đó để thanh toán nhanh chóng, không ma sát như Apple Pay trình bày một luồng thanh toán Apple Pay.

Tại Corbado, chúng tôi đã phát triển một cơ chế “Passkey Intelligence” tự động phát hiện khi môi trường của người dùng có khả năng chứa một passkey hợp lệ, cho phép trải nghiệm thanh toán một chạm thực sự. Dưới đây là các yếu tố cốt lõi làm cho điều này trở nên khả thi.

Khi một người dùng quay lại được nhận dạng, giao diện người dùng của Corbado sẽ hiển thị một nút chuyên dụng (ví dụ: “Thanh toán bằng Passkey”) thay vì buộc nhập thông tin xác thực dự phòng.

Một lần chạm vào nút này sẽ kích hoạt luồng WebAuthn get() (hoặc lời nhắc passkey gốc), cho phép người dùng xác thực ngay lập tức thông qua sinh trắc học/PIN - không cần thêm bước hoặc nhập liệu vào biểu mẫu.

SDK của Corbado thu thập các tín hiệu (ví dụ: cookie bộ nhớ cục bộ, việc sử dụng passkey thành công trước đó, phát hiện môi trường) để dự đoán xem thiết bị + trình duyệt hiện tại có khả năng có passkey hợp lệ cho người dùng này hay không.

Nếu cookie bị xóa hoặc không khả dụng, Corbado sẽ chuyển sang các phương pháp phỏng đoán bổ sung (ví dụ: môi trường đã biết của người dùng, gợi ý người dùng do bên bán cung cấp) để quyết định xem có an toàn để tự động bắt đầu luồng passkey hay không.

Nếu không có đủ bằng chứng cho thấy có passkey, giao diện người dùng sẽ cung cấp các luồng dự phòng một cách duyên dáng hoặc nhắc người dùng xác nhận họ có passkey.

Corbado không lưu trữ thông tin nhận dạng cá nhân (PII) như email đầy đủ hoặc tên.

Thay vào đó, bên bán có thể chuyển một định danh đã được băm hoặc che giấu (ví dụ: một chuỗi băm email hoặc ID người dùng nội bộ). Corbado sử dụng thông tin đó để tra cứu các đăng ký passkey tiềm năng, sau đó quyết định xem có nên bắt đầu xác thực bằng passkey hay quay lại một phương pháp chung hơn. Nếu được nhà cung cấp thanh toán hỗ trợ, chúng tôi có thể tra cứu thông tin do bên bán cung cấp để tìm ID người dùng nội bộ.

Điều này đảm bảo quyền riêng tư của người dùng trong khi vẫn cho phép khớp môi trường với độ chính xác cao.

Trong các kịch bản mà passkey của người dùng có thể đã tồn tại nhưng không thể phát hiện được (ví dụ: cookie bị xóa, thiết bị mới), Passkey Intelligence của Corbado sẽ phân tích cẩn thận xem việc tự động bắt đầu lời nhắc passkey có hợp lý hay không.

Thay vào đó, người dùng sẽ thấy các luồng dự phòng thay thế hoặc tùy chọn “quét passkey từ thiết bị khác” trong khi vẫn giữ được một con đường nhanh chóng để quay lại sử dụng passkey nếu người dùng có thể xác nhận thủ công rằng họ có một passkey.

Mỗi khi Corbado chọn bắt đầu hoặc bỏ qua một lời nhắc passkey một chạm, quyết định đó sẽ được ghi lại. Theo thời gian, bạn có thể thấy chính xác trình duyệt hoặc loại thiết bị nào mang lại độ phủ passkey cao nhất so với những trình duyệt thường xuyên quay lại phương án dự phòng.

Vòng lặp phản hồi phân tích này cho phép bạn xác định các môi trường hoạt động kém hiệu quả (ví dụ: các phiên bản iOS hoặc Android cụ thể) hoặc các phân khúc người dùng nơi việc sử dụng passkey vẫn còn thấp - để bạn có thể tinh chỉnh các chiến lược giới thiệu hoặc giáo dục.

Bất kể người dùng đến từ chiến dịch tạo passkey của ngân hàng hay trực tiếp tại trang thanh toán của bên bán, logic một chạm vẫn nhất quán.

Corbado đảm bảo rằng nếu một passkey được tìm thấy (dựa trên cookie tên miền, token bộ nhớ cục bộ hoặc tín hiệu passkey intelligence), người dùng sẽ ngay lập tức được trình bày với luồng đăng nhập/thanh toán không ma sát nhất.

Tóm tắt

Nói tóm lại, việc sử dụng passkey một chạm là thành quả cuối cùng của việc tạo ra passkey ngay từ đầu. Bằng cách tận dụng Passkey Intelligence - một sự kết hợp giữa phát hiện môi trường, sử dụng PII tối thiểu và logic dự phòng - Corbado đảm bảo người dùng chỉ được trình bày xác thực bằng passkey khi nó thực sự có khả năng thành công. Điều này làm giảm đáng kể các lần thử thất bại, tránh sự thất vọng của người dùng và thúc đẩy thói quen sử dụng passkey, đỉnh điểm là một luồng thanh toán một chạm sánh ngang với sự tiện lợi của Apple Pay hoặc các trải nghiệm thanh toán gốc khác.

Ngoài việc chỉ đơn giản là kích hoạt passkeys, việc hiểu chúng được áp dụng và sử dụng hiệu quả như thế nào trên các thiết bị, trình duyệt và hành trình người dùng khác nhau là rất quan trọng. Các nhà cung cấp thanh toán cần dữ liệu cứng về việc liệu passkeys có thực sự giảm ma sát, cắt giảm gian lận và cải thiện chuyển đổi hay không. Dựa trên các phương pháp tốt nhất từ Hướng dẫn Mua và Xây dựng Passkey, Corbado cung cấp một lớp phân tích phong phú cho phép bạn theo dõi, phân đoạn và tối ưu hóa hiệu suất passkey trong thời gian thực.

Dưới đây là những điểm nổi bật chính.

Corbado tổ chức tất cả các sự kiện passkey thành một phễu: từ thời điểm người dùng được nhắc tạo passkey, qua đăng ký thành công, đến các lần đăng nhập/thanh toán tiếp theo (sử dụng passkey).

Việc trực quan hóa phễu này cho phép bạn xem người dùng bỏ ngang ở đâu - ví dụ: bao nhiêu người không bao giờ bắt đầu tạo, bao nhiêu người bỏ ngang giữa chừng, hoặc bao nhiêu người quay lại các phương pháp dự phòng khi đăng nhập.

Dựa trên kinh nghiệm sâu rộng của chúng tôi trong việc giúp các doanh nghiệp triển khai passkeys, chúng tôi tập trung vào các chỉ số ảnh hưởng trực tiếp đến ROI và sự hài lòng của người dùng:

• Tỷ lệ chấp nhận Passkey: Có bao nhiêu người dùng thấy lời nhắc tạo đã hoàn thành việc đăng ký passkey?

• Tỷ lệ tạo Passkey thành công: Trong số những người bắt đầu quy trình (nhấp vào “Tạo Passkey”), tỷ lệ phần trăm nào hoàn thành mà không có lỗi hoặc bỏ ngang?

• Tỷ lệ sử dụng Passkey: Người dùng quay lại thực sự chọn passkeys để xác thực hoặc thanh toán hàng ngày thường xuyên như thế nào, thay vì mật khẩu hoặc OTP?

• Tỷ lệ đăng nhập Passkey thành công: Tỷ lệ phần trăm các lần thử passkey thành công mà không cần phương án dự phòng hoặc gây thất vọng cho người dùng.

• Sử dụng phương án dự phòng: Có bao nhiêu người dùng bắt đầu một luồng passkey nhưng lại quay về các phương pháp cũ? Điều này báo hiệu các rào cản tiềm ẩn về UX hoặc kỹ thuật.

Corbado tự động gắn thẻ mỗi sự kiện với hệ điều hành (Windows, macOS, iOS, Android) và trình duyệt (Chrome, Safari, Edge, Firefox, v.v.).

Với sự phân đoạn này, bạn có thể thấy liệu, ví dụ, iOS Safari có tỷ lệ bỏ ngang passkey cao hơn, hoặc liệu Windows Chrome có mang lại tỷ lệ chấp nhận passkey tốt hơn hay không.

Dữ liệu này cũng giúp bạn tinh chỉnh các chiến lược dự phòng - đặc biệt nếu các hạn chế cross-origin của Apple ảnh hưởng đến cơ sở người dùng của bạn nhiều hơn dự kiến.

Chúng tôi cung cấp các chế độ xem bảng điều khiển cho mỗi giai đoạn của phễu passkey: lời nhắc tạo, đăng ký thành công, đăng nhập của người dùng, sử dụng phương án dự phòng.

Các biểu đồ thời gian thực cho phép các nhà quản lý sản phẩm phát hiện xu hướng nhanh chóng (ví dụ: nếu một bản cập nhật hệ điều hành mới làm hỏng các luồng passkey).

Các cảnh báo tự động có thể thông báo cho nhóm của bạn nếu tỷ lệ thành công của passkey giảm đáng kể - để bạn có thể nhanh chóng điều tra một lỗi trình duyệt mới hoặc vấn đề cấu hình.

Mỗi luồng passkey (từ tạo đến đăng nhập) được ghi lại với các sự kiện từng bước có dấu thời gian, cho phép phân tích pháp y sâu.

Bạn có thể nhanh chóng tìm kiếm theo mã băm người dùng, ID phiên hoặc chữ ký thiết bị để xem chính xác người dùng đã gặp khó khăn ở đâu hoặc mã lỗi nào đã được trả về.

Điều này rất quan trọng cho các lần triển khai quy mô lớn, nơi bạn không thể dựa vào các phiếu hỗ trợ mang tính giai thoại mà cần dữ liệu chính xác để giải quyết các vấn đề của người dùng.

Nền tảng phân tích của Corbado hỗ trợ A/B testing được tích hợp vào phễu passkey: kiểm tra các văn bản CTA khác nhau, lời nhắc tạo, thông báo dự phòng hoặc vị trí của các nút “Tạo Passkey” trong luồng thanh toán.

Các chỉ số như “Tỷ lệ chấp nhận Passkey” hoặc “Tỷ lệ dự phòng” có thể được đo lường song song cho mỗi biến thể.

Phương pháp này đảm bảo sự cải tiến liên tục, phản ánh sự thành công của các nhà áp dụng passkey hàng đầu, những người tinh chỉnh các luồng theo thời gian.

Trong khi các bảng điều khiển của Corbado cung cấp một giao diện trực quan sẵn có, bạn cũng có thể xuất hoặc webhook các điểm dữ liệu chính (ví dụ: thành công tạo passkey, đăng nhập) vào các công cụ BI hoặc SIEM của mình.

Điều này cho phép các nhà cung cấp thanh toán kết hợp các KPI passkey vào các bộ phân tích rộng hơn - theo dõi ROI từ passkeys cùng với các chỉ số bảo mật, tiếp thị hoặc hoạt động khác.

Tóm tắt

Bằng cách đo lường và trực quan hóa mọi bước của hành trình passkey - trên các kết hợp HĐH/trình duyệt, các luồng tạo và các kịch bản đăng nhập - Corbado cung cấp cho bạn những thông tin chi tiết cần thiết để liên tục tinh chỉnh sản phẩm passkey của mình. Những phân tích này không chỉ xác nhận rằng passkeys đã được kích hoạt; chúng chứng minh liệu người dùng có thực sự áp dụng chúng ở quy mô lớn hay không, xác định các điểm ma sát và giúp bạn thúc đẩy tỷ lệ sử dụng đến mức passkeys thực sự thay thế mật khẩu để thanh toán an toàn, không ma sát.

Đối với các nhà cung cấp thanh toán, việc chỉ tạo một passkey cho mỗi người dùng thường không đủ để mang lại trải nghiệm xác thực thực sự liền mạch. Trong thực tế, người dùng thường xuyên chuyển đổi thiết bị - từ máy tính xách tay ở nơi làm việc đến điện thoại thông minh cá nhân, máy tính bảng và thậm chí cả máy tính dùng chung trong gia đình. Đảm bảo mọi thiết bị đều có passkey hợp lệ cho cùng một tài khoản là rất quan trọng để giảm ma sát và ngăn chặn việc quay lại sử dụng mật khẩu. Apple Pay đạt được điều này bằng cách có thể tận dụng Tài khoản iCloud trên tất cả các thiết bị được kết nối iCloud.

Dưới đây là cách Corbado giúp duy trì độ phủ đa thiết bị trong suốt vòng đời của người dùng.

• Màn hình tạo Passkey chính: Corbado ban đầu tập trung vào việc giúp mỗi người dùng đăng ký ít nhất một passkey - passkey “chính” - ở bất cứ đâu họ gặp luồng thanh toán của bạn lần đầu tiên (ví dụ: tại trang thanh toán, trong cổng thông tin trực tuyến của ngân hàng hoặc trong cài đặt tài khoản của bạn).

• Màn hình tạo Passkey phụ: Sau khi người dùng đã đăng ký thành công passkey đầu tiên của họ, các lần đăng nhập tiếp theo trên các thiết bị khác có thể tự động nhắc một luồng ngắn “Thêm thiết bị này”. Điều này đảm bảo người dùng nhanh chóng có được quyền truy cập passkey không ma sát trên tất cả các thiết bị liên quan mà không cần nhập lại mật khẩu hoặc chuyển sang các phương pháp dự phòng.

Ngay cả khi người dùng có passkey trên một thiết bị, họ có thể xuất hiện mà không có passkey cục bộ trên thiết bị thứ hai (do cài đặt lại hệ điều hành, xóa cookie hoặc đơn giản là chưa bao giờ tạo passkey trên thiết bị đó).

Phương pháp của Corbado thường sử dụng một bước kết hợp: người dùng có thể đăng nhập bằng passkey hiện có trên điện thoại của họ hoặc một phương pháp dự phòng, sau đó ngay lập tức “chữa lành” khoảng trống bằng cách tạo một passkey trên thiết bị hiện tại.

Quá trình tự sửa chữa này giúp giữ độ phủ cao và loại bỏ việc sử dụng phương án dự phòng lặp đi lặp lại trong tương lai.

Thông qua các tín hiệu đa thiết bị và “Passkey Intelligence” của Corbado, hệ thống có thể phát hiện khi một người dùng có passkey hiện có đã chuyển sang một thiết bị chưa đăng ký.

Nếu chiến lược UX của bạn nhằm mục đích đạt độ phủ tối đa, Corbado có thể tự động nhắc: “Bạn có muốn thêm một passkey trên thiết bị này để không phải dùng phương án dự phòng lần sau không?”

Người dùng có thể bỏ qua điều này nếu họ đang ở trên một thiết bị dùng một lần, nhưng thường đánh giá cao sự tiện lợi của việc đăng nhập sinh trắc học dựa trên passkey sau khi nó được giải thích.

SDK của Corbado cung cấp các luồng màn hình riêng biệt cho “tạo passkey lần đầu” (tức là lần đầu tiên người dùng đăng ký thông tin xác thực) và tạo “thiết bị phụ”.

Thông điệp có thể khác nhau: ví dụ: “Bảo mật thiết bị mới này bằng passkey” so với “Thiết lập passkey đầu tiên của bạn.”

Điều này đảm bảo sự rõ ràng cho người dùng cuối, những người hiểu sự khác biệt giữa việc đăng ký ban đầu và mở rộng độ phủ sang các thiết bị bổ sung.

Đôi khi việc tạo passkey có thể thất bại giữa chừng hoặc hệ điều hành của người dùng đã lỗi thời. Trong những kịch bản đó, Corbado ghi lại nỗ lực một phần và đề xuất các biện pháp khắc phục có thể một cách duyên dáng (chuyển hướng, dự phòng thủ công hoặc luồng QR đa thiết bị).

Người dùng luôn có thể thử lại việc thêm passkey trên thiết bị đó vào lần đăng nhập tiếp theo, hoặc dựa vào một passkey hiện có từ một thiết bị khác.

Phân tích của Corbado không chỉ cho thấy có bao nhiêu người dùng đã tạo passkey ban đầu, mà còn có bao nhiêu người đã mở rộng passkeys sang nhiều thiết bị.

Bạn có thể theo dõi tỷ lệ phủ sóng thiết bị (ví dụ: 1 thiết bị so với 2 hoặc nhiều hơn) và xem điều đó tương quan như thế nào với việc giảm sử dụng phương án dự phòng hoặc cải thiện thành công thanh toán.

Điều này giúp nhóm của bạn ưu tiên giáo dục người dùng, lời nhắc trong ứng dụng hoặc các luồng đăng ký dựa trên ngân hàng để tăng cường sự thâm nhập của passkey đa thiết bị.

Tóm tắt: Tại sao độ phủ đa thiết bị lại quan trọng

Nếu không có độ phủ nhất quán trên tất cả các thiết bị của người dùng, bạn có nguy cơ người dùng bị buộc phải quay lại các biện pháp xác thực dự phòng bất cứ khi nào họ ở trên một thiết bị “không có passkey”. Điều này phá vỡ trải nghiệm không ma sát và giữ chi phí hoạt động ở mức cao (ví dụ: phí SMS, chi phí hỗ trợ). Bằng cách cung cấp các màn hình tạo passkey phụ, chữa lành dự phòng kết hợp và các lời nhắc dựa trên môi trường, Corbado đảm bảo mọi người dùng cuối cùng đều có thể duy trì passkeys trên tất cả các thiết bị họ sử dụng - thúc đẩy tỷ lệ chấp nhận tổng thể cao hơn và giảm thiểu những khoảnh khắc dự phòng khó chịu đó.

Một trong những quan niệm sai lầm lớn nhất khi xây dựng SDK passkeys của bên thứ ba là phần khó nhất là triển khai các lệnh gọi WebAuthn (ví dụ: navigator.credentials.create() hoặc navigator.credentials.get()).

Trong thực tế, đây là phần “dễ” - một hoặc hai lệnh gọi API để kích hoạt quy trình cơ bản. Sự phức tạp thực sự và yếu tố quyết định thành công thực sự nằm ở việc đảm bảo việc áp dụng quy mô lớn và xây dựng một hệ sinh thái đầy đủ xung quanh các lệnh gọi API đó.

Dưới đây là những điểm chính - được củng cố bởi Hướng dẫn Mua và Xây dựng Passkey - nêu bật lý do tại sao các triển khai tối thiểu, chỉ tập trung vào quy trình thường không mang lại kết quả trong thế giới thực.

• Triển khai quy trình: Việc tạo hoặc xác thực một passkey thường chỉ liên quan đến một vài dòng JavaScript để gọi navigator.credentials.create() hoặc navigator.credentials.get().

• Sự phức tạp thực sự: Đảm bảo luồng passkey hoạt động trên nhiều trình duyệt, xử lý lỗi một cách duyên dáng và cung cấp phương án dự phòng cho các hệ thống cũ hơn. Bạn cũng sẽ cần quản lý phiên mạnh mẽ, ghi nhật ký lỗi, phân tích, chiến lược phủ sóng thiết bị, và nhiều hơn nữa.

• Những cạm bẫy không lường trước: Khi bạn vượt ra ngoài một “bản demo công nghệ” của passkeys, bạn sẽ phát hiện ra các trường hợp đặc biệt như chặn cross-origin, hạn chế của WebView nhúng và sự phức tạp của việc đồng bộ hóa đa thiết bị. Đây là những điều chưa biết làm hỏng các bản dựng tự phát triển ngây thơ.

• Quy trình và Việc áp dụng: Ngay cả khi bạn có một quy trình WebAuthn hoàn hảo, tỷ lệ người dùng áp dụng thấp (ví dụ: tỷ lệ sử dụng passkey <5%) sẽ mang lại lợi ích bảo mật hoặc UX tối thiểu.

• Phương pháp toàn diện: Một lần triển khai passkey thành công đòi hỏi mọi thứ từ các lời nhắc người dùng hấp dẫn và bản sao được A/B-tested đến các luồng phủ sóng đa thiết bị, xử lý dự phòng và phân tích liên tục - vượt xa các lệnh gọi quy trình cơ bản.

• Thông tin chi tiết từ Hướng dẫn Mua và Xây dựng: Hướng dẫn nhấn mạnh rằng việc thúc đẩy áp dụng passkey - không chỉ là kích hoạt passkeys - cuối cùng quyết định ROI. Nếu người dùng không đăng ký và tích cực sử dụng passkeys, dự án thực chất bị đình trệ ở “MFA 2.0” mà không có cải thiện tỷ lệ chuyển đổi.

• Xử lý dự phòng & Lỗi không hoàn chỉnh: Thiếu logic dự phòng nâng cao hoặc gỡ lỗi thời gian thực có thể dẫn đến việc người dùng bị khóa và chi phí hỗ trợ cao hơn.

• Độ phủ đa thiết bị phân mảnh: Nếu không có kế hoạch đồng bộ hóa các thiết bị bổ sung hoặc “chữa lành” các khoảng trống passkey, người dùng sẽ quay lại mật khẩu bất cứ khi nào họ chuyển nền tảng.

• Phân tích & A/B Testing hạn chế: Thiếu dữ liệu về các phễu tạo passkey hoặc việc sử dụng môi trường có nghĩa là bạn không thể cải thiện việc áp dụng một cách có hệ thống hoặc nhanh chóng khắc phục các vấn đề mới của trình duyệt.

• Giao diện người dùng & Phương pháp tốt nhất được xây dựng sẵn: Thay vì chỉ cung cấp các điểm cuối của quy trình, một giải pháp phù hợp (như Corbado) sẽ gói gọn các màn hình tùy chỉnh thương hiệu, các luồng dự phòng, xử lý lỗi và độ phủ đa thiết bị.

• Trí tuệ thích ứng & Ghi nhật ký: Tự động phát hiện sự hiện diện có khả năng của passkey, hướng dẫn người dùng tạo hoặc sửa các passkey bị thiếu và ghi lại các nhật ký sự kiện chi tiết.

• Những điều chưa biết tập trung vào việc áp dụng: Nhiều chi tiết - như dự phòng dựa trên email hoặc cách xử lý các thiết bị của công ty - không rõ ràng cho đến khi người dùng bắt đầu gặp phải chúng trong các lần triển khai thực tế.

• Tìm hiểu sâu hơn về chiến lược áp dụng: Hướng dẫn Mua và Xây dựng Passkey nêu bật cách cân bằng chi phí, thời gian ra mắt thị trường và những phức tạp ẩn giấu của một giải pháp passkey mạnh mẽ.

• Các tiêu chuẩn thực tế: Tìm hiểu cách các lần triển khai quy mô lớn từ các ngân hàng lớn và các nhà cung cấp thương mại điện tử đã vượt qua những điều chưa biết phát sinh sau khi bạn đã viết mã logic quy trình “đơn giản”.

• Thành công bền vững: Đầu tư vào một nền tảng đã được thiết lập với các mô hình áp dụng đã được chứng minh đảm bảo bạn không bị mắc kẹt trong việc phát minh lại bánh xe - và phát hiện ra những bất ngờ tốn kém trên đường đi.

Tóm lại

Chỉ đơn thuần kết nối quy trình WebAuthn là không đủ để đạt được việc áp dụng passkey có ý nghĩa. Thành công thực sự phụ thuộc vào việc điều phối các luồng từ đầu đến cuối - như các phương án dự phòng, phân tích, mở rộng đa thiết bị và các hành trình người dùng được A/B-tested. Bằng cách giải quyết những phức tạp tinh tế vượt ra ngoài “chỉ là quy trình”, bạn có thể biến dự án passkey của mình từ một sự tò mò kỹ thuật thành một giải pháp xác thực thực sự không ma sát, được sử dụng rộng rãi và tiết kiệm chi phí.

Ngoài những phức tạp xung quanh các luồng cross-origin, việc áp dụng của người dùng và quản lý vòng đời passkey, các cân nhắc về lưu trữ và triển khai là rất quan trọng đối với bất kỳ giải pháp passkey quy mô lớn nào. Các nhà cung cấp thanh toán thường phải đối mặt với các yêu cầu tuân thủ nghiêm ngặt, yêu cầu về nơi cư trú của dữ liệu và các yêu cầu về khả năng phục hồi có thể thay đổi đáng kể giữa các khu vực. Dưới đây là cách Corbado (hoặc các giải pháp mạnh mẽ tương tự) giải quyết những mối quan tâm này:

Để tuân thủ chủ quyền dữ liệu hoặc các khung pháp lý (ví dụ: GDPR ở Châu Âu, PIPEDA ở Canada hoặc NIST/HIPAA ở Hoa Kỳ), một số nhà cung cấp phải giữ dữ liệu trong các ranh giới địa lý cụ thể.

Một kiến trúc độc lập vùng đảm bảo dịch vụ passkey có thể được triển khai ở bất kỳ vùng AWS nào mong muốn, đáp ứng các yêu cầu tuân thủ địa phương mà không làm giảm hiệu suất hoặc khả năng mở rộng.

Sự linh hoạt này đặc biệt quan trọng nếu cơ sở người dùng của bạn trải rộng trên nhiều quốc gia, mỗi quốc gia thực thi các quy tắc xử lý dữ liệu khác nhau.

Đối với các luồng xác thực thanh toán quan trọng, thời gian chết không phải là một lựa chọn. Corbado sử dụng các triển khai multi-AZ, phân phối các thành phần chính trên nhiều vùng sẵn sàng.

Thiết lập này giúp đảm bảo rằng nếu một AZ gặp sự cố hoặc vấn đề kết nối, cơ sở hạ tầng passkey của bạn ở các vùng khác vẫn trực tuyến - để người dùng có thể tiếp tục xác thực.

Kết quả là một hệ thống có khả năng phục hồi cao hơn, đáp ứng các SLA nghiêm ngặt cho các dịch vụ tài chính và các trang thương mại điện tử, nơi ngay cả thời gian chết ngắn cũng có thể dẫn đến tác động doanh thu đáng kể.

Một số nhà cung cấp thanh toán thích một cụm riêng tư chuyên dụng - dù là để cách ly dữ liệu chặt chẽ hơn, kiểm tra tuân thủ tùy chỉnh, hay kiểm soát sâu hơn đối với các bản vá và cập nhật.

Một giải pháp linh hoạt có thể hỗ trợ cả hai thái cực:

• SaaS / Đa người thuê: Nhanh chóng triển khai, chi phí thấp hơn, phù hợp cho nhiều triển khai quy mô vừa.

• Phiên bản đám mây chuyên dụng: Một tài khoản và phiên bản cơ sở dữ liệu riêng biệt trong vùng bạn chọn, dành cho những người cần cách ly hoặc tuân thủ bổ sung.

Passkeys phải xử lý các khối lượng công việc đột biến: các đợt tăng lưu lượng truy cập lớn (ví dụ: các đợt mua sắm cao điểm trong kỳ nghỉ lễ hoặc bán vé sự kiện) có thể làm quá tải các hệ thống có công suất cố định.

Một back-end passkey hiện đại có thể mở rộng theo chiều ngang trong thời gian thực, thêm hoặc bớt các phiên bản tính toán dựa trên các mẫu sử dụng. Việc tự động mở rộng này đảm bảo hiệu suất nhất quán mà không cần can thiệp thủ công.

Các tiêu chuẩn ngành như PCI-DSS, PSD2 SCA, hoặc ISO 27001 thường áp dụng cho các nhà cung cấp thanh toán. Một nhà cung cấp passkey mạnh mẽ thường tích hợp với các khung tuân thủ đã biết ngay từ đầu:

• Mã hóa khi lưu trữ và khi truyền: Bảo mật dữ liệu bằng TLS mạnh và mã hóa phía máy chủ hoặc phía máy khách cho các thông tin xác thực được lưu trữ.

• Ghi nhật ký và Dấu vết kiểm toán: Nhật ký chi tiết cho mỗi hoạt động passkey, phù hợp cho các cơ quan quản lý hoặc điều tra sự cố.

• Vá lỗi bảo mật thường xuyên: Tự động vá lỗi hệ điều hành và container để ngăn chặn các lỗ hổng, đặc biệt liên quan trong một môi trường multi-AZ linh hoạt.

Khả năng phục hồi thực sự vượt ra ngoài một khu vực duy nhất. Một số nhà cung cấp yêu cầu sao chép liên vùng để duy trì tính liên tục của hoạt động kinh doanh trong các thảm họa quy mô lớn.

Dự phòng địa lý có thể sao chép dữ liệu passkey ở một khu vực hoặc lục địa khác, đảm bảo rằng thời gian chết của cả một khu vực không làm ngừng các luồng xác thực.

Tóm tắt: Multi-AZ và Độc lập vùng

Việc chọn một giải pháp passkey có thể dễ dàng mở rộng, thích ứng về mặt địa lý và chống lại cả các sự cố cục bộ và thảm họa quy mô lớn là điều cần thiết đối với các nhà cung cấp thanh toán hiện đại - đặc biệt là những nhà cung cấp hoạt động ở nhiều quốc gia hoặc tuân thủ nghiêm ngặt. Bằng cách hỗ trợ các triển khai multi-AZ và các cấu hình độc lập vùng, Corbado (hoặc các giải pháp tương đương) đảm bảo các dịch vụ passkey thanh toán vẫn luôn sẵn sàng và tuân thủ, bất kể người dùng hoặc dữ liệu của bạn ở đâu.

Passkeys thực sự đại diện cho thế hệ tiếp theo của xác thực an toàn, thân thiện với người dùng. Tuy nhiên, các nhà cung cấp thanh toán phải đối mặt với những thách thức riêng mà thiết kế WebAuthn truyền thống không trực tiếp giải quyết. Những hạn chế này rõ rệt nhất ở:

1. Việc Safari từ chối cho phép tạo passkey cross-origin (đặc biệt trong iframes), buộc phải sử dụng phương pháp dựa trên chuyển hướng hoặc dựa vào các passkeys đã được tạo trước đó.

2. Việc Apple thiếu hỗ trợ cho Secure Payment Confirmation (SPC), ngăn cản một luồng thanh toán không ma sát, được tiêu chuẩn hóa trên các trình duyệt và nền tảng.

Tuy nhiên, passkeys vẫn rất cần thiết cho các nhà cung cấp thanh toán muốn cung cấp trải nghiệm thanh toán giống như Apple Pay: hợp lý, an toàn và cực kỳ đơn giản cho người dùng cuối. Dưới đây là cách giải quyết những thách thức này và cách Corbado giúp đỡ.

1. Những hạn chế hiện tại của việc sử dụng passkeys trong bối cảnh bên thứ ba đối với các nhà cung cấp thanh toán là gì?

• Hạn chế Cross-Origin: Safari (và một số trình duyệt cũ hơn) chặn navigator.credentials.create() khi được nhúng qua iframe. Điều này có nghĩa là bạn không thể tạo passkeys mới một cách liền mạch trong một luồng nhúng của bên bán trên các trình duyệt đó.

• Thiếu hỗ trợ SPC: Việc Apple từ chối áp dụng SPC hạn chế khả năng tiêu chuẩn hóa các xác nhận thanh toán cross-origin, buộc các nhà cung cấp phải duy trì các phương pháp riêng biệt cho Safari so với Chrome/Edge.

• Ràng buộc WebView & Ứng dụng gốc: WebView nhúng thường làm hỏng các luồng passkey, yêu cầu các phiên trình duyệt hệ thống hoặc các phương pháp chuyên biệt khác để quản lý sự phù hợp nguồn gốc tên miền.

• Độ phủ thiết bị phân mảnh: Ngay cả khi người dùng tạo một passkey trên một thiết bị hoặc trình duyệt, họ có thể thiếu độ phủ trên các thiết bị khác, gây ra việc sử dụng phương án dự phòng.

2. Làm thế nào các nhà cung cấp thanh toán có thể vượt qua những hạn chế này để triển khai thành công việc tích hợp passkey của bên thứ ba?

• Tận dụng chiến lược kết hợp (Iframe + Chuyển hướng):

  • Iframe cho các trình duyệt hỗ trợ đầy đủ passkeys cross-origin, cung cấp một giao diện người dùng nhúng liền mạch.

  • Chuyển hướng làm phương án dự phòng cho Safari hoặc các thiết lập không tương thích, đảm bảo việc tạo passkey mạnh mẽ luôn khả thi.

• WebView hệ thống hoặc Chuyển hướng trình duyệt trong ứng dụng gốc:

  • Thay vì nhúng iframes trong các ứng dụng của bên bán, hãy chuyển sang ASWebAuthenticationSession (iOS) hoặc Chrome Custom Tabs (Android) để bảo tồn tính liên tục của tên miền.

  • Bộ công cụ tập trung vào việc áp dụng: Cung cấp các lời nhắc tạo passkey hấp dẫn, các luồng phủ sóng đa thiết bị và các bước “chữa lành” dự phòng để giữ tỷ lệ sử dụng cao.

  • Phân tích nâng cao & A/B Testing:

    • Liên tục đo lường tỷ lệ thành công/dự phòng của passkey, độ phủ môi trường và phản hồi của người dùng để tinh chỉnh các luồng của bạn.

    • Sử dụng trí tuệ passkey để tự động trình bày passkeys chỉ khi thành công có khả năng xảy ra.

Trong suốt hướng dẫn này, chúng tôi đã nhấn mạnh rằng chỉ đơn thuần kết nối navigator.credentials.create() là không đủ. Thành công thực sự phụ thuộc vào tỷ lệ chấp nhận passkey cao, trải nghiệm người dùng nhất quán và độ phủ đa thiết bị có khả năng phục hồi. Đó là nơi Corbado vượt trội:

• Hỗ trợ thống nhất cho Iframe & Chuyển hướng: SDK của Corbado tự động phát hiện xem một luồng passkey nhúng có khả thi hay không (ví dụ: trên Chrome hoặc Edge) hoặc nếu cần chuyển hướng (ví dụ: Safari). Điều này tối đa hóa khả năng tương thích mà không yêu cầu các bên bán phải duy trì nhiều đường dẫn mã.

  • Trải nghiệm thanh toán một chạm: Với Passkey Intelligence, Corbado ngay lập tức phát hiện xem môi trường của người dùng có khả năng có passkey hợp lệ hay không - kích hoạt một luồng “thanh toán bằng passkey” không ma sát. Phương pháp này tương tự với thanh toán một chạm của Apple Pay, thúc đẩy việc sử dụng passkey hàng ngày thay vì biến nó thành một bước MFA hiếm khi được sử dụng.

  • Độ phủ đa thiết bị mạnh mẽ: Corbado cung cấp các luồng đặc biệt cho việc tạo passkey ban đầu so với việc mở rộng passkey phụ, để mỗi người dùng có thể nhanh chóng thêm độ phủ cho các thiết bị mới sau khi đăng nhập qua phương án dự phòng hoặc QR đa thiết bị.

  • Tập trung vào việc áp dụng toàn diện: Thông qua các phân tích tích hợp, A/B testing và xử lý lỗi, Corbado giúp các nhà cung cấp xác định các điểm ma sát và tối ưu hóa việc chấp nhận passkey một cách có hệ thống. Điều này mở rộng từ các lời nhắc passkey đầu tiên của ngân hàng đến trải nghiệm thanh toán của các bên bán.

  • Lưu trữ linh hoạt, tuân thủ: Các triển khai multi-AZ, độc lập vùng của Corbado phù hợp với các yêu cầu tuân thủ nghiêm ngặt của ngành thanh toán (PCI DSS, PSD2 SCA, v.v.), đảm bảo thời gian hoạt động và tuân thủ các quy tắc về nơi cư trú của dữ liệu trên toàn thế giới.

Trong khi các chính sách hạn chế của Apple tạo ra ma sát không thể tránh khỏi, các nhà cung cấp thanh toán vẫn có thể triển khai thành công passkeys của bên thứ ba bằng cách:

1. Kết hợp phương pháp nhúng (iframe) với phương án dự phòng chuyển hướng.

2. Áp dụng các webview hệ thống chuyên biệt hoặc các luồng trình duyệt bên ngoài cho các ứng dụng gốc.

3. Tập trung vào các chiến lược áp dụng mạnh mẽ: độ phủ đa thiết bị, “chữa lành” dự phòng, phân tích nâng cao và A/B testing.

Corbado mang tất cả các yếu tố này lại với nhau, cung cấp một nền tảng passkey doanh nghiệp bao gồm đăng ký passkey, sử dụng một chạm, tối ưu hóa dựa trên phân tích và lưu trữ quy mô toàn cầu. Kết quả: một trải nghiệm thực sự không ma sát như Apple Pay cho dịch vụ thanh toán của riêng bạn, mang lại cả bảo mật nâng cao và một hành trình người dùng vượt trội.