Passkeys for Payments: Secure Payment Confirmation, 3DS and SCA With WebAuthn

A passkey proves that the cardholder is present, but on its own it does not prove which payment they agreed to, and that gap is exactly what payment regulation and payment fraud are about. Secure Payment Confirmation (SPC) is the W3C web API that closes it: the browser shows the payee, amount and payment instrument in its own dialog, and the passkey signs those details. This guide goes deeper than the overview pages on the mechanics an issuer, payment service provider (PSP) or merchant must get right: registering payment passkeys, calling SPC from a merchant page, verifying the signed transaction data, mapping the design to strong customer authentication (SCA) and dynamic linking under the PSD2 regulatory technical standards, and where SPC sits inside EMV 3-D Secure. It is for payments architects, issuer authentication teams and fraud engineers. Transaction signing in general is covered in the Transaction Authorisation Guide, and the 3DS protocol in the EMV 3-D Secure Guide.

Source note: the PSD2 RTS and W3C specification points on this page are paraphrased from Commission Delegated Regulation (EU) 2018/389 on EUR-Lex and the W3C Secure Payment Confirmation draft, checked on 12 November 2026. Confirm against the official text before relying on it.

Key takeaways

• SPC binds the passkey to the transaction. The authentication client data has type payment.get and carries the payee, total and instrument that the browser displayed, all covered by the passkey signature.
• Registration is stricter than an ordinary passkey. The payment extension with isPayment: true requires a platform authenticator, a discoverable credential and userVerification: "required".
• A merchant can run the ceremony with the bank's passkey. Credentials registered as payment credentials are third-party enabled, so the merchant or PSP page calls SPC and the relying party verifies the result.
• The bank must check what was signed. The merchant supplies the displayed amount and payee, so the relying party verifies total, instrument, payeeName or payeeOrigin against its own record of the transaction.
• SCA evidence comes from the server checks, not the API. Article 5 of the PSD2 RTS requires the code to be specific to amount and payee and invalidated by any change; SPC supplies the signed data, and the PSP's verification makes it compliant.

Where SPC fits among payment authentication patterns

Passkeys appear in payments in several ways. They differ in who holds the credential, what is signed and who verifies it.

The difference that matters is that with SPC the browser, not the merchant page, draws the confirmation and the client data records what it drew. A malicious script on the merchant page can still try to change the amount sent to the bank, but the signed data will then not match the bank's record.

Specification status and building blocks

As checked on 12 November 2026, Secure Payment Confirmation is a W3C Candidate Recommendation Draft dated 13 October 2026 from the Web Payments Working Group. Draft details can change, so pin implementations to tested browser behaviour and re-check the specification before relying on newer members such as browser bound keys. SPC builds on Web Authentication Level 3, a W3C Recommendation dated 25 August 2026, and on the Payment Request API.

Registering payment passkeys

The relying party (normally the issuer or the PSP acting for it) registers the credential with navigator.credentials.create() and the payment extension. The specification requires authenticatorAttachment: "platform", residentKey of required or preferred, and userVerification: "required"; other values throw a TypeError.

1. Choose the moment. Offer registration after a strong authentication the bank already trusts: a completed 3DS challenge, a signed-in banking session that met SCA, or enrolment in the banking app.
2. Decide where registration runs. On the bank's own origin, or cross-origin inside an iframe on a merchant or PSP page. The specification lets the payment permissions policy act as an alternative create policy for public-key credentials, so the embedding page must grant payment to the frame. The specification notes that this compatibility route may be deprecated later.
3. Bind the credential to the instrument. Store the credential ID against the card or account and the cardholder. The specification's privacy section warns that reusing one credential across instruments lets merchants link them; consider a credential per instrument.
4. Record assurance context. Store how the user was authenticated before registration, the device platform and, where you require it, attestation results, so later risk decisions and audits can rely on it.

Separate payment credentials from login credentials where possible. The specification's security considerations describe a login attack in which an SPC assertion is replayed at a login endpoint, and suggest separating payment and login credentials, for example with a payment subdomain as the RP ID, alongside strict checks of type, challenge and origin.

Running the payment ceremony

1. Obtain credentials and a challenge. In a 3DS flow the issuer's access control server returns the eligible credential IDs and a transaction-specific challenge; in a delegated or PSP-run flow the PSP obtains them from the relying party.
2. Feature detect. Call securePaymentConfirmationAvailability() and fall back to the existing challenge (one-time code, banking app approval) if SPC is unavailable.
3. Build the request. new PaymentRequest([{ supportedMethods: "secure-payment-confirmation", data }], details), where data carries the credential IDs, challenge, rpId, instrument display name and icon, and payeeName or payeeOrigin (which must be https), and details carries the total.
4. Show from a user gesture. The specification lets user agents reject show() with a SecurityError without transient activation; trigger it from the pay button click.
5. Handle outcomes. No matching credential and user cancellation both return NotAllowedError, by design, so the caller cannot probe which credentials exist. If showOptOut is set, an OptOutError means the user asked the relying party to forget them; route it to the bank, not the merchant's error page.
6. Return the assertion to the relying party. The merchant or PSP passes it through the 3DS or PSP channel for verification.

Note that a third-party ceremony throws if extensions is non-empty; the specification disallows WebAuthn extensions in cross-origin ceremonies to protect data such as largeBlob contents.

Verifying the assertion

The specification tells the relying party to run the normal WebAuthn assertion verification steps with SPC-specific changes. Treat each as mandatory.

The specification is explicit that the merchant supplies the amount, instrument name and icon and payee details, and could supply incorrect ones; the bank's comparison against its own transaction record is what makes the signature meaningful.

Mapping SPC to SCA and dynamic linking

For payments in scope of PSD2, Commission Delegated Regulation (EU) 2018/389, the regulatory technical standards on strong customer authentication, sets the technical rules. The relevant articles map onto an SPC design as follows.

Whether a particular passkey configuration counts as two independent SCA elements is a judgement for the PSP and its competent authority, and synced passkeys raise the Article 7 replication question directly. Document the analysis, keep evidence of user verification per transaction, and confirm the current position with your regulator. Successor EU payment legislation has been under negotiation; check its current status on EUR-Lex before planning against it. The UK, US and other markets have their own rules and card scheme requirements.

SPC inside EMV 3-D Secure

For card payments, SPC most often runs as an authentication method inside a 3DS flow rather than as a separate integration: the issuer decides whether to offer it, the merchant or 3DS server invokes it with the credential list the issuer returns, and the result goes back to the issuer through 3DS messaging. The protocol versions, message fields and transaction status values are set out in the EMV 3-D Secure Guide. Practical points for the passkey side:

• Issuers: own registration and verification; keep the credential-to-card binding and SCA evidence in the access control server's records.
• Merchants and PSPs: render nothing of your own for the confirmation; pass the issuer's credential list and challenge unchanged, and grant payment to any iframe that registers or authenticates.
• Delegated authentication: where a scheme or issuer lets a PSP or wallet act as relying party, the PSP takes on the verification table above and the evidence duties that go with it.

Decision guidance

• Issuers with high challenge volumes: SPC replaces one-time passcodes with a phishing-resistant, transaction-bound signature at checkout; start with cardholders who already use passkeys in the banking app.
• Banks with a strong mobile app: in-app signing or decoupled approval may cover most payments; add SPC for browser checkouts on desktop. On the bank's own site, a passkey ceremony with mediation: "required", which MDN suggests for sensitive operations such as reauthenticating before a payment, plus server-rendered transaction details, is the simpler route.
• Merchants: rely on your PSP and the issuer's 3DS flow; do not build your own payment passkey relying party unless you are the account holder's bank or a regulated PSP doing delegated authentication.
• Small PSPs: use a certified 3DS server or authentication provider that supports SPC rather than implementing verification yourself.
• Agent-initiated payments: an AI agent should not hold or trigger a user's payment passkey; human confirmation of the amount and payee is the point of the control. See the Agent Payments Protocols Guide.

Detection and measurement

• Log per transaction: credential ID, UV flag, origin and topOrigin, payee and total as signed, verification result and which check failed.
• Mismatch rate: assertions where signed total, instrument or payee differ from the bank's record; any rise suggests page tampering or integration faults.
• SPC coverage: share of challenged transactions completed with SPC rather than a one-time code.
• Abandonment and fallback: SPC prompts that ended in cancellation or fallback, by browser and platform.
• Fraud outcome: fraud reports on SPC-authenticated transactions against other methods, watched together with authorised push payment scams, which SCA does not stop. See the Authorised Push Payment (APP) Fraud Guide.

Common failure patterns

• Verifying the signature but not the data: accepting a valid assertion without comparing total and payee to the transaction record turns SPC back into a login.
• Shared login and payment credentials: the same credential and RP ID for sign-in and payments, opening the login replay route the specification describes.
• Weak registration: registering payment passkeys after only a password or SMS step, so the passkey inherits weak assurance.
• Treating SPC as a fraud cure: a deceived customer will approve a scammer's payee in the browser dialog; social engineering controls still matter.
• Merchant-side error handling: showing an OptOutError or NotAllowedError as a payment failure instead of falling back to the issuer's other method.

Framework mapping

Practitioner checklist

• Register payment passkeys with the payment extension only after an authentication that met SCA.
• Use a dedicated payment RP ID and keep payment credentials separate from login credentials.
• Issue a single-use, transaction-specific challenge and expire it with the transaction.
• Verify type, challenge, origin, topOrigin, rpId, UV and signature on every assertion.
• Compare signed total, instrument, payeeName and payeeOrigin to the bank's transaction record and reject mismatches.
• Trigger show() from the pay button and fall back cleanly to the issuer's existing challenge.
• Document how the design meets RTS Articles 4, 5 and 7 to 9, including your position on synced passkeys.
• Monitor mismatch, fallback and fraud rates per browser and platform.

Standards and references

• W3C: Secure Payment Confirmation
• W3C: Web Authentication Level 3
• EUR-Lex: Commission Delegated Regulation (EU) 2018/389 on strong customer authentication
• MDN: CredentialsContainer get() method
• OWASP: Application Security Verification Standard 5.0
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Transaction Authorisation Guide · EMV 3-D Secure Guide · Passwordless and Passkeys Guide · Passkey Autofill and Conditional UI. This guide summarises the PSD2 regulatory technical standards and is not legal advice.