Re: Upcoming changes to payment method manifests.

Yes, that's a great suggestion, Anders! I've filed https://crbug.com/1069954
to keep track of progress on that.

On Fri, Apr 10, 2020 at 10:11 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> This is great news Rouslan!  Thanx!
> As you know I have had considerable problems with this part which even
> required factory reset of the device to be "cured".
> My current scheme (which seems to work...) for Android native looks like
> this:
> In https://mobilepki.org/w3cpay/payment-manifest.json you'll find:
> {
>    "default_applications": ["
> https://mobilepki.org/w3cpay/payment-manifest.json"],
>    "related_applications": [{
>      "platform": "play",
>      "id": "org.webpki.mobile.android",
>      "min_version": "1",
>      "fingerprints": [{
>        "type": "sha256_cert",
>        "value":
> "85:0B:99:03:54:CE:71:6E:18:7C:43:1F:7F:C1:F1:5E:9B:81:84:1D:36:CE:F3:F6:E2:97:15:70:79:7F:B0:F7"
>      }],
>      "url": "
> https://play.google.com/store/apps/details?id=org.webpki.mobile.android"
>    }],
>    "supported_origins": "*"
> }
>
> I got that from a previously listed application on your github.
>
> Question: If the URL for the resource holding "default_applications"
> equals that of the argument (as in my case), shouldn't a single GET should
> suffice?  That would be a HUGE improvement over the current 6 accesses.
>
> Best regards,
> Anders
>
> On 2020-04-10 12:54, Rouslan Solomakhin wrote:
> > 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 linkis 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
> >
>
>