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
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.
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.
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.
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.
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:
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.
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)
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/