Supporting push payment methods

[rvm4]

I put out a PR that I expect to spur discussion, so let's use this issue to discuss: #223.

[adrianhopebailie]

@rvm4 thanks for kicking this off!

In my experience the best way to guarantee that the sender (in this case the merchant) will have the same transaction reference as the receiver (in this case the payment app) in the case where no response is received and we don't know how far processing got is to send the transaction identifier in the original request.

I'd propose that we have a field in payment request that allows a unique identifier (UUID makes the most sense I think) and that this is returned in the "payment processing" event.

If you wait for the TX id to come from the app you risk comms going down before the app can provide this to the browser.

[rvm4]

A few comments:

1. I think it is important that the payment app be allowed to provide the identifier because the payment app is the one implementing a bunch of abstractions that rely on this identifier being unique. Allowing the merchant to supply the identifier forces all payment apps to architect their backend around tuples of the form (merchant, identifier) which is not going to be easily adoptable by any existing apps. It makes sense for merchants to take on this burden because in many situations the merchant will be incentivized to implement addition integrations with a particular payment app (when sufficient traction has amassed) and in doing so need to differentiate ids.

2. You are right that a requestId could fail to make its way to the merchant from the payment app, but it is of little consequence because it only provides a way to query about payment status. Failure to receive the requestId implies that payment did not occur because the event must proceed payment. I didn't call out that requirement, I will add that.

[adrianhopebailie]

Failure to receive the requestId implies that payment did not occur.

Is that true?

[rvm4]

Well that is what I'm trying to propose, I will make that more clear in the PR.

[rvm4]

Any additional thought here? I think this topic needs just as much consideration as the security consideration we are giving the credit card flow. If we are concerned about specifying ways to avoid security flaws, certainly we want to specify ways to prevent expected failure scenarios.

[adrianhopebailie]

I think this topic needs just as much consideration as the security consideration we are giving the credit card flow.

+1 - however I think rather than diving straight into a PR why don't we map out the expected flows for a push payment first and identify the failure scenarios we are trying to address

[webpayments-specs]

We MUST already have such a flow. Matt Saxon?

On Tue, Jul 12, 2016 at 5:43 PM, Adrian Hope-Bailie <
notifications@github.com> wrote:

I think this topic needs just as much consideration as the security
consideration we are giving the credit card flow.

+1 - however I think rather than diving straight into a PR why don't we
map out the expected flows for a push payment first and identify the
failure scenarios we are trying to address

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#224 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AQ8khsdBFaOpiUIDlzydLsZ7bbtzXAFAks5qVBimgaJpZM4JHRXE
.

Shane McCarron
Projects Manager, Spec-Ops

[rvm4]

Sounds great, can we add to our call agenda an item to establish a task force for solving this problem?

[mattsaxon]

I would request that we use the Push SEPA flow as documented in the specification as an example

http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/

The document doesn’t look specifically as failure modes at the moment, but the data specification has a reference field on both request and response (payeePaymentIdentification & payerPaymentIdentificaiton) that is designed to address deduplication on any double submission due to failure. These fields are direct pass throughs from the SEPA specification.

[adrianhopebailie]

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 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.

1. 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 #109 but probably has more general/generic use cases.

1. 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.

[ianbjacobs]

Hi @adrianhopebailie,

Here are some comments on your three proposals.

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

Do you mean: For the purposes of payment app / browser communication
about transactions (e.g., to learn state following a network outage), the payment
app specification will define how browsers MUST provide browser-generated identifiers
per transaction when they launch a payment app?

I phrase it this way to see whether it makes sense as a requirement in scope for the payment app spec. I want to distinguish the purpose of these identifiers from other identifiers that might be circulating in the system (e.g., merchant generated identifiers that they use for their own internal
purposes, e.g., for returns).

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

In spec terms, I hear: The payment request API specification should be modified to include
a standard field for payees to (optionally) specify a callback URL for payment apps to contact
the merchants directly. While I understand the idea, how would this work in practice?
Because of the standard, all payment app developers would know that they could reach
a merchant through a service identified by that URL. But how would payment app developers know how to interact with that service (e.g., what the parameters and responses would be)? What
would be the interoperability gain in practice?

1. 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).

I don't understand this requirement. It seems to me that when the promise resolves, the merchant gets back data. It seems appropriate at that time to identify the payment method, so that the response data can be routed appropriately. But why does the merchant need to know which payment app was used?

[ianbjacobs]

Related:
#287

[ianbjacobs]

@rvm4, @stan-stripe, @adamroach, and I discussed WPWG feedback
and propose as next steps:

1. To enable various parties to reconcile transactions (especially
   push payments), add support for paymentRequestID to Payment Request
   API.

   a) A paymentRequestID must be unique within the scope of each domain.
   b) We will not specify the format of the identifier; UUID has
   been cited as an example that may be useful.
   c) The payee can (optionally) provide a paymentRequestID in
   the constructor. When the payee does not provide one,
   the user agent generates one.

2. In the Payment Method Best Practice specification [1],
   discuss how paymentRequestID and other payment method
   specific information can be used to help parties reconcile
   their systems. In particular:

   a) Payment methods may enable payees to provide a URL
   where payment services can send transaction status information.
   b) State information useful to payees (e.g., success, fail, processing)
   will depend on the payment method.
   c) Parties may secure the callback channel in a variety of
   ways. Some parties may wish to provide the same data asynchronously
   that is available synchronously through Payment Request API; this
   is likely to involve some form of mutual authentication. Other
   payment servers may prefer to send minimal information to the
   payee, and require the payee to query the payment server for
   authoritative status information.

[1] https://w3c.github.io/webpayments/proposals/method-practice/

[marcoscaceres]

Discussed today with editors, concluded that this can be closed because we added id to PaymentRequest.