> An individual bank or payment gateway could not start experimenting with Payment Handler before Currence agrees to do this.
They can create their own payment methods such as `https://individual-bank-1.nl` and partner with the merchant to use this payment method identifier through the PaymentRequest API before Currence is ready.
> Only the second one would work with Payment Handler because the payment method manifest cannot whitelist every possible store?
Actually, the whitelisting in the payment method manifest is not for merchant stores, but for the banks and gateways, which is a much more manageable number of players.
> Sequence diagram of the protocol on page 9.
Thank you for the diagram. It clarifies a lot. The current flow will have to be modified a bit.
For example, the client's device would have a previously installed client bank's payment handler, which would be the only option shown in the browser payment sheet, thus eliminating the steps of `DirectoryRequest` and `DirectoryResponse`.
Because the client bank's payment handler receives the `PaymentRequestEvent` when it is selected, there is no need for the merchant bank to retrieve the `issuerURL` from the client bank. The payment handler can call `paymentRequestEvent.openWindow(url)` from its payment handler.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/251#issuecomment-372341582