W3C home > Mailing lists > Public > public-payments-wg@w3.org > June 2019

Another nice feature of Payment Handler

From: Adrian Hope-Bailie <adrian@coil.com>
Date: Mon, 10 Jun 2019 19:58:44 +0200
Message-ID: <CAFYU5zawHS48AKr7T5n6mXEi2S_U=iCJp68HNyAtu8+T8OVFpw@mail.gmail.com>
To: Payments WG <public-payments-wg@w3.org>
We've been doing some experiments with PH API the last few months and came
across this cool feature that may not be obvious to all.

Many online payment systems/wallets require the user to be redirected to
the wallet's origin where they will first login (if they are not already)
and then approve the payment. Increasingly this is part of a generic
delegated authorization flow such as OAuth 2.0 (see the Open Banking APIs
in Europe).

For security reasons many OAuth 2 or similar authorization providers block
rendering in an iframe. This means that if a user wants to pay with a
wallet then the merchant must redirect the user to the wallet's origin in
the same tab (moving the context away from the checkout and requiring that
the session is cached and can be rehydrated later) or show the wallet in a
pop-up (and hope that the pop-up isn't blocked).

In contrast we built a great POC that rendered the wallet in the Payment
Handler window, meaning it is the top-level context and the wallet will not
block the user.

The user is shown the rich wallet experience (login, authorize the payment
request) and then the window disappears as they are returned to the
checkout page which has never lost context.

When we tried the same thing on browsers that don't support PH API our
fallback (an iframe in a lightbox) fails for many wallets due to their
security configurations.
Received on Monday, 10 June 2019 17:59:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:32 UTC