This guide was written by members of the Google Chrome team, to support web developers experimenting with Secure Payment Confirmation (SPC) as part of the SPC v0.2 Origin Trial. It gives an overview of what SPC is, explains how to experiment with it on your website, and provides an FAQ.
Secure Payment Confirmation is a standard-track web API proposal that enables FIDO-based authentication for web payments.
Users enroll a payment instrument using on-device biometrics, creating a FIDO credential that can be held by the relying party (e.g. a PSP or issuer). This credential can be used in later transactions to authenticate the user and produce a signed challenge that includes the transaction value, which can be verified by the PSP/issuer.
Stripe and Chrome collaborated on a first Origin Trial in Q4, 2020 which showed that SPC provided a higher conversion rate and faster authentication time than 3DS2 step-up flows.
The second version of the Origin Trial (v0.2) improves on the first by allowing enrollment from cross-origin iframes and a new associated browser dialog. Other than this permission change, the API shape is unchanged.
Secure Payment Confirmation v0.2 is available for developer testing in Chrome Beta, and will soon be available in stable channels as an Origin Trial.
This section explains how to enable Secure Payment Confirmation locally on your device for testing, and how to enable it for users of your site via the v0.2 Origin Trial.
Quick links to code snippets:
Currently, SPC is available on:
- MacOS with the secure enclave feature (e.g., 2016 MacBookPro or later).
- Windows 10 with Windows Hello support (e.g., version 1607 or later).
Note that the feature is designed for use with biometric authenticators such as Touch ID on Mac, but more generally it is compatible with user-verifying platform authenticators that may use a device PIN, for example.
The v0.2 version of SPC is available from Chrome version 91 onwards (currently in Beta, releasing to Stable in late May 2021).
You can test out the feature by registering your site in the origin trial (see below), or by enabling the flag chrome://flags#enable-experimental-web-platform-features. You can verify that you have the right version of Chrome by trying out this test page.
Enabling SPC via Origin Trial for your website will make it available to users of Google Chrome, without them having to set any flag locally on their client.
Origin Trials are origin-bound, time-limited releases of experimental features in Chrome, used to test whether upcoming web APIs are useful and to let web developers gather real-world data and provide feedback. Production systems should not rely on a feature in Origin Trial existing for any given user, or continuing to exist in the future.
To enroll your website in the SPC v0.2 Origin Trial, register your origin for the trial here. The Origin Trial Developer Guide explains how to enable the feature on your website once registered.
SPC is similar in concept to WebAuthn, but has two key differences:
- A
PaymentCredentialcan be created inside a cross-origin iframe, which is not allowed in WebAuthn. This supports user enrollment during the common payments flow of abank.comembedded-iframe inside a top-levelmerchant.comorpsp.comwebsite. - A
PaymentCredentialcan be authenticated against from a 3p origin, e.g.merchant.comcan exercise a credential whose relying party isbank.com. This allows merchants or PSPs to to use SPC authentication without the friction of redirecting to an issuer bank website.
SPC also provides a standardized format for including transaction details (amount and currency) inside the signed assertation. This is possible to do with WebAuthn today, but SPC brings a convenient and standardized way to do it.
This is a good question, and one we are still exploring and would love input on!
Having the credential be per-instrument was a convenient way to ensure that the user is presented with the correct instrument details during authentication. Relaxing this requirement would make SPC more powerful, and individual Relying Parties (RPs) could still opt to make credentials on a per-instrument basis - but UXR explorations are needed to ensure the user understands the situation.
What are the maximum dimensions of the payment instrument icon when registering a PaymentCredential?
Chrome's current implementation expects an icon that is 32px wide by 20px high.
Please contact payments-dev@chromium.org.