Thông tin xác thực kỹ thuật số & Thanh toán: So sánh chiến lược của Apple Wallet và Google Wallet

Lĩnh vực thanh toán kỹ thuật số luôn thay đổi. Chúng ta muốn chúng nhanh hơn, an toàn hơn và dễ sử dụng hơn. Đồng thời, các công cụ ID kỹ thuật số, như Thông tin xác thực có thể xác minh (Verifiable Credentials - VCs) và tài liệu nhận dạng di động (mdocs), cũng đang được cải tiến. Chúng mang đến những cách thức mới để mọi người chứng minh họ là ai. Vậy, câu hỏi lớn là: liệu các ID kỹ thuật số mới này có thể giúp cho thanh toán kỹ thuật số tốt hơn hoặc đơn giản hơn nhiều không?

Bài viết này xem xét cách thông tin xác thực kỹ thuật số (bao gồm mdocs theo chuẩn ISO và VCs được gửi bằng OpenID4VC) kết nối với thế giới thanh toán. Chúng ta sẽ đề cập đến:

• Cách các ví điện thoại hiện tại (Apple Wallet, Google Wallet) xử lý thông tin ID so với thẻ thanh toán.
• Tại sao các tiêu chuẩn ID kỹ thuật số hiện tại như mdocs theo ISO 18013-5/7 không thực sự phù hợp để làm công cụ thanh toán trực tiếp.
• Vai trò mà các giao thức như OpenID4VC có thể đóng trong các phương thức thanh toán trong tương lai.
• Cách các ứng dụng ví khác (của bên thứ ba) có thể xử lý các tính năng thanh toán.
• Các vấn đề chính và những gì có thể xảy ra trong tương lai khi cố gắng sử dụng thông tin xác thực có thể xác minh trong các hệ thống thanh toán.

Văn bản này bổ sung cho cuộc thảo luận khác của chúng tôi về Thông tin xác thực kỹ thuật số & Passkeys bằng cách chỉ tập trung vào thanh toán.

Để xem thông tin xác thực kỹ thuật số có thể được sử dụng trong thanh toán như thế nào, trước tiên chúng ta cần hiểu cách các nền tảng di động chính hiện nay và các ví tích hợp sẵn của chúng (Apple Wallet, Google Wallet) tách biệt thông tin nhận dạng khỏi quy trình xử lý thanh toán.

Các ví nền tảng gốc đã trở thành những trung tâm phức tạp cho người dùng, nhưng chúng thường duy trì sự phân biệt rõ ràng giữa thông tin xác thực nhận dạng và công cụ thanh toán:

• Thông tin xác thực nhận dạng (ví dụ: mDLs):
  • Apple Wallet: Chủ yếu hỗ trợ giấy phép lái xe di động (mDLs) và ID tiểu bang tuân thủ ISO/IEC 18013-5. Kể từ WWDC25, Apple đã xác nhận rằng Safari 26 (trong iOS 26) sẽ hỗ trợ API Thông tin xác thực Kỹ thuật số của W3C để trình bày trực tuyến, với sự tập trung độc quyền vào giao thức org.iso.mdoc. Điều này dùng để xác minh các thuộc tính nhận dạng (ví dụ: tên, tuổi, địa chỉ), không phải để thanh toán.
  • Google Wallet & Android Credential Manager: Google Wallet cũng hỗ trợ mDLs dựa trên ISO 18013-5. Trình quản lý thông tin xác thực (Credential Manager) của Android cung cấp một khuôn khổ linh hoạt hơn. Mặc dù việc triển khai API Thông tin xác thực Kỹ thuật số của nó không phụ thuộc vào giao thức, Android cung cấp một triển khai mặc định sử dụng OpenID4VP làm cơ chế truyền tải.
• Công cụ thanh toán (ví dụ: Thẻ tín dụng/ghi nợ):
  • Cả Apple Pay (trong Apple Wallet) và Google Pay (trong Google Wallet) đều sử dụng các công nghệ thanh toán đã được thiết lập và quản lý chặt chẽ. Chúng chủ yếu dựa trên các tiêu chuẩn EMV (Europay, Mastercard, Visa), bao gồm mã hóa (tokenization) (số PAN thiết bị hoặc DPAN thay thế số thẻ thực tế cho các giao dịch), các yếu tố bảo mật hoặc bảo mật dựa trên phần cứng để lưu trữ token thanh toán, và các mã mật mã động để bảo mật giao dịch.
  • Các hệ thống thanh toán này tương tác trực tiếp với các mạng lưới thanh toán hiện có (Visa, Mastercard, Amex, v.v.) và các ngân hàng thanh toán.

Điểm chính cần nhớ: Các ví nền tảng gốc hiện đang hoạt động với các "ngăn xếp" hoặc công nghệ riêng biệt cho thông tin xác thực nhận dạng so với thẻ thanh toán. Một mdoc được trình bày để chứng minh một thuộc tính nhận dạng; một thẻ đã được mã hóa được trình bày để thực hiện thanh toán. Không có việc sử dụng trực tiếp một mdoc như một công cụ thanh toán trong các hệ sinh thái gốc này.

Tiêu chuẩn ISO/IEC 18013-5 định nghĩa cấu trúc dữ liệu cho mDLs và các ID di động khác (mdocs). Mặc dù rất tuyệt vời cho việc xác minh danh tính, thiết kế của nó không phù hợp để sử dụng trực tiếp như một công cụ thanh toán:

Ngay cả khi một mdoc về mặt lý thuyết có thể được thêm các trường dữ liệu tùy chỉnh để chứa PAN hoặc token thanh toán (vì ISO 18013-5 cho phép các không gian tên tùy chỉnh), bản thân tiêu chuẩn mdoc không định nghĩa:

• Cách tạo hoặc xử lý các mã mật mã thanh toán động.
• Cách thực hiện ủy quyền trực tuyến với một mạng lưới thanh toán.
• Các cơ chế bảo mật cần thiết đặc thù cho các giao dịch thanh toán (ngoài tính toàn vẹn của dữ liệu nhận dạng).

Do đó, hiện tại không có cách nào để sử dụng mdoc theo chuẩn ISO 18013-5 như một công cụ thanh toán trực tiếp.

Trong khi mdoc không phải là một công cụ thanh toán, nó có thể đóng một vai trò trong luồng "xác thực nâng cao", nơi danh tính của người dùng phải được xác minh một cách rõ ràng cho một hành động có rủi ro cao. Điều này khác biệt với việc sử dụng nó để thực hiện chính giao dịch thanh toán. Luồng này thường sẽ trông như sau:

1. Xác thực chính: Người dùng đăng nhập vào một dịch vụ, thường bằng một phương thức ít ma sát như passkey.
2. Kích hoạt xác thực nâng cao: Đối với một hành động cần độ đảm bảo cao (ví dụ: chuyển khoản ngân hàng lớn, cập nhật thông tin cá nhân), dịch vụ yêu cầu kiểm tra danh tính rõ ràng.
3. Trình bày mdoc: Dịch vụ yêu cầu trình bày mdoc của người dùng (ví dụ: giấy phép lái xe). Người dùng trình bày các thuộc tính được yêu cầu từ ví của họ.
4. Xác minh: Dịch vụ xác minh dữ liệu mdoc bằng mật mã so với một nguồn đáng tin cậy hoặc một danh tính đã được đăng ký trước đó.

Trong mô hình này, mdoc cung cấp bằng chứng nhận dạng mạnh mẽ, chống lừa đảo, cho một thời điểm cụ thể có rủi ro cao. Tuy nhiên, giao dịch tài chính sau đó vẫn sử dụng các kênh thanh toán đã được thiết lập. Mdoc xác minh con người, không phải phương thức thanh toán.

Trong khi bản thân mdocs không phải là công cụ thanh toán, các giao thức như OpenID for Verifiable Credentials (OpenID4VC – bao gồm OpenID4VP để trình bày và OpenID4VCI để phát hành) cung cấp một lớp truyền tải linh hoạt hơn.

Đặc điểm chính của OpenID4VC:

• Giao thức, không phải Tải trọng (Payload): OID4VC định nghĩa cách yêu cầu và trình bày VCs nhưng phần lớn không phụ thuộc vào định dạng của chính payload VC. Nó có thể vận chuyển mdocs, VCs tiêu chuẩn W3C (ví dụ: ở định dạng JWT hoặc SD-JWT), hoặc các loại thông tin xác thực tùy chỉnh khác.
• Phạm vi sử dụng rộng: Sự linh hoạt này cho phép các nền tảng như Android (thông qua Trình quản lý thông tin xác thực) hỗ trợ các yêu cầu cho nhiều loại thông tin xác thực khác nhau thông qua một cơ chế chung.
• Tương thích trong tương lai cho VCs thanh toán: Nếu ngành công nghiệp thanh toán tiêu chuẩn hóa một định dạng thông tin xác thực "token thanh toán" hoặc "ủy quyền thanh toán" có thể xác minh, OID4VC về mặt lý thuyết có thể vận chuyển một thông tin xác thực như vậy giữa ví của người dùng và đơn vị chấp nhận thanh toán/PSP.

Tuy nhiên, bản thân OID4VC không phải là một giải pháp thanh toán:

• Vai trò của OID4VC là tạo điều kiện thuận lợi cho việc trao đổi thông tin xác thực. Nó không định nghĩa nội dung, các tính năng bảo mật của thông tin xác thực thanh toán, hoặc cách nó tương tác với các hệ thống xử lý thanh toán.
• Để OID4VC hữu ích cho thanh toán, một định dạng thông tin xác thực thanh toán có thể xác minh được chấp nhận rộng rãi, an toàn và được tiêu chuẩn hóa trước tiên cần được phát triển và hỗ trợ bởi hệ sinh thái thanh toán (nhà phát hành, ngân hàng thanh toán, các mạng lưới). Điều này hiện chưa tồn tại.

Ngoài các ví nền tảng gốc, một hệ sinh thái ngày càng phát triển của các ví của bên thứ ba (ví dụ: EUDI Wallet, ví do ngân hàng cung cấp, ví chuyên dụng của ngành) đang nổi lên. Những chiếc ví này phải điều hướng sự khác biệt cơ bản giữa xác thực nhanh, ít ma sát và xác minh thuộc tính có độ đảm bảo cao, đặc biệt là trong bối cảnh thanh toán.

Sự đồng thuận mới nổi là passkeys là lý tưởng cho việc xác thực cốt lõi vào một dịch vụ thanh toán, vì chúng có khả năng chống lừa đảo và được thiết kế cho trải nghiệm người dùng liền mạch. Việc chèn một trình bày thông tin xác thực kỹ thuật số vào bước xác nhận thanh toán quan trọng sẽ làm tăng thêm ma sát đáng kể và có khả năng gây hại cho tỷ lệ chuyển đổi. Do đó, vai trò chính của thông tin xác thực kỹ thuật số là trong giai đoạn giới thiệu và KYC một lần, có độ đảm bảo cao, cho phép các khả năng thanh toán, thay vì trong chính giao dịch. Những chiếc ví này có thể tiếp cận thanh toán như thế nào, đặc biệt là khi kết hợp với các tính năng nhận dạng kỹ thuật số?

Để một ví của bên thứ ba ủy quyền thanh toán, nó cần một cách để được gọi bởi ứng dụng hoặc trang web của đơn vị chấp nhận thanh toán. Có một số mô hình tương tác đã được thiết lập cho việc này, mỗi mô hình có các mức độ tích hợp nền tảng và trải nghiệm người dùng khác nhau:

• Liên kết sâu giữa các ứng dụng (App-to-App Deep Linking): Đây là một phương pháp phổ quát, trong đó ứng dụng của đơn vị chấp nhận thanh toán (gốc hoặc web) chuyển hướng người dùng đến ứng dụng ví của bên thứ ba bằng một lược đồ URL tùy chỉnh (ví dụ: eudi-wallet://...). Chi tiết giao dịch được truyền dưới dạng tham số trong URL. Sau khi người dùng xác nhận thanh toán trong ứng dụng ví, nó sẽ chuyển hướng trở lại ứng dụng của đơn vị chấp nhận thanh toán bằng một liên kết sâu khác. Điều này hoạt động trên cả iOS và Android nhưng liên quan đến việc chuyển đổi ngữ cảnh có thể nhìn thấy giữa các ứng dụng.
• Lựa chọn ví gốc: Với Lựa chọn ví gốc, một ứng dụng có thể gọi một dịch vụ hệ thống chung hiển thị tất cả các trình xử lý thanh toán hoặc ví đã đăng ký. Sau đó, người dùng có thể chọn ví ưa thích của họ từ một giao diện người dùng do hệ thống cung cấp. Điều này mang lại cảm giác tích hợp hơn so với liên kết sâu đơn giản (API Thông tin xác thực Kỹ thuật số).
• Thanh toán đơn giản bằng mã QR: Mô hình này lý tưởng cho các luồng từ máy tính để bàn đến di động. Trang web của đơn vị chấp nhận thanh toán hiển thị một mã QR chứa chi tiết giao dịch hoặc một URL. Người dùng quét mã này bằng ứng dụng ví di động của họ, sau đó ứng dụng này sẽ tự xử lý việc xác nhận trên điện thoại. Backend của ví sau đó sẽ thông báo sự chấp thuận trở lại hệ thống của đơn vị chấp nhận thanh toán.
• Luồng đa thiết bị được tiêu chuẩn hóa (FIDO CTAP): Là một sự phát triển của phương pháp mã QR, phương pháp này sử dụng các giao thức như Giao thức từ Client đến Authenticator (CTAP) của FIDO để tạo ra một kênh trực tiếp, an toàn và được mã hóa giữa trình duyệt máy tính để bàn (client) và ví di động (đóng vai trò là một authenticator). Điều này an toàn hơn so với các mã QR đơn giản vì trình duyệt và điện thoại giao tiếp trực tiếp, một mô hình được Google hỗ trợ mạnh mẽ cho cả passkeys và thông tin xác thực kỹ thuật số.
• Tích hợp Backend trực tiếp: Trong một số hệ thống khép kín, ứng dụng ví của bên thứ ba có thể tương tác trực tiếp với một Nhà cung cấp dịch vụ thanh toán (PSP) hoặc backend của một tổ chức tài chính để xử lý thanh toán, thường sử dụng các API độc quyền.

Các mô hình này cung cấp "lớp truyền tải" để bắt đầu một xác nhận thanh toán, trong đó một luồng mật mã (như luồng được chi tiết cho EUDI Wallet) sau đó có thể diễn ra.

Với các thông báo tại WWDC25, bối cảnh về cách các trình duyệt xử lý thông tin xác thực kỹ thuật số đã trở nên rõ ràng hơn nhiều, củng cố sự tách biệt giữa xác minh danh tính và xử lý thanh toán. Các nền tảng đang cho phép các ví của bên thứ ba tương tác với trình duyệt để xác minh danh tính thông qua API Thông tin xác thực Kỹ thuật số của W3C, nhưng các cách tiếp cận đang khác nhau:

• Quan điểm của Apple (Được xác nhận tại WWDC25): Apple đã chính thức công bố hỗ trợ API Thông tin xác thực Kỹ thuật số trong Safari 26 (đi kèm với iOS 26). Như được chi tiết trong phiên "Xác minh tài liệu nhận dạng trên web" của họ, việc triển khai chỉ hỗ trợ độc quyền giao thức org.iso.mdoc. Điều này cho phép các trang web yêu cầu thông tin có thể xác minh từ mdocs trong Apple Wallet hoặc các ứng dụng cung cấp tài liệu của bên thứ ba đã đăng ký khác, nhưng nó không hỗ trợ giao thức OpenID4VP có mục đích chung hơn. Với sự hỗ trợ ngày càng tăng cho thông tin xác thực kỹ thuật số và các tích hợp web nâng cao, việc duy trì hiệu suất và bảo mật hệ thống càng trở nên quan trọng hơn - các công cụ như CleanMyMac giúp đảm bảo máy Mac của bạn chạy mượt mà khi các công nghệ này phát triển.
• Quan điểm của Google: Trình quản lý thông tin xác thực của Android cho phép các ví của bên thứ ba đăng ký làm trình xử lý cho các yêu cầu thông tin xác thực. Việc triển khai API Thông tin xác thực Kỹ thuật số trong Chrome tập trung vào việc sử dụng OpenID4VP làm giao thức truyền tải chính. Mặc dù OpenID4VP có thể mang một mdoc dưới dạng payload, bản thân giao thức này khác với cách tiếp cận org.iso.mdoc trực tiếp của Apple.

Điều quan trọng là, các tích hợp trình duyệt này dành cho các thuộc tính nhận dạng, không phải để coi mDoc hoặc VC được trình bày như một công cụ thanh toán.

Nếu người dùng trình bày một mDL từ ví của họ cho một trang web thông qua API Thông tin xác thực Kỹ thuật số của trình duyệt, trang web đó có thể sử dụng thông tin để tự động điền địa chỉ hoặc xác minh tuổi trong quá trình thanh toán. Tuy nhiên, bước thanh toán thực tế vẫn sẽ yêu cầu một tương tác riêng biệt với một phương thức thanh toán (ví dụ: Apple Pay, Google Pay, hoặc nhập chi tiết thẻ). Bản thân API của trình duyệt không được thiết kế để bắt đầu hoặc xử lý một giao dịch tài chính bằng thông tin xác thực nhận dạng.

Ví Nhận dạng Kỹ thuật số EU (EUDI) là một ví dụ điển hình xuất sắc về cách một ví của bên thứ ba phải điều hướng trong bối cảnh phức tạp, thực tế của các hệ điều hành và sự sẵn có của API. Trong số nhiều chức năng của nó, hai trong số các trường hợp sử dụng nổi bật nhất là xác minh danh tính và xác nhận thanh toán, và các con đường kỹ thuật để hoàn thành hai nhiệm vụ này là khác nhau, đặc biệt là khi so sánh khuôn khổ linh hoạt của Android với việc triển khai cứng nhắc hơn của Apple.

Bảng sau đây phân tích cách EUDI Wallet có thể được gọi để xác minh danh tính hoặc ủy quyền thanh toán, làm nổi bật sự hỗ trợ khác nhau giữa các nền tảng.

Những điểm chính từ so sánh:

• API Thông tin xác thực Kỹ thuật số: Tiêu chuẩn W3C mới nổi này không phụ thuộc vào giao thức và được hỗ trợ tốt cho nhận dạng trên cả hai nền tảng. Đối với việc triển khai của mình, Android cung cấp một luồng mặc định sử dụng giao thức OpenID4VP linh hoạt, có thể mang nhiều định dạng thông tin xác thực khác nhau. Ngược lại, việc triển khai của Apple chỉ dành riêng cho định dạng org.iso.mdoc. Điều quan trọng là, các trình duyệt giới hạn API này cho các trường hợp sử dụng nhận dạng, không phải để bắt đầu thanh toán.
• Lựa chọn ví gốc: Cả hai hệ điều hành đều cung cấp một giao diện người dùng gốc để chọn ví, nhưng với những hạn chế khác nhau. Android cung cấp một bộ chọn cho cả ứng dụng nhận dạng và thanh toán. iOS cung cấp một bộ chọn cho các ứng dụng "Nhà cung cấp tài liệu" nhận dạng đã đăng ký nhưng không cung cấp cho các ứng dụng thanh toán của bên thứ ba.
• Liên kết sâu giữa các ứng dụng: Đây là công cụ phổ quát, hoạt động đáng tin cậy cho cả trường hợp sử dụng nhận dạng và thanh toán trên cả hai nền tảng. Nó vẫn là phương pháp chính để gọi một ví của bên thứ ba để thanh toán trên iOS.
• Đa thiết bị được tiêu chuẩn hóa: Luồng dựa trên FIDO CTAP này hiện là một tính năng của hệ sinh thái Google/Android và không được hỗ trợ trên iOS.

(*) Lưu ý về Thanh toán qua API DC: Mặc dù việc sử dụng OpenID4VP của Android làm cho một luồng thanh toán về mặt kỹ thuật khả thi thông qua API Thông tin xác thực Kỹ thuật số, đây không phải là trọng tâm thiết kế chính của nó. Việc tích hợp liền mạch cho thanh toán qua API cụ thể này, trái ngược với các phương pháp gốc khác, vẫn còn phải xem và sẽ yêu cầu sự hỗ trợ rõ ràng từ các nhà cung cấp trình duyệt.

So sánh này làm rõ rằng trong khi xác minh danh tính ngày càng được tiêu chuẩn hóa thông qua API Thông tin xác thực Kỹ thuật số, việc ủy quyền thanh toán cho các ví của bên thứ ba như EUDI Wallet vẫn phụ thuộc nhiều vào các mẫu tích hợp gốc truyền thống hơn như liên kết sâu giữa các ứng dụng, đặc biệt là trên iOS.

Bất kể mô hình tích hợp thanh toán nào được sử dụng để gọi ví, cốt lõi của việc xác nhận thanh toán của Ví EUDI dựa trên một luồng mật mã được tiêu chuẩn hóa được chi tiết trong EWC RFC008.

Dưới đây là một hướng dẫn cấp cao về quy trình này:

Đây là một ví dụ không chuẩn về đối tượng payment_data được gửi đến ví, chi tiết giao dịch để người dùng xác nhận.

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

Sau khi người dùng phê duyệt, ví tạo ra một JWT ràng buộc khóa. Các claim của nó chứng minh rằng người dùng đã xác nhận dữ liệu giao dịch cụ thể.

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

Trong khi các tiêu chuẩn kỹ thuật đang phát triển, ngành công nghiệp thanh toán không đứng yên. Các bên tham gia chính đang tích cực khám phá cách kết hợp tính bảo mật của thông tin xác thực kỹ thuật số với chức năng của thanh toán.

Một cách mạnh mẽ để hiểu tiềm năng của Thông tin xác thực có thể xác minh (VCs) là so sánh chúng với các hệ thống mã hóa thanh toán mạng lưới thành công (như Dịch vụ Token của Visa hoặc MDES của Mastercard).

• Mã hóa thanh toán đã thay thế Số tài khoản chính (PAN) nhạy cảm bằng một token an toàn và một mã mật mã dùng một lần. Điều này bảo vệ tài sản cốt lõi—số thẻ—trong các giao dịch.
• Thông tin xác thực có thể xác minh nhằm mục đích làm cho dữ liệu cá nhân những gì mã hóa đã làm cho PANs. Thay vì chia sẻ dữ liệu thô (tên, ngày sinh, địa chỉ), người dùng trình bày một thông tin xác thực được ký bằng mật mã từ một nhà phát hành đáng tin cậy.

Về bản chất, một VC đối với dữ liệu cá nhân cũng giống như một token thanh toán và mã mật mã đối với dữ liệu thẻ: một sự thay thế an toàn, có thể xác minh giúp giảm rủi ro và tăng cường quyền riêng tư.

Dựa trên sự tương đồng này, các cơ quan trong ngành đang làm việc trên khái niệm về một "thông tin xác thực thanh toán có thể xác minh." Đây sẽ là một thông tin xác thực, do ngân hàng cấp, đóng gói một công cụ thanh toán (như một thẻ được mã hóa) và có thể được sử dụng để ủy quyền các giao dịch.

• EMVCo, cơ quan tiêu chuẩn cho thanh toán an toàn, đang tích cực tích hợp các tiêu chuẩn FIDO vào giao thức EMV 3-D Secure. Điều này cho phép các xác thực passkey trước đó được sử dụng như một tín hiệu mạnh mẽ cho các phê duyệt không ma sát, đồng thời chuẩn bị cho Xác nhận thanh toán an toàn (SPC) để phục vụ như một giải pháp thay thế hiện đại, chống lừa đảo cho các thách thức OTP truyền thống. Cũng có các cuộc thảo luận đang diễn ra về cách thông tin xác thực có thể xác minh có thể được tích hợp vào các luồng này trong tương lai.
• Visa đã công bố Dịch vụ Visa Payment Passkey, dịch vụ này liên kết một cách an toàn một authenticator FIDO với thông tin xác thực thanh toán. Dịch vụ này được thiết kế để xác nhận danh tính và ủy quyền thanh toán trong một bước duy nhất, không ma sát mà không làm gián đoạn trải nghiệm thanh toán.
• Mastercard đang theo đuổi một chiến lược song song với Dịch vụ Mastercard Payment Passkey, dịch vụ này tận dụng Dịch vụ xác thực Token (TAS) của mình để thay thế mật khẩu và OTP bằng xác thực sinh trắc học dựa trên passkey, được tích hợp chặt chẽ với các dịch vụ mã hóa của mình (MDES).

Điều này cho thấy một xu hướng rõ ràng: ngành công nghiệp đang hướng tới một tương lai nơi một chiếc ví có thể trình bày một bằng chứng có thể xác minh bằng mật mã về cả danh tính và ủy quyền thanh toán trong một luồng duy nhất, được tiêu chuẩn hóa.

Phần lớn sự đổi mới này đang được thúc đẩy bởi những làn gió pháp lý mạnh mẽ, đặc biệt là từ Liên minh châu Âu.

Quy định eIDAS 2.0 của EU không chỉ là về việc cung cấp cho công dân một ID kỹ thuật số; nó còn hình dung rõ ràng EUDI Wallet như một phương pháp để thực hiện SCA cho các khoản thanh toán trực tuyến. Điều này có nghĩa là trong tương lai, các ngân hàng và nhà cung cấp thanh toán ở EU có thể được yêu cầu chấp nhận EUDI Wallet như một cách để người dùng xác nhận các giao dịch trực tuyến, cung cấp một giải pháp thay thế dựa trên tiêu chuẩn cho các ứng dụng ngân hàng độc quyền hoặc mã SMS.

Một thỏa thuận chống độc quyền mang tính bước ngoặt tại EU đã buộc Apple phải mở giao diện NFC trước đây bị đóng trên iPhone. Kể từ iOS 17.4 (phát hành ngày 5 tháng 3 năm 2024), Apple đã triển khai các API cần thiết và cho phép người dùng chọn một ứng dụng thanh toán không tiếp xúc mặc định, đáp ứng thời hạn ràng buộc của Ủy ban châu Âu là ngày 25 tháng 7 năm 2024. Đây không còn là một viễn cảnh tương lai; đó là thực tế hiện tại trong Khu vực Kinh tế Châu Âu (EEA).

Sự thay đổi này có nghĩa là các ứng dụng ví của bên thứ ba giờ đây có thể cung cấp các giải pháp chạm để thanh toán của riêng họ trên iOS, chấm dứt sự độc quyền lâu dài của Apple Pay. Các khả năng chính hiện có sẵn cho các nhà phát triển bao gồm:

• Lựa chọn ví mặc định: Người dùng trong EEA có thể đặt một ứng dụng của bên thứ ba đủ điều kiện làm ứng dụng thanh toán không tiếp xúc mặc định của họ, có thể được gọi thông qua một cú nhấp đúp vào nút bên.
• Tích hợp đầy đủ: Những chiếc ví này có thể sử dụng các tính năng bảo mật gốc của iPhone, bao gồm Face ID và Touch ID, để ủy quyền thanh toán.
• Áp dụng trong thực tế: Một số công ty lớn đã ra mắt các giải pháp của họ, bao gồm Vipps MobilePay ở Na Uy và PayPal ở Đức.

Tác động của việc mở cửa này là rất đáng kể và đã và đang diễn ra:

• Tăng cường cạnh tranh: Các ngân hàng và fintech giờ đây có thể cạnh tranh trực tiếp với Apple Pay trên chính nền tảng của nó, điều này được kỳ vọng sẽ làm giảm phí của nhà phát hành và thúc đẩy sự đổi mới.
• Sử dụng thông tin xác thực rộng rãi hơn: Các API tương tự có thể được sử dụng cho nhiều mục đích hơn là chỉ thanh toán, bao gồm thẻ công ty, vé phương tiện công cộng và chìa khóa khách sạn, mà không cần phải có trong Apple Wallet.
• Một con đường cho thông tin xác thực được tiêu chuẩn hóa: Điều này tạo ra một tiền lệ quan trọng. Logic pháp lý tương tự đã mở giao diện NFC cho các ứng dụng thanh toán cuối cùng có thể được sử dụng để bắt buộc hỗ trợ cho các "Thông tin xác thực thanh toán có thể xác minh" trung lập, được tiêu chuẩn hóa (như những thông tin đang được thử nghiệm cho EUDI Wallet), cho phép chúng hoạt động cùng với các giải pháp độc quyền.
• Tiền lệ toàn cầu: Mặc dù sự thay đổi hiện chỉ giới hạn ở EEA, nó tạo ra một tiền lệ toàn cầu mạnh mẽ. Các nhà quản lý ở các khu vực khác, bao gồm cả Hoa Kỳ, đang theo dõi chặt chẽ, và điều này có thể đẩy nhanh các động thái mở cửa tương tự trên toàn thế giới.

Đối với các nhà phát hành thanh toán (ngân hàng, các chương trình thẻ, fintech), việc điều hướng sự chuyển đổi sang thông tin xác thực kỹ thuật số đòi hỏi một chiến lược thực tế, theo từng giai đoạn. Mục tiêu là xây dựng dựa trên các tài sản bạn kiểm soát ngày hôm nay để chuẩn bị cho hệ sinh thái của ngày mai. Cẩm nang này phác thảo chiến lược đó, chuyển từ các hành động tức thời, ít rủi ro đến các đánh giá chiến lược, dài hạn hơn.

Nền tảng của bất kỳ chiến lược ví nào trong tương lai là một ứng dụng gốc an toàn, được chấp nhận rộng rãi. Ưu tiên trước mắt là tối đa hóa phạm vi tiếp cận của ứng dụng và củng cố xác thực của nó cho cả đăng nhập và thanh toán.

1. Thúc đẩy việc sử dụng ứng dụng gốc: Ứng dụng di động của bạn là ví tương lai của bạn. Mục tiêu chính là biến nó thành một công cụ không thể thiếu cho khách hàng của bạn. Sự phân phối và tương tác này là nền tảng quan trọng cho bất kỳ việc phát hành thông tin xác thực hoặc chức năng ví nào trong tương lai.

2. Sử dụng Passkeys cho Thanh toán, theo mô hình của PayPal: Triển khai passkeys ngay lập tức, không chỉ để đăng nhập, mà còn để ủy quyền thanh toán. Hướng tới một trải nghiệm gần như tương đương với các giải pháp nền tảng gốc như Apple Pay. Đối với các môi trường pháp lý yêu cầu Xác thực khách hàng mạnh (SCA), hãy áp dụng cách tiếp cận thực tế của PayPal:

   • Tận dụng passkeys như một yếu tố xác thực chính.
   • Kết hợp chúng với các tín hiệu thiết bị đáng tin cậy (ví dụ: "thiết bị đã ghi nhớ" được quản lý qua ứng dụng của bạn hoặc cookie an toàn) để đáp ứng yếu tố "sở hữu" của SCA.
   • Sự kết hợp này cho phép bạn cung cấp một trải nghiệm xác nhận thanh toán liền mạch, ít ma sát, vừa có độ bảo mật cao vừa tuân thủ, mà không cần chờ đợi sự hỗ trợ VC phổ biến.

Với một ứng dụng an toàn, được bảo vệ bằng passkey làm nền tảng, bạn có thể bắt đầu tích hợp có chọn lọc các công nghệ thông tin xác thực mới ở những nơi chúng mang lại giá trị rõ ràng.

3. Theo dõi sự trỗi dậy của Thông tin xác thực thanh toán có thể xác minh: Khái niệm về một VC mang theo một token thanh toán là mạnh mẽ nhưng chưa được tiêu chuẩn hóa. Vai trò của bạn ở đây là một người quan sát và tham gia tích cực.

   • Hành động: Theo dõi chặt chẽ tiến trình trong các cơ quan tiêu chuẩn như EMVCo và W3C. Chuẩn bị để tận dụng Thông tin xác thực thanh toán có thể xác minh được tiêu chuẩn hóa nếu và khi chúng cung cấp một lợi thế rõ ràng so với các luồng dựa trên passkey hiện có.

4. Tích hợp Thông tin xác thực kỹ thuật số cho các trường hợp sử dụng nhận dạng: Khi các ví nhận dạng kỹ thuật số (như EUDI Wallet) trở nên phổ biến, hãy tích hợp API Thông tin xác thực Kỹ thuật số cho các tác vụ liên quan đến nhận dạng, không phải thanh toán.

   • Hành động: Sử dụng các trình bày VC cho các quy trình có độ đảm bảo cao mà chúng vượt trội:
     • Giới thiệu & KYC: Hợp lý hóa việc thiết lập tài khoản mới.
     • Xác thực nâng cao: Xác minh danh tính cho các hành động có rủi ro cao.
     • Khôi phục tài khoản: Cung cấp một con đường an toàn cho người dùng đã mất thiết bị của họ.

Rào cản cuối cùng đối với việc áp dụng bất kỳ công nghệ thanh toán mới nào là ma sát người dùng. Trước khi thay thế một luồng passkey đơn giản, một giải pháp thay thế dựa trên VC phải chứng minh rằng nó không chỉ an toàn hơn mà còn liền mạch không kém.

5. So sánh không ngừng với trải nghiệm một chạm: Tiêu chuẩn cho một trải nghiệm thanh toán hiện đại được thiết lập bởi các nhà lãnh đạo như Apple Pay và người theo sát nó trên Web, PayPal. Bất kỳ luồng mới nào bạn giới thiệu phải cạnh tranh với xác nhận gần như tức thì, một chạm của họ. Tất cả các tín hiệu hiện tại đều cho thấy rằng đối với đại đa số các giao dịch, khả năng chống lừa đảo của passkeys cung cấp một mức độ bảo vệ đủ và một trải nghiệm người dùng vượt trội. Đừng thêm một bước trình bày VC vào một luồng thanh toán nếu nó gây ra bất kỳ ma sát nào có thể nhận thấy.

6. Theo dõi các tín hiệu thiết bị trong băng tần (In-Band) trong WebAuthn: Sự phát triển của passkeys không tĩnh. Trong khi các nỗ lực ban đầu để cung cấp các tín hiệu cụ thể cho thiết bị đã bị ngừng, các cơ quan tiêu chuẩn đang tích cực làm việc để tích hợp các tín hiệu tin cậy ràng buộc thiết bị mạnh mẽ hơn trực tiếp vào giao thức WebAuthn. Điều này sẽ cho phép một RP xác định một thiết bị đáng tin cậy trong quá trình xác thực passkey, tăng cường hơn nữa tín hiệu cho các công cụ rủi ro mà không yêu cầu một trình bày VC riêng biệt, ngoài băng tần. Theo dõi chặt chẽ không gian này, vì đây là con đường có khả năng nhất để tăng cường bảo mật mà không phải hy sinh trải nghiệm không ma sát của passkey.

Bằng cách tuân theo cẩm nang theo từng giai đoạn này, một nhà phát hành có thể xây dựng một chiến lược mạnh mẽ, thực tế, tối đa hóa bảo mật và nâng cao trải nghiệm người dùng ngày hôm nay, đồng thời chuẩn bị để áp dụng một cách chu đáo các công nghệ thanh toán có thể xác minh của ngày mai.

Để thông tin xác thực kỹ thuật số trở thành một phần không thể thiếu của các quy trình thanh toán ngoài việc chỉ hỗ trợ KYC hoặc xác thực người dùng vào tài khoản thanh toán, một số thách thức đáng kể phải được giải quyết:

1. Tiêu chuẩn hóa các VC dành riêng cho thanh toán: Một định dạng thông tin xác thực có thể xác minh chuyên dụng, an toàn và được chấp nhận rộng rãi cho thanh toán cần được phát triển. Điều này sẽ cần phải gói gọn các token thanh toán, dữ liệu cụ thể cho giao dịch và có khả năng là các yếu tố bảo mật động, vượt xa phạm vi của các mdocs tập trung vào nhận dạng hiện tại hoặc các VCs chung chung.
2. Tích hợp với các mạng lưới thanh toán: Bất kỳ giải pháp thanh toán dựa trên VC nào cũng phải tích hợp liền mạch với các mạng lưới thanh toán toàn cầu hiện có (Visa, Mastercard, v.v.) hoặc đề xuất các kênh mới khả thi. Điều này liên quan đến các sự điều chỉnh phức tạp về kỹ thuật, bảo mật và mô hình kinh doanh.
3. Tuân thủ quy định: Thanh toán được quản lý rất chặt chẽ (ví dụ: PSD2/SCA ở Châu Âu, PCI DSS trên toàn cầu). Một hệ thống thanh toán dựa trên VC sẽ cần phải đáp ứng tất cả các quy định tài chính có liên quan, bao gồm cả những quy định về bảo mật, bảo vệ người tiêu dùng và chống gian lận.
4. Sự chấp nhận của nhà phát hành và ngân hàng thanh toán: Các ngân hàng, tổ chức tài chính (với tư cách là nhà phát hành VCs thanh toán) và các ngân hàng thanh toán của đơn vị chấp nhận thanh toán sẽ cần phải đầu tư vào cơ sở hạ tầng để hỗ trợ một hệ thống như vậy.
5. Mô hình bảo mật: Một mô hình bảo mật mạnh mẽ dành riêng cho VCs thanh toán sẽ là điều cần thiết, bao gồm việc phát hành, lưu trữ (lý tưởng là trong các yếu tố bảo mật được hỗ trợ bằng phần cứng), trình bày và thu hồi trong bối cảnh tài chính.
6. Trải nghiệm người dùng: Mặc dù VCs có thể cung cấp quyền kiểm soát cho người dùng, trải nghiệm thanh toán phải vẫn nhanh chóng, trực quan và đáng tin cậy để được chấp nhận rộng rãi.

Khả năng trong tương lai:

• VCs cho phiếu ủy quyền thanh toán: VCs có thể đại diện cho một "ủy quyền" thanh toán được ký bằng mật mã từ một tài khoản được liên kết, được trình bày qua OpenID4VP, với việc chuyển tiền thực tế vẫn diễn ra thông qua các kênh truyền thống.
• VCs chứa token thanh toán: Một VC được tiêu chuẩn hóa có thể được định nghĩa để giữ một cách an toàn một token thanh toán (tương tự như một EMV DPAN), sau đó được xử lý bởi các cơ sở hạ tầng thanh toán hiện có.
• VCs thanh toán trong hệ thống khép kín: Các nhà phát hành hoặc cộng đồng cụ thể có thể tạo VCs cho các khoản thanh toán trong các hệ thống khép kín của riêng họ.

Tuy nhiên, những điều này hiện tại phần lớn vẫn là khái niệm. Động lực chính đằng sau sự phát triển VC và mdoc hiện tại, giờ đây được củng cố bởi các triển khai cụ thể của các API trình duyệt, vẫn tập trung vào xác minh danh tính và chứng thực thuộc tính, không phải thực thi thanh toán.

Sự hội tụ của nhận dạng kỹ thuật số và thanh toán tạo ra một bối cảnh phức tạp nhưng có thể điều hướng được. Mặc dù lời hứa về một "thông tin xác thực thanh toán có thể xác minh" duy nhất, phổ quát là hấp dẫn, bài viết này kết luận rằng chiến lược hiệu quả và thực tế nhất cho các nhà phát hành thanh toán ngày nay được đặt trên một thực tế khác: cuộc chiến giành trải nghiệm người dùng tốt nhất là tối quan trọng, và passkeys là vũ khí mạnh mẽ nhất.

Cẩm nang chiến lược rất rõ ràng. Động thái tức thời, ít rủi ro là tập trung vào việc thiết lập một ứng dụng gốc không thể đánh bại, sử dụng nó như một phương tiện để triển khai các khoản thanh toán dựa trên passkey có thể cạnh tranh với tiêu chuẩn "một chạm" không ma sát do Apple Pay và PayPal thiết lập. Cách tiếp cận này giải quyết các nhu cầu cốt lõi về bảo mật (thông qua khả năng chống lừa đảo) và trải nghiệm người dùng ngày hôm nay, sử dụng công nghệ trưởng thành, được chấp nhận rộng rãi.

Trong mô hình này, Thông tin xác thực có thể xác minh tìm thấy vai trò quan trọng nhưng khác biệt của chúng. Chúng chưa phải là công cụ cho chính hành động thanh toán, nhưng lại không thể thiếu cho các tác vụ nhận dạng có độ đảm bảo cao xung quanh nó: giới thiệu an toàn, khôi phục tài khoản mạnh mẽ và KYC theo quy định.

Tương lai của thanh toán sẽ không được quyết định bởi một công nghệ duy nhất mà bởi sự tập trung không ngừng vào người dùng. Thành công sẽ đến với các nhà phát hành làm chủ được trải nghiệm dựa trên passkey trong các ứng dụng của riêng họ trước, đồng thời theo dõi một cách chu đáo sự phát triển của thông tin xác thực có thể xác minh và các tín hiệu tin cậy passkey trong băng tần. Họ phải sẵn sàng tích hợp các công nghệ mới này không phải khi chúng chỉ đơn thuần có sẵn, mà chỉ khi chúng có thể đáp ứng được tiêu chuẩn đáng gờm của một trải nghiệm thanh toán thực sự liền mạch, an toàn và vượt trội.