Intent to Implement: Per-method quota for PaymentRequest.canMakePayment().
56 views
Skip to first unread message
Rouslan Solomakhin
Oct 30, 2018, 4:12:50 PM10/30/18
to blin...@chromium.org, durga...@chromium.org
Contact emails
rou...@chromium.org
Spec
Interoperability risk
Firefox: No public signals - Firefox currently implements only "basic-card" and returns "true" for canMakePayment() only with "basic-card", regardless of user's autofill database contents.
Edge: No public signals
Safari: No public signals - Safari currently implements only Apple Pay and returns "true" for canMakePayment() only if the user has an active card in Apple Pay.
Web developers: Strongly positive - A long-requested feature from merchants in private conversations.
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6014793655779328
Requesting approval to ship?
No
rou...@chromium.org
Spec
The spec is at https://w3c.github.io/payment-request/#canmakepayment-method, but it does not specify detailed rules for quota enforcement, which is left up to user agent implementers by design.
Summary
A website should be able to query whether the user has a Google Pay wallet or cards in autofill database in two separate canMakePayment() calls, but should not be able to iterate all payment instruments within these wallets.
Motivation
Previously Chrome would reject PaymentRequest.canMakePayment() with NotAllowedError if a website queried different payment methods or different payment method specific parameters within the span of 30 minutes. Now Chrome would allow querying different payment methods, as long as the payment method specific parameters remain the same. This allows the website to query user wallets (e.g., to present wallet-branded buttons on the webpage), but not to iterate individual instruments in a wallet.
Summary
A website should be able to query whether the user has a Google Pay wallet or cards in autofill database in two separate canMakePayment() calls, but should not be able to iterate all payment instruments within these wallets.
Motivation
Previously Chrome would reject PaymentRequest.canMakePayment() with NotAllowedError if a website queried different payment methods or different payment method specific parameters within the span of 30 minutes. Now Chrome would allow querying different payment methods, as long as the payment method specific parameters remain the same. This allows the website to query user wallets (e.g., to present wallet-branded buttons on the webpage), but not to iterate individual instruments in a wallet.
Interoperability risk
Firefox: No public signals - Firefox currently implements only "basic-card" and returns "true" for canMakePayment() only with "basic-card", regardless of user's autofill database contents.
Edge: No public signals
Safari: No public signals - Safari currently implements only Apple Pay and returns "true" for canMakePayment() only if the user has an active card in Apple Pay.
Web developers: Strongly positive - A long-requested feature from merchants in private conversations.
Note that users can prohibit canMakePayment() through Chrome settings.
Compatibility risk
Small implementation detail change.
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 implemented in WebView.
OWP launch tracking bug
https://crbug.com/871791
Compatibility risk
Small implementation detail change.
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 implemented in WebView.
OWP launch tracking bug
https://crbug.com/871791
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6014793655779328
Requesting approval to ship?
No
Thiemo Nagel
Dec 14, 2018, 10:48:23 AM12/14/18
to blink-dev, durga...@chromium.org
This seems to impact privacy. Could you please make sure the change is reviewed, either as part of a launch bug or by filing a privacy review [1] bug?
Thiemo
tna...@google.com
Dec 15, 2018, 5:24:31 PM12/15/18
to blink-dev, durga...@chromium.org
This looks like it has privacy impact. Could you please request a privacy review either as part of launch review or via https://bugs.chromium.org/p/chromium/issues/entry?template=Privacy+Review?
Kind regards,
Thiemo
On Tuesday, October 30, 2018 at 9:12:50 PM UTC+1, Rouslan Solomakhin wrote:
On Tuesday, October 30, 2018 at 9:12:50 PM UTC+1, Rouslan Solomakhin wrote:
Reply all
Reply to author
Forward
0 new messages