I’d like to further suggest that the TAG:
(If you do have an agenda item for this, I’d like to call in as well, and maybe @ianbjacobs would as well.)
@sideshowbarker can you post the specific drafts you would like the TAG to review? We are open to putting this on our agenda for this week still. We could discuss on Wednesday afternoon UK time or Thursday afternoon UK time. Would those times suit the tz needs of yourself, @ianbjacobs and/or @zkoch, @adrianba ?
The complete list of the current drafts is:
oops in my previous comment I put the (not-yet-existing) TR URL for the architecture doc. Please instead use https://w3c.github.io/browser-payment-api/specs/architecture.html (and edited my other comment to correct the URL there too)
Thank you for taking this early opportunity to review the Web Payment WG specs. I suggest focusing on the Payment Request API and the Payment Method Identifiers specs. There are some good TAG questions in their like "what identifiers should we use for payment methods?"
The architecture document has multiple parts, some of which are simply informative (such as explaining how we organized the documents in this set). The more architectural bit involves a description of "how all of this is expected to work from the user perspective."
The Basic Card Payment spec is an example of the sort of spec we anticipate for each new payment method that people wish to use via the API. It describes (in this case) the required inputs and outputs for handling card payments. Anyone will be able to publish this sort of spec to tell the world how to support different payment methods interoperably through this API. (I do not yet know how many such payment method specs the WG itself will publish.)
We will also want to engage the TAG around "payment app registration" but we do not yet have a spec for it.
Let’s go ahead as scheduled at 5pm UK time today. I still hope Ade will be able to join also, but if needed Zach on his own can handle doing the overview and Q&A from the editors’ perspective.
OK, this is my first attempt at a TAG spec review, so please tell me how I'm cocking it up so I can do it better.
My understanding is that this API enables a native browser UI to sit between a 'pay' button on a website and the resulting submission of payment credentials to the merchant.
In the simplest case, this is not much more than what we have seen before with
However, the majority of the architectural complexity of this draft is in anticipation of token based payment systems, where the user would hit Pay, choose to use a token generating payment app, and that would invoke a request directly to the payment app provider. The payment app provider, having authenticated the user and confirmed their consent, would generate a single-use token binding the merchant, the amount and the date and sent that back through the browser to be handed back to the merchant web page. The merchant would then submit that to their server and use it in an exchange between the merchant's servers and those of the payment app, to settle the transaction. Being largely unopinionated enables this API to be compatible with a variety of payment settlement workflows, so it would also work with bitcoin, for example.
High level questions
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?
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 finalises the transaction, especially in the case of a basic card payment?
paymentRequest.complete feels slightly weird, and I'm wondering why the merchant page does not instead receive an unresolved promise that it can resolve or reject. That would seem more aligned with the use of promises elsewhere.
Issue 40 describes non payment method specific data - would that be data specific to a payment app then? AFAICT, the merchant doesn't know about payment apps, only payment methods, so it's hard to see how custom data not tied to a payment method could be useful. The issue is a bit unclear on what the core problem is here.
Issue 16 discusses the method of instantiation of the PR object. I prefer a constructor. I'd definitely say no to a singleton unless it was a solid certainty that we'll never want a UA to be processing multiple payments at a time, since the instance provides a means of storing state which seems like it would become more useful as the API is extended in future.
I'm wondering if
Issue 23 and issue 4 discuss the ability for merchants to express a payment method preference and to charge differently for different payment methods. Merchant preference seems basically meaningless unless there is a charge element - the user has no reason to choose a particular payment method simply because the merchant wants them to, but they would certainly be swayed if using one method added a surcharge. Perhaps the simplest way to model that would be to have the merchant pre-calculate a supplement charge to attach to the payment method at the PaymentRequest level, rather than polluting the PaymentDetails items dictionary with multiple additional charges per item (this is suggested in w3c/payment-request#4 (comment), which I agree with). I'm concerned that any potential desire to add granularity to the cost of an individual item will get multi-dimensional very quickly - eg supporting different charges based on payment method, and also expressing pricing in different currencies, you would need a value for each intersection of that possibility space.
Issue 2 discussed whether iframes should be able to request payment. It seems like a severe limitation to me to prohibit that mode of use.
Issue 18 discusses the format of the PaymentDetails dictionary and the special case treatment of the final 'sum' item. I'm very strongly in favour of breaking this out into a separate element. To me it has no business being in that sequence. In fact I'm dubious of the need for an explicit total at all.
shippingOptions appears not to support the idea of a transaction that does not require shipping (eg a digital service). This is covered off by the PaymentOptions interface but it would be worth clarifying that shippingOptions is only expected to be supplied by the merchant when they are also requesting shipping address in PaymentOptions
Issue 1. Yes. Otherwise you will end up with a paymentrequest flow leading into a conventional webform to collect all the data the PR API is failing to deliver. Email and phone number are really obvious and will be needed by lots of merchants.
Issue 5. Yes. Unless the API can set out guarantees or limits on the duration of the merchant's payment processing, it must support feedback. It's also out of the scope of this API to understand whether a payment method contains distinct phases to its settlement process, and if it does, but those cannot be surfaced, PR may be an inferior user experience to the current methods available to merchants.
To clarify, the singleton would instantiate a Promise and return it. You'd be able to run multiple payment requests in a page. I'm not strongly arguing for/against - just clarifying.
The Web Payments Community Group Browser API specification proposed .start():
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:
To answer some of your questions:
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 w3c/payment-request#45 and w3c/payment-request#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.
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
This is an issue that the group is actively discussing. There is one PR proposing a mechanism to deal with this use case (w3c/payment-request#111) and two related issues (w3c/payment-request#19 and w3c/payment-request#113). Your input on those threads would be greatly appreciated.
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
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:
Or created a new issue: