...

The same security measures used for the Banking Environment of the Issuers apply to the iDEAL API that is used for iDEAL Transactions. The Banking Environment of the Issuers must meet strict security standards to ensure that iDEAL Transactions by Users can be carried out securely.

3 iDEAL

...

Transaction

3.1 Initiating an iDEAL Transaction

...

3.2  Process flow for iDEAL Transactions

An iDEAL Transaction for a single iDEAL Payment is the basis for the iDEAL Transaction flow. The actual iDEAL Transaction flow that the User follows, depends on:(i)     the device the

1. The connection the Acquirer offers to its iDEAL Participants (see paragraph 3.4):

   1. Via its own technical interface (Route 1 - see R1a & R1b in flow below).

   2. Via a Direct Connection

      1. For its CPSPs and C2C Providers Route 2 is applicable (see R2 in flow below), including iDEAL Transaction initiated by their clients (Merchants and Private Beneficiaries).

      2. For its Merchants Route 3 is applicable (see R3 in flow below).

2. Furthermore the flow depends on:

(i)     the device the User is using when initiating an iDEAL Transaction;
(ii)    whether a User has already registered an iDEAL Profile;
(iii)   whether a User with an iDEAL Profile is recognised by the iDEAL Hub (via an iDEAL User Token or a browser cookie); and
(iv)   whether or not the Acquiring Participant or Merchant has a direct connection with the iDEAL Hub.

...

^{Figure 2: Indicative iDEAL Transaction flow}
* iR2P = iDEAL Request to PayThe full iDEAL Transaction flow broadly follows the following steps (as further specified in the iDEAL API Specifications):

1. Shopping process & payment preference: The User places an order with a Merchant and chooses iDEAL as payment method. If the Merchant makes use of iDEAL User Tokens, the Merchant (or CPSP/Acquirer) shows the preferred Issuer and the preferred IBAN registered in the iDEAL User Profile of the recognised User. The Merchant or Private Beneficiary sends the iDEAL Transaction – via the Direct Connection or through a CPSP/Acquirer/C2C Provider – to the iDEAL Hubpayment preference: The User places wants to pay to a Merchant or Private Beneficiary and chooses iDEAL as payment method*. The iDEAL Transaction will be sent to the iDEAL Hub either via the technical interface of the Acquirer or via the Direct Connection, in accordance with the iDEAL API Specifications (or the technical interface offered by the Acquirer).

2. Transaction initiation: An iDEAL Transaction is initiated at the iDEAL Hub, which responds to the Acquiring Participant with a redirect URL to the iDEAL Checkout Page or the Issuer.

3. Customer recognition / Issuer selection: The User is redirected by the Merchant (or CPSP/Acquirer) to the iDEAL Checkout Page, where the User can choose an Issuer or scan a QR code (depending on the web/app context). Alternatively, if the iDEAL Profile is recognised (by a browser cookie or iDEAL User Token), the User may be redirected to its preferred Issuer or receive a push notification from its preferred Issuer to authorise the iDEAL Transaction.

4. Issuer Authorisation: The User is presented with the iDEAL Transaction details at the Issuer, where the User authorises the iDEAL Transaction;

...

The Acquirer must connect its Acquiring Participants (Merchants, CPSPs and C2C Providers) to the iDEAL Hub. he The Acquirer can offer two connections:

1. Via its own technical interface, which can be a (backwards compatible) extension of the iDEAL technical interface.

   • Before connecting the Acquiring Participant (or implementing new versions), the Acquirer must implement and test those versions with its Acquiring Participants. In addition, the Acquirer must provide its own discretionary Merchant implementation guide to its Acquiring Participants.

2. Via Direct Connection in accordance with the iDEAL API Specifications for Acquiring Participants, the iDEAL API Specification‘Direct Connection Acquiring Participant’.

   • Before connecting (or implementing new versions) a CPSP or C2C Provider to the iDEAL Hub, the Acquirer must inform Currence via implementation@ideal.nl. The CPSP / C2C Provider must have successfully completed all tests as described in theTest Strategyand the test results must be reported via the form ‘In control Statement’ and this form must be approved by Currence before go-live.

   • Before connecting (or implementing new versions) a Merchant to the iDEAL Hub, the Acquirer must check if the Merchant meets the requirements as set out in the iDEAL R&R and any further requirements set by Currence in the MACC (Merchant Admission and Connection Conditions) document.

...

A Merchant will pay a fee to his Acquirer or CPSP.

...

^{Figure 3: Fee model}
* A Merchant can have an iDEAL Contract with either an Acquirer or a CPSP

4.2 Contract model

...

^{Figure 4: Contract model}
* A Merchant can have an iDEAL Contract with either an Acquirer or a CPSP

The contract model developed by Currence forms the basis of the contents of the iDEAL R&R. This is represented in Figure 4.
The various Roles in the Schemes are explained on the basis of this contract model in paragraphs 4.2.1 up to and including 4.2.8.

...