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

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](https://w3c.github.io/payment-method-id/#url-based-payment-method-identifiers) with a [payment method manifest](https://w3c.github.io/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:

```json
{
   "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.)

```javascript
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()`.

```javascript
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

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