Intent to Implement and Ship: PaymentRequest.hasEnrolledInstrument()

[Danyao Wang]

Contact emails dan...@chromium.org,rou...@chromium.org Spec https://github.com/w3c/payment-request/pull/833

Summary A method in PaymentRequest, hasEnrolledInstrument() returns a boolean indicating whether or not the user has a payment instrument in their profile that matches the payment identifier in a PaymentRequest and is ready to handle payment at the time PaymentRequest.show() is called.

When this feature is enabled, it also changes the meaning of the existing PaymentRequest.canMakePayment() method to return true as long as the browser has a suitable payment handler for a payment method, even if the payment handler is not ready for payment (e.g., user hasn't provisioned an instrument such as a credit card). Motivation The original canMakePayment() method was implemented differently in each browser that supported Payment Request. After discussion at TPAC, browser vendors and merchants all agreed [1] to align on a more permissive definition of canMakePayment(). This allows developers to display a "pay with basic card" option as long as user's browser supports this payment method and defer the need to add a card to a later point in the checkout flow.

hasEnrolledInstrument() is introduced to provide the stricter check that Chrome used to implement inside canMakePayment(). Developers can use this method to detect if user has an enrolled instrument that's ready for payment, e.g., to display a "buy-now" button. Interoperability risk Firefox: Public support Edge: Public support Safari: Public support Web developers: Positive

Compatibility risk Low. canMakePayment() is primarily used on merchant websites to decide which payment options to display. After this change, more payment options will appear available in Chrome, but users may need to take additional steps to add a credit cards later in the checkout flow. Developers that want to maintain existing behavior can switch to using hasEnrolledInstrument(). Ongoing technical constraints None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. No. Payment Request is not supported in Android WebView.

OWP launch tracking bug http://crbug.com/915907 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5646573451083776 Requesting approval to ship? Yes

[Philip Jägenstedt]

LGTM1, sounds like a great way to converge on a sensible behavior and allowing web developers to detect when it has changed.

Thanks also for sending https://github.com/web-platform-tests/wpt/pull/15306! I see that these are manual and while I've seen discussions on how to automate payments tests, I can't find the issue now. Would you mind filing a new issue on wpt describing which steps need to be automated? I suspect that it will require a WebDriver extension, and +Luke Z may be interested in tracking this.

--
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/CAErabb9NDuvzUG9vOCuT8kVLZV%2BRBrpoiMNzX-akJ1YvuuRi2w%40mail.gmail.com.

[Daniel Bratell]

Looks reasonable, though I'd wait at least until the spec change has landed considering the discussion is still ongoing (but probably won't result in anything that requires implementation changes). Just to avoid that we have a release that is neither the old API nor the final new API.

/Daniel

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/CAARdPYe0jEBCe%3DGkYGeEuBiaXxDnRNEuwh5vyLs%2B%2B9_du-JDRQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Danyao Wang]

Thanks also for sending https://github.com/web-platform-tests/wpt/pull/15306! I see that these are manual and while I've seen discussions on how to automate payments tests, I can't find the issue now. Would you mind filing a new issue on wpt describing which steps need to be automated? I suspect that it will require a WebDriver extension, and +Luke Z may be interested in tracking this.

Thanks Philip! Here's the discussion about testing support for PaymentRequest: https://github.com/w3c/payment-request/issues/799. There are two main blockers:

• A test API to inject payment instruments, which lives inside the browser process. There's concern about exposing test API in stable and also increase in binary size, but it seems that we can mostly follow the example of Web Bluetooth and Web USB. Would this be your recommended approach?
• Some of the tests require calling PaymentRequest.show(), which must be triggered by user activation. Is WebDriver the correct solution for this? I'd be happy to file a bug if so.

@Daniel:

Looks reasonable, though I'd wait at least until the spec change has landed considering the discussion is still ongoing (but probably won't result in anything that requires implementation changes). Just to avoid that we have a release that is neither the old API nor the final new API.

Sounds good. I'll ping back on this thread when the PR lands.

[Philip Jägenstedt]

On Mon, Feb 11, 2019 at 7:17 PM Danyao Wang <dan...@chromium.org> wrote:

Thanks also for sending https://github.com/web-platform-tests/wpt/pull/15306! I see that these are manual and while I've seen discussions on how to automate payments tests, I can't find the issue now. Would you mind filing a new issue on wpt describing which steps need to be automated? I suspect that it will require a WebDriver extension, and +Luke Z may be interested in tracking this.

Thanks Philip! Here's the discussion about testing support for PaymentRequest: https://github.com/w3c/payment-request/issues/799. There are two main blockers:

• A test API to inject payment instruments, which lives inside the browser process. There's concern about exposing test API in stable and also increase in binary size, but it seems that we can mostly follow the example of Web Bluetooth and Web USB. Would this be your recommended approach?

I believe this case is much simpler than Web Bluetooth or USB in that the communication only needs to go one way. I'd recommend first trying to define a WebDriver extension API with the semantics "make available these mock payment instruments". Would that solve the whole use case? Let's continue discussion in https://github.com/w3c/payment-request/issues/799.

• Some of the tests require calling PaymentRequest.show(), which must be triggered by user activation. Is WebDriver the correct solution for this? I'd be happy to file a bug if so.

The ability to click was the first capability we added to testdriver.js so this already works. There's also a test_driver.bless() wrapper for it which is appropriate if you really just want user activation and don't care about the click as such. payment-is-showing.https.html is a real test using it.

 

@Daniel:

Looks reasonable, though I'd wait at least until the spec change has landed considering the discussion is still ongoing (but probably won't result in anything that requires implementation changes). Just to avoid that we have a release that is neither the old API nor the final new API.

Sounds good. I'll ping back on this thread when the PR lands.

Thanks for taking care of that!

[Danyao Wang]

On Tue, Feb 12, 2019 at 4:58 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Mon, Feb 11, 2019 at 7:17 PM Danyao Wang <dan...@chromium.org> wrote:

Thanks also for sending https://github.com/web-platform-tests/wpt/pull/15306! I see that these are manual and while I've seen discussions on how to automate payments tests, I can't find the issue now. Would you mind filing a new issue on wpt describing which steps need to be automated? I suspect that it will require a WebDriver extension, and +Luke Z may be interested in tracking this.

Thanks Philip! Here's the discussion about testing support for PaymentRequest: https://github.com/w3c/payment-request/issues/799. There are two main blockers:

• A test API to inject payment instruments, which lives inside the browser process. There's concern about exposing test API in stable and also increase in binary size, but it seems that we can mostly follow the example of Web Bluetooth and Web USB. Would this be your recommended approach?

I believe this case is much simpler than Web Bluetooth or USB in that the communication only needs to go one way. I'd recommend first trying to define a WebDriver extension API with the semantics "make available these mock payment instruments". Would that solve the whole use case? Let's continue discussion in https://github.com/w3c/payment-request/issues/799.

• Some of the tests require calling PaymentRequest.show(), which must be triggered by user activation. Is WebDriver the correct solution for this? I'd be happy to file a bug if so.

The ability to click was the first capability we added to testdriver.js so this already works. There's also a test_driver.bless() wrapper for it which is appropriate if you really just want user activation and don't care about the click as such. payment-is-showing.https.html is a real test using it.

Cool! I didn't know about this. I was able to convert a number of existing manual tests to promise_test using test_driver.bless. I'll send out a CL for this soon.

[Mike West]

LGTM2. This doesn't create a differential to our currently shipping implementation, and seems like an API structure that vendors generally can agree upon.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAErabb-ZHo_rb6JZ_UGMLRueODX6uSdzAbE80gp%3DmaY-DBT9bw%40mail.gmail.com.

[Danyao Wang]

Hi API owners,

The spec PR has been approved by the editor (Marcos Cáceres from Firefox). It's pending final feedback from Andy Estes from Apple, but I don't expect significant changes to the spec because the split of old canMakePayment method into two methods, canMakePayment and hasEnrolledInstrument, was based on the Apple Pay JS API design, which has canMakePayments and canMakePaymentsWithActiveCard.

May I have a 3rd LGTM please? Thanks!

Danyao

[Rick Byers]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAErabb8-0Pf2Xu26_kW%3D%3DrFEt7XewvkHcNK6VWvY-EHUq8v0ig%40mail.gmail.com.

[Danyao Wang]

Hi all,

I want to provide a mini-postmortem for this feature. We shipped hasEnrolledInstrument and the new meaning of canMakePayment in M74. This broke some functionality on Stripe and Google Pay. We considered reverting the launch using Finch, but fortunately we didn't have to because Stripe and GPay were able to ship a patch pretty quickly. The lessons learned were:

• As spec editors, we should have deprecated canMakePayment instead of changing the meaning of an existing API
• blink-dev@ Intents are not sufficient communication for partners because developers don't actively monitor this. So although there were 3 months of lead time for developer to add feature detection to their code, in reality they didn't notice until their old code was broken.
  

To prevent this from happening again, we are implementing a new communication process for Payment Request changes going forward (details):

• All new features in addition to being feature-detectable, will bake for 1 milestone behind a #web-payments-experimental-features flag before being promoted to default enabled
• Summary of all changes in every milestone will be announced directly on the public payment...@chromium.org mailing list, which our partners will subscribe to.
• Partners are expected to implement feature detection of new features during the baking period.

We may make changes based on learning from the next few milestones. If you have questions & suggestions, let us know!

Thanks,

Danyao