Re: [w3c/browser-payment-api] Supporting push payment methods (#224)

Some additional requirements for push payments:
 1. Payment app must validate that the details of the payee are correct
 2. The ability for the payee to establish the status of a payment if they don't get a response from the API

It's useful to think of push payments in the context of the following roles:
1. The payee (merchant)
2. The payer (buyer)
3. The payment app publisher
4. The merchant processor
5. The push payment scheme operator

It's quite likely that the same entity could fulfill many of these for example Alipay could be 3, 4, and 5.

The challenge we must deal with is that in preparing the payment request it's not desirable for the merchant to need to call out to the processor (4) each time if it's possible that the user may use another payment method. (e.g. If the merchant must call out to the processor to sign the request each time)

It's also challenging to deal with PKI (and especially verification of public keys and who they belong to) so offline validation is complex unless the scheme can support this.

There will likely be schemes/methods that use PKI and those that don't to make the job of the merchant simpler

PROPOSAL:

1. Payment Requests should all be generated with a universally unique identifier.

A [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) is probably a good option. 

It's simpler but quite inefficient for this to be done per payment method so it would make sense to make this a requirement for all Payment Requests and ignore it if it's not required. UAs could easily provide a function to generate these effectively (i.e. The browser could generate this when the PaymentRequest constructor is called and assign it to a read-only property of the new object).

This Payment Request ID can be used by the merchant (and possibly the payment app?) for interactions between roles and phases where state has been lost or is not shared.

For resilience it is best if this identifier is generated as early as possible by the first entity in the multi-party interaction. If it's generated by the payment app, for example, then if the communication breaks down between the website and the payment app then the website has no way to query the state of the request later.

2. Payment Requests for push payments should include a callback URL

This URL could either be hosted by the merchant (1) or their processor (4) and is a reliable means for the payment app and the merchant/processor to establish an interactive channel for processing the payment.

This is similar to the proposal in https://github.com/w3c/browser-payment-api/issues/109 but probably has more general/generic use cases.

3. The browser should raise an event when a payment app is invoked

When the browser passes the flow control to the payment app it should notify the website which payment app was selected (and therefor which payment methods may be used to process the payment).

This is required by the website to know how to track the payment as it progresses.

An event similar to that proposed by @rvm4 is probably the best solution.

These 3 changes, and some guidance on how these may be used to make push payments more resilient, is probably sufficient from a standardization perspective.

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/224#issuecomment-238177520