Upcoming W3C Payment API changes in Chrome 83

103 views
Skip to first unread message

Danyao Wang

unread,
Apr 21, 2020, 12:21:04 PM4/21/20
to payment...@chromium.org

The following changes are coming to Chrome 83.


Note: The Chrome 82 release was cancelled. So the following includes all changes since Chrome 81.


Canary: today  |  Beta: Apr 16, 2020  |  Stable: May 19, 2020

Summary


Enabled by default

Available for testing behind flag

Payment Request API

  1. Payment sheet UI tweak

N/A

Payment Handler API

  1. Hosting manifest at payment method identifier URL

  2. Relative URL for “default_applications”

  3. More accurate NotSupportedError message on Android

  4. Bug Fix | CSP blocks manifest icon loading (crbug/1055360)

  5. Bug Fix | Use correct SecFetchSite header (crbug/1048201)

7. Minimal UI experimental support

8. Bug Fix | WebAuthn in Expandable Payment Handler Window (crbug/1051786)

Details

1. Payment sheet UI tweak

The call to action on Chrome’s payment sheet now says “Continue” instead of “Pay” when the pre-selected payment method is an external payment handler. We believe this helps the user better understand the expectation when using payment handlers to complete a transaction.


M83 and later

M81 and earlier

2. Hosting manifest at payment method identifier URL

To simplify development and testing of URL-based payment methods, Chrome 83 now supports ingesting the response body at the payment method identifier URL as the payment method manifest.


For example, If your payment method identifier is “https://example.com/web-pay”, then Chrome 83 will switch from making an HTTP HEAD to making an HTTP GET request to https://example.com/web-pay. If the response headers include a Link rel=”payment-method-manifest”, then Chrome will follow it as before. Otherwise, Chrome will attempt to parse the response body for the contents of the payment method manifest. See this announcement for more details.

3. Relative URL for “default_applications”

In Chrome 81 and earlier, the “default_applications” field in Chrome always required an absolute URL, which complicated deployment of the same file to multiple environments, e.g., test and production. For example, https://pay.google.com/gp/p/payment_method_manifest.json currently points to the “default_applications” value of “https://pay.google.com/gp/p/web_manifest.json”, which is an absolute URL.


In Chrome 83 and later, the “default_applications” field can be a relative URL, which is resolved relative to the final URL of the payment method manifest after all redirects, if any. For example, https://pay.google.com/gp/p/payment_method_manifest.json can be updated to point to the “default_applicatoins” value of “web_manifest.json” without loss of functionality, after all affected users have switched to Chrome 83.

4. More accurate NotSupportedError message on Android

To unify the error messages across all platforms, Android now prints out the list of requested payment methods in the error message when these methods are not supported.


In Chrome 81 and earlier, Android always printed the generic “Payment method not supported” error message, while other operating systems printed more specific messages, such as “Payment methods https://google.com/pay, https://apple.com/web-pay are not supported.”


In Chrome 83 and later, Android prints the same detailed error message as the other operating systems, i.e., the message that lists out the payment method names.

5. Bug Fix | CSP blocks manifest icon loading (crbug.com/1055360

Chrome 83 fixes crbug.com/1055360, which affects websites that use Payment Request API from an iframe to trigger web-based payment handlers. Affected websites may see warnings like this in the developer console:


Refused to load the image 'https://path/to/icon.png' because it violates the following Content Security Policy directive: "img-src 'self'"

6. Bug Fix | Use correct SecFetchSite header (crbug.com/1048201)

Chrome 83 sets the correct SecFetchSite header when downloading manifests to verify Android native payment handlers, instead of always using the strict “cross-origin” setting (crbug.com/1048201). This allows web servers hosting manifests to appropriately respond to the SecFetchSite headers without breaking web payments integration. 

7. Minimal UI experimental support

Chrome 83 adds support for the CanMakePaymentEvent.respondWithMinimalUI() method described in the Minimal UI explainer. This unblocks early developers to prototype Minimal UI. To test this feature:

  • Visit chrome://flags

  • Enable “Web Payments Minimal UI” (#enable-web-payments-minimal-ui)

8. Bug Fix | WebAuthn in Expandable Payment Handler Window (crbug.com/1051786)

Chrome 83 fixes crbug.com/1051786 that prevents WebAuthn to be used in the new experimental Expandable Payment Handler Window. With this fix, the Expandable Payment Handler Window matches all key features with the existing CCT-based payment handler window, and adds new benefits such as drag to expand. To test this feature:

  • Visit chrome://flags

  • Disable “Web Payments Minimal UI” (#enable-web-payments-minimal-ui)

  • Enable “Experimental Web Payments API features” (#enable-web-payments-experimental-features)

  • Live demo: https://rsolomakhin.github.io/pr/skip-ui/


Reply all
Reply to author
Forward
0 new messages