Temu Duga Reka Bentuk Sistem: Bagaimanakah anda akan melancarkan Secure Payment Confirmation dengan selamat?

Makluman dan skop

Sebuah platform pembayaran pelbagai pedagang mahu pembeli mengesahkan penerima bayaran, jumlah dan mata wang semasa pembayaran keluar (checkout) serta menghasilkan bukti kriptografi yang boleh disahkan oleh bank atau perkhidmatan pembayaran. Pasukan sedang mempertimbangkan W3C Secure Payment Confirmation Candidate Recommendation Draft yang diterbitkan pada 2 Julai 2026. Halaman pedagang, pengatur pembayaran (orchestrator) dan halaman pengesahan pengeluar (issuer) mungkin mempunyai asal (origin) yang berbeza, manakala penyemak imbas lama mesti mengekalkan laluan pengesahan sedia ada.

Reka bentuk sistem daripada pendaftaran kelayakan SPC hingga pengesahan assertion. Terangkan cara pihak ketiga boleh memulakan pengesahan untuk pihak yang bergantung (relying party), medan yang mesti diikat oleh pelayan, dan cara mengendalikan ketidaktersediaan API, pembatalan, pembayaran pendua serta pengunduran. Spesifikasi ini masih dalam bentuk draf; jangan anggap status tersebut sebagai sokongan penyemak imbas sejagat.

Perkara yang dinilai oleh penemu duga

Penemu duga ingin melihat sama ada anda mengikat butiran transaksi yang ditunjukkan kepada pengguna, pesanan yang diluluskan oleh pelayan dan assertion pengesahan kepada satu percubaan pembayaran. Anda harus menerangkan hubungan antara SPC dan WebAuthn serta implikasi keselamatan seruan silang asal.

Jawapan yang kukuh juga merangkumi Permission Policy payment, had privasi securePaymentConfirmationAvailability(), pengasingan kelayakan, kunci ketakberubahan (idempotency keys), sandaran berasaskan risiko, pengekalan bukti dan pelancaran yang boleh diundur, bukannya sekadar menerangkan dialog biometrik.

Penjelasan yang perlu ditanya terlebih dahulu

• Siapakah yang mendaftarkan kelayakan SPC, dan adakah ia berasingan daripada kelayakan log masuk?
• Apakah asal (origins) pengeluar, pedagang dan pengatur pembayaran, dan pihak manakah yang merupakan WebAuthn Relying Party?
• Adakah data pengesahan mesti merangkumi jumlah, penerima bayaran, mata wang, ID pesanan dan tarikh luput?
• Bolehkah laluan pengesahan sedia ada mengambil alih dengan selamat apabila SPC tidak tersedia atau dibatalkan?
• Apakah bukti yang diperlukan untuk percubaan semula, panggilan balik (callback) pendua, bayaran balik dan pertikaian?

Jawapan 30 saat

“Saya akan mencipta percubaan pembayaran bahagian pelayan yang tidak boleh diubah (immutable) sebelum pengesahan, mendaftarkan kelayakan SPC khusus pembayaran dan mengehadkan asal pemanggil yang dibenarkan. Pelayan mengeluarkan cabaran (challenge) sekali guna dan ringkasan (digest) pesanan; pedagang hanya menghantar data pembayaran yang diluluskan pelayan kepada SPC, dan callback disemak terhadap dasar asal, challenge, kelayakan, pengesahan pengguna dan status pesanan. Ketidaktersediaan atau pembatalan mengikut laluan legasi yang jelas, bukan jalan pintas kejayaan. Peralihan keadaan menggunakan kunci ketakberubahan. Saya akan bermula dengan trafik berisiko rendah, mengukur kegagalan assertion, pertikaian dan sandaran, serta melumpuhkan percubaan SPC baharu sambil mengekalkan bukti dalam proses jika anomali dikesan.”

Penyelesaian langkah demi langkah

Tentukan asal dan pemilikan kelayakan

SPC dibina berasaskan WebAuthn tetapi membenarkan pihak ketiga mencetuskan upacara (ceremony) untuk pihak yang bergantung. Gunakan Relying Party ID khusus pembayaran atau subdomain pembayaran supaya kelayakan log masuk dan pembayaran tidak boleh ditukar ganti secara senyap. Pendaftaran hanya menerima token pengikat pengguna dan pedagang yang dikeluarkan oleh pelayan. Simpan ID kelayakan, asal, masa penciptaan, status pembatalan dan sifat pengikatan peranti; jangan sekali-kali mempercayai Relying Party ID yang dibekalkan oleh penyemak imbas sebagai kebenaran.

Ikat keadaan pesanan pada challenge

Cipta payment_attempt yang mengandungi versi pesanan, jumlah, mata wang, penerima bayaran, challenge, tarikh luput dan kunci ketakberubahan. Gunakan challenge sekali sahaja. Pengeditan pesanan, penukaran mata wang atau pertukaran penerima bayaran akan mencipta percubaan baharu. Jumlah yang dipaparkan kepada pengguna mestilah datang daripada rekod atau digest yang diluluskan pelayan yang sama; pedagang tidak boleh menggabungkan nilai dalam penyemak imbas dan memanggil SPC secara terus.

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

Penguatkuasaan sempadan silang asal

Perubahan penting SPC ialah pihak ketiga boleh menggunakan kelayakan milik pihak bergantung yang lain. Letakkan pemanggil, pihak bergantung, pesanan dan asal pengesahan yang dibenarkan dalam dasar pelayan. Konfigurasikan Permission Policy payment sebelum membenamkan iframe pembayaran dan sahkan asal peringkat teratas terhadap senarai dibenarkan (allowlist) pedagang. Selepas assertion silang asal dikembalikan, pemanggil hanya menerima keputusan yang diperlukan untuk transaksi tersebut; ia tidak boleh meminta sambungan WebAuthn sewenang-wenangnya atau mengakses kelayakan log masuk.

Kesan keupayaan dan pilih sandaran

Utamakan PaymentRequest.securePaymentConfirmationAvailability() dan rekod available secara berasingan daripada sebab ketidaktersediaan; ejen pengguna mungkin mengembalikan sebab yang sengaja dikaburkan untuk mengurangkan cap jari peranti (fingerprinting). Ketersediaan masih tidak membuktikan bahawa kelayakan tertentu wujud. Sandaran berasaskan risiko boleh memilih SPC, pengesahan bank, kod sekali guna atau semakan manual. Setiap laluan menyemak semula pesanan dan challenge, jadi ralat SPC tidak boleh bertukar menjadi kejayaan pembayaran.

Sahkan assertion dan semantik pembayaran

Pelayan mengesahkan asal data klien, challenge, Relying Party ID, tandatangan, bendera pengesahan pengguna, status kelayakan dan digest pesanan. Gunakan kemas kini bersyarat untuk menuntut percubaan created sebelum mengenakan caj; callback pendua mengembalikan keputusan yang sama. Ketidakpadanan digest ialah kegagalan keselamatan dan tidak boleh dicuba semula tanpa had. Assertion membuktikan bahawa pengesahan telah selesai; ia tidak membuktikan bahawa dana telah dijelaskan (settled).

Kendalikan pembatalan, tamat tempoh dan kerosakan

Pembatalan, ketiadaan pengesah (authenticator), penyemak imbas ditutup dan masa tamat pengeluar menjadi status penamat yang berbeza. Percubaan semula mencipta percubaan dan challenge baharu. Masa tamat gerbang (gateway timeout) tidak boleh memainkan semula challenge lama: tanya kunci ketakberubahan terlebih dahulu, kemudian tentukan sama ada keputusannya masih belum selesai, berjaya atau memerlukan semakan manusia. Peristiwa antara perkhidmatan pembayaran, pedagang dan pengeluar membawa maklumat versi supaya peristiwa lama tidak boleh menulis ganti keadaan yang lebih baharu.

Pantau risiko dan kekalkan bukti

Segmenkan ketersediaan SPC, pembatalan pengguna, kegagalan assertion, callback pendua, kadar sandaran, kependaman caj dan pertikaian mengikut penyemak imbas, gabungan asal, kaedah pengesahan dan tahap risiko. Kekalkan cincangan digest pesanan, pengecam kelayakan yang tidak boleh diterbalikkan, ID percubaan, versi dasar dan keputusan pengesahan; jangan log data biometrik atau kunci peribadi. Hadkan kadar (rate-limit) anomali silang asal, percubaan kelayakan berulang dan perubahan jumlah yang mendadak.

Peringkatkan, uji dan undurkan

Mulakan dengan pedagang dalaman dan jumlah berisiko rendah, kemudian kembangkan mengikut penyemak imbas, asal dan rantau. Uji iframe silang asal, ketiadaan Permission Policy, penolakan pengguna, kelayakan hilang, ulangan challenge, pengeditan pesanan, callback pendua, masa tamat gerbang dan perlumbaan bayaran balik. Semasa pengunduran, hentikan penciptaan percubaan SPC baharu, biarkan transaksi dalam proses selesai melalui mesin keadaan (state machine), dan halakan transaksi baharu ke laluan legasi. Simpan assertion dan bukti pesanan untuk analisis pertikaian.

Contoh jawapan berkualiti tinggi

“SPC menjana bukti pengesahan; ia bukan penjelasan dana. Saya akan mengikat payment_attempt yang tidak boleh diubah pada versi pesanan, jumlah, penerima bayaran, challenge, dasar asal dan kunci ketakberubahan. Kelayakan pembayaran diasingkan daripada kelayakan log masuk, dan Permission Policy mengehadkan pemanggil silang asal. Selepas pengesahan, pelayan mengesahkan assertion WebAuthn dan digest pesanan, kemudian memajukan keadaan caj secara bersyarat. Ketidaktersediaan, pembatalan dan masa tamat menggunakan sandaran yang jelas, manakala callback pendua mengembalikan hasil yang telah ditetapkan. Semasa pelancaran berperingkat, saya akan memantau kegagalan assertion, sandaran, pertikaian dan anomali silang asal; pengunduran menghentikan percubaan SPC baharu dan mengekalkan bukti dalam proses.”

Kesilapan lazim

• Menganggap available sebagai kelayakan → pengguna mungkin masih belum mempunyai kelayakan yang boleh digunakan → asingkan pengesanan keupayaan daripada ketersediaan kelayakan.
• Membiarkan penyemak imbas memilih jumlah → pengesahan dan caj boleh menyimpang → ikat digest pesanan dan challenge pelayan.
• Menganggap seruan silang asal sebagai log masuk biasa → kelayakan log masuk atau data sambungan mungkin bocor → asingkan kelayakan pembayaran dan hadkan pemanggil.
• Mengubah kegagalan SPC kepada kejayaan pembayaran → pengesahan dikelirukan dengan penjelasan dana → modelkan pengesahan, caj dan penjelasan secara berasingan.
• Menggunakan semula challenge semasa percubaan semula → assertion boleh dimainkan semula → gunakan sekali dan keluarkan challenge baharu bagi setiap percubaan.
• Memadamkan rekod semasa pengunduran → pertikaian dan caj pendua menjadi mustahil untuk dikesan → bekukan permintaan baharu dan kekalkan bukti dalam proses.

Soalan susulan dan jawapan

Soalan susulan 1: Mengapa tidak menggunakan semula passkey log masuk?

Pembayaran dan log masuk mempunyai ancaman, asal dan tujuan kebenaran yang berbeza. Spesifikasi ini membenarkan kelayakan WebAuthn dalam SPC, tetapi subdomain pembayaran dan kelayakan berasingan mengurangkan permukaan serangan log masuk. Jika kelayakan dikongsi, tujuan assertion, Relying Party dan semakan pelayan mestilah jelas.

Soalan susulan 2: Bagaimanakah anda menghalang pedagang daripada menunjukkan satu dolar tetapi mengenakan caj seratus dolar?

UI pedagang bukan pihak berkuasa penentu jumlah. Perkhidmatan pembayaran mencipta digest daripada versi pesanan, aliran pengesahan membawa digest tersebut, dan perkhidmatan caj hanya menerima percubaan yang sama. Sebarang perubahan medan akan mencipta percubaan baharu.

Soalan susulan 3: Apakah risiko mengembalikan sebab ketersediaan yang terperinci?

Sebab yang terperinci boleh menjadi cap jari peranti atau konfigurasi, jadi ejen pengguna mungkin mengembalikan unavailable-unknown-reason. Perniagaan menggunakan keputusan tersebut untuk pemilihan pengalaman sahaja, bukan sebagai profil pengguna, skor risiko atau fakta kebenaran.

Soalan susulan 4: Bolehkah perkhidmatan pembayaran memanggil SPC sekali lagi selepas masa tamat?

Mula-mula, tanya keadaan caj dan pengesahan menggunakan kunci ketakberubahan. Jika percubaan lama belum selesai, jangan mainkannya semula secara membuta tuli. Batalkan atau tamatkan tempohnya secara eksplisit, kemudian cipta percubaan baharu dengan challenge dan digest pesanan yang baharu.