- From: Adrian Hope-Bailie <adrian@coil.com>
- Date: Mon, 10 Jun 2019 19:58:44 +0200
- To: Payments WG <public-payments-wg@w3.org>
- Message-ID: <CAFYU5zawHS48AKr7T5n6mXEi2S_U=iCJp68HNyAtu8+T8OVFpw@mail.gmail.com>
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