Wawancara Desain Sistem: Bagaimana Anda meluncurkan Secure Payment Confirmation secara aman?

Konteks dan cakupan

Sebuah platform pembayaran multi-merchant ingin agar pembeli mengonfirmasi penerima pembayaran, jumlah, dan mata uang saat checkout serta menghasilkan bukti kriptografis yang dapat diverifikasi oleh bank atau layanan pembayaran. Tim sedang mempertimbangkan W3C Secure Payment Confirmation Candidate Recommendation Draft yang diterbitkan pada 2 Juli 2026. Halaman merchant, orkestrator pembayaran, dan halaman autentikasi penerbit (issuer) dapat memiliki origin yang berbeda, sedangkan peramban lama harus tetap mempertahankan jalur autentikasi yang ada.

Rancang sistem dari pendaftaran kredensial SPC hingga verifikasi assertion. Jelaskan bagaimana pihak ketiga dapat memulai autentikasi untuk relying party, bidang mana saja yang harus diikat oleh server, dan cara menangani ketidaktersediaan API, pembatalan, pembayaran duplikat, serta rollback. Spesifikasi ini masih berupa draf; jangan perlakukan status tersebut sebagai dukungan peramban universal.

Apa yang dievaluasi oleh pewawancara

Pewawancara ingin melihat apakah Anda mengikat rincian transaksi yang ditampilkan kepada pengguna, pesanan yang disetujui oleh server, dan assertion autentikasi ke dalam satu percobaan pembayaran. Anda harus menjelaskan hubungan antara SPC dan WebAuthn serta implikasi keamanan dari pemanggilan lintas-asal.

Jawaban yang kuat juga mencakup Permission Policy payment, batas privasi securePaymentConfirmationAvailability(), pemisahan kredensial, kunci idempotensi, fallback berbasis risiko, retensi bukti, dan peluncuran yang dapat dibatalkan (reversible) alih-alih hanya menjelaskan dialog biometrik.

Klarifikasi yang perlu ditanyakan terlebih dahulu

• Siapa yang mendaftarkan kredensial SPC, dan apakah kredensial tersebut terpisah dari kredensial masuk (login)?
• Apa saja origin dari penerbit, merchant, dan orkestrator pembayaran, serta pihak mana yang bertindak sebagai WebAuthn Relying Party?
• Apakah data autentikasi harus menyertakan jumlah, penerima pembayaran, mata uang, ID pesanan, dan masa berlaku?
• Bisakah jalur autentikasi yang ada mengambil alih dengan aman saat SPC tidak tersedia atau dibatalkan?
• Bukti apa yang diperlukan untuk percobaan ulang, panggilan balik (callback) duplikat, pengembalian dana, dan sengketa?

Jawaban 30 detik

“Saya akan membuat percobaan pembayaran sisi server yang tidak dapat diubah (immutable) sebelum autentikasi, mendaftarkan kredensial SPC khusus pembayaran, dan membatasi origin pemanggil yang diizinkan. Server menerbitkan challenge sekali pakai dan digest pesanan; merchant hanya meneruskan data pembayaran yang disetujui server ke SPC, dan callback diperiksa terhadap kebijakan origin, challenge, kredensial, verifikasi pengguna, serta status pesanan. Ketidaktersediaan atau pembatalan mengikuti jalur lama yang eksplisit, bukan jalan pintas menuju sukses. Transisi status menggunakan kunci idempotensi. Saya akan mulai dengan lalu lintas berisiko rendah, mengukur kegagalan assertion, sengketa, dan fallback, serta menonaktifkan percobaan SPC baru sambil mempertahankan bukti yang sedang berjalan jika ditemukan anomali.”

Solusi langkah demi langkah

Tentukan origin dan kepemilikan kredensial

SPC dibangun di atas WebAuthn tetapi mengizinkan pihak ketiga untuk memicu seremoni bagi pihak relying party. Gunakan Relying Party ID khusus pembayaran atau subdomain pembayaran agar kredensial login dan pembayaran tidak dapat dipertukarkan secara diam-diam. Pendaftaran hanya menerima token pengikat pengguna dan merchant yang diterbitkan server. Simpan ID kredensial, origin, waktu pembuatan, status pencabutan, dan properti pengikatan perangkat; jangan pernah memercayai Relying Party ID yang diberikan peramban sebagai otorisasi.

Ikat status pesanan ke challenge

Buat payment_attempt yang berisi versi pesanan, jumlah, mata uang, penerima pembayaran, challenge, masa berlaku, dan kunci idempotensi. Gunakan challenge hanya satu kali. Pengeditan pesanan, konversi mata uang, atau perubahan penerima pembayaran akan membuat percobaan baru. Jumlah yang ditampilkan kepada pengguna berasal dari catatan atau digest yang disetujui server yang sama; merchant tidak boleh menggabungkan nilai di peramban dan langsung memanggil SPC.

type PaymentAttempt = {
  id: string;
  orderVersion: number;
  amountMinor: bigint;
  currency: string;
  payeeOrigin: string;
  challenge: Uint8Array;
  expiresAt: Date;
  status: "created" | "authorizing" | "approved" | "cancelled" | "expired";
};

Terapkan batasan lintas-asal

Perubahan penting pada SPC adalah bahwa pihak ketiga dapat menggunakan kredensial milik relying party lain. Cantumkan pemanggil, relying party, pesanan, dan origin autentikasi yang diizinkan dalam kebijakan server. Konfigurasikan Permission Policy payment sebelum menyematkan iframe pembayaran dan validasi origin tingkat atas terhadap daftar izin merchant. Setelah assertion lintas-asal kembali, pemanggil hanya menerima hasil yang diperlukan untuk transaksi tersebut; pemanggil tidak boleh meminta ekstensi WebAuthn arbitrer atau mengakses kredensial login.

Deteksi kapabilitas dan pilih fallback

Pilih PaymentRequest.securePaymentConfirmationAvailability() dan catat available secara terpisah dari alasan ketidaktersediaan; agen pengguna dapat mengembalikan alasan yang sengaja dibuat tidak spesifik untuk mengurangi fingerprinting. Ketersediaan tetap tidak membuktikan bahwa kredensial tertentu ada. Fallback berbasis risiko dapat memilih SPC, autentikasi bank, kode sekali pakai, atau peninjauan manual. Setiap jalur memeriksa ulang pesanan dan challenge, sehingga kesalahan SPC tidak dapat berubah menjadi pembayaran yang berhasil.

Verifikasi assertion dan semantik pembayaran

Server memverifikasi origin client-data, challenge, Relying Party ID, tanda tangan, flag verifikasi pengguna, status kredensial, dan digest pesanan. Gunakan pembaruan bersyarat untuk mengklaim percobaan created sebelum menagih; callback duplikat mengembalikan hasil yang sama. Ketidakcocokan digest adalah kegagalan keamanan dan tidak boleh dicoba ulang tanpa batas. Suatu assertion membuktikan bahwa autentikasi telah selesai; ini tidak membuktikan bahwa dana telah diselesaikan (settled).

Tangani pembatalan, masa kedaluwarsa, dan kegagalan

Pembatalan, ketiadaan autentikator, peramban yang ditutup, dan batas waktu penerbit menjadi status akhir yang berbeda. Percobaan ulang membuat percobaan dan challenge baru. Batas waktu gateway tidak boleh memutar ulang challenge lama: periksa kunci idempotensi terlebih dahulu, lalu tentukan apakah hasilnya tertunda, berhasil, atau memerlukan peninjauan manual. Peristiwa antara layanan pembayaran, merchant, dan penerbit memiliki versi sehingga peristiwa lama tidak dapat menimpa status yang lebih baru.

Amati risiko dan simpan bukti

Segmentasikan ketersediaan SPC, pembatalan pengguna, kegagalan assertion, callback duplikat, rasio fallback, latensi penagihan, dan sengketa berdasarkan peramban, kombinasi origin, metode autentikasi, serta tingkat risiko. Simpan hash digest pesanan, pengidentifikasi kredensial yang tidak dapat dibalik (non-reversible), ID percobaan, versi kebijakan, dan hasil verifikasi; jangan mencatat data biometrik atau kunci privat. Terapkan rate-limiting pada anomali lintas-asal, percobaan kredensial berulang, dan perubahan jumlah yang mendadak.

Tahapan peluncuran, pengujian, dan rollback

Mulailah dengan merchant internal dan nominal berisiko rendah, lalu perluas berdasarkan peramban, origin, dan wilayah. Uji iframe lintas-asal, ketiadaan Permission Policy, penolakan pengguna, kredensial yang hilang, pemutaran ulang challenge, pengeditan pesanan, callback duplikat, batas waktu gateway, dan kondisi perlombaan (race condition) pengembalian dana. Saat rollback, hentikan pembuatan percobaan SPC baru, biarkan transaksi yang sedang berjalan selesai melalui state machine, dan rute transaksi baru ke jalur lama. Simpan assertion dan bukti pesanan untuk analisis sengketa.

Contoh jawaban berkualitas tinggi

“SPC menghasilkan bukti autentikasi; ini bukan penyelesaian dana. Saya akan mengikat payment_attempt yang tidak dapat diubah ke versi pesanan, jumlah, penerima pembayaran, challenge, kebijakan origin, dan kunci idempotensi. Kredensial pembayaran dipisahkan dari kredensial login, dan Permission Policy membatasi pemanggil lintas-asal. Setelah autentikasi, server memverifikasi assertion WebAuthn dan digest pesanan, lalu memajukan status penagihan secara bersyarat. Ketidaktersediaan, pembatalan, dan batas waktu menggunakan fallback eksplisit, sementara callback duplikat mengembalikan hasil yang telah ditetapkan. Selama peluncuran bertahap, saya akan memantau kegagalan assertion, fallback, sengketa, dan anomali lintas-asal; rollback menghentikan percobaan SPC baru dan mempertahankan bukti yang sedang berjalan.”

Kesalahan umum

• Memperlakukan available sebagai kredensial → pengguna mungkin masih belum memiliki kredensial yang dapat digunakan → pisahkan deteksi kapabilitas dari ketersediaan kredensial.
• Membiarkan peramban memilih jumlah transaksi → konfirmasi dan tagihan dapat berbeda → ikat digest pesanan dan challenge dari server.
• Memperlakukan panggilan lintas-asal sebagai login biasa → kredensial login atau data ekstensi dapat bocor → pisahkan kredensial pembayaran dan batasi pemanggil.
• Mengubah kegagalan SPC menjadi keberhasilan pembayaran → autentikasi disamakan dengan penyelesaian dana → modelkan autentikasi, penagihan, dan penyelesaian secara terpisah.
• Menggunakan kembali challenge saat mencoba ulang → assertion dapat diputar ulang → gunakan sekali dan terbitkan challenge baru per percobaan.
• Menghapus catatan selama rollback → sengketa dan tagihan duplikat menjadi tidak dapat dilacak → bekukan permintaan baru dan simpan bukti yang sedang berjalan.

Pertanyaan lanjutan dan jawaban

Pertanyaan lanjutan 1: Mengapa tidak menggunakan kembali passkey login?

Pembayaran dan login memiliki ancaman, origin, dan tujuan otorisasi yang berbeda. Spesifikasi memang mengizinkan kredensial WebAuthn dalam SPC, tetapi subdomain pembayaran dan kredensial terpisah mengurangi attack surface login. Jika kredensial digunakan bersama, tujuan assertion, Relying Party, dan pemeriksaan server harus eksplisit.

Pertanyaan lanjutan 2: Bagaimana Anda mencegah merchant menampilkan satu dolar tetapi menagih seratus dolar?

UI merchant bukan otoritas penentu jumlah. Layanan pembayaran membuat digest dari versi pesanan, alur autentikasi membawa digest tersebut, dan layanan penagihan hanya menerima percobaan yang sama. Setiap perubahan bidang akan membuat percobaan baru.

Pertanyaan lanjutan 3: Apa risiko dari mengembalikan alasan ketersediaan yang mendetail?

Alasan yang terlalu terperinci dapat menjadi sidik jari perangkat atau konfigurasi, sehingga agen pengguna mungkin mengembalikan unavailable-unknown-reason. Bisnis menggunakan hasil tersebut hanya untuk pemilihan pengalaman pengguna, tidak pernah sebagai profil pengguna, skor risiko, atau fakta otorisasi.

Pertanyaan lanjutan 4: Bisakah layanan pembayaran memanggil SPC lagi setelah batas waktu (timeout)?

Pertama, kueri status penagihan dan autentikasi menggunakan kunci idempotensi. Jika percobaan lama belum terselesaikan, jangan memutar ulangnya secara membabi buta. Batalkan atau kedaluwarsakan secara eksplisit, lalu buat percobaan baru dengan challenge dan digest pesanan yang baru.