How would iDeal work?

[bdewater]

I’ve been playing around a bit with the Android/Chrome implementation and trying to imagine how the Dutch payment method iDeal could fit into Payment Handler. For those unfamiliar with it: it’s the most popular way of paying online in the Netherlands (57% market share) with over half of transactions being done on mobile (source: Currence, the company that owns iDeal).

The simplified way it currently works for ecommerce:

• The buyer checks out and selects their bank before clicking a ‘pay’ button.
• A transaction is requested (with the selected bank, a uniquely generated session identifier entranceCode, purchaseID and the merchantReturnURL) by the merchant on the iDeal network (gateway/acquiring bank). The response contains a issuerAuthenticationURL, purchaseID and transactionID.
• The merchant redirect the buyer to this issuer URL.
  • On mobile, the bank’s apps have an URL handler registered for the bank domains to continue the authorization process within the app.
  • If the app is not installed or the buyer is on desktop, the regular internet banking environment is used.
• The buyer logs in and authorizes, or cancels, the transaction and is redirected to the merchantReturnURL which can be a website or native mobile app link. The ec (entranceCode) and trxid (transactionID) fields are appended in the query string that allows the merchant to retrieve the initiated iDeal session for a purchase and the transaction status.

As it currently stands, it seems that Payment Handler could work with Dutch banking apps on Chrome/Android with no major changes to UX and use the same fields in the PaymentHandlerResponse details.

For service workers things are less clear for me:

• Service workers add no value, since all Dutch banks implement a form of two factor auth (SMS, card + reader device) and iDeal transactions require authentication for each transaction.
• I understand the reasoning for installation to filter out payment methods the buyer has, but IMO it is a step back from a buyer’s UX perspective compared to what there is today.
• If we must use a service worker, who would own/host it? With the way it works now it should probably be Currence and not one of the 61 payment gateways and 10 banks that participate in iDeal. But this would either confuse buyers with various deny any of these companies to innovate/experiment on their own
• Also how is a buyer expected to distinguish between a legit innovative gateway/bank that a merchant is using versus a malicious actor?

Hope this makes sense!

[rsolomakhin]

Hi Bart!

Thank you for submitting your query. This is a very interesting use case. Let's try to work it out together.

how is a buyer expected to distinguish between a legit innovative gateway/bank that a merchant is using versus a malicious actor?

I recommend that you define a URL-based payment method identifier with a payment method manifest that whitelists the legit gateways and banks. For example. you could name your identifier https://www.ideal.nl/webpay and place the following information in your manifest:

{
   "supported_origins": ["https://legit-gateway-1.nl", "https://legit-bank-2.nl"]
}

The browser will not allow payment via any payment app that does not come from the list of supported_origins that you control.

If we must use a service worker, who would own/host it? With the way it works now it should probably be Currence and not one of the 61 payment gateways and 10 banks that participate in iDeal. But this would either confuse buyers with various deny any of these companies to innovate/experiment on their own.

Given the setup that I propose, the gateways and banks are free to innovate using their own service workers and payment page flows. The service workers would live in such files as https://legit-gateway-1.nl/webpay/sw.js or https://legt-bank-2.nl/webpay/sw.js.

As for merchants, they would call into PaymentRequest as follows. (Please excuse my assumptions about the purposes of the fields in the iDeal protocol and who needs them when.)

const purchaseID = 'abcdef';
const request = new PaymentRequest(
  [{
    supportedMethods: 'https://www.ideal.nl/webpay',
    data: {entranceCode: '12345', purchaseID: purchaseID}
  }], shoppingCart, options);

Note that there's no need to specify a merchantReturnURL, because transactionID would be returned in response to request.show().

const response = await request.show();
console.log(response.methodName); // "https://www.ideal.nl/webpay"
console.log(response.details.transactionID);
// Send information to the merchant server for processing.
// I assume that's 'purchaseID' and 'transactionID'.

Since the merchant does not navigate away, the purchaseID would be unchanged and so does not need to be specified in the payment response.

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

The merchant can determine whether to use PaymentRequest or your existing flows by either checking request.canMakePayment() (returns false when no apps are installed) or by handling the rejection of the request.show() promise (rejected with NotSupportedError when no apps are installed). If any of these happens, then the existing iDeal flows should be used instead of PaymentRequest.

Let's continue this conversation and get your concerns addressed. I'm very happy to assist in any way possible. Have a great day!

Cheers, Rouslan

[bdewater]

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 by Willem Burgers) that has a nice sequence diagram of the protocol on page 9: There's also a demo available 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?

[rsolomakhin]

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) on its own.

[arisc097]

Hi Rouslan, if a payment process involves 2FA, what's the direction on W3C? For a Web / Desktop experience, if a one-time pin delivered out of band, how can that OTP be entered in this journey? Could you please clarify the original observation "Service workers add no value, since all Dutch banks implement a form of two factor auth (SMS, card + reader device) and iDeal transactions require authentication for each transaction." How can an OTP delivered via SMS be entered on the payment sheet?

[rsolomakhin]

@arisc097: Payment handlers can show an HTML page in the payment sheet that can prompt users to enter their username, password, PIN, etc.

Service workers add no value, since all Dutch banks implement a form of two factor auth (SMS, card + reader device) and iDeal transactions require authentication for each transaction.

I don't follow this line of reasoning. For example, one way that service workers provide value is through ability to update the registered payment instruments on user device in the background, without the need for the user to re-visit the banking website. @bdewater: Would you agree?

[adrianhopebailie]

@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)

[ianbjacobs]

@adrianhopebailie, thanks for the write-up!

Regarding option 1 and potentially being tricked by a malicious 3rd-party payment app to enter account information. First, my understanding from previous conversations about this is that, under PSD2, those credentials are NOT considered to be sensitive. I think there is, furthermore, an expectation that strong user authentication will be required, so that even if the credentials are phished, without strong authentication the payment will not be authorized.

Ian

[glelouarn]

Discussing with a PSD2 NCA (National Competent Authority) on that topic, please note that there are exemptions for SCA (amount, number of payments, low level of risk...) and as a consequence, authority are requesting engagement from licensed TPP on how they will manage sensitive data such as credentials (HSM, encrypted database...).

[ianbjacobs]

Rouslan and I added some text to our Payment Method Good practice document: https://github.com/w3c/payment-request-info/wiki/PaymentMethodPractice#payment-handler-ecosystem

I propose we close this issue.

Ian

[bdewater]

Thanks for all the insightful comments! I've been a bit busy lately but will get back to this in the beginning of next week.

[ianbjacobs]

Closing this issue as there has not been specific issues with the spec raised, and the spec has evolved since this was raised. @bdewater, it would be great to know whether you have continued to do experiments with the iDeal payment method, especially now that Chrome (since v68) supported Payment Handler API.

[bdewater]

Thanks @ianbjacobs - our experimentation with iDeal can be found here: https://www.w3.org/2018/08/shopify.html 🙂

[ianbjacobs]

@bdewater, thanks for the helpful link! 😉

[muzammilmuzamil]

Hi, I'm using https://www.targetpay.com/ideal/check and I am unable to access my trxid on my page URL. I am really stuck All is done accurately ,Payment is updated in database, But after payment done , i cant access the TRXID in my URL ..... here is the requesting code. //IDEAL CHECK if(isset($_REQUEST['trxid'])) {

$trx = $_REQUEST['trxid'];

$bbdata = array( 'rtlo' => '151309', 'once' => 1, 'trxid' => $trx, 'once' => 1 );

// send a request to example.com (referer = jonasjohn.de) $iresult = PostRequest( "http://www.targetpay.nl/ideal/check", "http://www.gambinospel.nl/test/", $bbdata );