Upcoming changes to payment method manifests.

If you don’t make payment apps, you can stop reading now.

TL;DR: Verify that your payment method manifest can respond to HTTP GET.

Summary

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
<https://w3c.github.io/payment-method-manifest/#format>.

Chrome 83 is currently available in Chrome Canary and Dev channels. It is
expected to start rolling out to the Stable channel around the 19th of May.

Background

When Chrome originally implemented payment method manifests, Chrome was
making an HTTP HEAD request for the payment method identifier to download
its payment method manifest and web app manifest. The HTTP headers returned
from the HTTP HEAD request were parsed for the Link
rel=”payment-method-manifest” header, which was then followed. Absence of
this header disabled payments.

Some websites popular among web developers do not offer header
customization, however. In particular, this presented a problem for hosting
pages on GitHub, where only content can be defined by web developers. As a
result, web developers had to resort to using more than one hosting
service: one for simplicity and one for powerful features required for
hosting the Link rel=”payment-method-manifest” header.

Multiple members of the Web Payment community have requested that payment
method manifests can optionally be hosted directly at the payment method
identifier URL, instead of always requiring the indirection via the Link
rel=”payment-method-manifest” link. We have updated the spec
<https://github.com/w3c/payment-method-manifest/pull/37> accordingly and
this email is the result of implementing
<https://chromiumdash.appspot.com/commit/4ab8845ffc07354385e6459d03b46d19881ca046>
this request.

How to check if you’re impacted

Check that HTTP GET request for your payment method identifier either
returns the payment method manifest:

    curl --silent https://example.com/web-pay

Or that it includes a Link rel=”payment-method-manifest” HTTP header:

  curl --silent --include https://example.com/web-pay | grep --ignore-case
link

If you receive an HTTP response code that is not either 200 or 204, then
please update your server to allow GET requests.

The old methodology of checking curl --silent --head
https://example.com/web-pay | grep --ignore-case link is no longer correct.

Examples

Google Pay, Tez, and BobPay all support the HTTP GET requests:

$ curl --silent --include https://pay.google.com/about | grep --ignore-case
link

link: <https://pay.google.com/gp/p/payment_method_manifest.json>;
rel="payment-method-manifest"

$ curl --silent --include https://tez.google.com/pay | grep --ignore-case
link

link: <https://tez.google.com/pay/payment-method-manifest.json>;
rel="payment-method-manifest"

$ curl --silent --include https://bobpay.xyz/pay | grep --ignore-case link

link: <https://bobpay.xyz/pay/payment-manifest.json>;
rel="payment-method-manifest"

Wait, I have more questions!

Please reply to this email and we will get your issues resolved.

Pay on!

Rouslan