[Openid-specs-fapi] W3C Payment Handler applied to Open Banking/OAuth2

Anders Rundgren anders.rundgren.net at gmail.com
Mon Jun 10 18:29:11 UTC 2019


F.Y.I.
-------- Forwarded Message --------
Subject: 	Another nice feature of Payment Handler
Resent-Date: 	Mon, 10 Jun 2019 17:59:24 +0000
Resent-From: 	public-payments-wg at w3.org
Date: 	Mon, 10 Jun 2019 19:58:44 +0200
From: 	Adrian Hope-Bailie <adrian at coil.com>
To: 	Payments WG <public-payments-wg at 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.


More information about the Openid-specs-fapi mailing list