Payment Method Manifest

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Payment Method Manifest
• Specification or proposal URL: https://w3c.github.io/payment-method-manifest/

Other information

This specification allows both web applications and native applications (specially on Android) to act as "payment handlers": A "native payment handler" is an native application capable of either settling a monetary transaction and returning a proof-of-payment token (e.g., the PayPal native app), or providing a website with an end-user's credit card information (e.g., Microsoft Wallet).

The purpose is to allow websites to bypass the browser's built in credit card store or "wallet", and to use, for instance, the natively installed PayPal application instead to settle a transaction.

Currently proposed by Google to the Web Payments Working Group. This spec is potentially controversial as it's specifically designed to bypass web applications to allow users to just use native apps.

However, to give the web the same capability, the Web Payments WG is proposing a specification called the Payment Handler API (will send a separate RFP).

Used by:

• Google Chrome
• Samsung Pay

[marcoscaceres]

Update from TPAC: Google would like to move this to FPWD in the next few weeks.

The proposal enables interesting things for payments, but I would appreciate some help with the security and privacy aspects: this does a lot of cross-origin requests and interactions and could have privacy/security implications. So if at all possible, I would like a few of us to discuss what they are proposing before the WG publishes FPWD.

[dbaron]

Some of my previous thoughts in this space are in the TAG review of Payment Method Manifest, the TAG review of Payment Handler, and a comment in the TAG review of Payment Method Identifiers.

[dbaron]

I'm inclined to mark this as worth prototyping. Does that make sense?

[marcoscaceres]

Makes sense.

[dbaron]

I'm actually having second thoughts about that. I think given that #23 will be defer, I think this probably should be as well.

I've also been concerned with this spec in the past about whether it's going to do things in a way that leads to interoperability. That is, does the manifest have enough information for an implementation to understand how to handle the payment method... and is that information specified in the spec.

[dbaron]

(Or to put it another way -- is it the case that the payment applications linked to either (a) use Payment Handler or (b) don't have a known way to handle payments? Or is there some other mechanism I'm missing here?)

[marcoscaceres]

"Defer" is good... there is a lot of work to be done on this spec + also the Payment Handler. Once they are in better shape, we can reevaluate our position.