Re: [w3ctag/spec-reviews] Payments Drafts Review (#109)

@triblondon

Thanks for this feedback.

It may help to have a look at the original architecture that was put in the wiki prior to the specs being drafted: https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web

Some of this is now reflected in the architecture document but some still needs to be pulled through in  documents about payment apps and registration and non-browser payments:

Some proposals exist for these:
 * http://w3c.github.io/webpayments/proposals/web-payments-http-api/index.html
 * https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html

To answer some of your questions:

> The payment app UI anticipated by the spec - would that be web UI? How would it be displayed to the user - in a new modal browsing context? And will the spec define separately how payment apps are to interact with a PaymentRequest, or are they expected to do so using the same methods as the merchant?

We have intentionally not prescribed this as we hope that payment apps will take a variety of forms depending on the deployment scenario. My position (chair hat on) is that we should prescribe a minimum web-based interface between the browser and a web-based payment app where the paymentRequest is serialized as JSON and sent via a POST to the endpoint URL of the payment app which responds with HTML that is rendered as the app UI.

My expectation is that the paymentRequest will be presented to the payment app purely as JSON serialized data (also see https://github.com/w3c/browser-payment-api/issues/45 and https://github.com/w3c/browser-payment-api/issues/47) so I don't presume we'll prescribe how the app will interact with the paymentRequest however there may be pending proposals that suggest otherwise.

> If the most likely early payment apps will simply return raw credit card credentials back to the merchant, is there an anticipated roadmap for how those apps would evolve? For example, would a next stage be a token generating payment app backed by a credit card? I guess I'm saying what is the likely progression and does the spec make any conscious design decisions based on the likely phases of adoption/support from banks or the payments industry?

The architecture intentionally tries to make the API very agnostic to payment methods and puts all of the method specific logic into stand-alone payment method specifications. The Basic Card Payment spec is one of these but the group recently resolved to produce a number of them based on the various payment flows that have been investigated. This will be entirely dependent on WG input to produce these. The flows TF has been primarily responsible for this work to date under the guidance of @mattsaxon. See more flows related stuff here: https://github.com/w3c/webpayments-flows

> There seems to be little specific support for recurring payments.

This is an issue that the group is actively discussing. There is one PR proposing a mechanism to deal with this use case (https://github.com/w3c/browser-payment-api/pull/111) and two related issues (https://github.com/w3c/browser-payment-api/issues/19 and https://github.com/w3c/browser-payment-api/issues/113). Your input on those threads would be greatly appreciated.

>> One principle of the Payment Request system is that when a merchant web site declares that it accepts a given payment method then it must know how to process the resulting response

> This implies that a payment method identifier is strongly coupled to the response format for that method. If the response format changed, you would need a new method identifier. Is that an issue?

Correct. Our expectation is that these formats will not change often. There is very little required to mint new identifiers so we expect that when payment apps and processors introduce changes to a payment method they will be non-breaking or introduces as new, versioned, payment methods. Example: http://w3.org/payments/basic-card could become http://w3.org/payments/basic-card/v2

>> three key parties in every transaction

> These are cited as being the user, the merchant, and the payment method. However, a payment method is an instrument, not a party, surely? Wouldn't the party be the payment app provider? And is it necessary to acknowledge that in some cases the payment app provider may not be the same as the party with whom the merchant finalizes the transaction, especially in the case of a basic card payment?

I agree that this needs revising. The traditional model for payments is the "4-party" model and I think we'd do well to describe the architecture in this context. The architecture puts the user agent in the role of mediator between the payer (and their PSP - likely the payment app issuer) and the merchant (and possibly their PSP too).

To address some of your other comments I have either added them to the relevant issue:
 * https://github.com/w3c/browser-payment-api/issues/1
 * https://github.com/w3c/browser-payment-api/issues/2
 * https://github.com/w3c/browser-payment-api/issues/4
 * https://github.com/w3c/browser-payment-api/issues/5
 * https://github.com/w3c/browser-payment-api/issues/15
 * https://github.com/w3c/browser-payment-api/issues/16
 * https://github.com/w3c/browser-payment-api/issues/18
 * https://github.com/w3c/browser-payment-api/issues/23

Or created a new issue:
 * https://github.com/w3c/browser-payment-api/issues/121
 * https://github.com/w3c/browser-payment-api/issues/122
 * https://github.com/w3c/browser-payment-api/issues/127
 * https://github.com/w3c/browser-payment-api/issues/128

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/109#issuecomment-207046442