Kredensial Digital & Pembayaran: Strategi Apple vs. Google Wallet

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 (termasuk mdocs ISO dan VC yang dikirim menggunakan OpenID4VC) terhubung dengan dunia pembayaran. Kita akan membahas:

• Bagaimana wallet ponsel saat ini (Apple Wallet, Google Wallet) menangani informasi ID versus kartu pembayaran.
• Mengapa standar ID digital saat ini seperti mdocs ISO 18013-5/7 tidak benar-benar cocok sebagai alat pembayaran langsung.
• Peran apa yang bisa dimainkan oleh protokol seperti OpenID4VC dalam metode pembayaran di masa depan.
• Bagaimana aplikasi wallet 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 & Passkeys dengan berfokus hanya pada pembayaran.

Untuk melihat bagaimana kredensial digital dapat digunakan dalam pembayaran, pertama-tama kita perlu memahami bagaimana platform seluler utama saat ini dan wallet bawaannya (Apple Wallet, Google Wallet) memisahkan informasi identitas dari cara pembayaran diproses.

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, Apple telah mengonfirmasi bahwa Safari 26 (di iOS 26) akan mendukung W3C 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 juga mendukung mDL berdasarkan ISO 18013-5. Android Credential Manager yang mendasarinya menyediakan kerangka kerja yang lebih fleksibel. Meskipun implementasi Digital Credentials API bersifat agnostik protokol, Android menyediakan implementasi default yang menggunakan OpenID4VP sebagai mekanisme transport.
• Instrumen Pembayaran (misalnya, Kartu Kredit/Debit):
  • Baik Apple Pay (di dalam Apple Wallet) maupun Google Pay (di dalam Google Wallet) menggunakan teknologi pembayaran yang sudah mapan dan sangat teregulasi. Ini terutama didasarkan pada standar EMV (Europay, Mastercard, Visa), yang melibatkan tokenisasi (Device PAN atau DPAN menggantikan nomor kartu aktual untuk transaksi), elemen aman atau keamanan berbasis perangkat keras untuk menyimpan token pembayaran, dan kriptogram dinamis untuk keamanan transaksi.
  • Sistem pembayaran ini berinteraksi langsung dengan jaringan pembayaran yang ada (Visa, Mastercard, Amex, dll.) dan bank acquirer.

Poin Penting: Wallet platform native saat ini beroperasi dengan "tumpukan" atau teknologi terpisah untuk kredensial identitas versus kartu pembayaran. Sebuah mdoc disajikan untuk membuktikan atribut identitas; kartu yang ditokenisasi disajikan untuk melakukan pembayaran. Tidak ada penggunaan langsung mdoc sebagai instrumen pembayaran dalam ekosistem native ini.

Standar ISO/IEC 18013-5 mendefinisikan struktur data untuk mDL dan ID seluler lainnya (mdocs). Meskipun sangat baik untuk verifikasi identitas, desainnya tidak cocok untuk penggunaan langsung sebagai instrumen pembayaran:

Bahkan jika sebuah mdoc secara teoretis dapat ditambahkan bidang data kustom untuk menampung PAN atau token pembayaran (seperti yang diizinkan oleh 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 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.

Walaupun mdoc bukan alat pembayaran, ia dapat berperan dalam alur "autentikasi 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 untuk momen spesifik yang berisiko tinggi. Namun, transaksi keuangan yang mengikutinya masih menggunakan jalur pembayaran yang sudah ada. Mdoc memverifikasi orangnya, bukan metode pembayarannya.

Walaupun mdocs itu sendiri bukan instrumen pembayaran, protokol seperti OpenID for Verifiable Credentials (OpenID4VC – mencakup OpenID4VP untuk presentasi dan 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 (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/PSP.

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, jaringan). Ini saat ini tidak ada.

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 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, karena tahan 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 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?

Agar wallet pihak ketiga dapat mengotorisasi pembayaran, ia memerlukan cara untuk dipanggil oleh aplikasi atau situs web 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 (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 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 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 Protocol (CTAP) dari FIDO untuk membuat saluran langsung, aman, dan terenkripsi antara browser desktop (klien) dan wallet seluler (bertindak sebagai authenticator). Ini lebih aman daripada kode QR 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 (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.

Dengan pengumuman di WWDC25, 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, tetapi pendekatannya berbeda:

• Sikap Apple (Dikonfirmasi di WWDC25): Apple secara resmi mengumumkan dukungan untuk Digital Credentials API di Safari 26 (dikirimkan bersama iOS 26). Seperti yang dirinci dalam sesi mereka "Verify identity documents on the web", 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 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 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 dari wallet mereka ke situs web melalui Digital Credentials 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, atau memasukkan detail kartu). API browser itu sendiri tidak dirancang untuk memulai atau memproses transaksi keuangan menggunakan kredensial identitas.

EU Digital Identity (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.

Tabel berikut menguraikan bagaimana EUDI Wallet dapat dipanggil untuk verifikasi identitas atau otorisasi pembayaran, menyoroti dukungan yang berbeda di seluruh platform.

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 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.
• Standardized Cross-Device: Alur berbasis FIDO 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 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.

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.

Di bawah ini adalah panduan tingkat tinggi dari proses ini:

Ini adalah contoh non-normatif dari objek payment_data yang dikirim ke wallet, merinci transaksi untuk dikonfirmasi oleh pengguna.

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

Setelah pengguna menyetujui, wallet membuat JWT pengikat kunci. Klaimnya membuktikan bahwa pengguna mengonfirmasi data transaksi spesifik tersebut.

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

Sementara standar teknis sedang berkembang, industri pembayaran tidak tinggal diam. Para pemain kunci secara aktif menjajaki cara menggabungkan keamanan kredensial digital dengan fungsionalitas pembayaran.

Cara yang ampuh untuk memahami potensi Verifiable Credentials (VC) adalah dengan membandingkannya dengan sistem tokenisasi pembayaran jaringan yang sukses (seperti Visa Token Service atau Mastercard 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. 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.

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, badan standar untuk pembayaran yang aman, secara aktif mengintegrasikan standar FIDO ke dalam protokol EMV 3-D Secure. Ini memungkinkan autentikasi passkey sebelumnya untuk digunakan sebagai sinyal kuat untuk persetujuan tanpa gesekan, sambil juga mempersiapkan Secure Payment Confirmation (SPC) untuk berfungsi sebagai alternatif modern yang tahan 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, yang secara aman mengikat 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, yang memanfaatkan Token Authentication Service (TAS) untuk menggantikan kata sandi dan OTP dengan autentikasi biometrik 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.

Sebagian besar inovasi ini dipercepat oleh dorongan regulasi yang kuat, terutama dari Uni Eropa.

Regulasi eIDAS 2.0 Uni Eropa bukan hanya tentang menyediakan ID digital bagi warga negara; secara eksplisit membayangkan EUDI Wallet sebagai metode untuk melakukan SCA 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 proprietary atau kode SMS.

Sebuah penyelesaian antimonopoli penting di UE telah memaksa Apple untuk membuka antarmuka NFC yang sebelumnya tertutup di iPhone. Sejak iOS 17.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 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 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 sekarang dapat bersaing langsung dengan 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.

Bagi penerbit pembayaran (bank, skema, fintech), 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.

Fondasi dari setiap strategi wallet di masa depan adalah 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 (SCA), adopsi pendekatan pragmatis PayPal:

   • Manfaatkan passkeys sebagai faktor autentikasi utama.
   • Gabungkan dengan sinyal perangkat tepercaya (misalnya, "perangkat yang diingat" yang dikelola melalui aplikasi Anda atau cookie aman) untuk memenuhi faktor "kepemilikan" dari SCA.
   • Kombinasi ini memungkinkan Anda untuk memberikan pengalaman konfirmasi pembayaran yang mulus dan rendah gesekan yang sangat aman dan patuh, tanpa menunggu dukungan VC universal.

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 (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.

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. 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, 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.

Agar kredensial digital menjadi bagian integral dari proses pembayaran di luar sekadar mendukung KYC 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/SCA di Eropa, PCI DSS 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 merchant perlu berinvestasi dalam infrastruktur 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 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 atribut, bukan eksekusi pembayaran.

Konvergensi identitas digital 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 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. 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 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 yang kuat, dan KYC 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.