More information about Secure Payment Confirmation. The current list of benefits is inspired by and borrows from that document.

Benefits

User Benefits

SPC provides a streamlined strong customer authentication experience on the Web that:

• Can be used to avoid the disruption of leaving the merchant context (e.g., to involve the bank via an iframe, redirect, or native app switch).
• Can be used to avoid the disruption of leaving the device context (e.g., to retrieve phone for SMS OTP or native bank app, which might fail if the phone is turned off or otherwise not readily available).
• Intends to provide a consistent user experience across all a large variety of SCA flows (including merchant-initiated and bank-initiated) and payment methods (e.g., cards, open banking). This is expected to increase user confidence.
• Provides greater security to the user through cryptographic evidence to banks or other parties that the user consented to the amount of a transaction. Such assurances are especially valuable in some regulatory contexts, such as satisfying the "dynamic linking" requirement of PSD2.
• Benefits in other ways from the security and privacy properties of FIDO authentication, now ubiquitously available through platform authenticators on desktops and mobile devices through all modern browsers.

FAQ

Q. Where Strong Customer Authentication is required by regulation or sought by merchants, what are the advantages of FIDO or SPC over OTP?

See FIDO white papers:

• FIDO for SCA Delegation to Merchants or Wallet Providers
• PSD2 Support: Why Change to FIDO
• Stripe experiment that reported 8% increase in conversions using SPC over OTP
• To do: include pointers to EBA statements about use of SMS OTP.

Q. How do user experience benefits of SPC compared to those of WebAuthn?

In a issuing bank-initiated flow where the bank is the RP:

• If the user is on the bank site in a first party context, either SPC or FIDO could be used.
• If the user is in a bank app in a first party context, FIDO could be used. Note: Discussions are ongoing about the use of SPC within a native mobile app.
• If the user is on the merchant site, either SPC or FIDO (Web Authentication Level 2 or greater) could be used by the issuing bank from a cross-origin iframe. Note: EMV® 3-D Secure does not permit the use of popups and the 3-D Secure iframe is therefore sandboxed to prevent them.

In either case, SPC user experience benefits include (1) more security about the origin requesting the authentication, and (2) a consistent user experience across the Web.

In a merchant initiated flows where the merchant (or PSP) is RP:

• If the PSP opens a popup from a cross-origin iframe, either SPC or FIDO could be used.

Here the user experience benefits with SPC are the same as for bank-initiated flows.

In a merchant initiated flow where the issuing bank is RP:

• This is only possible with SPC because SPC allows other parties than the RP to initiate authentication. The authentication results are returned to the issuing bank for validation (using other means such as 3DS). This cannot be achieved with Web Authentication.

The user experience benefits include (1) the user remains close to the merchant experience instead of being redirected to the issuing bank site or being presented with issuing bank UX (2) consistent user experience with other flows described above.

Q. Could SPC capabilities be achieved without a new API, in JavaScript alone?

No. The SPC assertion includes a signature over the transaction details. With SPC, native browser UX displays information to the user then passes it to the platform for the user to sign via authentication. With JavaScript it is possible to display transaction details but pass different data to the authenticator for the user to sign. Thus, there are much weaker assurances that the user consented to the transaction details, and therefore a less secure user experience.

Q. Does the bank have to trust the merchant?

No. SPC is integrated into 3-D Secure and potentially other protocols. Together, these protocols enable the issuing bank (as Relying Party) to provide information for the merchant who can initiate the authentication ceremony (without a redirect), then validate the assertion and only approve the authentication if the results meet their expectations.

Q. What happens when SPC authentication fails?

The caller receives an error message and can initiate a fallback authentication experience (e.g., OTP).

Q. What will the user experience be if authentication succeeds but authorization then fails?

It is first worth noting that authorization rates are expected to increase when SCA succeeds (cf, for example, Microsoft report). It is also worth noting based on discussions with card network representatives, that it is very rare that merchants modify transaction amounts between authentication and authorization; there are many disincentives to doing so.

Depending on the transaction type and merchant preference, authorization may occur at any time, not merely immediately following authentication.

In the case where authorization fails immediately following a successful SPC authentication, the caller may display an error message to the user (outside of SPC). This allows the PSP or merchant to provide suggestions for alternatives depending on context.

In the case where authorization fails at some later date, we expect the user will no longer be in the ecommerce context and thus the merchant and/or payment service provider will contact the user through email or other means. We would expect this user experience for any transaction type or payment method where authorization can occur at a later time.

Q. Can login credentials be used for payments as well?

Yes, if the Relying Party so wishes.

Q. Can existing credentials (not created for SPC) be used with SPC?

Yes, but only by the Relying Party.

Payments ecosystem

• Introduce a new FIDO-based authentication value (AV) format, allowing AVs to be generated in secure hardware on the user's device and routed directly on the authorization network.

  • HOW: Sign transaction data using FIDO authenticator.

• Improve user privacy while still providing tools for payment industry risk assessment.

  • HOW: Cryptographically strong possession signal sent with user consent.

• Aid in satisfying regulatory requirements related to transaction confirmation (e.g., PSD2 dynamic linking).

  • HOW: Transaction confirmation dialog / signing of data.

Merchants

• Provide a reliable, reliably low-friction payment authentication mechanism.

  • Browser-native authentication optimized for payment (expected to improve on other authentication approaches).
  • Remove the need to redirect the user to another site to authenticate.
  • Remove need for PSP to open user-facing UX to authenticate the user.
    • HOW: Transaction confirmation dialog (built into browser)

• Improve security boundary between the merchant and issuing bank, avoiding the need to poke holes in Content Security Policy.

  • HOW: PSP can initiate authentication without code injection; issuer still validates results.

When used with 3DS specifically (or similar flows):

• Reduce latency and increase availability compared to vanilla 3DS.
• Can be used to improve conversion compared to vanilla 3D Secure.
  • HOW: Fewer user gestures required; harmonized experience across sites.

Benefits of FIDO

Accelerate adoption of FIDO (Web Authentication) to enable two-factor, biometric-enabled, hardware-backed, phishing-resistant checkout. For more on the usability, security, and privacy benefits of FIDO authentication to Web payments, see:

• What is FIDO?
• FIDO privacy principles
• FIDO and GDPR