Skip to content

Secure Payment Confirmation

Jump to bottom
ianbjacobs edited this page Oct 4, 2022 · 19 revisions

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 on the current device (e.g., which might fail if the user's mobile phone is turned off or otherwise not available).
  • Intends to provide a consistent user experience across all a large variety of SCA flows (including merchant-initiated and bank-initiated).
  • 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.
  • Can streamline registration of FIDO credentials in a cross-origin iframe (unavailable in vanilla Web Authentication).
  • 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.
  • Is designed to provide a consistent user experience across a variety of payment methods (e.g., cards, open banking, etc.).

FAQ

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:

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 / app, either SPC or FIDO could be used (assuming they are supported).
  • If the user is on the merchant site and the bank opens a popup from a cross-origin iframe, either SPC or FIDO could be used.

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.

Can you achieve SPC 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.

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.

What happens when SPC authentication fails?

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

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.

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:

To Be Discussed

  • Support for low friction (e.g., multifactor) and zero friction flows with the same API, where the preferred friction would be chosen by the RP with input from the merchant. However, user preference (e.g., for explicit interaction) would override other preferences.
  • Instrument storage; for more information see payments architecture notes

Home

How we work

Mailing list archives

Meetings

Issues

Tests

Adoption

Previous Topics

Clone this wiki locally