---
url: 'https://www.corbado.com/id/blog/passkey-penyedia-pembayaran-sdk-pihak-ketiga'
title: 'Passkey Penyedia Pembayaran: Cara Membangun SDK Pihak Ketiga'
description: 'Pelajari cara membuat passkey lintas-asal sebagai penyedia pembayaran. Bandingkan iframe vs. redirect, tawarkan UX sekelas Apple Pay & gunakan analitik untuk adopsi yang lebih tinggi.'
lang: 'id'
author: 'Vincent Delitz'
date: '2025-07-15T13:24:16.376Z'
lastModified: '2026-03-25T10:06:43.018Z'
keywords: 'psp, penyedia layanan pembayaran, passkey penyedia pembayaran'
category: 'Passkeys Strategy'
---

# Passkey Penyedia Pembayaran: Cara Membangun SDK Pihak Ketiga

## 1. Pendahuluan: Mengapa Penyedia Pembayaran Membutuhkan Passkey?

Passkey muncul sebagai metode paling efektif untuk mengamankan dan mengotorisasi transaksi
online, secara signifikan meningkatkan
[keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) dan kenyamanan dibandingkan dengan
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) multifaktor (MFA)
tradisional. Baru-baru ini,
[PayPal mengadopsi passkey sebagai solusi MFA mandiri utama mereka](https://www.forbes.com/sites/daveywinder/2025/03/01/paypal-security-2fa-codes-to-be-replaced-by-single-step-login/),
menetapkan tren yang jelas bagi penyedia [pembayaran](https://www.corbado.com/passkeys-for-payment) di seluruh
dunia.

Namun, passkey pada awalnya dirancang dengan mempertimbangkan konteks pihak pertama, yang
berarti passkey berfungsi optimal saat pengguna melakukan
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) langsung di situs web atau
aplikasi yang memiliki kredensial tersebut. Sebaliknya, penyedia
[pembayaran](https://www.corbado.com/passkeys-for-payment) biasanya beroperasi dalam konteks pihak ketiga, di
mana layanan mereka (seperti formulir [pembayaran](https://www.corbado.com/passkeys-for-payment) atau SDK)
disematkan ke dalam situs web dan aplikasi [merchant](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
(SPC)—terhambat oleh rintangan strategis yang secara implisit diberlakukan oleh Apple.
Secara spesifik, dukungan terbatas Apple untuk
[pembuatan passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) lintas-asal di Safari dan
tidak adanya dukungan dari Standar
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) merupakan penghalang
signifikan, yang mempersulit adopsi mulus
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) 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.

## 2. Manfaat Passkey di Seluruh Ekosistem Pembayaran

Passkey membawa login berbasis biometrik yang tahan [phishing](https://www.corbado.com/glossary/phishing) ke
setiap lapisan tumpukan pembayaran. Berikut adalah rincian bagaimana setiap pemain dalam
rantai nilai pembayaran dapat memperoleh manfaat dari integrasi
[autentikasi passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi).

### 2.1 Passkey untuk Merchant

**Dampak:** Checkout lebih cepat, konversi lebih tinggi, lebih sedikit pengabaian
keranjang belanja. **Peluang:** [Merchant](https://www.corbado.com/glossary/merchant) yang menawarkan passkey
melalui SDK atau alur redirect dapat meniru UX sekelas
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) dan mengurangi ketergantungan pada kata sandi atau
OTP—yang mengarah pada kepercayaan dan penjualan yang lebih tinggi.

### 2.2 Passkey untuk Pemegang Kartu / Pelanggan

**Dampak:** [Autentikasi tanpa kata sandi](https://www.corbado.com/id/blog/revolut-passkey) yang mulus di seluruh
perangkat. **Peluang:** Passkey menawarkan UX yang lebih baik daripada OTP atau kode SMS
dan menghilangkan risiko [phishing](https://www.corbado.com/glossary/phishing). Adopsi yang luas dapat mengubah
passkey menjadi standar baru untuk verifikasi pemegang kartu.

### 2.3 Passkey untuk Penerbit (Bank Penerbit)

**Dampak:** Pencegahan penipuan yang lebih kuat. **Peluang:** Penerbit dapat menawarkan
autentikasi step-up berbasis passkey dalam alur 3DS, menurunkan
[biaya OTP](https://www.corbado.com/id/blog/mengurangi-biaya-sms-dengan-passkeys) dan meningkatkan kepuasan
pengguna.

### 2.4 Passkey untuk Akseptor (Bank Akseptor)

**Dampak:** Penerimaan transaksi lebih tinggi dan lebih sedikit autentikasi yang gagal.
**Peluang:** Mendukung passkey melalui
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) dapat meningkatkan hasil
[merchant](https://www.corbado.com/glossary/merchant) dan mengurangi hambatan selama checkout atau alur penagihan
berulang.

### 2.5 Passkey untuk Penyedia Layanan Pembayaran (PSP) / Gerbang Pembayaran

**Dampak:** Mengurangi penipuan, UX merchant yang lebih baik, dan kepatuhan yang lebih
baik. **Peluang:** Dengan menyematkan atau mengalihkan alur passkey,
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) dapat menyediakan autentikasi
generasi berikutnya sambil mempertahankan kompatibilitas di seluruh browser dan aplikasi
native.

### 2.6 Passkey untuk Pemroses Pembayaran

**Dampak:** Persetujuan transaksi yang lebih efisien dengan lebih sedikit
[pembayaran](https://www.corbado.com/passkeys-for-payment) yang ditolak. **Peluang:**
[Perusahaan pemrosesan pembayaran](https://dashdevs.com/blog/best-payment-processing-companies/)
dapat mengintegrasikan verifikasi passkey ke dalam API mereka untuk mengurangi risiko dan
mendukung alternatif [SCA](https://www.corbado.com/id/blog/psd2-passkeys) biometrik untuk alur yang patuh.

### 2.7 Passkey untuk Penyedia Tokenisasi & Dompet Digital

**Dampak:** Penyimpanan kredensial yang aman dan reautentikasi tanpa hambatan.
**Peluang:** Penyedia [dompet digital](https://www.corbado.com/id/blog/jaminan-dompet-digital) seperti
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) dan [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay)
sudah menggunakan alur yang mirip dengan passkey.

## 3. Penyedia Pembayaran Mana yang Telah Meluncurkan Passkey?

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

### 3.1 Mastercard Passkeys

![menggunakan passkey pembayaran mastercard](https://www.corbado.com/website-assets/using_mastercard_payment_passkey_7f8121856f.png)

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

### 3.2 Visa Passkeys

[Visa](https://www.corbado.com/blog/visa-passkeys) 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](https://www.corbado.com/blog/visa-passkeys) bertujuan untuk memodernisasi pengalaman checkout online
dengan [keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) dan kenyamanan pengguna yang
ditingkatkan. Baca lebih lanjut: [VISA Passkeys](https://www.corbado.com/blog/visa-passkeys)

### 3.3 American Express Passkeys

American Express belum secara publik meluncurkan penawaran passkey. Namun, sebagai anggota
dewan [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), kemungkinan besar American Express akan
meluncurkan solusi autentikasi berbasis passkey dalam waktu dekat, sejalan dengan tren
industri yang lebih luas.

### 3.4 PayPal Passkeys

![paypal login passkeys](https://www.corbado.com/website-assets/paypal_login_passkeys_3c664c9248.png)

[PayPal](https://www.corbado.com/blog/paypal-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys)

### 3.5 Klarna 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) membatasi
[pembuatan passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) di
[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) / [WebView](https://www.corbado.com/blog/native-app-passkeys), ini
mungkin menjadi alasan mengapa Klarna belum meluncurkan passkey sejauh ini.

### 3.6 Block (Square) Passkeys

Square telah memperkenalkan [login passkey](https://www.corbado.com/id/blog/passkey-login-praktik-terbaik) untuk
dasbor pengembang dan konsol manajemen mereka, memungkinkan akses
[tanpa kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) yang aman ke alat internal.
Namun, belum ada pengumuman mengenai dukungan passkey dalam alur pembayaran atau API untuk
pengguna akhir atau merchant.

### 3.7 Stripe Passkeys

Stripe telah meluncurkan [login passkey](https://www.corbado.com/id/blog/passkey-login-praktik-terbaik) 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](https://www.corbado.com/passkeys-for-payment)—akan mengikuti arsitektur redirect yang sama.

### 3.8 BILL Passkeys

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

### 3.9 Remitly Passkeys

Remitly belum mengungkapkan rencana atau informasi publik apa pun tentang penerapan
[autentikasi passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) dalam layanan mereka.

### 3.10 Payoneer Passkeys

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

### 3.11 Adyen Passkeys

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

### 3.12 Worldpay Passkeys

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.

### 3.13 Checkout.com Passkeys

Checkout.com belum secara publik meluncurkan dukungan passkey. Tidak ada pembaruan
pengembang, posting blog, atau pengumuman resmi mengenai
[adopsi passkey](https://www.corbado.com/id/blog/kasus-bisnis-adopsi-passkey).

### 3.14 AliPay Passkeys

AliPay belum secara resmi meluncurkan passkey. Mengingat tren yang berkembang dalam
[autentikasi biometrik](https://www.corbado.com/id/faq/apa-itu-passkeys) dalam ekosistem pembayaran Tiongkok,
peluncuran mungkin terjadi di masa depan, tetapi tidak ada dokumentasi saat ini yang
mengonfirmasi hal ini.

### 3.15 Mollie Passkeys

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

### 3.16 Amazon Pay Passkeys

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.

### 3.17 Braintree Passkeys

Braintree, sebuah perusahaan [PayPal](https://www.corbado.com/blog/paypal-passkeys), belum secara resmi
mengadopsi [autentikasi passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi). Dokumentasi
mereka saat ini tidak menyebutkan passkey dalam konteks login pengguna atau API merchant.

### 3.18 Link Passkeys

Link, solusi checkout sekali klik dari Stripe, telah meluncurkan passkey yang mungkin
berfungsi sebagai dasar untuk strategi passkey Stripe dalam
[pembayaran](https://www.corbado.com/passkeys-for-payment) konsumen. Namun, Stripe belum secara resmi mengumumkan
dukungan passkey untuk Link atau rencana spesifik apa pun untuk peluncuran.

![link passkeys login](https://www.corbado.com/website-assets/link_passkeys_login_88b6b731dd.png)

### 3.19 Afterpay Passkeys

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](https://www.corbado.com/id/blog/kasus-bisnis-adopsi-passkey)
karena batasan [WebView](https://www.corbado.com/blog/native-app-passkeys) yang disematkan.

## 4. Mengapa Upaya Industri untuk Menstandardisasi Passkey Dihambat oleh Apple?

[Adopsi passkey](https://www.corbado.com/id/blog/kasus-bisnis-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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC)

- [Pembuatan Passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) Pihak Ketiga di Iframes

### 4.1 Di Mana Apple Menghambat Secure Payment Confirmation (SPC)?

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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) menstandardisasi cara penyedia pembayaran
mengautentikasi pengguna di berbagai situs merchant tanpa mengorbankan
[keamanan](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) atau pengalaman pengguna. Namun,
Apple secara konsisten menahan dukungan untuk [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) di
dalam Safari, kemungkinan sebagai langkah strategis untuk memastikan bahwa
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) tetap menjadi solusi pembayaran yang paling
disukai dan paling lancar di dalam ekosistemnya. Penolakan Apple untuk mengadopsi
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-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.

### 4.2 Bagaimana Pembatasan Iframe Safari Memengaruhi Pembuatan Passkey Pihak Ketiga

Penghalang kritis lainnya melibatkan pembatasan yang disengaja oleh Apple terhadap
pembuatan passkey di dalam [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) lintas-asal. Meskipun
Safari mengizinkan penggunaan passkey yang ada untuk autentikasi
(`navigator.credentials.get()`) di [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) pihak ketiga,
Safari secara eksplisit memblokir
[pendaftaran passkey](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-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.

## 5. Cara Membangun SDK Pembayaran Passkey Pihak Ketiga untuk Web

### 5.1 Strategi A: Menyematkan iframe Lintas-Asal (Pro & Kontra)

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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get)
  dan
  [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/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”](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation)
  (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.

![Iframe lintas asal](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/embedding_cross_origin_iframe_8b52f6996e.png)

### 5.2 Strategi B: Pendekatan Berbasis Redirect untuk Kompatibilitas yang Lebih Luas

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](https://passkeys.eu/device-support)
  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.

![Pendekatan redirect untuk kompatibilitas yang lebih luas](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_approach_for_broader_compatibility_701166520a.png)

## 6. SDK Pembayaran Passkey Pihak Ketiga untuk Aplikasi Native

Mengintegrasikan passkey dalam aplikasi seluler native menghadirkan tantangan unik
dibandingkan dengan skenario berbasis web.
[Aplikasi native](https://www.corbado.com/id/blog/passkey-aplikasi-native) untuk merchant (baik di
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) maupun
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) sering kali menyematkan alur pembayaran
di dalam aplikasi menggunakan [WebView](https://www.corbado.com/blog/native-app-passkeys) 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.

### 6.1 Mengapa Passkey Penyedia Passkey tidak dapat digunakan secara langsung di Aplikasi Native Merchant

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](https://www.corbado.com/blog/how-to-enable-passkeys-ios)
maupun [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/id/blog/passkey-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](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) dalam konteks merchant
bergantung pada browser sistem atau WebView berbasis sistem (seperti
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) di iOS atau Chrome Custom Tabs di
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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.

### 6.2 Tantangan dengan WebView yang Disematkan: Mengapa Mereka Merusak Passkey

WebView yang disematkan (misalnya, [WKWebView](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) 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](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) 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.

### 6.3 Menggunakan WebView Sistem atau Redirect untuk Passkey Pihak Ketiga

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:

#### 6.3.1 Gunakan WebView Sistem

**iOS (ASWebAuthenticationSession):**

Apple menyediakan [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/id/blog/passkey-aplikasi-native) BOSS. Ini menunjukkan bagaimana
webview sistem [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) dibuka, yang
berbagi statusnya dengan cookie Safari, memungkinkan dialog passkey untuk segera dimulai.

![ios asweb passkeys e-commerce](https://www.corbado.com/website-assets/ios_asweb_passkeys_e_commerce_34ecd03796.jpeg)

**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:

![android asweb passkeys paypal](https://www.corbado.com/website-assets/android_asweb_passkeys_paypal_5eb366dce2.jpeg)

#### 6.3.2 Redirect ke Browser Default

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](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi)—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.

![Redirect ke browser default](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_to_default_browser_48b9e771a3.png)

## 7. Iframe vs. Redirect: Pendekatan Mana untuk Checkout dengan Passkey?

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.

### 7.1 Tabel Perbandingan Detail Pendekatan yang Disematkan & Redirect

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](https://www.corbado.com/passkeys-for-critical-infrastructure) teknis.

| **Aspek**                            | **Pendekatan yang Disematkan (Iframe)**                                                                                                                                                                                                                                                   | **Pendekatan Redirect**                                                                                                                                                                                                                                                                                                                |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pengalaman Pengguna**              | ✅ Sangat mulus; pengguna tetap berada di situs merchant selama seluruh proses checkout, meningkatkan konsistensi merek merchant.                                                                                                                                                         | ⚠️ Berpotensi mengganggu; pengguna meninggalkan situs merchant atau menemukan pop-up/tab baru, menimbulkan gesekan.                                                                                                                                                                                                                    |
| **Kompatibilitas Browser**           | ⚠️ Terbatas karena Safari Apple memblokir pembuatan passkey lintas-asal dan pembatasan browser lama; dukungan parsial, terutama untuk alur autentikasi.                                                                                                                                   | ✅ Kuat; sangat kompatibel di semua browser utama karena beroperasi dalam konteks domain pihak pertama.                                                                                                                                                                                                                                |
| **Dukungan Aplikasi Native**         | ⚠️ Dukungan buruk; rusak di webview yang disematkan karena kebijakan asal yang ketat dan batasan keamanan.                                                                                                                                                                                | ✅ Dukungan kuat; mudah ditangani melalui webview sistem atau browser eksternal, selaras dengan pedoman platform (iOS dan Android).                                                                                                                                                                                                    |
| **Daya Tarik bagi Merchant**         | ✅ Lebih tinggi; merchant lebih suka pengalaman yang sepenuhnya disematkan karena mereka mempertahankan kontrol atas UX dan branding.                                                                                                                                                     | ⚠️ Sedang; pengalihan dapat menyebabkan gesekan, berpotensi memengaruhi tingkat konversi merchant dan kepuasan pelanggan kecuali ditangani dengan baik.                                                                                                                                                                                |
| **Kompleksitas Implementasi Teknis** | ⚠️ Kompleksitas lebih tinggi; memerlukan konfigurasi Kebijakan Izin yang tepat dan menangani berbagai keunikan browser dengan batasan pada aplikasi native.                                                                                                                               | ✅ Kompleksitas lebih rendah; mudah diimplementasikan karena kesederhanaan pihak pertama, mengurangi potensi jebakan integrasi.                                                                                                                                                                                                        |
| **Kompatibilitas Passkey**           | ⚠️ Parsial; autentikasi didukung secara luas, tetapi pembuatan passkey sangat bermasalah karena batasan lintas-asal.                                                                                                                                                                      | ✅ Penuh; dukungan lengkap untuk pendaftaran dan autentikasi passkey tanpa batasan lintas-asal.                                                                                                                                                                                                                                        |
| **Pemeliharaan dan Dukungan**        | ⚠️ Overhead lebih tinggi karena pembaruan browser yang sering dan tantangan kompatibilitas.                                                                                                                                                                                               | ✅ Overhead lebih rendah; pemeliharaan lebih sederhana, lebih sedikit pembaruan kompatibilitas lintas-asal yang diperlukan.                                                                                                                                                                                                            |
| **Contoh Praktik Terbaik**           | Klarna: Klarna selalu sangat fokus pada pengalaman pengguna yang disematkan dan telah menyarankan untuk tidak menggunakan WebView sistem. Karena alasan ini, Klarna berjuang untuk memberikan pengalaman passkey pihak ketiga yang lengkap kepada pelanggannya hingga saat penulisan ini. | PayPal: PayPal selalu membawa pengguna ke situs web mereka, memberlakukan pendekatan berbasis redirect karena kekuatan pasar dan sejarah panjang mereka. Oleh karena itu, mengintegrasikan passkey ke dalam alur pembayaran menjadi mudah dan cepat dicapai, bahkan dalam konteks pihak ketiga, karena WebView sistem sudah digunakan. |

### 7.2 Ringkasan: Memilih Alur Terbaik untuk SDK Pembayaran Anda

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](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-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.

## 8. Praktik Terbaik & Rekomendasi untuk SDK Passkey Lintas-Asal

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.

### 8.1 Cara Menyiapkan Pendekatan SDK untuk Alur Passkey

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](https://www.corbado.com/faq/enable-passkeys-iframe) 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](https://www.corbado.com/id/blog/passkey-login-praktik-terbaik) 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.

### 8.2 Mendeteksi Kemampuan Browser (Safari vs. Chrome vs. Edge vs. Firefox)

Mendeteksi kemampuan browser secara akurat tetap menantang karena berkurangnya
granularitas [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) dan
dukungan yang tidak konsisten untuk
[Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) di seluruh platform.

#### 8.2.1 Kompleksitas Parsing User-Agent

Parsing tradisional semakin tidak dapat diandalkan karena browser mengurangi detail dalam
string [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) untuk melindungi
privasi pengguna. Membedakan detail penting—seperti Windows 10 vs.
[Windows 11](https://www.corbado.com/blog/passkeys-windows-11), versi macOS yang tepat, atau arsitektur
CPU—sekarang sulit atau tidak mungkin hanya menggunakan
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox).

#### 8.2.2 Dukungan Client Hints yang Tidak Konsisten

Meskipun [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) 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.

#### 8.2.3 Batasan Aplikasi yang Disematkan dan Native:

WebView yang disematkan biasanya membatasi akses ke informasi perangkat terperinci dan
jarang mendukung [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox).
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.

### 8.3 Menangani Aplikasi Native dengan Hati-hati: WebView yang Disematkan vs. WebView Sistem

Aplikasi merchant native sering kali menyematkan konten web di
[WKWebView](https://www.corbado.com/blog/native-app-passkeys) (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.

### 8.4 Memastikan Keamanan & Kepatuhan (PCI)

Sebagai penyedia pembayaran, keamanan yang kuat dan kepatuhan terhadap peraturan (PCI,
[PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/id/blog/psd2-passkeys), dll.) adalah kunci:

- **Header & Keamanan Konten**: Terapkan header
  [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) 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.

### 8.5 Pengujian & Pemantauan Berkelanjutan Passkey

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](https://www.corbado.com/id/blog/pemecahan-masalah-passkey-solusi) (pembuatan atau login)
  untuk memperbaiki masalah dengan cepat, terutama untuk pengguna berbasis Apple.

### 8.6 KPI Passkey Esensial: Cara Melacak Pembuatan & Login

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.

#### 8.6.1 Tingkat Penerimaan Passkey

- **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%

#### 8.6.2 Tingkat Keberhasilan Pembuatan Passkey

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

#### 8.6.3 Tingkat Penggunaan Passkey

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

#### 8.6.4 Tingkat Keberhasilan Login Passkey

- **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.”

#### 8.6.5 Penggunaan Fallback

- **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%

#### 8.6.6 Metrik Konversi & Penipuan

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](https://www.corbado.com/glossary/3d-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.

## 9. Bagaimana Corbado Membantu Penyedia Pembayaran Mencapai Kesuksesan Passkey

### 9.1 Pembuatan Passkey yang Mulus: Lingkungan Bank, Platform & Merchant

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](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-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:

#### 9.1.1 Layar Pembuatan & Komponen UI yang Seragam

Terlepas dari di mana pengguna diminta untuk membuat passkey—baik itu lingkungan
[perbankan](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/blog/vicroads-passkeys):

![Corbado optimized ux passkeys](https://www.corbado.com/website-assets/Corbado_optimized_ux_passkeys_e5deec9ed9.png)

#### 9.1.2 Pelacakan & Analitik Terpusat

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.

#### 9.1.3 KPI & Pengujian A/B

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.

#### 9.1.4 Konteks Pembuatan Fleksibel: Bank, Penyedia Pembayaran, atau Merchant

Pengguna dapat membuat passkey dalam konteks berikut:

- **Konteks Bank**: Alur pembuatan dipicu setelah pengguna login ke bank mereka,
  memanfaatkan kepercayaan dan keakraban lingkungan [perbankan](https://www.corbado.com/passkeys-for-banking).

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

#### 9.1.5 Metadata & Penautan Pengidentifikasi yang Konsisten

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.

#### 9.1.6 UI Adaptif & Penanganan Kesalahan

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.

#### 9.1.7 Pengalaman Mendalam Corbado dalam Alur Pembuatan Passkey

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.

### 9.2 Maksimalkan Penggunaan Passkey untuk Checkout 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.

![apple pay passkeys checkout](https://www.corbado.com/website-assets/apple_pay_passkeys_checkout_f63fb27017.jpeg)

Di Corbado, kami telah mengembangkan mekanisme
“[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)”
yang secara otomatis mendeteksi kapan lingkungan pengguna kemungkinan besar berisi passkey
yang valid, memungkinkan pengalaman pembayaran
[satu ketukan](https://docs.corbado.com/corbado-connect/features/one-tap-login) yang
sesungguhnya. Di bawah ini adalah elemen inti yang memungkinkan hal ini.

#### 9.2.1 Alur Satu Ketukan: Tidak Perlu Memasukkan Ulang Kredensial

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

![Tangkapan layar halaman login Konten yang dihasilkan AI mungkin tidak benar.](bc386dced8be285ec3788060ed5cdb7b.png)

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.

#### 9.2.2 Passkey Intelligence: Deteksi & Penilaian Lingkungan

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.

#### 9.2.3 Tidak Ada Penyimpanan PII, namun Sadar Konteks

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.

#### 9.2.4 Logika Fallback & Pemulihan Otomatis

Dalam skenario di mana passkey pengguna mungkin ada tetapi tidak dapat dideteksi
(misalnya, cookie dihapus, perangkat baru),
[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/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.

#### 9.2.5 Pelacakan Lanjutan & Wawasan Cakupan

![process events trigger overview](https://www.corbado.com/website-assets/process_events_trigger_overview_e101d943f1.png)

Setiap kali Corbado memilih untuk memulai atau melewatkan permintaan passkey
[satu ketukan](https://docs.corbado.com/corbado-connect/features/one-tap-login), 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.

#### 9.2.6 Pengalaman Satu Ketukan Terpadu di Seluruh Kasus Penggunaan

Terlepas dari apakah pengguna datang dari kampanye pembuatan passkey bank atau langsung di
checkout merchant, logika
[satu ketukan](https://docs.corbado.com/corbado-connect/features/one-tap-login) tetap
konsisten.

Corbado memastikan bahwa jika passkey ditemukan (berdasarkan cookie domain, token
penyimpanan lokal, atau sinyal
[passkey intelligence](https://docs.corbado.com/corbado-connect/features/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.

### 9.3 Analitik Kaya untuk KPI Pembuatan & Login Passkey

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.

#### 9.3.1 Funnel Passkey Terpadu: Pembuatan → Penggunaan

![analisis funnel passkey](https://www.corbado.com/website-assets/passkeys_funnel_analysis_436af30b87.png)

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.

#### 9.3.2 KPI Inti dari Panduan Beli vs. Bangun Passkey

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

![kpi inti panduan passkey](https://www.corbado.com/website-assets/core_kpis_passkey_guide_e37543f9f2.png)

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

#### 9.3.3 Segmentasi OS & Browser Granular

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.

#### 9.3.4 Pelaporan Dinamis & Dasbor Real-Time

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.

#### 9.3.5 Debugging & Log Proses

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.

#### 9.3.6 Optimisasi Funnel dengan Pengujian A/B

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.

#### 9.3.7 Akses & Integrasi Data Fleksibel

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.

### 9.4 Sinkronisasi Multi-Perangkat & “Kecerdasan” untuk Adopsi Tinggi

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.

#### 9.4.1 Pembuatan Passkey Pertama vs. Perangkat Tambahan

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

#### 9.4.2 Autentikasi Hibrida untuk “Penyembuhan” Perangkat

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.

#### 9.4.3 Mendeteksi & Membimbing Pengguna untuk Menambahkan Perangkat yang Hilang

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?”

![strategi ux passkey corbado](https://www.corbado.com/website-assets/ux_strategy_passkeys_corbado_9884e5167c.png)

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

#### 9.4.4 Alur UI Adaptif

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.

#### 9.4.5 Menangani Ketidakcocokan & Kesalahan

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.

#### 9.4.6 Metrik Cakupan Berkelanjutan

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](https://www.corbado.com/id/blog/mengurangi-biaya-sms-dengan-passkeys), 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.

### 9.5 Waktu Peluncuran yang Dipercepat: Mengapa Solusi Holistik Penting

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.

#### 9.5.1 Hal-hal yang Tidak Diketahui & Melampaui Seremoni

- **Implementasi Seremoni**: Membuat atau mengautentikasi passkey biasanya hanya
  melibatkan beberapa baris [JavaScript](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) 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.

#### 9.5.2 Adopsi Adalah Tujuan Sebenarnya

- **Seremoni vs. Adopsi**: Bahkan jika Anda memiliki seremoni WebAuthn yang sempurna,
  adopsi pengguna yang rendah (misalnya, tingkat penggunaan passkey &lt;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.

#### 9.5.3 Risiko Implementasi Minimal “Lakukan Sendiri”

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

#### 9.5.4 Solusi Holistik: Lebih dari Sekadar API

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

#### 9.5.5 Rekomendasi untuk Membaca Panduan Beli vs. Bangun

- **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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/id/blog/penyedia-autentikasi-passkey-hemat-biaya).

### 9.6 Hosting & Penerapan Fleksibel (Multi-AZ, Agnostik Wilayah)

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:

#### 9.6.1 Penerapan Cloud Agnostik Wilayah

Untuk mematuhi kedaulatan data atau kerangka kerja peraturan (misalnya, GDPR di Eropa,
[PIPEDA](https://www.corbado.com/blog/pipeda) di Kanada, atau [NIST](https://www.corbado.com/blog/nist-passkeys)/HIPAA di Amerika
Serikat), beberapa penyedia harus menyimpan data dalam batas geografis tertentu.

Arsitektur agnostik wilayah memastikan layanan passkey dapat diterapkan di wilayah
[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) 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.

#### 9.6.2 Ketersediaan Tinggi Multi-AZ (Availability Zone)

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](https://www.corbado.com/passkeys-for-critical-infrastructure) 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](https://www.corbado.com/passkeys-for-banking) dan situs
[e-commerce](https://www.corbado.com/passkeys-for-e-commerce), di mana bahkan waktu henti singkat dapat
menyebabkan dampak pendapatan yang signifikan.

#### 9.6.3 Hosting Terkelola Mandiri atau Hibrida

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.

#### 9.6.4 Infrastruktur Skalabel & Elastis

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.

#### 9.6.5 Alat Keamanan & Kepatuhan

Standar industri seperti [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)-DSS,
[PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/id/blog/psd2-passkeys), atau
[ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks) sering berlaku untuk penyedia pembayaran.
[Penyedia passkey](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) 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.

#### 9.6.6 Pemulihan Bencana & Geo-Redundancy

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](https://www.corbado.com/id/blog/visa-passkeys) tetap tersedia
dan patuh, di mana pun pengguna atau data Anda berada.

## 10. Kesimpulan: Mengatasi Hambatan Apple & Merangkul Passkey

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.

### 10.1 Pertanyaan Kunci Terjawab: Batasan Lintas-Asal & SPC

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.

### 10.2 Bagaimana Corbado Menjembatani Kesenjangan untuk Penyedia Pembayaran

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](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-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.

### 10.3 Kesimpulan Akhir: Membangun Pengalaman Passkey yang Tanpa Gesekan dan Dapat Diskalakan

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.