Is an issuer hosted payment handler necessary for secure-payment-confirmation flow?

[w3c]

Is an issuer hosted payment handler necessary for secure-payment-confirmation flow?

[adrianhopebailie]

The fallback URL is very specific to 3DS but is probably not a bad thing to standardise for any payment method that wants to have a fallback authentication flow.

As with the challenge and credential ids, I think we can support both options. Maybe we need a way to emit the PaymentRequestEvent to the merchant (on the PaymentRequest) if the user selects a payment instrument with no payment handler linked to it. Then the merchant can call e.openWindow to render the modal the same way the PH would.

Side note: Alternatively, we COULD try to enumerate the alternative authN mechanisms and provide for these directly through the browser. A quick win would be simply prompting for a code (either SMS/Email OTP or TOTP) although this may be getting a little too specific.

[btidor-stripe]

One quick clarification: the fallback URL is meant to support fallback to an existing authentication protocol, which could be 3D Secure, Paypal, iDEAL, Alipay, or really anything. There are a lot of redirect-based payment methods out there and they should be pretty straightforward to integrate with Secure Payment Confirmation, if that's of interest.

I'd like to explore Option 1 a little further: considering that issuers haven't been broadly interested in implementing payment handlers so far, I think a simpler approach could get more traction. A lot the value of Secure Payment Confirmation is that the issuer-side changes are extremely minimal: our pitch is that the complex functions are offloaded to the browser (issuers don't have to write a service worker!); they just need to accept the attestation in a standard web format (so the browser doesn't have to implement a different protocol for every payment system).

If we think of Secure Payment Confirmation as just a special kind of payment handler, I think the open questions are tractable. I don't want to get in the way of the pilot though, and we can definitely work through this in parallel:

• The browser controls the lifecycle of the Secure Modal Window. The handoff points are:

  • Opening the window: the flow is initiated via a standard PaymentRequest.show() call. The fallback URL is loaded automatically by the Secure Payment Confirmation handler if the biometric flow is unavailable, in the same way any payment handler can trigger a full-page redirect to an external origin within the payment handler modal.

  • Closing the window: the issuer needs some way to signal when the fallback flow is complete. All of the redirect-based payment methods I'm aware of signal completion by redirecting to a specific URL provided by the merchant (the "return URL"). The easiest solution might be for the Secure Payment Confirmation flow to define a special return URL (e.g. chrome://spc-return), but I'm not sure if there's a more web-native way, like defining a message that the issuer should send via Window.parent.postMessage(). In any case, it would be easy for the merchant to host a shim page at the return URL that triggers the completion message if issuers don't support the native mechanism.

  • The merchant can control the Secure Modal Window with the methods already defined by the Payment Request API: PaymentRequest.abort(), etc.

  • Existing redirect-based payment methods take two broad approaches to return data: either the success notification is delivered out of band via a webhook from the payment system to the merchant (most common, e.g. Paypal IPNs), or the transaction data are signed and POSTed through the user's browser to the merchant (less common). It may not be necessary for the issuer content in the Secure Modal Window to return a response to the merchant, other than an empty completion event ("the fallback flow completed, please check your backend for details"). But for a more full-featured API, accepting an opaque data object and passing it back to the merchant would be a nice addition, possibly via a similar Window.parent.postMessage() (only an example -- I'm definitely not an expert here).

• The privacy and security threat model of the Secure Modal Window should be a restricted subset of the payment handler threat model, because an issuer or merchant or anyone else can write a payment handler using the current APIs that simply redirects to the fallback URL. This came up in the earlier discussions of how the current 3D Secure spec could be shimmed into a payment handler: shouldn't it already be possible to use the payment handler as a kind of Secure Modal Window?

  I seem to remember there being some privacy concerns around how payment handlers require having a long-lived service worker that can perform arbitrary actions in the background; this proposal sidesteps that issue by having the payment handler be provided by the browser. But aside from that, I believe the concerns are the same, and are addressed through the same mechanisms (e.g. we propose that from a privacy perspective, having the window be first-party is acceptable because the user explicitly confirms every time a Secure Modal Window is opened).

Thanks!

[adrianhopebailie]

One quick clarification: the fallback URL is meant to support fallback to an existing authentication protocol, which could be 3D Secure, Paypal, iDEAL, Alipay, or really anything.

👍

considering that issuers haven't been broadly interested in implementing payment handlers so far

I don't agree with this. I think issuers have been largely removed from the conversation until recently and we have seen very compelling examples of what's possible using payment handlers from ACS vendors (i.e. the folks who would actually have to run this stuff)

A lot the value of Secure Payment Confirmation is that the issuer-side changes are extremely minimal

Actually I don't think this is true. If we want issuers to enroll credentials then we want them to run Javascript in the user's browser in which case installing a Service Worker is exactly the same level of complexity. We gain nothing by avoid Service Workers.

Finally, anything we design that involves a back-and-forth conversation between the acquirer domain and the browser is going to be a non-starter from a privacy perspective.

[ianbjacobs]

At this point in SPC's design, which is expected to support enrollment from an iframe in 3p context, a payment handler is not expected to be required.