Passkey Penyedia Pembayaran: Cara Membangun SDK Pihak Ketiga

Passkey muncul sebagai metode paling efektif untuk mengamankan dan mengotorisasi transaksi online, secara signifikan meningkatkan keamanan dan kenyamanan dibandingkan dengan autentikasi multifaktor (MFA) tradisional. Baru-baru ini, PayPal mengadopsi passkey sebagai solusi MFA mandiri utama mereka, menetapkan tren yang jelas bagi penyedia pembayaran di seluruh dunia.

Namun, passkey pada awalnya dirancang dengan mempertimbangkan konteks pihak pertama, yang berarti passkey berfungsi optimal saat pengguna melakukan autentikasi langsung di situs web atau aplikasi yang memiliki kredensial tersebut. Sebaliknya, penyedia pembayaran biasanya beroperasi dalam konteks pihak ketiga, di mana layanan mereka (seperti formulir pembayaran atau SDK) disematkan ke dalam situs web dan aplikasi merchant. Ketidakcocokan mendasar antara desain passkey dan model operasional penyedia pembayaran ini menimbulkan batasan kritis untuk integrasi yang mulus. Untuk mengatasi tantangan ini, kita harus mengeksplorasi dua pertanyaan penting:

1. Apa saja batasan saat ini dalam menggunakan passkey dalam konteks pihak ketiga untuk penyedia pembayaran? 2. Bagaimana penyedia pembayaran dapat mengatasi batasan ini untuk berhasil mengimplementasikan integrasi passkey pihak ketiga?

Dengan mengkaji pertanyaan-pertanyaan ini, kita akan menemukan bahwa upaya industri yang sedang berlangsung untuk mengadaptasi passkey ke konteks pihak ketiga—terutama melalui standar web seperti Secure Payment Confirmation (SPC)—terhambat oleh rintangan strategis yang secara implisit diberlakukan oleh Apple. Secara spesifik, dukungan terbatas Apple untuk pembuatan passkey lintas-asal di Safari dan tidak adanya dukungan dari Standar Secure Payment Confirmation merupakan penghalang signifikan, yang mempersulit adopsi mulus autentikasi berbasis passkey oleh penyedia pembayaran pihak ketiga. Memahami dan mengatasi rintangan ini sangat penting bagi setiap penyedia yang bertujuan untuk memberikan pengalaman pembayaran yang aman dan tanpa hambatan.

Passkey membawa login berbasis biometrik yang tahan phishing ke setiap lapisan tumpukan pembayaran. Berikut adalah rincian bagaimana setiap pemain dalam rantai nilai pembayaran dapat memperoleh manfaat dari integrasi autentikasi passkey.

Dampak: Checkout lebih cepat, konversi lebih tinggi, lebih sedikit pengabaian keranjang belanja. Peluang: Merchant yang menawarkan passkey melalui SDK atau alur redirect dapat meniru UX sekelas Apple Pay dan mengurangi ketergantungan pada kata sandi atau OTP—yang mengarah pada kepercayaan dan penjualan yang lebih tinggi.

Dampak: Autentikasi tanpa kata sandi yang mulus di seluruh perangkat. Peluang: Passkey menawarkan UX yang lebih baik daripada OTP atau kode SMS dan menghilangkan risiko phishing. Adopsi yang luas dapat mengubah passkey menjadi standar baru untuk verifikasi pemegang kartu.

Dampak: Pencegahan penipuan yang lebih kuat. Peluang: Penerbit dapat menawarkan autentikasi step-up berbasis passkey dalam alur 3DS, menurunkan biaya OTP dan meningkatkan kepuasan pengguna.

Dampak: Penerimaan transaksi lebih tinggi dan lebih sedikit autentikasi yang gagal. Peluang: Mendukung passkey melalui PSP dapat meningkatkan hasil merchant dan mengurangi hambatan selama checkout atau alur penagihan berulang.

Dampak: Mengurangi penipuan, UX merchant yang lebih baik, dan kepatuhan yang lebih baik. Peluang: Dengan menyematkan atau mengalihkan alur passkey, PSP dapat menyediakan autentikasi generasi berikutnya sambil mempertahankan kompatibilitas di seluruh browser dan aplikasi native.

Dampak: Persetujuan transaksi yang lebih efisien dengan lebih sedikit pembayaran yang ditolak. Peluang: Perusahaan pemrosesan pembayaran dapat mengintegrasikan verifikasi passkey ke dalam API mereka untuk mengurangi risiko dan mendukung alternatif SCA biometrik untuk alur yang patuh.

Dampak: Penyimpanan kredensial yang aman dan reautentikasi tanpa hambatan. Peluang: Penyedia dompet digital seperti Apple Pay dan Google Pay sudah menggunakan alur yang mirip dengan passkey.

Berikut ini, kita akan melihat secara singkat penyedia pembayaran dan kartu kredit utama dan menganalisis apakah dan bagaimana mereka telah mengimplementasikan passkey:

Mastercard telah secara resmi meluncurkan Payment Passkey Service-nya, menyediakan pengalaman autentikasi tanpa kata sandi yang disematkan ke dalam alur EMV 3DS. Pengguna dapat membuat dan menggunakan passkey yang terikat pada domain autentikasi Mastercard (misalnya, verify.mastercard.com), memungkinkan login biometrik yang aman di seluruh merchant yang berpartisipasi. Peluncuran ini merupakan langkah besar menuju autentikasi yang tahan phishing dan patuh PSD2 di industri pembayaran. Baca lebih lanjut: Mastercard Passkeys

Visa telah memperkenalkan Visa Payment Passkey Service-nya, mengintegrasikan passkey ke dalam alur “Click to Pay”. Dengan memungkinkan pengguna untuk melakukan autentikasi secara mulus menggunakan biometrik alih-alih kata sandi atau OTP, Visa bertujuan untuk memodernisasi pengalaman checkout online dengan keamanan dan kenyamanan pengguna yang ditingkatkan. Baca lebih lanjut: VISA Passkeys

American Express belum secara publik meluncurkan penawaran passkey. Namun, sebagai anggota dewan FIDO Alliance, kemungkinan besar American Express akan meluncurkan solusi autentikasi berbasis passkey dalam waktu dekat, sejalan dengan tren industri yang lebih luas.

PayPal adalah salah satu penyedia pembayaran pertama yang mengadopsi passkey. Peluncuran mereka mendukung login biometrik yang mulus untuk akun pribadi dan bisnis di seluruh perangkat. Passkey terikat pada domain PayPal dan sudah tersedia di banyak wilayah. Namun, implementasi mereka masih memiliki ruang untuk perbaikan, terutama dalam hal alur multi-perangkat dan deteksi platform. Baca lebih lanjut: PayPal Passkeys

Klarna belum secara resmi memperkenalkan dukungan passkey. Dari pengamatan kami, Klarna sangat bergantung pada WebView yang disematkan di aplikasi dan SDK checkout mereka. Karena Safari dan iOS membatasi pembuatan passkey di iframe / WebView, ini mungkin menjadi alasan mengapa Klarna belum meluncurkan passkey sejauh ini.

Square telah memperkenalkan login passkey untuk dasbor pengembang dan konsol manajemen mereka, memungkinkan akses tanpa kata sandi yang aman ke alat internal. Namun, belum ada pengumuman mengenai dukungan passkey dalam alur pembayaran atau API untuk pengguna akhir atau merchant.

Stripe telah meluncurkan login passkey untuk dasbor mereka, memungkinkan pengembang untuk melakukan autentikasi menggunakan biometrik. Passkey untuk Stripe Checkout atau Elements belum tersedia. Mengingat advokasi kuat Stripe untuk alur berbasis redirect, kemungkinan besar passkey—jika diimplementasikan dalam pembayaran—akan mengikuti arsitektur redirect yang sama.

Sampai sekarang, BILL belum membuat pengumuman publik atau pembaruan produk terkait passkey untuk autentikasi.

Remitly belum mengungkapkan rencana atau informasi publik apa pun tentang penerapan autentikasi passkey dalam layanan mereka.

Tidak ada laporan publik atau dokumentasi produk yang menunjukkan bahwa Payoneer telah mengadopsi atau sedang menguji login atau alur transaksi berbasis passkey.

Adyen belum memperkenalkan passkey ke dalam alur autentikasi atau pembayaran mereka. Tidak ada pernyataan publik atau dokumentasi pengembang yang menyebutkan dukungan passkey.

Worldpay belum mengumumkan dukungan apa pun untuk passkey hingga saat ini. Tumpukan autentikasi mereka masih mengandalkan metode tradisional seperti kata sandi, OTP, dan alur berbasis 3DS.

Checkout.com belum secara publik meluncurkan dukungan passkey. Tidak ada pembaruan pengembang, posting blog, atau pengumuman resmi mengenai adopsi passkey.

AliPay belum secara resmi meluncurkan passkey. Mengingat tren yang berkembang dalam autentikasi biometrik dalam ekosistem pembayaran Tiongkok, peluncuran mungkin terjadi di masa depan, tetapi tidak ada dokumentasi saat ini yang mengonfirmasi hal ini.

Mollie belum membuat pernyataan publik atau pembaruan produk apa pun mengenai adopsi passkey dalam sistem autentikasi atau checkout-nya.

Amazon telah meluncurkan dukungan passkey untuk login pengguna di platform utamanya. Memperluas teknologi ini ke Amazon Pay akan menjadi langkah selanjutnya yang wajar, terutama karena banyak pengguna sudah memiliki passkey yang terdaftar di Amazon, yang akan secara signifikan menyederhanakan orientasi pengguna selama checkout.

Braintree, sebuah perusahaan PayPal, belum secara resmi mengadopsi autentikasi passkey. Dokumentasi mereka saat ini tidak menyebutkan passkey dalam konteks login pengguna atau API merchant.

Link, solusi checkout sekali klik dari Stripe, telah meluncurkan passkey yang mungkin berfungsi sebagai dasar untuk strategi passkey Stripe dalam pembayaran konsumen. Namun, Stripe belum secara resmi mengumumkan dukungan passkey untuk Link atau rencana spesifik apa pun untuk peluncuran.

Afterpay belum merilis pernyataan atau fitur apa pun yang terkait dengan dukungan passkey. Seperti Klarna, integrasi checkout mereka sangat berbasis aplikasi, yang mungkin menimbulkan rintangan teknis untuk adopsi passkey karena batasan WebView yang disematkan.

Adopsi passkey oleh penyedia pembayaran pihak ketiga menghadapi hambatan strategis, terutama didorong oleh kebijakan restriktif Apple di Safari. Dua upaya standardisasi kritis secara konsisten terhambat:

• Secure Payment Confirmation (SPC)

• Pembuatan Passkey Pihak Ketiga di Iframes

Secure Payment Confirmation (SPC) merupakan upaya paling signifikan dari industri—terutama didorong oleh Google—untuk memungkinkan penggunaan passkey lintas-asal yang mulus dan dirancang khusus untuk otorisasi pembayaran yang aman. SPC menstandardisasi cara penyedia pembayaran mengautentikasi pengguna di berbagai situs merchant tanpa mengorbankan keamanan atau pengalaman pengguna. Namun, Apple secara konsisten menahan dukungan untuk SPC di dalam Safari, kemungkinan sebagai langkah strategis untuk memastikan bahwa Apple Pay tetap menjadi solusi pembayaran yang paling disukai dan paling lancar di dalam ekosistemnya. Penolakan Apple untuk mengadopsi SPC tidak hanya membatasi penyebaran luas passkey dalam konteks pihak ketiga tetapi juga secara efektif menunda adopsi industri yang lebih luas terhadap autentikasi pembayaran yang terstandardisasi.

Baca posting blog ini tentang SPC jika Anda ingin mempelajari lebih lanjut tentang detailnya.

Penghalang kritis lainnya melibatkan pembatasan yang disengaja oleh Apple terhadap pembuatan passkey di dalam iframe lintas-asal. Meskipun Safari mengizinkan penggunaan passkey yang ada untuk autentikasi (navigator.credentials.get()) di iframe pihak ketiga, Safari secara eksplisit memblokir pendaftaran passkey (navigator.credentials.create()) dalam konteks semacam itu.

Batasan ini sangat membatasi penyedia pembayaran yang bergantung pada pembuatan passkey baru secara mulus selama alur checkout merchant. Akibatnya, penyedia terpaksa menggunakan pendekatan berbasis redirect atau harus mengandalkan passkey yang sudah ada yang sebelumnya dibuat langsung di domain mereka sendiri. Keputusan oleh Apple ini secara langsung memengaruhi kepraktisan dan kelancaran integrasi merchant, menciptakan titik gesekan yang signifikan bagi konsumen dan penyedia.

Dalam pendekatan ini, merchant menyertakan formulir pembayaran Anda dalam <iframe> yang disajikan dari domain penyedia pembayaran Anda—misalnya, https://pay.provider.com. Pengguna tetap berada di domain merchant (misalnya, https://www.mystore.com), melihat UI pembayaran Anda di iframe yang disematkan dan melakukan autentikasi dengan passkey yang terikat pada ID Pihak yang Bergantung pay.provider.com.

Poin Kunci:

• Lintas-Asal: Karena iframe berada di domain yang berbeda, Anda harus mengonfigurasi kebijakan izin untuk publickey-credentials-get dan publickey-credentials-create untuk mengizinkan operasi passkey di dalam iframe.

• Batasan Pembuatan: Beberapa browser (terutama versi lama dan Safari) masih tidak mengizinkan pembuatan passkey di iframe lintas-asal. Autentikasi (navigator.credentials.get()) lebih banyak didukung, tetapi pendaftaran (navigator.credentials.create()) mungkin gagal di lingkungan tertentu, terutama di Safari.

• Aktivasi Pengguna: Alur passkey biasanya memerlukan “aktivasi sementara” (misalnya, klik tombol langsung dari pengguna). Pastikan antarmuka iframe Anda memicu seremoni passkey dalam acara yang diinisiasi oleh pengguna.

• Keamanan & UX: Pendekatan iframe memberikan pengalaman checkout inline yang lancar, tetapi jika browser pengguna memblokir atau membatasi cookie pihak ketiga atau penyimpanan lokal, hal itu dapat mengganggu alur passkey.

Dengan alur berbasis redirect, Anda mengirim pengguna dari domain merchant ke domain pembayaran Anda, atau membuka tab/jendela baru yang menunjuk ke sesuatu seperti https://pay.provider.com/checkout. Passkey kemudian dibuat atau digunakan langsung di domain Anda dalam konteks pihak pertama.

Poin Kunci:

• Kesederhanaan Pihak Pertama: Seluruh alur kerja passkey (pembuatan, autentikasi) terjadi di domain penyedia pembayaran, jadi tidak ada batasan lintas-asal. Semua browser utama mendukung pembuatan dan login passkey dalam konteks pihak pertama.

• UX Redirect: Pengguna meninggalkan halaman merchant (atau melihat pop-up) untuk menyelesaikan autentikasi. Ini bisa jadi kurang mulus, tetapi menyederhanakan arsitektur alur passkey dan mengurangi kompleksitas lintas-asal.

• Fallback untuk Browser yang Tidak Kompatibel: Anda dapat melakukan degradasi secara halus jika passkey tidak tersedia (misalnya, browser lama) dengan menyediakan metode login alternatif di domain pembayaran Anda tanpa memerlukan penanganan izin lintas-asal tambahan.

Mengintegrasikan passkey dalam aplikasi seluler native menghadirkan tantangan unik dibandingkan dengan skenario berbasis web. Aplikasi native untuk merchant (baik di iOS maupun Android) sering kali menyematkan alur pembayaran di dalam aplikasi menggunakan WebView yang disematkan untuk mempertahankan pengalaman pengguna yang mulus. Namun, mengimplementasikan autentikasi passkey pihak ketiga dalam konteks yang disematkan ini bisa menjadi masalah karena kebijakan asal-browser yang ketat dan batasan spesifik platform.

Passkey secara inheren terikat pada domain tertentu (ID “Pihak yang Bergantung”), yang merupakan prinsip keamanan inti yang memastikan bahwa kredensial tidak dapat disalahgunakan di situs web atau aplikasi yang tidak terkait. Ketika penyedia pembayaran membuat passkey di bawah domainnya sendiri—misalnya, pay.provider.com—passkey tersebut secara ketat terbatas pada domain itu baik di iOS maupun Android. Akibatnya, aplikasi native merchant (yang secara alami beroperasi di bawah pengidentifikasi aplikasi dan domain merchant sendiri) tidak dapat secara langsung memanggil passkey penyedia sebagai kredensial “pihak pertama”. Melakukannya akan memerlukan pembagian kunci pribadi lintas-asal, yang secara eksplisit dilarang oleh sistem operasi dan spesifikasi WebAuthn untuk mencegah phishing dan pencurian kredensial.

Dari perspektif perangkat, aplikasi native merchant adalah “asal” yang berbeda dari domain penyedia pembayaran. Mencoba melakukan autentikasi secara native terhadap kredensial yang terdaftar ke asal yang terpisah akan merusak model keamanan fundamental passkey yang terikat pada asal. Inilah sebabnya mengapa penggunaan passkey pihak ketiga dalam konteks merchant bergantung pada browser sistem atau WebView berbasis sistem (seperti ASWebAuthenticationSession di iOS atau Chrome Custom Tabs di Android). Alur khusus ini mempertahankan konteks domain asli penyedia—memastikan passkey tetap terikat pada asal dengan aman—sambil tetap memungkinkan pengguna untuk melakukan autentikasi dengan penyedia pembayaran di dalam aplikasi merchant. Di bagian berikut, kita akan menjelajahi cara kerjanya.

WebView yang disematkan (misalnya, WKWebView di iOS atau WebView Android) sangat disukai karena memungkinkan aplikasi untuk menyematkan konten web langsung ke antarmuka native mereka, menawarkan integrasi yang erat dan konsistensi UX. Namun, lingkungan yang disematkan ini sangat dibatasi saat menangani passkey pihak ketiga karena kebijakan asal dan keamanan:

• Ketidakcocokan Asal: Passkey sangat bergantung pada asal domain untuk penanganan kredensial yang aman. WebView yang disematkan beroperasi di bawah domain konten yang ditampilkannya (sering kali milik merchant), membuatnya menantang atau tidak mungkin untuk membuat atau mengautentikasi passkey yang terikat secara eksplisit ke domain penyedia pembayaran pihak ketiga.

• Batasan Keamanan Platform: Baik Apple (iOS) maupun Google (Android) secara progresif telah membatasi kemampuan WebView yang disematkan untuk autentikasi, terutama saat berhadapan dengan kredensial yang aman. Batasan ini dirancang untuk melindungi privasi pengguna dan keamanan tetapi membuat implementasi passkey pihak ketiga menjadi jauh lebih rumit.

Secara keseluruhan, meskipun WebView yang disematkan menarik bagi merchant dari perspektif UX, mereka memperkenalkan batasan praktis yang signifikan untuk mengimplementasikan alur autentikasi passkey pihak ketiga yang kuat.

Mengingat batasan yang terkait dengan WebView yang disematkan, penyedia pembayaran biasanya mengadopsi salah satu dari dua strategi alternatif untuk mengimplementasikan passkey pihak ketiga secara andal di aplikasi seluler native:

iOS (ASWebAuthenticationSession):

Apple menyediakan ASWebAuthenticationSession sebagai lingkungan yang aman dan mirip browser di luar konteks aplikasi host. Ini berbagi penyimpanan cookie dengan browser Safari default dan mendukung passkey pihak ketiga secara andal karena kredensial selaras dengan domain asal penyedia pembayaran.

Contoh berikut menunjukkan fungsionalitas “Check out with PayPal” di dalam aplikasi native BOSS. Ini menunjukkan bagaimana webview sistem ASWebAuthenticationSession dibuka, yang berbagi statusnya dengan cookie Safari, memungkinkan dialog passkey untuk segera dimulai.

Android (Chrome Custom Tabs):

Demikian pula, Custom Tabs Android menawarkan lingkungan yang mendekati browser yang memungkinkan pembuatan dan autentikasi passkey yang konsisten. Seperti ASWebAuthenticationSession, Custom Tabs berjalan terpisah dari konteks aplikasi merchant, memastikan integritas domain dan kredensial.

Lihat contoh yang sama dari aplikasi native BOSS di Android di sini:

Pendekatan lain melibatkan pengalihan pengguna keluar dari aplikasi native ke browser web default perangkat seluler (Safari di iOS, Chrome di Android). Ini memastikan alur pembayaran—dan dengan demikian manajemen passkey—terjadi sepenuhnya dalam konteks pihak pertama yang tepercaya yang terkait dengan domain penyedia pembayaran. Pengguna kemudian kembali ke aplikasi merchant setelah autentikasi atau penyelesaian pembayaran berhasil. Opsi ini sangat tidak nyaman bagi pelanggan karena mereka harus meninggalkan aplikasi.

Kedua solusi tersebut memerlukan transisi sementara pengguna keluar dari lingkungan aplikasi native merchant. Meskipun sedikit kurang mulus dibandingkan dengan solusi yang disematkan, pendekatan ini secara signifikan meningkatkan kompatibilitas, keamanan, dan keandalan operasi passkey pihak ketiga.

Pada akhirnya, penyedia pembayaran yang mengembangkan SDK native harus secara cermat menyeimbangkan pertimbangan pengalaman pengguna dengan batasan teknis praktis. Meskipun preferensi merchant untuk pengalaman yang sepenuhnya disematkan, memanfaatkan WebView sistem atau pengalihan browser eksternal tetap menjadi praktik terbaik untuk memastikan autentikasi passkey pihak ketiga yang aman dan dapat diandalkan di dalam aplikasi native.

Memilih antara pendekatan yang disematkan (iframe) dan pendekatan berbasis redirect untuk mengintegrasikan passkey pihak ketiga ke dalam SDK pembayaran melibatkan evaluasi trade-off di seluruh pengalaman pengguna, kompatibilitas browser, kompleksitas teknis, dan preferensi merchant.

Kedua solusi memiliki kelebihan dan kekurangan yang berbeda, yang harus dipertimbangkan dengan cermat oleh penyedia pembayaran berdasarkan pasar target mereka, UX yang diinginkan, dan infrastruktur teknis.

Pendekatan yang disematkan (iframe) menawarkan pengalaman pengguna yang mulus dan bermerek merchant yang sangat menarik bagi merchant, tetapi terhambat oleh kompatibilitas browser yang terbatas, terutama penolakan Safari untuk mengizinkan pembuatan passkey lintas-asal. Batasan ini memaksa merchant dan penyedia ke dalam solusi berbasis solusi sementara yang kompleks yang sering kali mengorbankan fungsionalitas atau mengarah pada dukungan yang tidak lengkap untuk pendaftaran passkey.

Sebaliknya, pendekatan redirect menawarkan kompatibilitas komprehensif di seluruh browser dan platform seluler native dengan beroperasi dalam konteks domain pihak pertama. Ini secara signifikan menyederhanakan integrasi, meningkatkan keandalan, dan memastikan dukungan penuh pembuatan dan autentikasi passkey. Kelemahan utamanya adalah potensi gesekan yang diciptakan dengan mengalihkan pengguna dari situs web atau aplikasi merchant, meskipun ini dapat dimitigasi dengan desain UX yang cermat, ekspektasi yang dikomunikasikan dengan jelas, atau integrasi dengan platform tepercaya seperti Corbado.

Mengingat pertimbangan ini, pendekatan hibrida sering kali ideal, memungkinkan penyedia pembayaran untuk memanfaatkan model iframe yang disematkan ketika browser pengguna mendukungnya dan secara halus beralih ke pendekatan redirect jika tidak. Strategi gabungan ini memaksimalkan kompatibilitas, daya tarik merchant, dan kepuasan pelanggan di berbagai lingkungan.

Mengimplementasikan SDK pembayaran passkey pihak ketiga melibatkan penyeimbangan pengalaman pengguna, kompatibilitas browser, batasan aplikasi native, analitik, dan keamanan—terutama mengingat rintangan spesifik Apple (misalnya, memblokir pembuatan passkey lintas-asal, tidak adanya dukungan SPC). Di bawah ini adalah rekomendasi utama untuk memastikan hasil terbaik saat mengintegrasikan passkey ke dalam alur pembayaran web atau native.

Karena dukungan browser yang bervariasi dan perilaku Apple yang tidak konsisten, mendukung pendekatan yang disematkan (berbasis iframe) dan pendekatan redirect sangat penting:

• Checkout Iframe (Disematkan)

  • Menyediakan pengalaman di halaman yang mulus untuk browser modern yang mengizinkan operasi passkey lintas-asal (terutama untuk autentikasi).

  • Harus mengatur Permissions-Policy yang benar untuk publickey-credentials-get/publickey-credentials-create.

  • Perhatikan bahwa Safari dan beberapa browser lama memblokir pembuatan passkey lintas-asal di iframe.

• Alur Redirect

  • Secara andal mendukung pendaftaran dan login passkey dalam konteks pihak pertama.

  • Sedikit lebih banyak gesekan karena redirect atau pop-up tambahan, tetapi secara universal lebih aman untuk kompatibilitas lintas-browser.

  • Fallback ideal untuk Safari, yang saat ini tidak mengizinkan pembuatan passkey pihak ketiga di iframe.

Dengan menawarkan kedua pendekatan, Anda dapat secara dinamis memutuskan—atau membiarkan merchant memutuskan—mana yang akan digunakan, memaksimalkan kompatibilitas untuk semua lingkungan pengguna.

Mendeteksi kemampuan browser secara akurat tetap menantang karena berkurangnya granularitas User-Agent dan dukungan yang tidak konsisten untuk Client Hints di seluruh platform.

Parsing tradisional semakin tidak dapat diandalkan karena browser mengurangi detail dalam string User-Agent untuk melindungi privasi pengguna. Membedakan detail penting—seperti Windows 10 vs. Windows 11, versi macOS yang tepat, atau arsitektur CPU—sekarang sulit atau tidak mungkin hanya menggunakan User-Agent.

Meskipun Client Hints menyediakan data entropi tinggi dengan cara yang menghormati privasi, hanya browser berbasis Chromium yang sepenuhnya mendukungnya. Safari dan Firefox tidak menawarkan dukungan Client Hint, sangat membatasi deteksi fitur yang tepat pada perangkat Apple.

WebView yang disematkan biasanya membatasi akses ke informasi perangkat terperinci dan jarang mendukung Client Hints. Batasan ini membuat deteksi kemampuan passkey menjadi sangat menantang dalam konteks aplikasi native.

Mengingat batasan ini, mendeteksi dukungan passkey lintas-asal secara andal—terutama di SDK pembayaran pihak ketiga—memerlukan kombinasi cermat dari kueri Client Hint dinamis (jika tersedia), heuristik User-Agent fallback, dan perilaku default konservatif untuk browser seperti Safari dan Firefox.

Aplikasi merchant native sering kali menyematkan konten web di WKWebView (iOS) atau Android WebView, yang sangat membatasi untuk passkey. Strategi umum meliputi:

• Sesi Browser Sistem: Gunakan ASWebAuthenticationSession (iOS) atau Custom Tabs (Android) untuk mengalihkan pembuatan/login passkey ke konteks browser “pihak pertama” yang aman.

• Redirect ke Browser Default: Pendekatan yang kurang mulus tetapi sangat andal untuk memastikan integritas domain untuk operasi passkey.

Sebagai penyedia pembayaran, keamanan yang kuat dan kepatuhan terhadap peraturan (PCI, PSD2 SCA, dll.) adalah kunci:

• Header & Keamanan Konten: Terapkan header Permissions-Policy yang ketat dan aturan CSP yang kuat untuk alur lintas-asal.

• Pencatatan & Pemantauan: Catat peristiwa pembuatan dan penggunaan passkey secara menyeluruh untuk pencegahan penipuan dan audit kepatuhan.

• Penyimpanan PII Minimal: Petakan pengguna ke passkey menggunakan pengidentifikasi yang di-hash, mengurangi paparan di bawah GDPR atau undang-undang perlindungan data serupa.

• Jejak Audit: Catat setiap peristiwa pembuatan dan autentikasi passkey untuk mendeteksi anomali dan memenuhi audit kepatuhan.

Passkey masih berkembang, jadi Anda akan memerlukan pemeriksaan berkelanjutan:

• Pengujian Lintas-Browser & Lintas-OS: Otomatiskan pengujian di Safari, Chrome, Edge, Firefox, dan versi OS seluler utama.

• Pembaruan Sering: Lacak perubahan dalam spesifikasi W3C WebAuthn, pedoman FIDO Alliance, atau proposal SPC.

• Umpan Balik Pengguna & Tingkat Kesalahan: Catat kesalahan passkey (pembuatan atau login) untuk memperbaiki masalah dengan cepat, terutama untuk pengguna berbasis Apple.

Kerangka kerja KPI yang kuat membantu Anda melacak apakah integrasi passkey pihak ketiga Anda benar-benar meningkatkan keamanan dan pengalaman pengguna. Meskipun artikel ini tentang mengimplementasikan SDK, penting untuk diingat bahwa adopsi passkey juga merupakan kunci dalam kasus penggunaan ini. Tingkat pembuatan dan tingkat penggunaan passkey memerlukan analisis dan optimisasi yang cermat.

• Definisi: Persentase pengguna yang berhasil membuat passkey saat diminta (misalnya, saat checkout atau pengaturan akun).

• Mengapa Penting: Tingkat pembuatan yang tinggi berarti alur orientasi/dorongan Anda untuk passkey menarik dan bebas gesekan.

• Target: Anda harus menargetkan tingkat 50-80%

• Definisi: Di antara pengguna yang memulai seremoni pembuatan (klik “Buat Passkey”), berapa banyak yang menyelesaikan tanpa membatalkan atau mengalami kesalahan?

• Mengapa Penting: Menunjukkan seberapa baik alur lintas-asal atau redirect Anda bekerja.

• Target: Idealnya, Anda memiliki angka sekitar 95–100% setelah pengguna memilih.

• Definisi: Persentase total otorisasi pembayaran (atau login) yang dilakukan melalui passkey, dibandingkan dengan metode fallback.

• Mengapa Penting: Pembuatan tidak ada artinya jika pengguna kembali ke metode lama.

• Target: Tingkat 50–80% menandakan adopsi passkey yang kuat.

• Definisi: Persentase upaya login passkey yang berhasil tanpa kesalahan atau fallback.

• Mengapa Penting: Cerminan dari kegunaan dunia nyata Anda.

• Target: Biasanya Anda harus melebihi 90–95% untuk menganggap passkey “tanpa gesekan.”

• Definisi: Seberapa sering pengguna gagal menggunakan passkey di tengah seremoni dan beralih ke kata sandi atau OTP?

• Mengapa Penting: Penggunaan fallback yang tinggi menunjukkan adanya rintangan teknis atau UX yang mencegah passkey menggantikan metode lama.

• Target: Idealnya, penggunaan fallback kurang dari 1-5%

Untuk penyedia pembayaran, ukur apakah passkey mengurangi penipuan, mempercepat checkout, atau menurunkan pengabaian keranjang. Gabungkan data penggunaan passkey dengan konversi pembayaran atau metrik keberhasilan 3-D Secure untuk pandangan holistik.

Memantau KPI ini membantu Anda menentukan lingkungan atau perjalanan pengguna mana yang perlu perbaikan—misalnya, jika Safari iOS memiliki tingkat pengabaian yang lebih tinggi karena blok lintas-asal, Anda dapat secara sistematis mengarahkan pengguna tersebut ke alur redirect.

Salah satu tantangan paling kritis dalam membangun SDK passkey pihak ketiga adalah mengatur alur pembuatan yang lancar dan konsisten—di mana pengguna benar-benar mendaftarkan passkey mereka. Apakah ini terjadi di portal bank, dalam pengaturan akun penyedia pembayaran sendiri, atau langsung di halaman checkout merchant, langkah-langkah pendaftaran passkey inti sangat mirip. Akibatnya, pendekatan pembuatan passkey tidak secara fundamental berubah berdasarkan apakah Anda menyematkan alur dalam iframe atau mengalihkan pengguna ke halaman pihak pertama; yang paling penting adalah menyediakan layar yang jelas dan ramah pengguna, mengelola batasan lintas-asal, dan melacak metrik penting yang menunjukkan seberapa efektif pengguna mengadopsi passkey. Di bawah ini adalah aspek kunci dari alur pembuatan passkey praktik terbaik dan bagaimana Corbado mendukungnya:

Terlepas dari di mana pengguna diminta untuk membuat passkey—baik itu lingkungan perbankan online bank, situs web/aplikasi penyedia pembayaran sendiri, atau checkout merchant—Corbado menyediakan komponen siap pakai yang dapat disesuaikan untuk permintaan pengguna, konfirmasi keberhasilan, dan penanganan kesalahan.

Komponen-komponen ini memastikan tampilan dan nuansa yang konsisten sambil memungkinkan branding white-label sehingga setiap bank atau merchant dapat mempertahankan elemen desain unik mereka jika diperlukan.

Lihat komponen UI berikut untuk layar pembuatan passkey dengan merek desain VicRoads:

Corbado mengumpulkan dan menyatukan data dari semua titik akhir pembuatan:

• Situs web atau aplikasi bank tempat passkey awalnya ditawarkan.

• Pengaturan akun pribadi penyedia pembayaran (tempat pengguna dapat mengelola kredensial).

• Halaman checkout merchant yang secara opsional memungkinkan pembuatan passkey “on the fly.”

Pendekatan terpadu ini memudahkan untuk mengukur tingkat pembuatan passkey, tingkat keberhasilan pembuatan, titik putus pengguna, dan kesalahan teknis apa pun—tidak peduli saluran mana yang memulai pendaftaran passkey.

Corbado menawarkan fitur pengujian A/B untuk menyempurnakan instruksi di layar, teks tombol, dan waktu permintaan. Perubahan halus dalam kata-kata (misalnya, “Buat passkey sekarang - tidak ada lagi kata sandi!” vs. “Amankan pembayaran Anda berikutnya dengan passkey!”) sering kali menghasilkan perbedaan signifikan dalam penerimaan pengguna.

Berdasarkan hasil pengujian A/B, KPI berikut dapat dioptimalkan:

• Tingkat Pembuatan: Persentase pengguna yang, setelah diminta, berhasil menyiapkan passkey.

• Tingkat Keberhasilan Pembuatan: Bagian dari pengguna yang menyelesaikan seremoni tanpa membatalkan atau mengalami kesalahan.

• Penggunaan Fallback: Tingkat di mana pengguna melewatkan pembuatan passkey demi metode login yang lebih lama.

• Dampak Konversi: Untuk merchant, ukur apakah pembuatan passkey saat checkout mengurangi pengabaian keranjang.

Pengguna dapat membuat passkey dalam konteks berikut:

• Konteks Bank: Alur pembuatan dipicu setelah pengguna login ke bank mereka, memanfaatkan kepercayaan dan keakraban lingkungan perbankan.

• Pengaturan Akun Penyedia Pembayaran: Pengguna menyiapkan passkey langsung di pengaturan “Profil Saya” atau “Keamanan” dari domain penyedia pembayaran.

• Checkout Merchant: Minta pada langkah pembayaran terakhir, terutama jika pengguna belum pernah membuat passkey sebelumnya. Ini bisa disematkan (iframe) atau melalui redirect.

Dalam setiap skenario, seremoni passkey yang mendasarinya mengikuti langkah-langkah yang sama—konfirmasi pengguna, permintaan biometrik/PIN, dan pendaftaran kredensial. SDK Corbado memastikan bahwa batasan lintas-asal (jika disematkan) atau konteks domain pihak pertama (jika dialihkan) ditangani dengan mulus di latar belakang.

Corbado melampirkan setiap passkey baru ke pengidentifikasi pengguna yang sesuai—apakah itu “bankPrefix_userId” atau referensi pengguna internal dalam sistem penyedia pembayaran—sehingga semua penggunaan selanjutnya dapat dilacak ke akun pengguna yang benar.

Metadata ini juga penting untuk analitik tingkat lanjut: misalnya, melihat bagaimana kinerja kampanye pembuatan passkey RBC dibandingkan dengan TD, atau bagaimana tingkat pembuatan berbeda antara checkout merchant dan alur “pengaturan akun” langsung.

Logika SDK Corbado yang sama dapat beradaptasi dengan apakah pembuatan passkey lintas-asal diizinkan (di Chrome atau Edge modern) atau harus beralih secara halus ke redirect untuk Safari.

Pelaporan kesalahan bawaan membantu mengidentifikasi jika ada subset pengguna yang secara konsisten gagal membuat passkey (misalnya, versi iOS yang lebih lama, perangkat Windows perusahaan), sehingga tim produk dapat menyempurnakan instruksi atau strategi fallback.

Tim kami telah menjalankan eksperimen pembuatan passkey yang ekstensif dengan klien perusahaan, mempelajari frasa, penempatan tombol, dan waktu mana yang menghasilkan tingkat adopsi terbaik.

Kami memasukkan praktik terbaik ini ke dalam setiap layar pembuatan, sambil tetap memungkinkan kustomisasi penuh untuk kebutuhan branding dan kepatuhan.

Secara keseluruhan, pembuatan passkey berdiri sebagai fase paling penting untuk memastikan adopsi yang tinggi: bahkan alur login passkey yang paling elegan pun tidak akan berarti jika pengguna tidak pernah mendaftarkan kredensial sejak awal. Dengan menawarkan layar pembuatan yang seragam dan dapat dilacak di semua saluran yang memungkinkan—bank, domain penyedia pembayaran, atau checkout merchant—dan melengkapinya dengan analitik KPI dan pengujian A/B, Corbado membantu penyedia pembayaran mendorong adopsi passkey yang benar-benar dapat diskalakan, meniru pengalaman pengguna solusi native seperti Apple Pay.

Setelah pengguna membuat passkey, langkah selanjutnya adalah memastikan mereka benar-benar menggunakan passkey tersebut untuk pembayaran yang cepat dan tanpa hambatan seperti yang disajikan oleh Apple Pay dalam alur pembayaran Apple Pay.

Di Corbado, kami telah mengembangkan mekanisme “Passkey Intelligence” yang secara otomatis mendeteksi kapan lingkungan pengguna kemungkinan besar berisi passkey yang valid, memungkinkan pengalaman pembayaran satu ketukan yang sesungguhnya. Di bawah ini adalah elemen inti yang memungkinkan hal ini.

Ketika pengguna yang kembali dikenali, front-end Corbado menampilkan tombol khusus (misalnya, “Bayar dengan Passkey”) daripada memaksa entri kredensial fallback.

Satu ketukan pada tombol ini memicu alur WebAuthn get() (atau permintaan passkey native), memungkinkan pengguna untuk melakukan autentikasi secara instan melalui biometrik/PIN—tidak ada langkah tambahan atau input formulir yang diperlukan.

SDK Corbado mengumpulkan sinyal (misalnya, cookie penyimpanan lokal, penggunaan passkey yang berhasil sebelumnya, deteksi lingkungan) untuk memprediksi apakah perangkat + browser saat ini kemungkinan memiliki passkey yang valid untuk pengguna ini.

Jika cookie dihapus atau tidak tersedia, Corbado beralih ke heuristik tambahan (misalnya, lingkungan yang sudah dikenal dari pengguna, petunjuk pengguna yang diberikan oleh merchant) untuk memutuskan apakah aman untuk memulai alur passkey secara otomatis.

Jika bukti tidak cukup menunjukkan adanya passkey, UI dengan halus menawarkan alur fallback atau meminta pengguna untuk mengonfirmasi bahwa mereka memiliki passkey.

Corbado tidak menyimpan informasi yang dapat diidentifikasi secara pribadi (PII) seperti email lengkap atau nama.

Sebaliknya, merchant dapat memberikan pengidentifikasi yang di-hash atau disamarkan (misalnya, hash email atau ID pengguna internal). Corbado menggunakan itu untuk mencari pendaftaran passkey potensial, kemudian memutuskan apakah akan memulai autentikasi passkey atau kembali ke pendekatan yang lebih umum. Jika didukung oleh penyedia pembayaran, kami dapat mencari informasi yang diberikan oleh merchant untuk mencari ID pengguna internal.

Ini memastikan privasi pengguna sambil tetap memungkinkan pencocokan lingkungan dengan akurasi tinggi.

Dalam skenario di mana passkey pengguna mungkin ada tetapi tidak dapat dideteksi (misalnya, cookie dihapus, perangkat baru), Passkey Intelligence Corbado dengan cermat menganalisis apakah memulai permintaan passkey secara otomatis masuk akal.

Sebaliknya, pengguna akan melihat alur fallback alternatif atau opsi “pindai passkey dari perangkat lain” sambil tetap mempertahankan jalur cepat kembali ke penggunaan passkey jika pengguna dapat secara manual mengonfirmasi bahwa mereka memilikinya.

Setiap kali Corbado memilih untuk memulai atau melewatkan permintaan passkey satu ketukan, keputusan itu dicatat. Seiring waktu, Anda dapat melihat dengan tepat browser atau jenis perangkat mana yang menghasilkan cakupan passkey tertinggi vs. yang sering kembali ke fallback.

Umpan balik analitik ini memungkinkan Anda untuk mengidentifikasi lingkungan yang berkinerja buruk (misalnya, versi iOS atau Android tertentu) atau segmen pengguna di mana penggunaan passkey tetap rendah—sehingga Anda dapat menyempurnakan strategi orientasi atau edukasi.

Terlepas dari apakah pengguna datang dari kampanye pembuatan passkey bank atau langsung di checkout merchant, logika satu ketukan tetap konsisten.

Corbado memastikan bahwa jika passkey ditemukan (berdasarkan cookie domain, token penyimpanan lokal, atau sinyal passkey intelligence), pengguna segera disajikan dengan alur login/pembayaran yang paling lancar.

Ringkasan

Singkatnya, penggunaan passkey satu ketukan adalah hasil akhir dari pembuatan passkey. Dengan memanfaatkan Passkey Intelligence—perpaduan deteksi lingkungan, penggunaan PII minimal, dan logika fallback—Corbado memastikan pengguna disajikan dengan autentikasi passkey hanya ketika kemungkinan besar akan berhasil. Ini secara dramatis mengurangi upaya yang gagal, menghindari frustrasi pengguna, dan menumbuhkan kebiasaan penggunaan passkey, yang berpuncak pada alur pembayaran satu ketukan yang menyaingi kenyamanan Apple Pay atau pengalaman pembayaran native lainnya.

Selain sekadar mengaktifkan passkey, memahami seberapa efektif passkey diadopsi dan digunakan di berbagai perangkat, browser, dan perjalanan pengguna sangat penting. Penyedia pembayaran memerlukan data konkret tentang apakah passkey benar-benar mengurangi gesekan, memotong penipuan, dan meningkatkan konversi. Mengacu pada praktik terbaik Panduan Beli vs. Bangun Passkey, Corbado menawarkan lapisan analitik yang kaya yang memungkinkan Anda melacak, mensegmentasi, dan mengoptimalkan kinerja passkey secara real time.

Di bawah ini adalah sorotan utamanya.

Corbado mengatur semua peristiwa passkey ke dalam funnel: dari saat pengguna diminta untuk membuat passkey, melalui pendaftaran yang berhasil, hingga login/pembayaran berikutnya (penggunaan passkey).

Visualisasi funnel ini memungkinkan Anda untuk melihat di mana pengguna putus—misalnya, berapa banyak yang tidak pernah memulai pembuatan, berapa banyak yang meninggalkan di tengah seremoni, atau berapa banyak yang kembali ke metode fallback saat login.

Berdasarkan pengalaman kami yang luas membantu perusahaan mengimplementasikan passkey, kami fokus pada metrik yang secara langsung memengaruhi ROI dan kepuasan pengguna:

• Tingkat Penerimaan Passkey: Berapa banyak pengguna yang melihat permintaan pembuatan yang benar-benar menyelesaikan pendaftaran passkey?

• Tingkat Keberhasilan Pembuatan Passkey: Dari mereka yang memulai seremoni (klik “Buat Passkey”), berapa persentase yang menyelesaikan tanpa kesalahan atau pengabaian?

• Tingkat Penggunaan Passkey: Seberapa sering pengguna yang kembali benar-benar memilih passkey untuk autentikasi atau pembayaran sehari-hari, daripada kata sandi atau OTP?

• Tingkat Keberhasilan Login Passkey: Persentase upaya passkey yang berhasil tanpa fallback atau frustrasi pengguna.

• Penggunaan Fallback: Berapa banyak pengguna yang memulai alur passkey tetapi kembali ke metode lama? Ini menandakan potensi hambatan UX atau teknis.

Corbado secara otomatis menandai setiap peristiwa dengan sistem operasi (Windows, macOS, iOS, Android) dan browser (Chrome, Safari, Edge, Firefox, dll.).

Dengan segmentasi ini, Anda dapat melihat apakah, misalnya, iOS Safari memiliki tingkat pengabaian passkey yang lebih tinggi, atau jika Windows Chrome menghasilkan adopsi passkey yang lebih baik.

Data ini juga membantu Anda menyempurnakan strategi fallback—terutama jika pembatasan lintas-asal Apple memengaruhi basis pengguna Anda lebih dari yang diantisipasi.

Kami menyediakan tampilan dasbor untuk setiap tahap funnel passkey: permintaan pembuatan, pendaftaran yang berhasil, login pengguna, penggunaan fallback.

Grafik real-time memungkinkan manajer produk melihat tren dengan cepat (misalnya, jika pembaruan OS baru merusak alur passkey).

Pemberitahuan otomatis dapat memberi tahu tim Anda jika tingkat keberhasilan passkey turun secara signifikan—sehingga Anda dapat segera menyelidiki bug browser baru atau masalah konfigurasi.

Setiap alur passkey (dari pembuatan hingga login) dicatat dengan peristiwa langkah demi langkah yang diberi stempel waktu, memungkinkan analisis forensik yang mendalam.

Anda dapat dengan cepat mencari berdasarkan hash pengguna, ID sesi, atau tanda tangan perangkat untuk melihat dengan tepat di mana pengguna kesulitan atau kode kesalahan mana yang dikembalikan.

Ini sangat penting untuk peluncuran skala besar, di mana Anda tidak dapat mengandalkan tiket dukungan anekdotal tetapi memerlukan data yang tepat untuk menyelesaikan masalah pengguna.

Platform analitik Corbado mendukung pengujian A/B yang terintegrasi ke dalam funnel passkey: uji teks CTA yang berbeda, permintaan pembuatan, pesan fallback, atau penempatan tombol “Buat Passkey” dalam alur checkout.

Metrik seperti “Tingkat Penerimaan Passkey” atau “Tingkat Fallback” dapat diukur berdampingan untuk setiap varian.

Pendekatan ini memastikan perbaikan berkelanjutan, meniru keberhasilan pengadopsi passkey terkemuka yang menyempurnakan alur dari waktu ke waktu.

Meskipun dasbor Corbado menyediakan antarmuka visual siap pakai, Anda juga dapat mengekspor atau mengirim webhook titik data utama (misalnya, keberhasilan pembuatan passkey, login) ke alat BI atau SIEM Anda.

Ini memungkinkan penyedia pembayaran untuk memasukkan KPI passkey ke dalam suite analitik yang lebih luas—melacak ROI dari passkey bersama metrik keamanan, pemasaran, atau operasional lainnya.

Ringkasan

Dengan mengukur dan memvisualisasikan setiap langkah perjalanan passkey—di seluruh kombinasi OS/browser, alur pembuatan, dan skenario login—Corbado memberi Anda wawasan yang diperlukan untuk terus menyempurnakan penawaran passkey Anda. Analitik ini tidak hanya mengonfirmasi bahwa passkey diaktifkan; mereka membuktikan apakah pengguna benar-benar mengadopsinya dalam skala besar, mengidentifikasi titik gesekan, dan membantu Anda mendorong tingkat penggunaan ke titik di mana passkey benar-benar menggantikan kata sandi untuk pembayaran yang aman dan tanpa hambatan.

Bagi penyedia pembayaran, sekadar membuat satu passkey per pengguna sering kali tidak cukup untuk memberikan pengalaman autentikasi yang benar-benar mulus. Kenyataannya, pengguna sering berpindah perangkat—dari laptop di tempat kerja ke smartphone pribadi, tablet, dan bahkan komputer keluarga bersama. Memastikan setiap perangkat memiliki passkey yang valid untuk akun yang sama sangat penting untuk mengurangi gesekan dan mencegah fallback ke kata sandi. Apple Pay mencapai ini dengan dapat memanfaatkan Akun iCloud di semua perangkat yang terhubung dengan iCloud.

Di bawah ini adalah bagaimana Corbado membantu mempertahankan cakupan multi-perangkat di seluruh siklus hidup pengguna.

• Layar Pembuatan Passkey Utama: Corbado pada awalnya berfokus untuk membuat setiap pengguna mendaftarkan setidaknya satu passkey—“passkey utama”—di mana pun mereka pertama kali menemukan alur pembayaran Anda (misalnya, saat checkout, di portal online bank, atau di pengaturan akun Anda).

• Layar Pembuatan Passkey Sekunder: Setelah pengguna berhasil mendaftarkan passkey pertama mereka, login berikutnya di perangkat lain dapat secara otomatis memicu alur singkat “Tambahkan perangkat ini”. Ini memastikan pengguna dengan cepat mendapatkan akses passkey tanpa gesekan di semua perangkat yang relevan tanpa memasukkan ulang kata sandi atau beralih ke metode fallback.

Bahkan jika pengguna memiliki passkey di satu perangkat, mereka mungkin muncul tanpa passkey lokal di perangkat kedua (karena instalasi OS baru, penghapusan cookie, atau hanya karena belum pernah membuat passkey di perangkat itu).

Pendekatan Corbado sering kali menggunakan langkah hibrida: pengguna dapat login dengan passkey yang ada di ponsel mereka atau metode fallback, kemudian secara instan “menyembuhkan” celah tersebut dengan membuat passkey di perangkat saat ini.

Proses perbaikan mandiri ini membantu menjaga cakupan tetap tinggi dan menghilangkan penggunaan fallback berulang di masa mendatang.

Melalui sinyal lintas-perangkat dan “Passkey Intelligence” Corbado, sistem dapat mendeteksi ketika pengguna dengan passkey yang ada telah beralih ke perangkat yang tidak terdaftar.

Jika strategi UX Anda bertujuan untuk cakupan maksimum, Corbado dapat secara otomatis meminta: “Apakah Anda ingin menambahkan passkey di perangkat ini agar tidak perlu fallback lain kali?”

Pengguna dapat melewatkan ini jika mereka berada di perangkat sekali pakai, tetapi biasanya menghargai kenyamanan login biometrik berbasis passkey setelah dijelaskan.

SDK Corbado menyediakan alur layar yang berbeda untuk “pembuatan passkey pertama” (yaitu, pertama kalinya pengguna mendaftarkan kredensial) dan pembuatan “perangkat sekunder”.

Pesan dapat berbeda: misalnya, “Amankan perangkat baru ini dengan passkey” vs. “Siapkan passkey pertama Anda.”

Ini memastikan kejelasan bagi pengguna akhir, yang memahami perbedaan antara pendaftaran awal dan memperluas cakupan ke perangkat tambahan.

Terkadang pembuatan passkey dapat gagal di tengah seremoni atau OS pengguna sudah usang. Dalam skenario tersebut, Corbado mencatat upaya parsial dan dengan halus menyarankan kemungkinan perbaikan (redirect, fallback manual, atau alur QR lintas-perangkat).

Pengguna selalu dapat mencoba lagi menambahkan passkey di perangkat itu pada upaya login berikutnya, atau mengandalkan passkey yang ada dari perangkat lain.

Analitik Corbado tidak hanya menunjukkan berapa banyak pengguna yang membuat passkey pada awalnya, tetapi juga berapa banyak yang telah memperluas passkey ke beberapa perangkat.

Anda dapat melacak tingkat cakupan perangkat (misalnya, 1 perangkat vs. 2 atau lebih) dan melihat bagaimana hal itu berkorelasi dengan berkurangnya penggunaan fallback atau peningkatan keberhasilan pembayaran.

Ini membantu tim Anda memprioritaskan edukasi pengguna, permintaan aplikasi, atau alur pendaftaran berbasis bank untuk meningkatkan penetrasi passkey multi-perangkat.

Ringkasan: Mengapa Cakupan Multi-Perangkat Penting

Tanpa cakupan yang konsisten di semua perangkat pengguna, Anda berisiko pengguna dipaksa kembali ke tindakan autentikasi fallback setiap kali mereka berada di perangkat “non-passkey”. Ini merusak pengalaman tanpa gesekan dan menjaga biaya operasional tetap tinggi (misalnya, biaya SMS, overhead dukungan). Dengan menawarkan layar pembuatan passkey sekunder, penyembuhan fallback hibrida, dan permintaan yang didorong oleh lingkungan, Corbado memastikan setiap pengguna pada akhirnya dapat mempertahankan passkey di semua perangkat yang mereka gunakan—mendorong adopsi keseluruhan yang lebih tinggi dan meminimalkan momen fallback yang membuat frustrasi.

Salah satu kesalahpahaman terbesar saat membangun SDK passkey pihak ketiga adalah bahwa bagian tersulit adalah mengimplementasikan panggilan WebAuthn (misalnya, navigator.credentials.create() atau navigator.credentials.get()).

Kenyataannya, ini adalah bagian yang “mudah”—satu atau dua panggilan API untuk memicu seremoni dasar. Kompleksitas sebenarnya, dan penentu keberhasilan yang sesungguhnya, terletak pada memastikan adopsi skala besar dan membangun ekosistem penuh di sekitar panggilan API tersebut.

Di bawah ini adalah poin-poin utama—diperkuat oleh Panduan Beli vs. Bangun Passkey—yang menyoroti mengapa implementasi minimal yang hanya berfokus pada seremoni sering kali gagal memberikan hasil di dunia nyata.

• Implementasi Seremoni: Membuat atau mengautentikasi passkey biasanya hanya melibatkan beberapa baris JavaScript untuk memanggil navigator.credentials.create() atau navigator.credentials.get().

• Kompleksitas Nyata: Memastikan alur passkey berfungsi di banyak browser, menangani kegagalan dengan baik, dan menawarkan fallback untuk sistem yang lebih lama. Anda juga akan memerlukan manajemen sesi yang kuat, pencatatan kesalahan, analitik, strategi cakupan perangkat, dan banyak lagi.

• Jebakan yang Tidak Terduga: Begitu Anda bergerak melampaui “demo teknologi” passkey, Anda menemukan kasus-kasus tepi seperti blok lintas-asal, batasan WebView yang disematkan, dan kompleksitas sinkronisasi multi-perangkat. Ini adalah hal-hal yang tidak diketahui yang menggagalkan pembangunan internal yang naif.

• Seremoni vs. Adopsi: Bahkan jika Anda memiliki seremoni WebAuthn yang sempurna, adopsi pengguna yang rendah (misalnya, tingkat penggunaan passkey <5%) akan menghasilkan manfaat keamanan atau UX yang minimal.

• Pendekatan Holistik: Peluncuran passkey yang sukses menuntut segalanya mulai dari permintaan pengguna yang menarik dan copywriting yang diuji A/B hingga alur cakupan multi-perangkat, penanganan fallback, dan analitik berkelanjutan—jauh melampaui panggilan seremoni dasar.

• Wawasan dari Panduan Beli vs. Bangun: Panduan ini menekankan bahwa mendorong adopsi passkey—bukan hanya mengaktifkan passkey—pada akhirnya menentukan ROI. Jika pengguna tidak mendaftar dan secara aktif menggunakan passkey, proyek tersebut secara efektif mandek di “MFA 2.0” tanpa peningkatan tingkat konversi.

• Fallback & Penanganan Kesalahan yang Tidak Lengkap: Kehilangan logika fallback canggih atau debugging real-time dapat menyebabkan penguncian pengguna dan biaya dukungan yang lebih tinggi.

• Cakupan Multi-Perangkat yang Terfragmentasi: Tanpa rencana untuk menyinkronkan perangkat tambahan atau “menyembuhkan” celah passkey, pengguna kembali ke kata sandi setiap kali mereka berpindah platform.

• Analitik & Pengujian A/B Terbatas: Kurangnya data tentang funnel pembuatan passkey atau penggunaan lingkungan berarti Anda tidak dapat secara sistematis meningkatkan adopsi atau dengan cepat memecahkan masalah keunikan browser baru.

• UI Siap Pakai & Praktik Terbaik: Alih-alih hanya mengekspos titik akhir seremoni, solusi yang tepat (seperti Corbado) menggabungkan layar white-label, alur fallback, penanganan kesalahan, dan cakupan lintas-perangkat.

• Kecerdasan Adaptif & Pencatatan: Mendeteksi secara otomatis kemungkinan adanya passkey, membimbing pengguna untuk membuat atau memperbaiki passkey yang hilang, dan menangkap log peristiwa granular.

• “Hal-hal yang Tidak Diketahui” yang Berfokus pada Adopsi: Banyak detail—seperti fallback berbasis email atau cara menangani perangkat perusahaan—tidak jelas sampai pengguna mulai menemukannya dalam penerapan nyata.

• Penjelasan Mendalam tentang Strategi Adopsi: Panduan Beli vs. Bangun Passkey menyoroti cara menyeimbangkan biaya, waktu peluncuran, dan kompleksitas tersembunyi dari solusi passkey yang kuat.

• Tolok Ukur Dunia Nyata: Pelajari bagaimana peluncuran skala besar dari bank-bank besar dan penyedia e-commerce mengatasi hal-hal yang tidak diketahui yang muncul setelah Anda mengkodekan logika seremoni yang “sederhana”.

• Keberhasilan Berkelanjutan: Berinvestasi dalam platform yang mapan dengan pola adopsi yang terbukti memastikan Anda tidak terjebak menemukan kembali roda—dan menemukan kejutan mahal di sepanjang jalan.

Singkatnya

Hanya menghubungkan seremoni WebAuthn tidak cukup untuk mencapai adopsi passkey yang berarti. Keberhasilan sejati bergantung pada pengaturan alur ujung-ke-ujung—seperti fallback, analitik, ekspansi multi-perangkat, dan perjalanan pengguna yang diuji A/B. Dengan mengatasi kompleksitas bernuansa di luar “hanya seremoni,” Anda dapat mengubah proyek passkey Anda dari keingintahuan teknis menjadi solusi autentikasi yang benar-benar tanpa gesekan, banyak digunakan, dan hemat biaya.

Selain kompleksitas seputar alur lintas-asal, adopsi pengguna, dan manajemen siklus hidup passkey, pertimbangan hosting dan penerapan sangat penting untuk solusi passkey skala besar mana pun. Penyedia pembayaran sering kali berurusan dengan kepatuhan yang ketat, tuntutan residensi data, dan persyaratan ketahanan yang dapat sangat bervariasi di seluruh wilayah. Di bawah ini adalah bagaimana Corbado (atau solusi kuat serupa) mengatasi masalah ini:

Untuk mematuhi kedaulatan data atau kerangka kerja peraturan (misalnya, GDPR di Eropa, PIPEDA di Kanada, atau NIST/HIPAA di Amerika Serikat), beberapa penyedia harus menyimpan data dalam batas geografis tertentu.

Arsitektur agnostik wilayah memastikan layanan passkey dapat diterapkan di wilayah AWS mana pun yang diinginkan, memenuhi mandat kepatuhan lokal tanpa mengorbankan kinerja atau skalabilitas.

Fleksibilitas ini sangat penting jika basis pengguna Anda mencakup beberapa negara, masing-masing memberlakukan aturan penanganan data yang berbeda.

Untuk alur autentikasi pembayaran yang kritis, waktu henti bukanlah pilihan. Corbado menggunakan penerapan multi-AZ, mendistribusikan komponen kunci di beberapa zona ketersediaan.

Pengaturan ini membantu memastikan bahwa jika satu AZ mengalami pemadaman atau masalah konektivitas, infrastruktur passkey Anda di zona lain tetap online—sehingga pengguna dapat terus melakukan autentikasi.

Hasilnya adalah sistem yang lebih tangguh yang memenuhi SLA ketat untuk layanan keuangan dan situs e-commerce, di mana bahkan waktu henti singkat dapat menyebabkan dampak pendapatan yang signifikan.

Beberapa penyedia pembayaran lebih memilih klaster khusus pribadi—baik untuk isolasi data yang lebih ketat, pemeriksaan kepatuhan khusus, atau kontrol yang lebih dalam atas patch dan pembaruan.

Solusi yang fleksibel dapat mendukung kedua ekstrem:

• SaaS / Multi-Tenant: Cepat diimplementasikan, biaya lebih rendah, cocok untuk banyak penerapan ukuran menengah.

• Instans Cloud Khusus: Akun dan instans basis data terpisah di wilayah pilihan Anda, bagi mereka yang membutuhkan isolasi atau kepatuhan tambahan.

Passkey harus menangani beban kerja yang melonjak: lonjakan lalu lintas yang besar (misalnya, puncak belanja liburan atau penjualan tiket acara) dapat membanjiri sistem berkapasitas tetap.

Back-end passkey modern dapat diskalakan secara horizontal secara real time, menambah atau menghapus instans komputasi berdasarkan pola penggunaan. Penskalaan otomatis ini memastikan kinerja yang konsisten tanpa intervensi manual.

Standar industri seperti PCI-DSS, PSD2 SCA, atau ISO 27001 sering berlaku untuk penyedia pembayaran. Penyedia passkey yang kuat biasanya terintegrasi dengan kerangka kerja kepatuhan yang dikenal secara langsung:

• Enkripsi saat Diam dan dalam Perjalanan: Amankan data dengan TLS yang kuat dan enkripsi sisi server atau sisi klien untuk kredensial yang disimpan.

• Pencatatan dan Jejak Audit: Log terperinci untuk setiap operasi passkey, cocok untuk regulator atau investigasi insiden.

• Patching Keamanan Reguler: Patching OS dan kontainer otomatis untuk menjaga kerentanan tetap terkendali, terutama relevan dalam lingkungan multi-AZ yang cair.

Ketahanan sejati melampaui satu wilayah. Beberapa penyedia mengamanatkan replikasi lintas-wilayah untuk menjaga kelangsungan bisnis selama bencana skala besar.

Geo-redundancy dapat mereplikasi data passkey di wilayah atau benua yang berbeda, memastikan bahwa waktu henti seluruh wilayah tidak menghentikan alur autentikasi.

Ringkasan: Multi-AZ dan Independen Wilayah

Memilih solusi passkey yang mudah diskalakan, beradaptasi secara geografis, dan tahan terhadap pemadaman lokal dan bencana skala besar sangat penting bagi penyedia pembayaran modern—terutama yang beroperasi di banyak negara atau di bawah kepatuhan yang ketat. Dengan mendukung penerapan multi-AZ dan konfigurasi agnostik wilayah, Corbado (atau solusi sebanding) memastikan layanan passkey pembayaran tetap tersedia dan patuh, di mana pun pengguna atau data Anda berada.

Passkey memang mewakili generasi berikutnya dari autentikasi yang aman dan ramah pengguna. Namun, penyedia pembayaran menghadapi tantangan unik yang tidak secara langsung ditangani oleh desain WebAuthn tradisional. Batasan-batasan ini paling menonjol dalam:

1. Penolakan Safari untuk mengizinkan pembuatan passkey lintas-asal (terutama di iframe), memaksa pendekatan berbasis redirect atau ketergantungan pada passkey yang dibuat sebelumnya.

2. Kurangnya dukungan Apple untuk Secure Payment Confirmation (SPC), mencegah alur pembayaran yang terstandardisasi dan tanpa gesekan di seluruh browser dan platform.

Namun demikian, passkey tetap penting bagi penyedia pembayaran yang ingin menawarkan pengalaman checkout seperti Apple Pay: efisien, aman, dan sangat sederhana bagi pengguna akhir. Di bawah ini adalah bagaimana tantangan-tantangan ini dapat diatasi dan bagaimana Corbado membantu.

1. Apa saja batasan saat ini dalam menggunakan passkey dalam konteks pihak ketiga untuk penyedia pembayaran?

• Pembatasan Lintas-Asal: Safari (dan beberapa browser lama) memblokir navigator.credentials.create() saat disematkan melalui iframe. Ini berarti Anda tidak dapat membuat passkey baru secara mulus dalam alur yang disematkan merchant di browser tersebut.

• Dukungan SPC yang Hilang: Penolakan Apple untuk mengadopsi SPC membatasi kemampuan untuk menstandardisasi konfirmasi pembayaran lintas-asal, memaksa penyedia untuk mempertahankan pendekatan terpisah untuk Safari vs. Chrome/Edge.

• Batasan WebView & Aplikasi Native: WebView yang disematkan sering kali merusak alur passkey, memerlukan sesi browser sistem atau pendekatan khusus lainnya untuk mengelola penyelarasan asal domain.

• Cakupan Perangkat yang Terfragmentasi: Bahkan jika pengguna membuat passkey di satu perangkat atau browser, mereka mungkin tidak memiliki cakupan di perangkat lain, menyebabkan penggunaan fallback.

2. Bagaimana penyedia pembayaran dapat mengatasi batasan ini untuk berhasil mengimplementasikan integrasi passkey pihak ketiga?

• Manfaatkan Strategi Hibrida (Iframe + Redirect):

  • Iframe untuk browser yang sepenuhnya mendukung passkey lintas-asal, menawarkan UI yang disematkan dengan mulus.

  • Redirect sebagai fallback untuk Safari atau pengaturan yang tidak kompatibel, memastikan pembuatan passkey yang kuat selalu memungkinkan.

• WebView Sistem atau Redirect Browser di Aplikasi Native:

  • Daripada menyematkan iframe di aplikasi merchant, beralihlah ke ASWebAuthenticationSession (iOS) atau Chrome Custom Tabs (Android) untuk menjaga kesinambungan domain.

  • Perangkat yang Berfokus pada Adopsi: Sediakan permintaan pembuatan passkey yang menarik, alur cakupan multi-perangkat, dan langkah-langkah “penyembuhan” fallback untuk menjaga penggunaan tetap tinggi.

  • Analitik Lanjutan & Pengujian A/B:

    • Terus ukur tingkat keberhasilan/fallback passkey, cakupan lingkungan, dan umpan balik pengguna untuk menyempurnakan alur Anda.

    • Gunakan kecerdasan passkey untuk secara otomatis menyajikan passkey hanya ketika keberhasilan kemungkinan besar terjadi.

Sepanjang panduan ini, kami telah menyoroti bahwa sekadar menghubungkan navigator.credentials.create() tidaklah cukup. Keberhasilan sejati bergantung pada adopsi passkey yang tinggi, pengalaman pengguna yang konsisten, dan cakupan multi-perangkat yang tangguh. Di situlah Corbado unggul:

• Dukungan Terpadu untuk Iframe & Redirect: SDK Corbado secara otomatis mendeteksi apakah alur passkey yang disematkan memungkinkan (misalnya, di Chrome atau Edge) atau jika redirect diperlukan (misalnya, Safari). Ini memaksimalkan kompatibilitas tanpa mengharuskan merchant untuk memelihara beberapa jalur kode.

  • Pengalaman Pembayaran Satu Ketukan: Dengan Passkey Intelligence, Corbado secara instan mendeteksi jika lingkungan pengguna kemungkinan memiliki passkey yang valid—memicu alur “bayar dengan passkey” yang tanpa gesekan. Pendekatan ini sejajar dengan checkout satu ketukan Apple Pay, meningkatkan penggunaan passkey sehari-hari daripada menurunkannya menjadi langkah MFA yang jarang digunakan.

  • Cakupan Multi-Perangkat yang Kuat: Corbado menyediakan alur khusus untuk pembuatan passkey awal versus ekspansi passkey sekunder, sehingga setiap pengguna dapat dengan cepat menambahkan cakupan untuk perangkat baru setelah login melalui fallback atau QR lintas-perangkat.

  • Fokus Adopsi Full-Stack: Melalui analitik terintegrasi, pengujian A/B, dan penanganan kesalahan, Corbado membantu penyedia mengidentifikasi titik gesekan dan secara sistematis mengoptimalkan penerimaan passkey. Ini meluas dari permintaan passkey pertama bank hingga pengalaman checkout merchant.

  • Hosting Fleksibel dan Patuh: Penerapan multi-AZ dan agnostik wilayah Corbado selaras dengan kepatuhan industri pembayaran yang ketat (PCI DSS, PSD2 SCA, dll.), memastikan waktu aktif dan kepatuhan terhadap aturan residensi data di seluruh dunia.

Sementara kebijakan restriktif Apple menciptakan gesekan yang tidak dapat dihindari, penyedia pembayaran masih dapat berhasil mengimplementasikan passkey pihak ketiga dengan:

1. Menggabungkan pendekatan yang disematkan (iframe) dengan fallback redirect.

2. Mengadopsi webview sistem khusus atau alur browser eksternal untuk aplikasi native.

3. Berfokus pada strategi adopsi yang kuat: cakupan multi-perangkat, “penyembuhan” fallback, analitik canggih, dan pengujian A/B.

Corbado menyatukan semua elemen ini, menawarkan platform passkey perusahaan yang mencakup pendaftaran passkey, penggunaan satu ketukan, optimisasi berbasis analitik, dan hosting skala global. Hasilnya: pengalaman yang benar-benar tanpa gesekan seperti Apple Pay untuk layanan pembayaran Anda sendiri, memberikan keamanan yang lebih tinggi dan perjalanan pengguna yang superior.