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

@bdewater the design is intended to accommodate different ecosystems and your questions are a useful way of highlighting some of the pros and cons of choosing how to support a payment method in different ways.

Ultimately this often boils down to a compromise between the best and most open technical solution and the most pragmatic. To deploy iDeal one could do 3 things:

## Option 1

Use the very generic "credit-transfer" payment method where the request is filtered by network and the merchant only specifies "ideal" as a supported credit transfer network.

This has the advantage of placing no limits on who can deploy a payment handler to support this scheme so there is no dependency on Currence.

It also has the possible advantage of making the burden for pan-European banks lower as they can publish payment apps that support this payment method and these will work for other credit transfer networks too.

The disadvantage is that malicious actors may try and trick users into entering their bank details into a payment handler application that is malicious and used to steal their details. There are ways to avoid this but let's skip all those details for now.

## Option 2

Currence manages the payment method and defines a URL that can be used as the payment method identifier and hosts a manifest to restrict who can publish iDeal payment handlers.

Described above.

## Option 3

Banks each define a payment method identifier of their own and all merchants need to explicitly add support for all banks.

Also described above.

======

In the case of iDeal option 2 is probably best because there is a central authority for the scheme and they should manage the way the scheme adopts payment request.

They could also publish a payment handler which would mean less work for the banks to do (although it wouldn't preclude the banks from having a payment handler that supports iDeal and possibly other payment methods too).

When a use visits a merchant that supports iDeal for the first time the Currence-published handler could be installed by the merchant using an iframe or script. When the user attempts to check-out the user may be prompted to install the iDeal handler and then go through the enrollment process through the UI of that handler, including defining where they bank etc.

As described by @rsolomakhin there is no longer a need to exchange URL's and perform redirects in the background as the user will simply interact directly with their bank via the payment handler UI.

Another possibility is that the iDeal app has no UI and simply posts the transaction details to the user's bank on subsequent payment requests and this causes the bank to push a message to the bank app on the user's phone where the transaction is authorized.

The payment handler is a very powerful event-driven service with the ability to spawn a UI and gather user input or interact directly with other services via HTTP requests.

Most importantly the payment handler is in a different origin (security domain) to the merchant so it can maintain state across multiple merchant sites. This should make the iDeal checkout experience better (not worse)

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