RFP: Payment Handler API

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Payment Handler API
• Specification or proposal URL: https://w3c.github.io/payment-handler/

Other information

The Payment Handler API allows a web application to register itself as capable of handling a "payment request". That is, it claims to either be able to settle a monetary transaction or is potentially capable of supplying a requesting website with payment instrument (e.g., a credit card) on behalf of the end-user.

For example, wallet.com could register itself as being able to handle requests for credit card information on behalf of the user. Then merchant.com can say: "I support 'wallet.com', if you'd like to pay with that". Then requests for payment are routed to wallet.com (via a service worker), and wallet.com responds with either a proof-of-settlement token, or possibly a payment instrument like a credit card number.

This allows Payment Handlers to work along side the browser's built in wallet: giving the user a choice of either picking a credit card form the browser's wallet, or letting wallet.com provide a token or credit card number (and possibly other things... that's still up for discussion).

This specification already has some Mozilla support (e.g., @adamroach and I have contributed to it) - but wanted to bring it to people's attention while it's still early.

[marcoscaceres]

@dbaron, as @stpeter and I are both going to be editing this spec, could you please mark this as participating?

[dbaron]

That seems reasonable, but I think it's also useful to document here why the spec is important. In other words: how does it fit into the plan for payments, what benefits does it have, etc.?

(For example, one of the things I'd like to see from the Web Payments work is the ability for trusted browser UI to tell the user that they're paying only amount X, which requires that the user or browser not give the site a credential (e.g., a credit card number) that could be used to get more money than that). It's not clear to me whether this API is part of the path to that.)

[marcoscaceres]

That seems reasonable, but I think it's also useful to document here why the spec is important. In other words: how does it fit into the plan for payments, what benefits does it have, etc.?

Right now, the Payment Request API only allows either the browser or native applications to handle request for payment. For example, the browser may present a UI to provide a website with credit card information. Unfortunately, the Payment Request API is only empowering a tiny number of proprietary payment methods: "Apple/Microsoft/Google/Samsung Pay". This greatly centralizes payment solutions to a couple of players, locking out everyone else.

Websites should also be able to handle request for payments. So, "bank.com" (or more realistically, sites like PayPal, Ripple, etc.) should also be able to handle requests for payment. This is where Payment Handler comes in.

The benefit to users being: web apps could handle request for payments without users needing to install a native app, while also opening up the payment ecosystem to everyone (and enabling alternative currency solutions too!). The browser should mediate the interaction between merchants and these web apps, providing a consistent user experience for performing a payment.

(For example, one of the things I'd like to see from the Web Payments work is the ability for trusted browser UI to tell the user that they're paying only amount X, which requires that the user or browser not give the site a credential (e.g., a credit card number) that could be used to get more money than that). It's not clear to me whether this API is part of the path to that.)

Definitely on that path: it's possible for a payment handler to generate a one-time single-use credit card number, derived from, say, the conversion of a crypto-currency or any other type of currency. How the payment handler does that is implementation specific (i.e., the handler would need to have some arrangement to get a virtual card number from one of the credit card networks) - but the API doesn't care where the credit card number comes from, it just passes what is given back to the merchant for processing.

[stpeter]

@marcoscaceres is spot on. One further aspect is that "user identification & verification" (ID&V) techniques such as two-factor auth and challenge-response will become more prevalent to help prevent fraud for high-risk transactions, and we want to ensure that a trusted application (e.g., a payment handler that the user has downloaded from the card issuer website) manages these interactions - not some random merchant website.

[marcoscaceres]

Following up with an update. Chrome folks are experimenting with including actual web content into the payment sheet:

This raises obvious concerns (noting that the payment sheet is presented as if it's browser UI/chrome):

• Will user's understand that this is also web content? Should they care?
• Will users be able to make sense of effectively two URL bars?
• What APIs can this content access? (e.g., camera?) Can this realistically be limited (e.g., via feature policy or some iframe-API-restricting magic)?
• If payment sheets are different sizes across UAs, can a consistent user experience be created? Or do we lose all the benefits we got from Payment Request (consistent and accessible payment sheet every time, for every user).
• This starts to look like window.open() again.

We (Mozilla folks participating) were hoping that web content would NOT be shown in the payment sheet. Instead, the payment sheet's UI elements would be controlled by events routed through a service worker.

Thoughts and/or concerns?

[marcoscaceres]

Just noting that Chrome has an intent to ship for Payment Handler. I've left some feedback there.

[ekr]

Yeah, I agree with you here that this is un-good.

[stpeter]

This is indeed very un-good. But Mozilla wouldn't need to go down this misguided path, would we? I'm seeing bad implementation decisions here on Google's part, not necessarily a problem with the spec (which admittedly has a lot of holes) or the underlying concept of invoking a payment handler.

[marcoscaceres]

Depends on what websites using the API expect: if they build their Payment Handler with the idea that they will have control over the payment sheet’s UI using web content, then we might be stuck.

I think websites will find having control over their UIs very appealing, which put us in a difficult position.

[stpeter]

I see your point. The potential for deliberate abuse, inadvertent misuse, or at the very least user confusion is huge here. I see nothing good coming out of allowing garden-variety web content into the protected area of the browser chrome!

[martinthomson]

@marcoscaceres shared this demo: https://www.w3.org/2018/06/worldline.html which does a great job of showing the limitations of the Chrome UX. I completely missed the transition from vendor site to the framed context of the payment provider. While I think that payments is very important, this UX question needs to be resolved.

[adrianhopebailie]

@martinthomson @stpeter can you expand on what it is you think is wrong with the current UX. Is there anything in the spec that prevents a Mozilla implementation doing the UX differently?

My understanding from discussions with members of the Chrome team is that the concept of "secure browser UI" vs "insecure website UI" is a misnomer. Users simply don't recognise the difference.

If the only way to get around this is to load the payment handler in a new tab then I'd suggest Mozilla simply implements the spec that way. As with all things related to security it's going to be a balance of more security vs better UX and the spec to my knowledge doesn't force implementors in any specific direction.

@dbaron asked:

it's also useful to document here why the spec is important. In other words: how does it fit into the plan for payments

The reality is that without payment handlers, the Payment Request API is just a pretty new auto-complete with very limited scope. In order to support new payment methods (i.e. offer something more secure than just exchanging clear card numbers) browsers MUST either:

• implement all the necessary processing logic themselves for every new payment method, or
• implement a mechanism for third-parties to provide that logic

The architecture we have based all of the payments work on assumed browsers would prefer the latter and that Payment Handlers would be the way this is done.

We are getting into a stalemate within the WG now because there is a desire to introduce more secure payment methods such as tokens but can't make forward progress while it's unclear if (not even how) browsers will implement Payment Handlers.

Note, Microsoft have recently updated this feature to "Under Consideration" for Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/paymenthandlerapi/

Note also that Google is dog-fooding this design with it's own payment method. Google Pay is implemented as a web-based payment handler using the Chrome implementation as it exists today.

TL;DR: It is getting quite urgent that Mozilla decide how you plan to proceed on this.

[marcoscaceres]

Just dropping this link here, which discusses some security aspects of payment handlers as provided by folks at the w3c and Google:
https://www.w3.org/blog/wpwg/2018/11/20/payment-handler-security/

[dbaron]

I'm really not sure how to proceed here. I agree this is an important part of the payments architecture (although I'd also be open to a standard for tokenized payments in the browser, avoiding the requirement for these custom handlers to get there). But at the same time I'm concerned about the UI aspects here. I think we could do a good bit better than what's in the above mockups, but I'm not sure that it would be good.

(I'm also curious how this relates to the Modal Window proposal and whether that has a path forward on fixing these issues.)

I think maybe the answer here is marking this as worth prototyping but with a written statement that is something like:

We believe this is worth prototyping because it is an important part of making an open and secure payments ecosystem for the web. At the same time, we're quite concerned about the tradeoffs being made between extensibility and the user interface that is best for users' security, and we might take a substantially different position from the current direction of that work, such as by limiting the ability for payment handlers to show UI when invoked from another page, or even by standardizing a set of handlers instead of having an extensible handler mechanism.

Thoughts?

[marcoscaceres]

I'd be ok with the text you propose above and revising if/when we do some prototyping.

[annevk]

Given that other vendors sometimes use worth prototyping to mean "worth shipping", I'd be rather hesitant to label anything that's not ready design-wise as such.

[dbaron]

So maybe then defer with the text revised to:

We believe this is worth working on because it is an important part of making an open and secure payments ecosystem for the web. At the same time, we're quite concerned about the tradeoffs being made between extensibility and the user interface that is best for users' security, and we might take a substantially different position from the current direction of that work, such as by limiting the ability for payment handlers to show UI when invoked from another page, or even by standardizing a set of handlers instead of having an extensible handler mechanism. So our eventual position will depend on how these tradeoffs are made.

[marcoscaceres]

I'm ok with the above.

[dbaron]

This position has been updated in #390 with a somewhat updated statement from @marcoscaceres.

[tantek]

@annevk per your comment in #420 (comment), could you summarize here (in this issue) our reasoning for changing to a "non-harmful" position, rather than "defer", and with explicit reasons for why we are downgrading from our previous "worth prototyping" position.

To be clear: I’m not disagreeing with "non-harmful". Thanks.

(Originally published at: https://tantek.com/2020/246/t1/)

[adamroach]

@tantek:

@annevk per your comment in #420 (comment), could you summarize here (in this issue) our reasoning for changing to a "non-harmful" position, rather than "defer", and with explicit reasons for why we are downgrading from our previous "worth prototyping" position.

Can you clarify where you're seeing "non-harmful" here? The dashboard currently says "worth prototyping," which appears to be the outcome of #390.

[tantek]

@adamroach:
> where you're seeing "non-harmful" here?
The first link (420 comment) you quoted.

(Originally published at: https://tantek.com/2020/246/t2/)

[marcoscaceres]

I don't think it's "non-harmful", tbh. What was outlined in #23 (comment) is still a concern - as are other concerns that have been raised in the working group, such as "is this a first-party or third-party context?". The intention behind prototyping this spec was to have the time to work through those issues/concerns and see if we could solve for that together with the WG. However, as efforts on prototyping were put on hold (see dev-platform "intent to prototype" followup), it seems appropriate to "defer" until such time that Mozilla returns to this (#420).

[zcorpan]

Closed by #660