Intent to Ship: Payment Handler
Rouslan Solomakhin
Contact emails
jinho...@samsung.com, rou...@chromium.org, anth...@chromium.org, goge...@chromium.org, zk...@chromium.org, durga...@chromium.org
Spec
The current iteration of the spec is at https://w3c.github.io/payment-handler/, but we would like to ship with the pull request for CanMakePaymentEvent (corresponding WPT pull request) and the pull request for removing requestPermission. These pull requests are unlikely to change, but in the worst case scenario we can turn off this feature before it hits stable if there are disagreements.
Summary
The Payment Handler API enables development of payment apps in web standard ways (e.g., service worker).
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/2ojnMk_T9_c/h7QfIhTeCAAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://rsolomakhin.github.io/pr/apps/ (Enabled by default in Chrome Canary.)
Risks
Interoperability and Compatibility
Interoperability risk: low -- have web platform test suite, working together with Mozilla.
Compatibility risk: none -- this is a new API.
Edge: No signals
Firefox: Participating
Safari: No signals
Web developers: Positive
Ergonomics
Payment Handler API is used in tandem with Service Worker, Payment Method Manifest, and Payment Request.
Activation
It should not be challenging for developers to take advantage of this feature immediately as-is.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
https://w3c-test.org/payment-handler/
https://wpt.fyi/payment-handler
Entry on the feature dashboard
https://www.chromestatus.com/feature/5160285237149696
Marcos Caceres
Marcos Caceres
On Friday, February 9, 2018 at 7:33:10 AM UTC+11, Marcos Caceres wrote:
Hi All, Just a heads up that Mozilla folks are drafting a response to this intent to ship with a couple of concerns for us to discuss. Will post it soon!
Dear Blink-Dev Friends, Mozilla would respectfully request that you reconsider shipping the Payment Handler API (or consider continuing to ship it behind a flag). As active participants in the Payment Handler work, we have several serious concerns with the Payment Handler API that we would like to discuss.
Of primary concern is the maturity of the specification. Although work on this specification has been ongoing since 2016, it has received relatively little attention when compared to the Payment Request API. Although those implementing at Google and Samsung have been reporting back with great implementation experience, Mozilla has not yet had a chance to evaluate implementability in our own browser. As this API deals with extremely important credentials (monetary instruments), we feel that we need to have a complete model for how this API interfaces with credential management, storage, and permissions. Discussions around these topics are ongoing as part of the standards setting process, but we don't feel that we have adequate answers yet to how everything will work together.
Secondly, the API has received relatively little review and quality assurance. Although a TAG review has been requested, it’s not yet taken place [0]. Additionally, as part of the process to assure the quality of the specification, Mozilla and Google have been coordinating closely on the web platform tests. However, thus far, together, we've only landed the absolute minimum: only the IDL definitions [1]. We still lack tests for all methods, the algorithms written in prose, and for attacking the state machine.
We'd like to emphasize the seriousness of the lack of tests: with the Payment Request API, our combined testing efforts not only greatly improved the quality of the specification, but it also managed to expose potential security vulnerabilities in the spec's state machine, and managed to crash multiple browsers, not just a child/tab process, with very simple attacks - things that we exposed and fixed together to the benefit of all constituents.
Thirdly, the Payment Request API, on which the Payment Handler API relies, is not yet meeting the needs of implementers - particularly requests from the WebKit team - and important partners like Stripe, on which merchants deploying this technology at scale will rely. We currently have 19 outstanding issues to close that implementers and merchants have agreed are critical to get us past "CR" - that is, to have something that adequately addresses real world use cases that allow people to buy things (not just W3C process stuff!). As such, we would encourage Google folks to continue to help us close those issues first, and help us and ship the necessary API changes being requested (there are quite a few and they range quite a bit in complexity). Over the next year, we should expect to see wider adoption and use of the API and and thus receive more real world feedback from those attempting to deploy the Payment Request API at scale.
Lastly, we are concerned by the lack of support from other implementers for the Payment Handler API. Both Microsoft and Apple are not participating in the work at this moment in time. We can't speak for their rationale for not participating. We are concerned at seeing Google moving on their own to ship this API. What made Payment Request API such a great success was that we had all engines onboard: Google, Microsoft, Apple, and Mozilla are all-in with implementing - and we expect all browsers to have fully interoperable implementations by the end of 2018. That's not the case with the Payment Handler API right now. Mozilla definitely wants to implement this API, but we just don't feel the specification is at a point where we can commit to that.
Let us be clear: At Mozilla, we understand how absolutely critical the Payment Handler API is to modernizing and opening up payments on the Web. It's the reason why, although we are not implementing the specification at this moment in time, we continue to fully participate in all aspects of the standards settings process. That is, from helping with editing, joining voice calls, working together on web platform tests for the spec, and doing as much as we can to push this specification forward. However, shipping this API prematurely risks us having significant interoperability issues in the future - or worse, having to standardize unintentional bugs due to premature adoption by sites in the wild.
Thanks for hearing us out, and we sincerely hope you will consider our feedback. We look forward to continuing to collaborate on Payment Handler together.
[0] https://github.com/w3ctag/design-reviews/issues/231
[1] https://github.com/w3c/web-platform-tests/tree/master/payment-handler
[2] https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit
est...@chromium.org
Philip Jägenstedt
You received this message because you are subscribed to the Google Groups "blink-dev" group.--
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75a32c57-1b53-4f2c-8ac8-309e716124e6%40chromium.org.
Ben Wells
Is this API shipping with a new permission as described in the spec? I ask because I discussed this payment flow with Zach a couple weeks ago (or at least, I think it was this spec, maybe it was something else?) and we both felt that it would be difficult to make a permission prompt that was understandable to users. There were also a number of tricky questions about how to display the payment handler app and I think the spec should document those concerns (non-normatively?) in Section 7 or 8.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2815ff86-603b-42d0-8ffa-a3597f38fb05%40chromium.org.
Rouslan Solomakhin
Rouslan, do we have other kinds of tests for this, brower_tests or something? What would it take to share virtually all of the tests that we have with WPT, what's missing infra-wise?
When the payment sheet is shown, please authorize the mock payment.
Yoav Weiss
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/71a8dd25-a0b7-4908-9ec4-95f0f26addc9%40chromium.org.
mcac...@mozilla.com
Apologies for the delay!
On February 22, 2018 at 5:15:06 AM, Philip Jägenstedt (foo...@google.com) wrote:
> Thanks for your detailed feedback, Marcos, much appreciated.
>
> Can you elaborate a bit on the connection between the Payment Request
> API being highly interoperable
https://github.com/w3c/web-platform-tests/tree/master/payment-request
And I've manually checked the interop across Edge, Firefox, Chrome, and Safari. The results are really positive: like ~90-95% pass rate across all engines (and like 99% in Chrome!). I'll be preparing a proper implementation report soon together with Mike Smith from the W3C.
We've also been coordinating really closely across all engines. See, for example, any of our pull requests. All contain links to each bug tracker, so we know who is committed to implementing a feature. Recent case in point, `show()` taking an optional promise - WebKit led the charge, we all agreed to have that released by November 2018:
https://github.com/w3c/payment-request/pull/672
Most of the implementers of Payment Request meet regularly on calls, where we attempt to coordinate our browser release schedules to maximize interop and minimize disruption to developers and end users of the API.
This is how standards are supposed to work, IMO - and it's awesome to see it working that way with Payment Request API...
> and the chances of the Payment Handler API also being so?
See the contributor's graph:
https://github.com/w3c/payment-handler/graphs/contributors
> Is it because the same people would be implementing in both
> cases and so a question of having to prioritize Request first,
The other part is standards participation: I'm currently doing most of the editorial work on the Payment Request spec (~95% of spec text and web platform tests) - with Domenic and Rouslan helping me with reviews, etc. But it's hard work, and it's slow going for all of us. See, for example, the dates on which the pull requests were filed (each taking a couple of weeks to months to land):
https://github.com/w3c/payment-request/pulls
> or are there
> foundational things in Request that Handler depends on that are somewhat
> likely to change based on implementation experience?
> Is there a list of
> issues on Payment Request API that you would consider blocking?
> For issues you believe need to be resolved for Handler, is it CR-Exit issues,
> or does that list include things which aren't really important? Any things
> known to be missing from the list?
> On the topic of testing, I'm very happy to hear that was a positive
> experience with Request. Could someone also clue me in on the state of
> automation I type:untestable issue for anything payments-related,
> but seem to remember it is a problem (need
> to mock out the UI) but that there wasn't much traction in a previous
> discussion.
> Does Handler depend on Request so that the testing difficulties
> multiply, or... not?
HTH!
Zach Koch
Hi all -
Sorry for the radio silence over the past few weeks. We've been chatting as a team, getting clearer on our permission story (or lack of one for that matter), and a few other housekeeping items. Let me try and summarize where we're at and address as many of the points as I can.
* I fully acknowledge many of the points that Marcos and team are raising. But I would also remind folks that all of these held true when we originally shipped PaymentRequest as well. We made a judgement call that, even in light of the risk of possible breaking changes, it was important to get the API out in the wild sooner rather than later. And because of a variety of factors for how checkout flows work, doing that within the confines of "safer" routes such as Origin Trials was not possible. Looking back, that was the right call to make, as I'm not sure we'd be having this conversation if it wasn't.
* The further reality is that we're at a critical juncture here. For the most part, the third party ecosystem supported by PaymentRequest is extremely limited, available only to Android apps in Chrome. This limits both our ability to scale and support the needs of millions of merchants worldwide for whom "basic-card" is insufficient as a payment method. In addition, the viability of “basic-card” continues to be diminished by changes in the payments industry that are only solved by Payment Handlers (e.g., 3DS 2.0, tokenization, etc). We announced publicly at I/O last year that we were working with some major payment providers, such as PayPal, to continue growing this ecosystem. These partners are working with us, but they will not wait for months to make progress. We need to be able to get this into production.
* In addition to the previous point, the set of players that would be implementing Payment Handlers is quite small, especially at the beginning. Unlike, for example, a Storage API that would be useful to nearly all developers, Payment Handlers only target a very small subset of companies (i.e., payment providers). This makes outreach in the event of breaking changes much simpler. Furthermore, the early partners we're working with know this is a new API and the potential risks of breaking changes. I think the Chrome teams' willingness to make core changes to the PaymentRequest API over the past year and a half is evidence of the fact that we're serious about making changes when they are necessary.
* We'll of course continue to support the efforts around PaymentRequest. Quite a few of us will be in Singapore in a couple of weeks for the face-to-face to engage on discussions around PaymentRequest, Payment Handlers, 3DS, Tokenization, and other topics. The payments system is complicated, and we're committed to pursuing these efforts in parallel to try and move forward an open and successful web payments ecosystem. We understand that not all teams are capable of that, so we're happy to help in whatever way we can to de-risk this.
* Lastly, just to clarify, we do not plan on having any permission prompts for this initial rollout. We’ll learn quickly if this is the wrong call and bring that experience back to the working group to inform the spec.
Thanks,
Zach
Rick Byers
- Accept the feedback - changing the spec, tests and impl
- Question the feedback but argue it's not blocking - i.e. file a spec issue marked somehow as for the future (eg. because it reflects a decision we can change post-ship without any substantial compat risk)
- Debate the feedback - i.e. file a spec issue, argue why you disagree and if consensus can't be reached in a reasonable timeframe, follow-up here with the list of outstanding issues.
- Moving the web forward
- Low friction payments is absolutely essential to our mission to improve the web
- Web-based payment handlers create a real opportunity to reduce friction for a broader set of players (instead of just for the biggest players who can get users to install their native app, etc.)
- Having a key partner like PayPal engaged and wanting to adopt this API ASAP is huge - we should be bending over backwards to make them feel that the web can evolve relatively quickly to better meet their needs.
- Compat risk for future breaking changes is low
- I agree that the number of impacted sites for future breaking changes should be quite low. Please keep an eye on the UKM UseCounter you added, and raise a red flag if it seems we're on a trajectory to exceed, say, 100 distinct origins using the API.
- It sounds like you're saying that you're confident that you can get consumers of the API to update for whatever changes the WG agrees to make post-ship. I agree that your claim of being able to do that for PaymentRequest seems to have worked out (Marcos or others, please provide any data to the contrary if you have it), and this case seems strictly lower risk. So I'm willing to treat this as a case where we'll be more aggressive with breaking changes due to the interop risk we're accepting here.
- Security / privacy concerns
- Like all major chrome features, this is subject to security/privacy sign-off as part of the Chrome feature launch process. I defer issues of security and privacy there - there's obviously a lot of nuance.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOsZg64VrtZKKNQLrjga8JXg3mrQNzRBc9GsxU2kxCEcGrpd%2Bw%40mail.gmail.com.
Rouslan Solomakhin
- Our WPTs cover the two major use cases of Payment Handler: responding to CanMakePaymentEvent and PaymentRequestEvent.
- I've responded to the TAG review and filed a few non-blocking issues against our specs. Addressing those issues should not pose substantial compat risk post-ship.
- Call out the need for merchants to validate payment responses.
- Propose to remove modifiers from CanMakePaymentEvent. (No partners plan to use modifiers in CanMakePaymentEvent.)
- Propose to merge payment method manifest into web app manifest spec.
- Call out the need to reuse web app manifest ImageResource better.
Rick Byers
Chris Harrelson
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-cuJL-q%2B5r0T4v6E6Nbvs-7bg1ZYDzJP1ra9cq-KQe5Q%40mail.gmail.com.
Ojan Vafai
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-Lnd8JOpMvHxFRQvM6nSY3FkSkyPCkeiQDafN6M9U%2Bcw%40mail.gmail.com.