Re: [w3c/payment-handler] How would iDeal work? (#251)

Hi Rouslan, thanks for your quick response!

> For example. you could name your identifier https://www.ideal.nl/webpay

That was my thinking too with suggesting Currence could be hosting this. It would however mean that an individual bank or payment gateway could not start experimenting with Payment Handler before Currence agrees to do this, which is where my concern around confusion comes from if certain parties decide not to wait and create their own thing. I guess in the long term this would eventually settle down and thus maybe is not such a big deal.

> I'm not sure what `issuerAuthenticationURL` does. Could you explain?

This is the internet banking URL returned for the buyer's selected bank in the transactionRequest. Selecting my own bank for example, it would be something like `https://www.abnamro.nl/nl/ideal-betalen/index.html?randomizedstring=4954102471&trxid=0020001873714550`.

I've found this master thesis ([Investigating the security of the iDEAL payment system](https://www.ru.nl/publish/pages/769526/z-scriptie_willem_burgers.pdf) by Willem Burgers) that has a nice sequence diagram of the protocol on page 9: 
![screen shot 2018-03-09 at 2 14 00 pm](https://user-images.githubusercontent.com/496367/37225505-d18ed41e-23a4-11e8-8b07-f88390b31603.png)
There's also a [demo available](https://www.ideal.nl/demo/en/) that might help to understand what it all looks like from a buyer's perspective.

I left out the `DirectoryRequest`/`issuerList` (fetching and showing an up to date list of available banks to the buyer, this may be cached) for brevity in my initial example, but that made it less instead of more clear. There's two main ways of integrating iDeal for a merchant:

1. **bank selection on their checkout:** merchant backend creates transaction, redirects buyer to the selected bank, redirect buyer directly back to their store, realtime transaction status check,  etc.
2. **checkout redirect to payment processor:** where all of the above happens, but the buyer first sees the confirmation page of the processor before being redirected back to the store.

The first option is a bit more complex to integrate but it is considered the superior experience since there's no visible third party and involves less redirection. But unless I'm mistaken, only the second one would work with Payment Handler because the payment method manifest cannot whitelist every possible store?

-- 
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-371958014