Intent to Implement and ship: PaymentRequest.canMakeActivePayment()

[Rouslan Solomakhin]

Contact email

rou...@chromium.org, zk...@chromium.org

Explainer

https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md

Tag review

https://github.com/w3ctag/spec-reviews/issues/146

Summary

We add a new method onto PaymentRequest, canMakeActivePayment(), that returns back a boolean indicating whether or not the user has the ability to make a payment at the time PaymentRequest.show() is called.

    var request = new PaymentRequest(supportedPaymentMethods, shoppingCartContents);
    if (request.canMakeActivePayment) {
      request.canMakeActivePayment().then(result => {
        console.log(result ? "Can make active payment" : "Cannot make active payment");
      }).catch(err => {
        console.log(err);
      });
    }

Motivation

We’ve heard very strong feedback from merchants that they would like to know before calling show() on PaymentRequest if a user has an available way to pay. Our initial response to this feedback was to call .show() and, if it throws, fall back to an existing checkout flow. This, however, has created challenges. Two are worth highlighting:

• Some merchants would like to use PaymentRequest as an abbreviated checkout of sorts, thus forgoing things like coupon codes, etc. Put in a more direct way: they would like to directly replace the Apple Pay button, whose appearance is determined by a canMakePaymentsWithActiveCard function. But this is only worth doing if a form of payment is already available inside of PaymentRequest (otherwise, overall benefit is reduced).
• Some merchants are interested in using PaymentRequest when a payment method is available, but otherwise would prefer their own flow.

Interoperability and Compatibility Risk

The risk is moderate, because the specification is not mature, but the API footprint is small.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The feature will be included on all platforms where PaymentRequest is supported. Support for PaymentRequest requires platform-specific UI. Currently only Android has UI for PaymentRequest. UI for Windows, Mac, Linux, and ChromeOS is in development.

OWP launch tracking bug

http://crbug.com/664619

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5702608073261056

Requesting approval to ship?

Yes

[Rick Byers]

I agree this sounds important.  But normally we don't ship a new API until there's at least a proposed specification somewhere (ideally in a WHATWG or W3C forum like WICG), written in enough detail that someone else could reasonably implement.  You could do this as a monkey-patch spec, or as a pull-request/fork of the web payments spec.  WDYT?

Have you asked the other vendors who are interested in web payments what they think of this proposal?

What about the payments WG, is there an issue filed for them to track getting something into the official payments spec eventually? 

[Rouslan Solomakhin]

WG discussed this in telecoms and zkoch@ is working on a pull request into the spec. Let's wait for that pull request to land and some more public support from other implementers. Sounds good?

[Rick Byers]

Getting the PR up and at least giving the other implementors some time to review and comment on it before making a ship decision sounds like a good idea to me, yes.  Thank you!

Rick

[Rouslan Solomakhin]

If no one objects, I will land the feature behind a flag, while we wait for more public support from other implementers and the PR into the spec.

[Rouslan Solomakhin]

Pull request into the web payments spec from Samsung Internet developers: https://github.com/w3c/browser-payment-api/pull/316

[rou...@google.com]

API owners: we are ready to ship canMakePayment().

Spec:

https://w3c.github.io/browser-payment-api/#canmakepayment-method

Added in:

https://github.com/w3c/browser-payment-api/pull/380

Blink implementation behind a flag:

src/third_party/WebKit/Source/modules/payments/PaymentRequest.idl

[Rick Byers]

I see the outstanding debate about rate limiting but FWIW shipping something now based on the "implementation defined heuristics" spec note is exactly the right next step.  This should give us the experience and flexibility (critically the opportunity to learn from mistakes) to find the sweet spot that can lead to some more precise spec language in the future.

LGTM1

[Chris Harrelson]

LGTM2

--
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+unsubscribe@chromium.org.

[Dimitri]

LGTM3.