- From: Rouslan Solomakhin <rouslan@google.com>
- Date: Fri, 10 Apr 2020 06:54:39 -0400
- To: Web Payments Working Group <public-payments-wg@w3.org>
- Message-ID: <CAMMzaWGRNUb0invKzV55T0vLmiN4TiCTWTRmZdF8eiGbs-KprQ@mail.gmail.com>
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
Received on Friday, 10 April 2020 10:55:05 UTC