--- url: 'https://www.corbado.com/id/blog/kredensial-digital-pembayaran' title: 'Kredensial Digital & Pembayaran: Strategi Apple vs. Google Wallet' description: 'Pelajari bagaimana kredensial digital memengaruhi pembayaran dan strategi penerbit untuk bersaing secara efektif dengan Apple Pay dan Google Wallet.' lang: 'id' author: 'Vincent Delitz' date: '2025-07-25T07:00:06.970Z' lastModified: '2026-03-27T07:07:13.022Z' keywords: 'pembayaran kredensial digital' category: 'Passkeys Strategy' --- # Kredensial Digital & Pembayaran: Strategi Apple vs. Google Wallet ### Ringkasan: Buku Panduan Strategis Penerbit | Fase | Strategi Inti Anda | Tindakan Kunci | | :------------------- | :-------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Sekarang** | πŸ“± **Dorong Aplikasi, Kuasai Passkeys** | Dorong adopsi aplikasi native tanpa henti. Gunakan passkeys untuk pengalaman pembayaran sekali klik yang menyaingi Apple Pay & PayPal. | | **2. Jangka Pendek** | πŸ†” **Gunakan VC untuk Identitas, Bukan Pembayaran** | Integrasikan kredensial digital untuk tugas berjaminan tinggi seperti KYC dan pemulihan akun. Pantau, tetapi jangan terburu-buru, kredensial pembayaran yang dapat diverifikasi. | | **3. Masa Depan** | βš–οΈ **Evaluasi VC vs. Passkeys yang Berkembang** | Bandingkan alur pembayaran VC apa pun dengan yang terbaik. Adopsi untuk pembayaran hanya jika diwajibkan atau jika memberikan nilai bersih yang superior. Perhatikan peningkatan passkey seperti sinyal perangkat in-band. | ## 1. Pendahuluan Pembayaran digital selalu berubah. Kita ingin pembayaran menjadi lebih cepat, lebih aman, dan lebih mudah digunakan. Pada saat yang sama, alat ID digital, seperti Verifiable Credentials (VC) dan dokumen identitas seluler (mdocs), terus berkembang. Alat-alat ini menawarkan cara baru bagi orang untuk menunjukkan identitas mereka. Jadi, pertanyaan besarnya adalah: dapatkah ID digital baru ini juga membuat pembayaran digital menjadi jauh lebih baik atau lebih sederhana? Artikel ini membahas bagaimana [kredensial digital](https://www.corbado.com/id/blog/digital-credentials-api) (termasuk mdocs ISO dan VC yang dikirim menggunakan [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc)) terhubung dengan dunia pembayaran. Kita akan membahas: - Bagaimana [wallet](https://www.corbado.com/blog/digital-wallet-assurance) ponsel saat ini (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) menangani informasi ID versus kartu pembayaran. - Mengapa standar ID digital saat ini seperti mdocs [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5)/7 tidak benar-benar cocok sebagai alat pembayaran langsung. - Peran apa yang bisa dimainkan oleh protokol seperti [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc) dalam metode pembayaran di masa depan. - Bagaimana aplikasi [wallet](https://www.corbado.com/blog/digital-wallet-assurance) lain (pihak ketiga) mungkin menangani fitur pembayaran. - Masalah utama dan apa yang bisa terjadi di masa depan saat mencoba menggunakan kredensial yang dapat diverifikasi dalam sistem pembayaran. Teks ini melengkapi diskusi kami yang lain tentang [Kredensial Digital](https://www.corbado.com/id/blog/digital-credentials-api) & Passkeys dengan berfokus hanya pada pembayaran. ## 2. Memahami Lanskap Saat Ini: Tumpukan Identitas vs. Pembayaran Untuk melihat bagaimana [kredensial digital](https://www.corbado.com/id/blog/digital-credentials-api) dapat digunakan dalam pembayaran, pertama-tama kita perlu memahami bagaimana platform seluler utama saat ini dan wallet bawaannya (Apple Wallet, [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) memisahkan informasi identitas dari cara pembayaran diproses. ### 2.1 Wallet Platform Native: Silo Terpisah untuk Identitas dan Pembayaran Wallet platform native telah menjadi pusat yang canggih bagi pengguna, tetapi biasanya mempertahankan perbedaan yang jelas antara kredensial identitas dan instrumen pembayaran: - **Kredensial Identitas (misalnya, mDL):** - **Apple Wallet:** Terutama mendukung surat izin mengemudi seluler (mDL) dan ID negara bagian yang sesuai dengan ISO/IEC 18013-5. Sejak [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26), Apple telah mengonfirmasi bahwa Safari 26 (di [iOS 26](https://www.corbado.com/blog/ios-26-passkeys)) akan mendukung W3C [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) untuk presentasi online, dengan fokus eksklusif pada protokol `org.iso.mdoc`. Ini untuk memverifikasi atribut identitas (misalnya, nama, usia, alamat), bukan untuk pembayaran. - **Google Wallet & Android Credential Manager:** [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay) juga mendukung [mDL](https://www.corbado.com/blog/mobile-drivers-license) berdasarkan [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5). [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Credential Manager yang mendasarinya menyediakan kerangka kerja yang lebih fleksibel. Meskipun implementasi [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) bersifat agnostik protokol, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) menyediakan implementasi default yang menggunakan [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) sebagai mekanisme transport. - **Instrumen Pembayaran (misalnya, Kartu Kredit/Debit):** - Baik [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) (di dalam Apple Wallet) maupun [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) (di dalam Google Wallet) menggunakan teknologi pembayaran yang sudah mapan dan sangat teregulasi. Ini terutama didasarkan pada standar EMV (Europay, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), [Visa](https://www.corbado.com/blog/visa-passkeys)), yang melibatkan tokenisasi (Device [PAN](https://www.corbado.com/glossary/pan) atau DPAN menggantikan nomor kartu aktual untuk transaksi), elemen aman atau [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) berbasis perangkat keras untuk menyimpan token pembayaran, dan kriptogram dinamis untuk [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) transaksi. - Sistem pembayaran ini berinteraksi langsung dengan jaringan pembayaran yang ada (Visa, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), Amex, dll.) dan bank [acquirer](https://www.corbado.com/glossary/acquirer). **Poin Penting:** Wallet platform native saat ini beroperasi dengan "tumpukan" atau teknologi terpisah untuk kredensial identitas versus kartu pembayaran. Sebuah [mdoc](https://www.corbado.com/glossary/mdoc) disajikan untuk membuktikan atribut identitas; kartu yang ditokenisasi disajikan untuk melakukan pembayaran. Tidak ada penggunaan langsung [mdoc](https://www.corbado.com/glossary/mdoc) _sebagai_ instrumen pembayaran dalam ekosistem native ini. ### 2.2 Mengapa mdocs ISO 18013-5 Bukan Instrumen Pembayaran Standar ISO/IEC 18013-5 mendefinisikan struktur data untuk [mDL](https://www.corbado.com/blog/mobile-drivers-license) dan ID seluler lainnya (mdocs). Meskipun sangat baik untuk verifikasi identitas, desainnya tidak cocok untuk penggunaan langsung sebagai instrumen pembayaran: | Fitur | Spesifikasi ISO 18013-5 (untuk mdocs Identitas) | Mengapa Ini Menjadi Masalah untuk Pembayaran | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Lingkup Utama** | Surat Izin Mengemudi Seluler & dokumen identitas lainnya. | Jaringan kartu memerlukan elemen data & kriptogram khusus pembayaran. | | **Model Data** | Elemen data terkait identitas yang tetap (misalnya, potret, nama, tanggal lahir). Dapat diperluas, tetapi masih terikat pada "namespace" identitas. | PAN kartu, DPAN yang ditokenisasi, CVM, kriptogram dinamis tidak dapat dipetakan dengan bersih ke elemen identitas ini. | | **Model Ancaman & Keamanan** | Verifikasi saat pemegang hadir ("attended"); "tap-to-verify" offline dengan pengungkapan selektif untuk atribut identitas. Pengambilan data yang aman dari mdoc. | Pembayaran memerlukan mekanisme yang kuat untuk otorisasi online, pembuatan kriptogram dinamis (gaya EMV), pencegahan penipuan khusus untuk transaksi keuangan, dan tautan ke sumber pendanaan. Keamanan mdoc adalah untuk integritas identitas, bukan pemrosesan transaksi keuangan. | | **Pengakuan Standar** | ISO 18013-5 secara eksplisit membatasi dirinya pada ID tatap muka. ISO/IEC 18013-7 dan ISO/IEC 23220 menentukan mekanisme presentasi online untuk mdocs (misalnya, untuk verifikasi identitas berbasis web melalui Digital Credentials API), tetapi ini masih berfokus pada _verifikasi identitas jarak jauh_, bukan jalur pembayaran. | Pembayaran, terutama online, tetap berada di luar lingkup standar mdoc itu sendiri. | Bahkan jika sebuah [mdoc](https://www.corbado.com/glossary/mdoc) secara teoretis _dapat_ ditambahkan bidang data kustom untuk menampung [PAN](https://www.corbado.com/glossary/pan) atau token pembayaran (seperti yang diizinkan oleh [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) untuk namespace kustom), standar mdoc itu sendiri tidak mendefinisikan: - Cara menghasilkan atau memproses kriptogram pembayaran dinamis. - Cara melakukan otorisasi online dengan jaringan pembayaran. - Mekanisme [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) yang diperlukan khusus untuk transaksi pembayaran (di luar integritas data identitas). Dengan demikian, saat ini tidak ada cara untuk menggunakan mdoc ISO 18013-5 sebagai instrumen pembayaran langsung. ### 2.3 Autentikasi Step-Up: Menggunakan mdocs untuk Pembuktian Identitas, Bukan Pembayaran Walaupun mdoc bukan alat pembayaran, ia dapat berperan dalam alur "[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) step-up", di mana identitas pengguna harus diverifikasi secara eksplisit untuk tindakan berisiko tinggi. Ini berbeda dengan menggunakannya untuk mengeksekusi pembayaran itu sendiri. Alurnya biasanya akan terlihat seperti ini: 1. **Autentikasi Utama:** Pengguna masuk ke layanan, seringkali dengan metode gesekan rendah seperti passkey. 2. **Pemicu untuk Step-Up:** Untuk tindakan berjaminan tinggi (misalnya, transfer bank dalam jumlah besar, memperbarui detail pribadi), layanan memerlukan pemeriksaan identitas eksplisit. 3. **Presentasi mdoc:** Layanan meminta presentasi mdoc pengguna (misalnya, surat izin mengemudi). Pengguna menyajikan atribut yang diperlukan dari wallet mereka. 4. **Verifikasi:** Layanan secara kriptografis memverifikasi data mdoc terhadap sumber tepercaya atau identitas yang terdaftar sebelumnya. Dalam model ini, mdoc memberikan bukti identitas yang kuat dan tahan [phishing](https://www.corbado.com/glossary/phishing) untuk momen spesifik yang berisiko tinggi. Namun, transaksi keuangan yang mengikutinya masih menggunakan jalur pembayaran yang sudah ada. Mdoc memverifikasi _orangnya_, bukan _metode pembayarannya_. ## 3. Peran OpenID4VC dalam Skenario Pembayaran Potensial Walaupun mdocs itu sendiri bukan instrumen pembayaran, protokol seperti OpenID for [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (OpenID4VC – mencakup [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) untuk presentasi dan [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) untuk penerbitan) menawarkan lapisan transport yang lebih fleksibel. **Karakteristik Utama OpenID4VC:** - **Protokol, Bukan Muatan:** OID4VC mendefinisikan cara meminta dan menyajikan VC tetapi sebagian besar agnostik tentang format muatan VC itu sendiri. Ia dapat mengangkut mdocs, VC standar W3C (misalnya, dalam format JWT atau SD-JWT), atau jenis kredensial kustom lainnya. - **Cakupan Kasus Penggunaan:** Fleksibilitas ini memungkinkan platform seperti [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) (melalui Credential Manager-nya) untuk mendukung permintaan berbagai jenis kredensial melalui mekanisme umum. - **Kompatibilitas Masa Depan untuk VC Pembayaran:** Jika industri pembayaran menstandarkan format kredensial "token pembayaran" atau "otorisasi pembayaran" yang dapat diverifikasi, OID4VC secara teoretis dapat mengangkut kredensial semacam itu antara wallet pengguna dan [merchant](https://www.corbado.com/glossary/merchant)/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk). **Namun, OID4VC Sendiri Bukan Solusi Pembayaran:** - Peran OID4VC adalah untuk memfasilitasi pertukaran kredensial. Ia tidak mendefinisikan konten kredensial pembayaran, fitur keamanan, atau bagaimana ia berinteraksi dengan sistem pemrosesan pembayaran. - Agar OID4VC berguna untuk pembayaran, _format kredensial pembayaran yang dapat diverifikasi_ yang diadopsi secara luas, aman, dan terstandarisasi perlu dikembangkan dan didukung terlebih dahulu oleh ekosistem pembayaran (penerbit, [acquirer](https://www.corbado.com/glossary/acquirer), jaringan). Ini saat ini tidak ada. ## 4. Wallet Pihak Ketiga dan Pembayaran Di luar wallet platform native, ekosistem wallet pihak ketiga yang berkembang (misalnya, EUDI Wallet, wallet yang disediakan bank, wallet industri khusus) sedang muncul. Wallet ini harus menavigasi perbedaan mendasar antara [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) cepat dengan gesekan rendah dan verifikasi atribut berjaminan tinggi, terutama dalam konteks pembayaran. Konsensus yang muncul adalah bahwa [passkeys ideal untuk _autentikasi_ inti ke layanan pembayaran](https://www.corbado.com/blog/digital-credentials-passkeys#34-payment-scenarios-low-friction), karena tahan [phishing](https://www.corbado.com/glossary/phishing) dan dirancang untuk pengalaman pengguna yang mulus. Menyuntikkan presentasi kredensial digital ke dalam langkah konfirmasi pembayaran yang kritis akan menambah gesekan yang signifikan dan kemungkinan akan merusak tingkat konversi. Oleh karena itu, peran utama kredensial digital adalah dalam fase orientasi dan [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) satu kali yang berjaminan tinggi yang memungkinkan kapabilitas pembayaran, bukan dalam transaksi itu sendiri. Bagaimana mungkin wallet ini mendekati pembayaran, terutama dalam hubungannya dengan fitur [identitas digital](https://www.corbado.com/id/blog/digital-credentials-api)? ### 4.1 Model Interaksi Saat Ini untuk Pembayaran Agar wallet pihak ketiga dapat mengotorisasi pembayaran, ia memerlukan cara untuk dipanggil oleh aplikasi atau situs web [merchant](https://www.corbado.com/glossary/merchant). Ada beberapa model interaksi yang sudah mapan untuk ini, masing-masing dengan tingkat integrasi platform dan pengalaman pengguna yang berbeda: - **Deep Linking Antar-Aplikasi:** Ini adalah metode universal di mana aplikasi [merchant](https://www.corbado.com/glossary/merchant) (native atau web) mengarahkan pengguna ke aplikasi wallet pihak ketiga menggunakan skema URL kustom (misalnya, `eudi-wallet://...`). Detail transaksi diteruskan sebagai parameter dalam URL. Setelah pengguna mengonfirmasi pembayaran di aplikasi wallet, ia akan mengarahkan kembali ke aplikasi merchant menggunakan deep link lain. Ini berfungsi di [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) dan Android tetapi melibatkan perpindahan konteks yang terlihat antar aplikasi. - **Pemilihan Wallet Native:** Dengan Pemilihan Wallet Native, sebuah aplikasi dapat memanggil layanan sistem generik yang menampilkan semua penangan pembayaran atau wallet yang terdaftar. Pengguna kemudian dapat memilih wallet pilihan mereka dari UI yang disediakan sistem. Ini menawarkan nuansa yang lebih terintegrasi daripada deep linking sederhana (Digital Credential API). - **Pembayaran Berbasis Kode QR Sederhana:** Model ini ideal untuk alur desktop-ke-seluler. Situs web merchant menampilkan [kode QR](https://www.corbado.com/id/blog/kode-qr-login-autentikasi) yang berisi detail transaksi atau URL. Pengguna memindai kode ini dengan aplikasi wallet seluler mereka, yang kemudian secara mandiri menangani konfirmasi di ponsel. Backend wallet kemudian mengomunikasikan persetujuan kembali ke sistem merchant. - **Alur Lintas Perangkat Terstandarisasi (FIDO CTAP):** Sebuah evolusi dari metode kode QR, ini menggunakan protokol seperti Client to [Authenticator](https://www.corbado.com/glossary/authenticator) Protocol (CTAP) dari FIDO untuk membuat saluran langsung, aman, dan terenkripsi antara browser desktop (klien) dan wallet seluler (bertindak sebagai [authenticator](https://www.corbado.com/glossary/authenticator)). Ini lebih aman daripada [kode QR](https://www.corbado.com/id/blog/kode-qr-login-autentikasi) sederhana karena browser dan ponsel berkomunikasi secara langsung, sebuah model yang sangat didukung oleh Google untuk passkeys dan kredensial digital. - **Integrasi Backend Langsung:** Dalam beberapa sistem loop tertutup, aplikasi wallet pihak ketiga mungkin berinteraksi langsung dengan [Payment Service Provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) (PSP) atau backend lembaga keuangan untuk memproses pembayaran, seringkali menggunakan API proprietary. Model-model ini menyediakan "lapisan transport" untuk memulai konfirmasi pembayaran, di mana alur kriptografis (seperti yang dirinci untuk EUDI Wallet) kemudian dapat berlangsung. ### 4.2 Integrasi Browser: Identitas Dahulu, Pembayaran Terpisah Dengan pengumuman di [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26), lanskap tentang bagaimana browser menangani kredensial digital menjadi jauh lebih jelas, memperkuat pemisahan antara verifikasi identitas dan pemrosesan pembayaran. Platform memungkinkan wallet pihak ketiga untuk berinteraksi dengan browser untuk _verifikasi identitas_ melalui W3C [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api), tetapi pendekatannya berbeda: - **Sikap Apple (Dikonfirmasi di WWDC25):** Apple secara resmi mengumumkan dukungan untuk Digital Credentials API di Safari 26 (dikirimkan bersama [iOS 26](https://www.corbado.com/blog/ios-26-passkeys)). Seperti yang dirinci dalam sesi mereka ["Verify identity documents on the web"](https://developer.apple.com/videos/play/wwdc2025/232/), implementasinya **secara eksklusif mendukung protokol `org.iso.mdoc`**. Ini memungkinkan situs web untuk meminta informasi yang dapat diverifikasi dari mdocs di Apple Wallet atau aplikasi penyedia dokumen pihak ketiga lainnya yang terdaftar, tetapi tidak mendukung protokol [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) yang lebih umum. Dengan meningkatnya dukungan untuk kredensial digital dan integrasi web yang disempurnakan, menjaga kinerja dan keamanan sistem menjadi lebih penting - alat seperti [CleanMyMac](https://cleanmymac.com/) membantu memastikan Mac Anda berjalan lancar seiring perkembangan teknologi ini. - **Sikap Google:** Credential Manager Android memungkinkan wallet pihak ketiga untuk mendaftar sebagai penangan permintaan kredensial. Implementasi Digital Credentials API di Chrome berfokus pada penggunaan **OpenID4VP** sebagai protokol transport utama. Meskipun OpenID4VP dapat membawa mdoc sebagai muatan, protokol itu sendiri berbeda dari pendekatan `org.iso.mdoc` langsung dari Apple. **Pentingnya, integrasi browser ini adalah untuk atribut identitas, bukan untuk memperlakukan mDoc atau VC yang disajikan sebagai instrumen pembayaran.** Jika pengguna menyajikan [mDL](https://www.corbado.com/blog/mobile-drivers-license) dari wallet mereka ke situs web melalui [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) API browser, situs web tersebut mungkin menggunakan informasi tersebut untuk pengisian otomatis alamat atau verifikasi usia saat checkout. Namun, langkah pembayaran yang sebenarnya masih memerlukan interaksi terpisah dengan metode pembayaran (misalnya, Apple Pay, [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay), atau memasukkan detail kartu). API browser itu sendiri tidak dirancang untuk memulai atau memproses transaksi keuangan menggunakan kredensial identitas. ## 5. EU Digital Identity Wallet dalam Praktik EU [Digital Identity](https://www.corbado.com/blog/digital-identity-guide) (EUDI) Wallet berfungsi sebagai studi kasus yang sangat baik tentang bagaimana wallet pihak ketiga harus menavigasi lanskap sistem operasi dan ketersediaan API yang kompleks dan nyata. Di antara banyak fungsinya, dua kasus penggunaan yang paling menonjol adalah verifikasi identitas dan konfirmasi pembayaran, dan jalur teknis untuk menyelesaikan kedua tugas ini berbeda, terutama saat membandingkan kerangka kerja fleksibel Android dengan implementasi Apple yang lebih kaku. ### 5.1 Perbandingan Model Interaksi: Identitas vs. Pembayaran Tabel berikut menguraikan bagaimana EUDI Wallet dapat dipanggil untuk verifikasi identitas atau otorisasi pembayaran, menyoroti dukungan yang berbeda di seluruh platform. | Model Integrasi | Identitas (Android) | Identitas (iOS) | Pembayaran (Android) | Pembayaran (iOS) | | :---------------------------- | :-----------------: | :-------------: | :------------------: | :--------------: | | **Digital Credentials API** | βœ… | βœ… | βœ…\* | ❌ | | **Native Wallet Selector** | βœ… | βœ… | βœ… | ❌ | | **App-to-App Deep Linking** | βœ… | βœ… | βœ… | βœ… | | **Standardized Cross-Device** | βœ… | ❌ | βœ… | ❌ | **Poin Penting dari Perbandingan:** - **Digital Credentials API:** Standar W3C yang sedang berkembang ini bersifat agnostik protokol dan didukung dengan baik untuk **identitas** di kedua platform. Untuk implementasinya, Android menyediakan alur default menggunakan protokol OpenID4VP yang fleksibel, yang dapat membawa berbagai format kredensial. Implementasi Apple, sebaliknya, secara ketat untuk format `org.iso.mdoc`. Yang terpenting, browser membatasi API ini untuk kasus penggunaan identitas, bukan untuk memulai pembayaran. - **Native Wallet Selector:** Kedua sistem operasi menyediakan UI native untuk memilih wallet, tetapi dengan batasan yang berbeda. Android menawarkan pemilih untuk aplikasi identitas dan pembayaran. [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) menyediakan pemilih untuk aplikasi "Penyedia Dokumen" identitas yang terdaftar tetapi tidak menawarkannya untuk aplikasi pembayaran pihak ketiga. - **App-to-App Deep Linking:** Ini adalah pekerja keras universal, berfungsi dengan andal untuk kasus penggunaan identitas dan pembayaran di kedua platform. Ini tetap menjadi metode utama untuk memanggil wallet pihak ketiga untuk pembayaran di [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios). - **Standardized Cross-Device:** Alur berbasis FIDO [CTAP](https://www.corbado.com/id/glossary/ctap) ini saat ini merupakan fitur ekosistem Google/Android dan tidak didukung di iOS. **(\*) Catatan tentang Pembayaran melalui DC API:** Meskipun penggunaan OpenID4VP oleh Android membuat alur pembayaran _secara teknis_ memungkinkan melalui [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) API, ini bukan fokus desain utamanya. Integrasi yang mulus untuk pembayaran melalui API spesifik ini, dibandingkan dengan metode native lainnya, masih harus dilihat dan akan memerlukan dukungan eksplisit dari vendor browser. Perbandingan ini menjelaskan bahwa meskipun verifikasi identitas semakin distandarisasi melalui Digital Credentials API, otorisasi pembayaran untuk wallet pihak ketiga seperti EUDI Wallet masih sangat bergantung pada pola integrasi native yang lebih tradisional seperti deep linking antar-aplikasi, terutama di iOS. ### 5.2 Di Balik Layar: Alur Konfirmasi Pembayaran EWC Terlepas dari model integrasi pembayaran mana yang digunakan untuk memanggil wallet, inti dari konfirmasi pembayaran EUDI Wallet bergantung pada alur kriptografis terstandarisasi yang dirinci dalam [`EWC RFC008`](https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc008-payment-data-confirmation.md). Di bawah ini adalah panduan tingkat tinggi dari proses ini: | Langkah | Tindakan | Artefak Kunci | | ------- | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Permintaan Otorisasi** | Merchant atau PSP mengirimkan permintaan OpenID4VP ke wallet yang berisi `presentation_definition` yang merujuk pada _Payment Wallet Attestation_ **dan** objek `transaction_data` yang di-encode base64url (jumlah, mata uang, penerima pembayaran). | | 2 | **Tinjauan & Persetujuan Pengguna** | Wallet menampilkan detail pembayaran yang dapat dibaca manusia (misalnya, € 23,58 ke _Merchant XYZ_) dan meminta pengguna untuk menyetujui dengan gerakan biometrik atau PIN. | | 3 | **Presentasi yang Dapat Diverifikasi** | Wallet mengembalikan Verifiable Presentation yang mencakup (a) Payment Wallet Attestation yang dipilih (sebagai SD-JWT VC) dan (b) JWT pengikat kunci yang klaim `transaction_data_hashes`-nya membuktikan pengguna menandatangani muatan yang sama persis dari langkah 1. | | 4 | **Verifikasi** | PSP memvalidasi presentasi, memeriksa bahwa hash dari `transaction_data` asli cocok dengan yang ada di JWT, dan memastikan stempel waktu masih baru. | | 5 | **Pergerakan Dana** | Setelah memenuhi SCA, PSP melanjutkan dengan pembayaran kartu atau akun normal, yakin bahwa pengguna secara eksplisit mengonfirmasi detail transaksi. | #### Contoh: Muatan Data Transaksi Ini adalah contoh non-normatif dari objek `payment_data` yang dikirim ke wallet, merinci transaksi untuk dikonfirmasi oleh pengguna. ```json { "payee": "Merchant XYZ", "currency_amount": { "currency": "EUR", "value": "23.58" }, "recurring_schedule": { "start_date": "2024-11-01", "expiry_date": "2025-10-31", "frequency": 30 } } ``` #### Contoh: Klaim JWT Pengikat Kunci Setelah pengguna menyetujui, wallet membuat JWT pengikat kunci. Klaimnya membuktikan bahwa pengguna mengonfirmasi data transaksi spesifik tersebut. ```json { "nonce": "n-0S6_WzA2Mj", "aud": "https://example.com/verifier", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4", "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"] } ``` ## 6. Respons Industri: Menyatukan Pembayaran dan Identitas Sementara standar teknis sedang berkembang, industri pembayaran tidak tinggal diam. Para pemain kunci secara aktif menjajaki cara menggabungkan keamanan kredensial digital dengan fungsionalitas pembayaran. ### 6.1 Paralel dengan Tokenisasi Pembayaran Cara yang ampuh untuk memahami potensi [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (VC) adalah dengan membandingkannya dengan sistem tokenisasi pembayaran jaringan yang sukses (seperti [Visa](https://www.corbado.com/blog/visa-passkeys) Token Service atau [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) MDES). - **Tokenisasi Pembayaran** menggantikan Primary Account Number (PAN) yang sensitif dengan token yang aman dan kriptogram sekali pakai. Ini melindungi aset intiβ€”nomor kartuβ€”selama transaksi. - **Verifiable Credentials** bertujuan untuk melakukan hal yang sama untuk data pribadi seperti yang dilakukan tokenisasi untuk [PAN](https://www.corbado.com/glossary/pan). Alih-alih membagikan data mentah (nama, tanggal lahir, alamat), pengguna menyajikan kredensial yang ditandatangani secara kriptografis dari penerbit tepercaya. Intinya, **VC bagi data pribadi adalah seperti token pembayaran dan kriptogram bagi data kartu**: pengganti yang aman dan dapat diverifikasi yang mengurangi risiko dan meningkatkan privasi. ### 6.2 Kebangkitan Kredensial Pembayaran yang Dapat Diverifikasi Berdasarkan paralel ini, badan-badan industri sedang mengerjakan konsep "kredensial pembayaran yang dapat diverifikasi." Ini akan menjadi kredensial, yang dikeluarkan oleh bank, yang mengemas instrumen pembayaran (seperti kartu yang ditokenisasi) dan dapat digunakan untuk mengotorisasi transaksi. - [**EMVCo**](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc), badan standar untuk pembayaran yang aman, secara aktif mengintegrasikan standar FIDO ke dalam protokol EMV [3-D Secure](https://www.corbado.com/glossary/3d-secure). Ini memungkinkan [autentikasi passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) sebelumnya untuk digunakan sebagai sinyal kuat untuk persetujuan tanpa gesekan, sambil juga mempersiapkan [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) untuk berfungsi sebagai alternatif modern yang tahan [phishing](https://www.corbado.com/glossary/phishing) terhadap tantangan OTP tradisional. Ada juga diskusi yang sedang berlangsung tentang bagaimana kredensial yang dapat diverifikasi dapat dimasukkan ke dalam alur ini di masa depan. - **Visa** telah mengumumkan [**Visa Payment Passkey Service**](https://www.corbado.com/blog/visa-passkeys), yang secara aman mengikat [authenticator](https://www.corbado.com/glossary/authenticator) FIDO ke kredensial pembayaran. Layanan ini dirancang untuk mengonfirmasi identitas dan mengotorisasi pembayaran dalam satu langkah mulus tanpa mengganggu pengalaman checkout. - **Mastercard** mengikuti strategi paralel dengan [**Mastercard Payment Passkey Service**](https://www.corbado.com/blog/mastercard-passkeys), yang memanfaatkan Token Authentication Service (TAS) untuk menggantikan kata sandi dan OTP dengan [autentikasi biometrik](https://www.corbado.com/id/faq/apa-itu-passkeys) berbasis passkey, yang terintegrasi erat dengan layanan tokenisasinya (MDES). Ini menunjukkan tren yang jelas: industri bergerak menuju masa depan di mana wallet dapat menyajikan bukti yang dapat diverifikasi secara kriptografis baik untuk identitas maupun otorisasi pembayaran dalam satu alur terstandarisasi. ## 7. Lanskap Regulasi: Eropa sebagai Katalisator Sebagian besar inovasi ini dipercepat oleh dorongan regulasi yang kuat, terutama dari Uni Eropa. ### 7.1 Peran EUDI Wallet dalam Strong Customer Authentication (SCA) Regulasi [eIDAS 2.0](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) Uni Eropa bukan hanya tentang menyediakan ID digital bagi warga negara; secara eksplisit membayangkan [EUDI Wallet](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en) sebagai metode untuk melakukan [SCA](https://www.corbado.com/id/blog/psd2-passkeys) untuk pembayaran online. Ini berarti bahwa di masa depan, bank dan penyedia pembayaran di UE mungkin diharuskan menerima EUDI Wallet sebagai cara bagi pengguna untuk mengonfirmasi transaksi online, menyediakan alternatif berbasis standar untuk aplikasi [perbankan](https://www.corbado.com/passkeys-for-banking) proprietary atau kode SMS. ### 7.2 Taman Berdinding NFC Apple Kini Terbuka (di Eropa) Sebuah [penyelesaian antimonopoli penting di UE](https://ec.europa.eu/commission/presscorner/detail/en/ip_24_3706) telah memaksa Apple untuk membuka antarmuka NFC yang sebelumnya tertutup di iPhone. Sejak [iOS 17](https://www.corbado.com/blog/apple-passkeys-integration).4 (dirilis 5 Maret 2024), Apple telah mengimplementasikan API yang diperlukan dan memungkinkan pengguna untuk memilih aplikasi pembayaran nirkontak default, memenuhi tenggat waktu yang mengikat dari Komisi Eropa pada 25 Juli 2024. Ini bukan lagi prospek masa depan; ini adalah kenyataan saat ini di Wilayah Ekonomi Eropa (EEA). Pergeseran ini berarti bahwa aplikasi wallet pihak ketiga sekarang dapat menawarkan solusi tap-to-pay mereka sendiri di iOS, mengakhiri monopoli [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) yang telah berlangsung lama. Kemampuan utama yang sekarang tersedia bagi pengembang meliputi: - **Pilihan Wallet Default:** Pengguna di EEA dapat mengatur aplikasi pihak ketiga yang memenuhi syarat sebagai aplikasi pembayaran nirkontak default mereka, yang dapat dipanggil melalui klik dua kali tombol samping. - **Integrasi Penuh:** Wallet ini dapat menggunakan fitur keamanan native iPhone, termasuk [Face ID](https://www.corbado.com/faq/is-face-id-passkey) dan Touch ID, untuk otorisasi pembayaran. - **Adopsi di Dunia Nyata:** Beberapa pemain besar telah meluncurkan solusi mereka, termasuk **Vipps MobilePay** di Norwegia dan **PayPal** di Jerman. Implikasi dari pembukaan ini signifikan dan sudah mulai terlihat: - **Peningkatan Persaingan:** Bank dan [fintech](https://www.corbado.com/id/blog/passkeys-finom) sekarang dapat bersaing langsung dengan [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) di platformnya sendiri, yang diharapkan dapat menekan biaya penerbit dan mendorong inovasi. - **Penggunaan Kredensial yang Lebih Luas:** API yang sama dapat digunakan untuk lebih dari sekadar pembayaran, termasuk lencana perusahaan, tiket transit, dan kunci hotel, tanpa perlu berada di Apple Wallet. - **Jalan untuk Kredensial Terstandarisasi:** Ini menetapkan preseden penting. Logika regulasi yang sama yang membuka antarmuka NFC untuk aplikasi pembayaran pada akhirnya dapat digunakan untuk mewajibkan dukungan untuk "Kredensial Pembayaran yang Dapat Diverifikasi" yang terstandarisasi dan netral (seperti yang sedang diujicobakan untuk EUDI Wallet), memungkinkan mereka berfungsi bersama solusi proprietary. - **Preseden Global:** Meskipun perubahan saat ini terbatas pada EEA, ini menetapkan preseden global yang kuat. Regulator di wilayah lain, termasuk AS, sedang mengamati dengan cermat, dan ini dapat mempercepat pembukaan serupa di seluruh dunia. ## 8. Buku Panduan Penerbit: Strategi Praktis untuk Pembayaran yang Dapat Diverifikasi Bagi penerbit pembayaran (bank, skema, [fintech](https://www.corbado.com/id/blog/passkeys-finom)), menavigasi pergeseran ke kredensial digital memerlukan strategi bertahap yang pragmatis. Tujuannya adalah membangun aset yang Anda kontrol hari ini untuk mempersiapkan ekosistem masa depan. Buku panduan ini menguraikan strategi tersebut, bergerak dari tindakan segera dengan penyesalan rendah ke evaluasi jangka panjang yang lebih strategis. ### Fase 1: Perluas Jangkauan & Amankan Pembayaran dengan Passkeys (Hari Ini) Fondasi dari setiap strategi wallet di masa depan adalah [aplikasi native](https://www.corbado.com/id/blog/passkey-aplikasi-native) yang aman dan diadopsi secara luas. Prioritas utama adalah memaksimalkan jangkauan aplikasi Anda dan memperkuat autentikasinya untuk login dan pembayaran. 1. **Dorong Adopsi Aplikasi Native:** Aplikasi seluler Anda adalah wallet masa depan Anda. Tujuan utamanya adalah menjadikannya alat yang sangat diperlukan bagi pelanggan Anda. Distribusi dan keterlibatan ini adalah fondasi penting untuk penerbitan kredensial atau fungsionalitas wallet di masa depan. 2. **Gunakan Passkeys untuk Pembayaran, Mengikuti Model PayPal:** Terapkan passkeys segera, tidak hanya untuk login, tetapi untuk otorisasi pembayaran. Targetkan pengalaman yang setara dengan solusi platform native seperti Apple Pay. Untuk lingkungan regulasi yang memerlukan [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA), adopsi pendekatan pragmatis [PayPal](https://www.corbado.com/blog/paypal-passkeys): - Manfaatkan passkeys sebagai faktor [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) utama. - Gabungkan dengan sinyal perangkat tepercaya (misalnya, "perangkat yang diingat" yang dikelola melalui aplikasi Anda atau cookie aman) untuk memenuhi faktor "kepemilikan" dari [SCA](https://www.corbado.com/id/blog/psd2-passkeys). - Kombinasi ini memungkinkan Anda untuk memberikan pengalaman konfirmasi pembayaran yang mulus dan rendah gesekan yang sangat aman dan patuh, tanpa menunggu dukungan VC universal. ### Fase 2: Kembangkan Kemampuan dengan Teknologi Baru (24-36 Bulan ke Depan) Dengan aplikasi yang aman dan dilindungi passkey sebagai fondasi Anda, Anda dapat mulai mengintegrasikan teknologi kredensial baru secara selektif di mana mereka menawarkan nilai yang jelas. 3. **Pantau Kebangkitan Kredensial Pembayaran yang Dapat Diverifikasi:** Konsep VC yang membawa token pembayaran sangat kuat tetapi belum terstandarisasi. Peran Anda di sini adalah menjadi pengamat dan peserta aktif. - **Tindakan:** Pantau dengan cermat kemajuan dalam badan standar seperti EMVCo dan W3C. Bersiaplah untuk memanfaatkan Kredensial Pembayaran yang Dapat Diverifikasi yang terstandarisasi jika dan ketika mereka memberikan keuntungan yang jelas dibandingkan alur berbasis passkey yang ada. 4. **Integrasikan Kredensial Digital untuk Kasus Penggunaan Identitas:** Seiring dengan semakin populernya wallet [identitas digital](https://www.corbado.com/id/blog/digital-credentials-api) (seperti EUDI Wallet), integrasikan Digital Credentials API untuk tugas-tugas _terkait identitas_, bukan pembayaran. - **Tindakan:** Gunakan presentasi VC untuk proses berjaminan tinggi di mana mereka unggul: - **Onboarding & KYC:** Sederhanakan penyiapan akun baru. - **Autentikasi Step-Up:** Verifikasi identitas untuk tindakan berisiko tinggi. - **Pemulihan Akun:** Sediakan jalur aman bagi pengguna yang kehilangan perangkat mereka. ### Fase 3: Pertahankan Tolok Ukur Tanpa Gesekan & Pantau Evolusi Passkey Penghalang utama adopsi untuk setiap teknologi pembayaran baru adalah gesekan pengguna. Sebelum menggantikan alur passkey yang sederhana, alternatif berbasis VC harus membuktikan bahwa ia tidak hanya lebih aman tetapi juga sama mulusnya. 5. **Bandingkan Tanpa Henti dengan Pengalaman Sekali Klik:** Standar untuk pengalaman pembayaran modern ditetapkan oleh para pemimpin seperti Apple Pay dan pengikut dekatnya di Web, [PayPal](https://www.corbado.com/blog/paypal-passkeys). Setiap alur baru yang Anda perkenalkan harus bersaing dengan konfirmasi sekali klik mereka yang hampir instan. Semua sinyal saat ini menunjukkan bahwa untuk sebagian besar transaksi, ketahanan phishing dari passkeys memberikan tingkat perlindungan yang cukup dan pengalaman pengguna yang superior. Jangan menambahkan langkah presentasi VC ke alur pembayaran jika itu menimbulkan gesekan yang terlihat. 6. **Perhatikan Sinyal Perangkat In-Band dalam WebAuthn:** Evolusi passkeys tidak statis. Meskipun upaya awal untuk menyediakan sinyal khusus perangkat dihentikan, badan standar secara aktif bekerja untuk mengintegrasikan sinyal kepercayaan pengikatan perangkat yang lebih kuat langsung ke dalam protokol WebAuthn. Ini akan memungkinkan RP untuk mengidentifikasi perangkat tepercaya selama [autentikasi passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi), lebih memperkuat sinyal untuk mesin risiko tanpa memerlukan presentasi VC terpisah di luar jalur. Pantau ruang ini dengan cermat, karena ini adalah jalur yang paling mungkin untuk meningkatkan keamanan tanpa mengorbankan pengalaman tanpa gesekan dari passkey. Dengan mengikuti buku panduan bertahap ini, seorang penerbit dapat membangun strategi yang kuat dan praktis yang memaksimalkan keamanan dan meningkatkan pengalaman pengguna hari ini, sambil bersiap untuk mengadopsi teknologi pembayaran yang dapat diverifikasi di masa depan dengan bijaksana. ## 9. Tantangan dan Prospek Masa Depan untuk VC dalam Pembayaran Agar kredensial digital menjadi bagian integral dari proses pembayaran di luar sekadar mendukung [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) atau mengautentikasi pengguna ke akun pembayaran, beberapa tantangan signifikan harus diatasi: 1. **Standardisasi VC Khusus Pembayaran:** Format kredensial yang dapat diverifikasi yang didedikasikan, aman, dan diterima secara luas untuk pembayaran perlu dikembangkan. Ini perlu merangkum token pembayaran, data spesifik transaksi, dan elemen keamanan dinamis yang potensial, jauh melebihi lingkup mdocs yang berfokus pada identitas saat ini atau VC generik. 2. **Integrasi dengan Jaringan Pembayaran:** Setiap solusi pembayaran berbasis VC harus terintegrasi secara mulus dengan jaringan pembayaran global yang ada (Visa, Mastercard, dll.) atau mengusulkan jalur baru yang layak. Ini melibatkan penyelarasan teknis, keamanan, dan model bisnis yang kompleks. 3. **Kepatuhan Regulasi:** Pembayaran sangat diatur (misalnya, [PSD2](https://www.corbado.com/blog/psd2-passkeys)/[SCA](https://www.corbado.com/id/blog/psd2-passkeys) di Eropa, [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) secara global). Sistem pembayaran berbasis VC perlu memenuhi semua peraturan keuangan yang relevan, termasuk yang untuk keamanan, perlindungan konsumen, dan anti-penipuan. 4. **Adopsi Penerbit dan Acquirer:** Bank, lembaga keuangan (sebagai penerbit VC pembayaran), dan [acquirer](https://www.corbado.com/glossary/acquirer) merchant perlu berinvestasi dalam [infrastruktur](https://www.corbado.com/passkeys-for-critical-infrastructure) untuk mendukung sistem semacam itu. 5. **Model Keamanan:** Model keamanan yang kuat khusus untuk VC pembayaran akan sangat penting, mencakup penerbitan, penyimpanan (idealnya dalam elemen aman yang didukung perangkat keras), presentasi, dan pencabutan dalam konteks keuangan. 6. **Pengalaman Pengguna:** Meskipun VC dapat menawarkan kontrol pengguna, pengalaman pembayaran harus tetap cepat, intuitif, dan andal untuk mendapatkan adopsi yang luas. **Kemungkinan di Masa Depan:** - **VC untuk Slip Otorisasi Pembayaran:** VC dapat mewakili "otorisasi" yang ditandatangani secara kriptografis untuk membayar dari akun yang ditautkan, disajikan melalui OpenID4VP, dengan transfer dana aktual masih terjadi melalui jalur tradisional. - **VC yang Mengandung Token Pembayaran:** VC terstandarisasi dapat didefinisikan untuk menyimpan token pembayaran dengan aman (mirip dengan EMV DPAN), yang kemudian diproses oleh [infrastruktur](https://www.corbado.com/passkeys-for-critical-infrastructure) pembayaran yang ada. - **VC Pembayaran Loop Tertutup:** Penerbit atau komunitas tertentu mungkin membuat VC untuk pembayaran dalam sistem loop tertutup mereka sendiri. Namun, ini sebagian besar masih konseptual saat ini. Dorongan utama di balik pengembangan VC dan mdoc saat ini, yang sekarang diperkuat oleh implementasi konkret API browser, tetap berfokus pada verifikasi identitas dan [atestasi](https://www.corbado.com/id/glossary/ctap) atribut, bukan eksekusi pembayaran. ## 10. Kesimpulan: Langkah Maju yang Pragmatis untuk Penerbit Konvergensi [identitas digital](https://www.corbado.com/id/blog/digital-credentials-api) dan pembayaran menyajikan lanskap yang kompleks namun dapat dinavigasi. Meskipun janji "kredensial pembayaran yang dapat diverifikasi" tunggal dan universal sangat menarik, artikel ini menyimpulkan bahwa strategi yang paling efektif dan praktis bagi penerbit pembayaran saat ini didasarkan pada kenyataan yang berbeda: **pertempuran untuk pengalaman pengguna terbaik adalah yang terpenting, dan passkeys adalah senjata paling ampuh.** Buku panduan strategisnya jelas. Langkah segera dengan penyesalan rendah adalah fokus pada membangun [aplikasi native](https://www.corbado.com/id/blog/passkey-aplikasi-native) yang tak terkalahkan, menggunakannya sebagai kendaraan untuk menerapkan pembayaran berbasis passkey yang dapat menyaingi standar "sekali klik" tanpa gesekan yang ditetapkan oleh Apple Pay dan [PayPal](https://www.corbado.com/blog/paypal-passkeys). Pendekatan ini menjawab kebutuhan inti keamanan (melalui ketahanan phishing) dan pengalaman pengguna saat ini, menggunakan teknologi yang matang dan diadopsi secara luas. Dalam model ini, [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) menemukan peran mereka yang krusial, tetapi berbeda. Mereka belum menjadi alat untuk tindakan pembayaran itu sendiri, tetapi sangat diperlukan untuk tugas-tugas identitas berjaminan tinggi yang mengelilinginya: orientasi yang aman, [pemulihan akun](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang kuat, dan [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) peraturan. Masa depan pembayaran tidak akan ditentukan oleh satu teknologi tunggal tetapi oleh fokus tanpa henti pada pengguna. Kesuksesan akan datang kepada penerbit yang menguasai pengalaman berbasis passkey di aplikasi mereka sendiri terlebih dahulu, sambil memantau evolusi kredensial yang dapat diverifikasi dan sinyal kepercayaan passkey in-band dengan bijaksana. Mereka harus siap untuk mengintegrasikan teknologi baru ini bukan saat mereka hanya tersedia, tetapi hanya ketika mereka dapat memenuhi tolok ukur yang tangguh dari pengalaman pembayaran yang benar-benar mulus, aman, dan superior.