Terms and conditions

Terms and conditions for provision of the iDEAL Merchant Integration Guide:

1. Scheme Owner Currence iDEAL B.V. provides the iDEAL Merchant Integration Guide to Acquiring banks which distribute it to (potential) Merchants and Payment Service Providers to enable them to form a good idea of what the implementation of the iDEAL product would involve and assess how any future use of iDEAL could affect their business operations.

2. Currence iDEAL B.V. reserves the right to deny access to the iDEAL Merchant Integration Guide to (potential) Merchants and Payment Service Providers on reasonable grounds, in consultation with the Acquiring bank with which the Merchant/PSP has a contract.

3. The iDEAL Merchant Integration Guide is explicitly and exclusively provided for the purpose mentioned above, and no other use is permitted. No rights can be derived from the information provided in this document or the accompanying notes. Currence iDEAL B.V. is in no way liable for the consequences of later changes to the iDEAL Standards or the iDEAL Merchant Integration Guide. If banks or other interested parties take decisions and/or make investments on the basis of the information that they obtain via the iDEAL Merchant Integration Guide, Currence iDEAL B.V. accepts no liability for this whatsoever.

4. The iDEAL Merchant Integration Guide is based on the information in the iDEAL Standards documents. In the event of any discrepancy between the iDEAL Merchant Integration Guide and the iDEAL Standards documents, the text in the iDEAL Standards documents shall prevail.

For any questions concerning this document or requests for further information, please contact your iDEAL acquiring bank or Collecting Payment Service Provider

Contents

1. Introduction 

2. Overview 

2.1 What is iDEAL?

iDEAL was developed by the Dutch banking community in order to facilitate easier payment for online products and services. iDEAL enables direct and secure real-time online payments between bank accounts of Consumers and iDEAL Merchants.
The main characteristics of iDEAL are:

• Real-time payment through accepted and trusted Internet banking that is already familiar to Consumers

• Real-time payment authorisation for the Consumer and real-time confirmation to the Merchant by the Acquiring bank, followed by the irrevocable transfer of funds to the Merchant

• Suitability for online delivery (e.g. downloads, mobile top-ups), offline delivery (e.g. goods) and time-critical payments (e.g. airline tickets)

• Offers the flexibility to make payments for many different purposes (e.g. charitable donations, telephone/e-mail orders)

In practice, nearly every Consumer that uses Internet banking with one of the Issuing banks that support iDEAL can pay with the iDEAL payment method.

2.2 What is iDEAL Mobile?

iDEAL is an online payment method for the Dutch market. Although it was originally developed for use with internet banking services, it is now also possible for Issuers to create iDEAL implementations based on mobile banking services like mobile web sites or mobile apps. This is called iDEAL Mobile.
The main characteristics of iDEAL Mobile are:

• There are no changes in the messages sent between Consumer bank and Merchant bank and no changes in messages sent between Merchant and bank;

• Merchant and Consumer do not need to take extra steps for a mobile iDEAL transaction. The redirecting of the Consumer to the mobile banking channel is done automatically by the Consumer's bank; For banks that support iDEAL in their mobile banking app, the Consumer can choose whether to pay using the mobile web browser or the mobile banking app.

• iDEAL Mobile is based on the same mechanisms to ensure trust, security and convenience as used in a desktop environment. In cases mobile technology does not support the same technical security measures as a desktop computer the bank will implement alternative measures to compensate.

Every Consumer that uses internet banking with one of the Issuing banks that supports iDEAL can pay with the iDEAL payment method on a mobile device (although it may be necessary for a Consumer to download and register a mobile application). Those Issuers that do not (yet) have an iDEAL Mobile implementation or that have an implementation that doesn't reach the majority of Consumers will still be able to process transactions through their regular (desktop focussed) iDEAL pages on a mobile device's browser.

2.3 Four party model

There are at least four parties involved in an iDEAL transaction. First there is the Consumer that buys a product or service online. The Consumer buys this from a Merchant that offers the iDEAL payment method; usually this is a web Merchant. The web Merchant is usually referred to as "Merchant" by the banks.The Consumer has a relation with his bank where he can execute iDEAL payments in his Internet banking environment. Within iDEAL, the Consumers' bank is called the Issuer. The Merchant has a relation with his bank in order to accept iDEAL payments. Within iDEAL, the Merchant's bank is referred to as the Acquirer. As stated in the introduction, this document will only cover the iDEAL messages that are exchanged between the Merchant and the Acquirer. However, the iDEAL messages that are exchanged between the Acquirer and the Issuer will be briefly explained if necessary to provide a good understanding of the entire iDEAL transaction.

Besides the four parties mentioned that are always involved in an iDEAL transaction, additional parties can be involved. The Merchant can, for example, use a Payment Service Provider (PSP) to establish the connection with its Acquiring bank. When this PSP receives/collects the payments before they are paid to the Merchant, this is called a "Collecting PSP" (CPSP). In this case the Collecting PSP acts as the Merchant for the purpose of the iDEAL payments and holds the iDEAL contract with the Acquiring bank on behalf of one or multiple other Merchants. Other roles related to iDEAL payments are out of scope for this document. (Other roles include Distributing PSPs (DPSPs) / Technical PSPs (TPSPs), which act as a software provider for the merchant and can provide a technical connection between merchant and Acquiring bank. They do not play a part in the payment process itself and do not have a contract with a bank and are therefore not included in the figure). The figure shows the parties in this model and their relations.

Open

 

A demo of an iDEAL payment can be found online at https://www.ideal.nl/demo/en/. A typical iDEAL transaction comprises (request-/response-) XML messaging and browser redirects, which handle the initiation, and processing of the transaction in a particular sequence, with all parties involved being informed on the status of the transaction. 

The steps in this transaction are shown in the figure.

• By using the Directory protocol the Merchant sends a DirectoryRequest to the Acquirer. This is a request in XML format to obtain the list of participating Consumer banks (Issuers) from the Acquirer. The Acquirer will provide this list back to the Merchant by sending back the DirectoryResponse. The Merchant will show the list of banks, which was sent in the DirectoryResponse to the Consumer. The Consumer will choose his bank from this list. The Directory protocol is explained in more detail in chapter 4.

• By using the Payment protocol the Merchant sends a TransactionRequest to the Acquirer, containing the Issuer chosen by the Consumer, the amount, a purchase id and other transaction details. This message also contains the merchantReturnURL. This URL is used by the Issuer to redirect the Consumer back to the Merchant's website when he has completed the payment process. After the Acquirer has received the message from the Merchant, he sends a separate message to the Issuer that was selected by the Consumer. In return, the Issuer responds with a message that contains the issuerAuthenticationURL (and other data). The Acquirer passes this issuerAuthenticationURL together with a unique TransactionID back to the Merchant via the TransactionResponse message, which is the response to the TransactionRequest. The Merchant now redirects the Consumer to the issuerAuthenticationURL, which refers to the page of the Internet banking portal where the Issuer provides the appropriate prefilled iDEAL transaction details. The Consumer authorizes the payment and receives a confirmation from the Issuer. Then the Consumer is redirected back to the website of the Merchant via the merchantReturnURL. The entire Payment protocol and the 2 redirects are further described in chapter 5.

• Finally the Merchant initiates the Query protocol by sending a StatusRequest message to the Acquirer. The Acquirer will request the transaction status, if necessary, from the appropriate Issuer and returns the status to the Merchant. If all steps in the transaction were successful this status message contains the proof of payment for the Merchant. Chapter 6 contains more detailed information on the Query protocol. Instead of a regular response to the messages mentioned above, it is also possible that an ErrorResponse is returned. This can be the case if the request contains an error, or if an error occurs during the processing of the request. The ErrorResponse messages are discussed in chapter 7.

Open

 

The next chapter describes the general format of iDEAL messages. In subsequent chapters the three protocols are discussed in more detail.

3. Message format 

3.1 General

This chapter contains a description of the general message structure for the Directory protocol, the Payment protocol and the Query protocol. The subsequent sections will describe the specific fields within the XML messages for each protocol in more detail.

3.2 Header format

The following HTTP header is used for all messages:

• All messages must comply with the HTTP 1.1 standard, as defined in RFC 2616 of W3C. For more information: http://www.w3.org/Protocols/rfc2616/rfc2616.html

• Each XML request message must be sent as the body of a HTTP POST message.

• Each XML response message must be sent as the body of a HTTP 200 OK message.

The following XML header is used for all messages:

3.3 XML Namespace declaration

XML namespace declaration in iDEAL messages can be done in any way allowed by the XML standards (default namespace declaration or namespace qualification/prefixes).
Most of the example messages given in this document use the default method of namespace declaration. At the end of appendix B one example is given of a message with namespace prefixes. Both types of messages are valid and must be accepted.

3.4 Conventions for empty fields

In iDEAL an XML tag for an optional or conditional field is either:

• present (in which case, the tag must be filled with a valid value)

• or not present at all.

XML tags without content are not allowed and will result in an error message.

3.5 Merchant information registered with Acquirer

Besides the transaction information that the Merchant provides in the iDEAL messages described in the following chapters, the Acquirer also adds information to the iDEAL messages from its own records. Some of this information needs to be registered by a Merchant with the Acquirer before the Merchant can send in its first iDEAL transactions. The relevant iDEAL information is described below:

^{Merchant information registrered by the acquirer.}

4. Directory protocol 

4.1 General

The Directory protocol allows a Merchant to fetch an up to date list of participating Issuers from his Acquirer, which can be presented to the Consumer. In case of changes in the list of Issuers, the Directory protocol will automatically take care of the update and make it visible in the Issuer lists of all Merchants.

It is not allowed to perform the Directory protocol for each transaction. Since the list of Issuers only changes occasionally, it is sufficient to execute the Directory protocol on a daily basis and check if the list has changed based on the directoryDateTimestamp. If the Issuer list has changed, the latest version has to be saved and used for any subsequent transaction. Acquirers will normally also inform all Merchants (e.g. by email) about changes in their Issuer list. The Directory protocol should at least be executed once a month.

The Directory protocol (like the Payment protocol and the Query protocol) consists of a HTTP POST request from the Merchant to the Acquirer, followed by a HTTP response. The DirectoryRequest is sent to the URL that is provided to the Merchant by the Acquirer for this specific purpose. This URL can be different from the one that is used for the TransactionRequest and the StatusRequest, but it can also be the same URL.

The Acquirer validates the authenticity of the message sent by the Merchant by verifying the signature in the message. In order to validate the Acquirer will need the Merchant's Certificate also containing the public key. The way in which the public part of the Merchant certificate is communicated with the Acquirer varies per bank. Please refer to chapter 8 for more information on authentication and security.

4.2 DirectoryRequest

The DirectoryRequest consists of an XML message that is sent to the Acquirer with HTTP POST (see chapter 3 for more information). The table below shows all fields and formatting of the DirectoryRequest. For legenda see 3.5.

Fields of the DirectoryRequest

*SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

Example Message

4.3 DirectoryResponse

The Merchant will receive the DirectoryResponse as a reply to the DirectoryRequest. This XML message contains a list of Issuer names with their corresponding issuerID (BIC). Issuers are grouped by country. The banks in the Merchant's country of choice may be presented at the top in the Issuer selection list, the rest are sorted alphabetically by country, then by bank name. The table below shows all fields that appear in the DirectoryResponse message. For legenda see 3.5.

Fields of the DirectoryResponse

*SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

Example Message

4.4 Presentation of the Issuer selection list

To ensure that the Consumer experience of an iDEAL transaction is consistent and recognizable through all Merchant websites; all Merchants have to comply with certain presentation standards:

If a Merchant learns via the iDEAL Notification System (Central Reporting tool for iDEAL banks to state system non-availability) or via error messages received from the Acquiring bank that a particular Issuing bank is currently not available, the Merchant may display a message on its website informing Consumers that the particular bank is not available. In other words, it is perfectly permissible to display a message conveying such information but it is not permissible to temporarily remove or grey out the Issuing bank concerned from the Issuer selection list. 

5. Payment protocol 

5.1 General

The Payment protocol initiates the exchange of messages of the actual iDEAL payment initiation. After the Consumer has chosen iDEAL as a payment method and has selected his bank, the Merchant sends a TransactionRequest to the Acquirer. Within the iDEAL standards this message is referred to as the AcquirerTransactionRequest. The Acquirer replies to the TransactionRequest with a TransactionResponse. This TransactionResponse will also (among other fields) contain the issuerAuthenticationURL. This URL will redirect the browser of the Consumer to the Issuer in order to let him authorize the payment.

5.2 TransactionRequest

The XML message sent by the Merchant to the Acquirer to initiate the payment contains the fields shown in below table. For legenda see 3.5.

Fields of the TransactionRequest

*SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

Example Message

5.3 TransactionResponse

If everything goes well the Acquirer will reply to the TransactionRequest with the TransactionResponse. The table below shows all fields of the TransactionResponse message. For legenda see 3.5.

Fields of the TransactionResponse

*SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

Example Message

5.4 Errors when executing Transaction Protocol

A number of errors may occur when executing the iDEAL Transaction Protocol. These may be related to unavailability within your own web store environment (Merchant), the Acquirer environment or the Issuer environment.
The following situations may occur:

• The iDEAL payment cannot successfully be initiated.

• You receive an error response (report 'X') from your Acquirer within the set time-out period.

• You do not receive any response within the set time-out period.

In all of the above cases, the transaction protocol cannot be successfully executed. This means it is not possible for the iDEAL payment to take place at that time. In these cases, except when you received a consumermessage in the ErrorResponse, it is recommended that you display a message along the following lines to the Consumer: 'Unfortunately, it is not possible to pay using iDEAL at this time. Please try again later or use an alternative method of payment'. Or in Dutch:  'Op dit moment is betalen met iDEAL helaas niet mogelijk. Probeer het op een later moment nog eens of gebruik een andere betaalmethode'.

5.5 Redirect to the Internet banking environment (issuerAuthenticationURL)

After receiving the TransactionResponse the Merchant has to redirect the Consumer to the issuerAuthenticationURL of the selected Issuer bank, as stated in the TransactionResponse message. If the Merchant's page contains HTML frames, these will be removed by the Issuer ('frame busting'). If and when the Consumer returns to the Merchant's website (with the merchantReturnURL), the Merchant will have to completely rebuild its own page for showing the Merchant's order confirmation.
For privacy reasons it is not allowed to include any personal and order information of the Consumer in the HTTP referer header (contains information of the URL that the Consumer was redirected from) , when redirecting the Consumer to the chosen bank.

5.6 Redirect to the Merchant environment (merchantReturnURL)

After the Consumer has performed the necessary steps at the Issuer he will be presented with a 'Continue' button that must redirect him back to the website of the Merchant with the merchantReturnURL as supplied in the TransactionRequest.
Two GET parameters are appended to this URL: the entranceCode (see paragraph 5.2) with 'ec' as GET parameter name, and the transactionID (see paragraph 5.3) with 'trxid' as GET parameter name. It is also possible for a Merchant to add additional parameters. For example, if the Merchant defines the merchantReturnURL as follows:

http://www.webshop.nl/processpayment?producttype=electronics

the final URL will look something like:

http://www.webshop.nl/processpayment?producttype=electronics&trxid=0010123456789012&ec=4hd7TD9wRn76w 

The entranceCode field, as previously described in paragraph 5.2, should contain a unique value, with the object of preventing message 'sniffing'. Use of the same entranceCode each time would allow malevolent individuals to intercept the data from the merchantReturnURL and make fraudulent use of this information. This is why using unique values for the entranceCode is extremely important.

5.7 Errors during execution of redirects

The following errors may occur during execution of the redirect to the online banking environment (Issuer), the execution of the payment at the Issuer and/or the redirect back to your (Merchant) environment:

• The bank page is unavailable as a result of which the Consumer cannot pay, but neither can they be properly redirected to your confirmation page.

• The bank page is available but the Consumer cannot (after paying or otherwise) be properly redirected to your confirmation page.

In both situations the Consumer cannot (as the result of a disturbance) return to your confirmation page in the normal way. In that case the Consumer can return to your website by using the 'back' button or entering the URL, for example. If the Consumer can be identified (for example because he or she has logged into the Merchant environment or via the browser session), the advice in these situations is to check the status of the payment and notify the Consumer of this.

If the Consumer can be identified and the status can be checked but is found to still be 'open', we recommend that the Consumer is shown the following message: We didn't receive a confirmation from your bank. When you see that your payment has been completed, we will deliver your order after we have received the payment. Or in Dutch: We hebben van uw bank nog geen bevestiging van uw betaling ontvangen. Als u in uw Internetbankieren ziet dat uw betaling heeft plaatsgevonden, zullen wij na ontvangst van de betaling tot levering overgaan.

If the Consumer cannot be identified, your system should check the status of the payment at the end of the expiration period. In such situations, we also recommend that the status of the payment is reported to the Consumer – as soon as it has become final – in one of the ways indicated below:

• By e-mail.

• On your website, for example in the account of the Consumer or via the Consumer's browser session.

5.8 Four different scenario's for completion of iDEAL Mobile payment

Four different scenario's that are possible in case of an iDEAL Mobile payment have been specified. There are four different scenarios possible because either the Issuer or the Merchant can both use a (mobile) web page or a mobile app.

_{Four different scenario’s for the completion of an iDEAL mobile payment}

5.9 Performance and time-out of payment message

The performance of the Issuer and Acquirer systems has a direct influence on the Consumer's user experience. Therefore iDEAL sets a target time and time-out for the transaction response message. For a Merchant the relevant target time and time-out apply to the communication with its iDEAL Acquirer:

^{Performance requirements (for the 95th percentile)}

The target time is the time (in seconds) within which a TransactionResponse message should be received by the Merchant after sending a TransactionRequest. The time-out is the length of time after which the Merchant should no longer expect a response (most likely an error has occurred) and should act accordingly (for example by displaying an appropriate error message to the Consumer). 95^th percentile is a statistical term indicating that 95% of transactions in a tested sample should be within the set target time.

5.10 Booking of payments

An iDEAL Transaction Request that has been succesfully authoirzed by the Consumer will eventually result in a payment from the Consumer's account at the Issuing bank to the Merchant's account. This has the form of a SEPA Credit Transfer (SCT). Below is a description of the information in this payment message and how it relates to the information in the iDEAL messages.

SEPA Credit Transfer

^{Mapping of transaction details for a SEPA Credit Transfer}

In 2.3 End to End Identification, Transaction.statusDateTimestamp is mandatory and is presented in the local time zone of the Issuer (including daylight saving changes) and format of the Consumer with a maximum of 16 positions (e.g. DD-MM-YYYY HH:MM). This can optionally be followed by Transaction.transactionID (which is also included in Remittance Information), separated by a space.

5.11 Specific requirement iDEAL Mobile: Print or e-mail confirmation message

After a successful regular iDEAL payment the Issuer will always give the Consumer the option to print a confirmation of the payment. However in a mobile payment environment printing will often not be possible so this requirement is expanded to include alternatives such as e-mailing the confirmation to the Consumer or receiving confirmation in the Consumer's internet banking portal.

6. Query protocol 

6.1 General

To verify whether a transaction was successful the Merchant will start the Query protocol by sending a StatusRequest to the Acquirer. This can be done after the return of the Consumer to the Merchant's website (after the redirect from the Issuer), or after a specified amount of time (for example 5 or 10 minutes after the expirationPeriod expired). To avoid unnecessary system load status requests should not be made unnecessarily often, see 6.5 for more details on what is allowed.
Within the iDEAL standards this message is also referred to as the AcquirerStatusRequest.

6.2 StatusRequest

The table below contains all fields that are part of the StatusRequest XML message. For legenda see 3.5.

Fields of the StatusRequest

*SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

Example Message

6.3 StatusResponse

The reply to the StatusRequest contains the fields listed in Table 14. This message communicates the status of the transaction (related to the transactionID which was sent in the StatusRequest) to the Merchant. If the status equals "Success" some additional fields with information about the Consumer are added to the message. If necessary, this information can be used to refund (part of) the transaction amount to the Consumer. For legenda see 3.5.

Fields of the StatusResponse.

*SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

6.4 Errors during execution of Query Protocol

When using the Query Protocol to fetch the iDEAL status, errors can occur as a result of which it is impossible for you to obtain the status of the payment at that moment. It is therefore not possible to show the Consumer the final status of the transaction at that moment.
It is recommended that you use the following message if it is not possible to obtain status details: We didn't receive a confirmation from your bank. When you see that your payment has been completed, we will deliver your order after we have received the payment. Or in Dutch: We hebben van uw bank nog geen bevestiging ontvangen. Als u in uw Internetbankieren ziet dat uw betaling heeft plaatsgevonden, zullen wij na ontvangst van de betaling tot levering overgaan. 
In addition to this, we recommend informing your customer how he or she will be notified of the payment status when it is known or where he or she can obtain that information (online).
You can then try to obtain the status through your Acquirer, in accordance with the guidelines (see MIG section 6.5). As soon as a definitive status has been received, you can notify the Consumer of the status of payment in the following ways, for example:

• By e-mail.

• On your website, for example in the account of the Consumer or via the Consumer's browser session.

6.5 Collection duty

The Merchant has to initiate a StatusRequest when the Consumer returns to the page to which he was redirected by the Issuer (the merchantReturnURL from the TransactionRequest). However, it is possible for the Consumer to close his browser before returning to this merchantReturnURL (even when he has authenticated the payment). It is mandatory for Merchants to perform a StatusRequest for every transaction, also in case the Consumer does not return to the Merchant's website. The iDEAL protocol prescribes a so called "collection duty" for the result of every transaction. The Merchant can comply with this "collection duty" by performing a StatusRequest for every transaction when

• the Consumer is redirected to the MerchantReturnURL

• more than 3 minutes have passed after the TransactionResponse and no final status has been retrieved yet

• the transaction's expiration period has passed and no final status has been retrieved yet.

If the retrieved status of a transaction is "Open", the StatusRequest for this transaction has to be repeated after a short period of time. All other statuses (Cancelled, Expired, Success and Failure) are final statuses. Since these statuses cannot change anymore, it is not necessary (and not allowed) to perform another StatusRequest. To avoid unnecessary load on the iDEAL systems, Merchants shall not perform unnecessary StatusRequests. 

The following situations must never occur:

• Request the status of a transaction more than 5 times before the expiration period has passed;

• Perform repeated StatusRequests with a time interval shorter than 60 seconds

The following situations should not occur after the expiration period has passed:

• Perform repeated StatusRequests with a time interval shorter than 60 minutes

• Request the status of a transaction more than 5 times per day

• Request the status of a transaction after the final status of the transaction has been received;

• Perform StatusRequests for transactions with a timestamp older than 7 days;

• Stop requesting the status of a transaction before the final status of the transaction has been received (unless timestamp is older than 7 days).

Usually one of the final statuses should be returned shortly after the expiration period. If the "Open" status is still returned after the expiration period, this can indicate a system failure. If this failure is not solved within 24 hours, please contact the Acquirer and stop sending StatusRequests. When the returned status is "Success" the Merchant will be able to proceed to deliver of the ordered product or service, using the saved order data. When the Consumer returns to your website inappropriately (e.g. using browser buttons to get back from the Issuing bank Internet Banking screens to the Merchant website) and decides to start a new iDEAL payment request, the Merchant must send a new transaction request to the Acquiring Bank, after first trying to collect the final status of the iDEAL transaction that was initiated earlier.

6.6 Performance and time-out of status message

The performance of the Issuer and Acquirer systems has a direct influence on the Consumer's user experience. Therefore iDEAL sets a target time and time-out for the status response message. For a Merchant the relevant target time and time-out apply to the communication with its iDEAL Acquirer:

^{Performance requirements (for the 95th percentile)}

The target time is the time (in seconds) within which a StatusResponse message should be received by the Merchant after sending a StatusRequest. The time-out is the length of time after which the Merchant should no longer expect a response (most likely an error has occurred) and should act accordingly (for example by displaying an appropriate error message to the Consumer). 95^th percentile is a statistical term indicating that 95% of transactions in a tested sample should be within the set target time.

7. Error handling 

7.1 General

If an error occurs while processing a DirectoryRequest, TransactionRequest or StatusRequest, for example because a request contains a invalid value, an ErrorResponse will be returned instead of the regular response. The ErrorResponse has the same structure for all three types of requests.

7.2 ErrorResponse

Instead of the regular response (DirectoryResponse, TransactionResponse of StatusResponse) the Acquirer will return an ErrorResponse if an error occurs during the reception or processing of the request, or if the request contains values that are not allowed or do not comply with the required format. The table below lists the fields that appear in the ErrorResponse. For legenda see 3.5.

Fields of the ErrorResponse.

*SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

Example Message

The consumerMessage is a message intended to show to the Consumer in case of an error. It contains one of the following messages (in Dutch):

• "Betalen met iDEAL is nu niet mogelijk. Probeer het later nogmaals of betaal op een andere manier." This message is returned in case something goes wrong in the Payment protocol.

• "Het resultaat van uw betaling is nog niet bij ons bekend. U kunt desgewenst uw betaling controleren in uw internetbankieren." This message is returned in case something goes wrong in the Query protocol.

• "De geselecteerde iDEAL bank is momenteel niet beschikbaar i.v.m. onderhoud tot naar verwachting date time from Notification System. Probeer het later nogmaals of betaal op een andere manier." This message is returned in case an Issuer is unavailable due to scheduled maintenance.

• "De geselecteerde iDEAL bank is momenteel niet beschikbaar. Probeer het later nogmaals of betaal op een andere manier." This message is returned in case an Issuer is unexpectedly unavailable.

Merchants should always show the standardised consumerMessage generated by the Acquirer to their customers. The other fields in the ErrorResponse should be used for local error detection. Appendix C contains a list of the possible error codes for the various messages and the associated text of the errorDetail field.

7.3 Non-availability

It might be possible that one of the Issuers is temporarily unavailable. In this case transactions that have to be processed by this Issuer will generate an ErrorResponse (see previous). When the Acquirer has determined unavailability at an Issuer he will communicate this to the Issuer immediately. This means that Merchant will never have to contact the Issuer directly.
It might also be possible that the Acquirer itself is temporarily unavailable. In this case, unless the Merchant has more than one Acquirer, no iDEAL transactions can be processed and the Acquirer will generate an ErrorResponse.
Also your confirmation page may fail to work properly. In that case, we recommend that you display a clear error message to the Consumer.
Subsequently, we also recommend that the status of the payment is reported to the Consumer in one of the ways indicated below:

• By e-mail.

• On your website, in the Consumer's account

• On your website, as part of the session information of the order.

8. Security and certificates 

8.1 General principles of certificates

For asymmetric encryption 2 keys are used: one public key and one private key. The public key is linked to the certificate and can be shared with anyone. The private key must be kept confidential by the owner of the certificate. The specific characteristics of the private and public part of the certificates will allow the encryption of a message with the public part while the result can be decrypted with the private part, and vice versa. It is not possible to decrypt a text with the same key that was used to encrypt it.
These specific characteristics enable two applications of a certificate:

1. Encryption of a message. By encrypting a message with the public key of the receiving party the information can only be read by the recipient (who has sole knowledge of the private key).

2. Creating an electronic signature of a message. By encrypting the (hash of a) message with the private key, the recipient can determine the authenticity of the (sender of the) message by successfully decrypting the signature with the public part of the certificate. The recipient will also verify the integrity of the message to make sure the contents of the message was not changed by a third party.

The one-sided TLS connection that is used within iDEAL between the Merchant and the Acquirer is based on the first application. The TLS connection uses at least 128-bit encryption based on a server side certificate of the Acquirer. It is important that your TLS implementation always complies with the latest security standards and patches (at least TLS 1.1 should be supported). Not implementing these patches might lead to the situation that it is no longer possible to submit transaction requests. Since iDEAL does not put any constraints on the communication between the Consumer and the Merchant, this can be either with or without a TLS connection. Merchants are advised, however, to always use TLS on the payment pages of their website.

The iDEAL standard also uses electronic signatures to ensure the authenticity, integrity and non- repudiation of all messages with the exception of redirects. The electronic signature of the Acquirer in the StatusResponse message, for example, enables the Merchant to verify the authenticity of the payment confirmation.

8.2 Signing iDEAL messages

All messages that are sent by the Merchant to the Acquirer (DirectoryRequest, TransactionRequest and StatusRequest) have to be signed by the Merchant. Messages are signed in accordance with the "XML Signature Syntax and Processing (2^nd Edition) W3C Recommendation" of 10 June 2008 http://www.w3.org/TR/xmldsig-core/, with the following settings and restrictions applied:

1. The entire XML message must be signed. Signature reference to the signed info URI is left blank, see example messages in Appendix B.

2. For the purpose of generating the digest of the main message, the inclusive canonicalization algorithm must be used. This method of canonicalization of the main message is not (always) explicitly indicated in the iDEAL XML messages. For this reason this transform has not been included in the example messages in this document. Merchants are not required to explicitly indicate this transform in their messages.

3. For the purpose of generating the signature value, the exclusive canonicalization algorithm must be used.

4. The syntax for an enveloped signature must be used. The signature itself must be removed from the XML message using the default transformation prescribed for this purpose.

5. For hashing purposes the SHA-256 algorithm must be used.

6. For signature purposes the RSAWithSHA256 algorithm must be used. RSA keys must be 2,048 bits long.

7. The public key must be referenced using a fingerprint of an X.509 certificate. The fingerprint must be calculated according to the following formula: HEX(SHA-1(DER certificate)). See example messages in iDEAL Merchant Integration Guide (EN)#Appendix B.

In general Merchants don't need to have extensive knowledge of RSA since most programming languages have libraries available that implement XML Digital Signature processing. It is strongly recommended to use these standard libraries. Standard functionality for creation and verification of RSAWithSHA256 digital signatures is available in commonly used software platforms, from the following versions and higher: PHP version 5.3.0, Microsoft .NET version 3.5 sp1 en Java version 1.6 u18. This functionality may also be available in earlier versions of these platforms and in other platforms (e.g. Python, Ruby). For information about creating the public and private key pair please refer to paragraph 8.4.

8.3 Authentication of iDEAL messages

To ensure the status of a transaction the Merchant has to verify the signature of the Acquirer in the Response messages. To verify the signature in the SignatureValue field it is recommended that merchants use standard XML Digital Signature libraries which are available in most (web) programming languages.

8.4 Creating a key pair

If you want to use a so-called "self signed certificate" this paragraph will explain how to do so. It is also possible to purchase a certificate at a company specialized in this field (Certificate Authority), see below.

In order to create a public and a private key execute the following steps:

1. Download the "OpenSSL Library" from http://www.openssl.org. You can find more information on the "certificate generating utility" at: http://www.openssl.org/docs/apps/req.html. You may also generate the key pair using other software. If so please use the manual that comes with your software. Always make sure you have the latest version installed to be sure that your implementation applies to the latest security standards.

2. Generate an "RSA private key" using the following command(choose your own password for the field [privateKeyPass]): openssl genrsa –aes-128 –out priv.pem –passout pass:[privateKeyPass] 2048

3. Create a certificate based on the "RSA private key" (use the same password as in the previous step for the field [privateKeyPass]): openssl req –x509 –sha256 –new –key priv.pem –passin pass:[privateKeyPass] -days 1825 –out cert.cer

   This OpenSSL command will generate a certificate in X.509 format, with a validity period of 5 years (1825 days), the maximum for iDEAL signing certificates.

4. The file priv.pem contains the private key. The file cert.cer contains the certificate with the public key. The Merchant has to keep the priv.pem file private, which is used in the RSA encryption. The cert.cer file has to be communicated to the Acquirer. The method of communication will depend on the Acquirer.

Buying a certificate from a Certificate Authority

When buying a certificate from a Certificate Authority (CA), rather than generating the certificate yourself it is important to note the following: the CA signing certificate (and the rest of the certificate chain) must use hashing algorithms and key lengths that are at least as secure or better than those of the Merchant certificate. Therefore CA-certificates used to sign certificates for electronic signatures must use at least SHA-256 for hashing and 2,048 bits for RSA keys. Signing certificates should also have a maximum validity period of 5 years.

9. Presentation 

9.1 General

There are some requirements regarding the presentation of the iDEAL payment method on the Merchant's website. The main purpose of these requirements is to create a uniform user experience for Consumers whenever they pay with iDEAL, regardless which Merchant's website they use. The requirements are further explained in the following paragraphs.

9.2 Payment method

A Merchant that accepts iDEAL as a payment method has to place the iDEAL payment method in its list of offered payment methods, in such a way that it is a logical step in the Merchant's ordering process. 
The iDEAL payment method must be presented in the list of payment methods in such a way that it receives at least the same amount of attention as other payment methods. Since iDEAL has the highest frequency of use in the Netherlands, it is recommended to place iDEAL at the top.

9.3 Payment button

It must be clear for the Consumer how and when the iDEAL payment method has been chosen. This is achieved by displaying a 'Payment' button, generally on that part of the page where one of the payment methods is normally selected.
The permitted depictions of the iDEAL 'Payment' button are supplied via the Merchant's portal on the website http://www.ideal.nl/en/payee/logos-banners/.

Specific Requirements iDEAL Mobile: Payment button iDEAL Mobile
In cases where the iDEAL logo cannot be displayed at the required size on a mobile device (for example if this would violate the requirements for app icons on the mobile device) the mandatory free space of 15px around the logo may be reduced to accommodate the requirements of the mobile device.

9.4 Payment flow

When the iDEAL button is clicked to select a payment method, the Consumer should immediately be presented with the iDEAL Issuer selection list without any intermediate screens being displayed by the Merchant (e.g. Consumer login and/or registration screens). And when the required Issuing bank has been selected by the Consumer, the Consumer should be immediately redirected to the iDEAL environment of the selected Issuing bank.
In other words, Consumer login and registration with the Merchant should have taken place before selection of the iDEAL payment method by clicking the iDEAL button.

9.5 Redirect to Issuer

The Merchant needs to perform the redirect to the Issuer, from the browser window where the Consumer selected the Issuing bank. The complete page of the Merchant shall be replaced by the complete page of the selected Issuing bank. Therefore it is not allowed to open the redirect to the Issuer in a new browser window. It is however allowed to open a new window, with visible address bar, before the Consumer selects his bank from the Issuer list.

9.6 Frames

Frames used on the Merchant's site are allowed. The page of the Issuing bank will remove these frames using a frame busting technique. This will allow the Consumer to verify whether the iDEAL payment is really taking place at the bank chosen from the Issuer list. After the redirect to the Merchant the Merchant shall completely rebuild the Merchant page to show the Merchant's order confirmation.

9.7 New Window

The iDEAL payment may take place in a new browser window, as long as the Merchant will have this window appear at (or before) the moment the Consumer chooses the payment method. A new window is only allowed if initiated by the Consumer (no pop-ups are allowed). The complete payment flow must take place in this window, including the Merchant's order confirmation. The new window must also contain an address bar that allows the Consumer to check the Internet address URL and SSL-certificate of the Issuing bank. During the payment flow it should not be possible for the Consumer to initiate another payment through the Merchant's original browser window.

Specific Requirements iDEAL Mobile: New window or app iDEAL Mobile

The iDEAL Mobile payment may redirect the Consumer to a different mobile page or app as part of the transaction. The Merchant should strive to keep the Consumer on one browser page as much as possible but should not make use of an in-app browser via webview in the Merchant app (see 5.5). In those cases where changing to another app or window is necessary (such as the redirect to the Issuer) the Consumer should be informed beforehand in order to avoid confusion (e.g. " You are being redirected to the mobile web site or the app of your bank").

9.8 Issuer list

The Issuer list has to be presented as described in paragraph 4.4.

9.9 iDEAL banners and logo's

Merchants that want to use a banner on their website to promote iDEAL can download the most recent banners at http://www.ideal.nl/en/payee/logos-banners/. These banners need to be installed only once, since the URL will always refer to the latest version of the banner containing the right logos of the participating Issuing banks.
When using a iDEAL banner on mobile devices it is recommended to either user the logo without the pay-off or use a pay-off spread over 2 lines to reduce the width taken up on the mobile device screen.

9.10 Explaining iDEAL to Consumers

Merchants that want to provide specific help and instructions to Consumers regarding the iDEAL payment method are advised to use the following text:

How does iDEAL work?
A few simple steps is all it takes to pay using iDEAL:

• Place your order

• Select iDEAL as payment method

• Select your bank

• This opens the familiar online banking application of your own bank

• The relevant details of your purchase will already be shown

• You merely authorise the payment in the way you are accustomed to at your Issuing bank

• Your bank confirms your payment

• You return to the online store – order accepted and payment successful!

10. Common Implementation pitfalls 

10.1 iDEAL Issuer selection list: keep it up-to-date

• When you don’t keep the iDEAL issuer selection list (bank list) up-to-date, some of your customers are unable to pay with iDEAL and furthermore you are in breach with iDEAL regulations.

• New iDEAL Issuers need to be added to your iDEAL issuer list as soon as possible, but no later than 1 month after the new Issuer joined iDEAL.

• The easiest way is to keep your issuer list updated fully automatic. You can do this in the following ways:

  • When possible, make use of an iDEAL landing page provided by your bank or CPSP. The Issuer selection list that is used on this page is automatically kept up-to-date by these parties;

  • In case you have an iDEAL contract with an Acquiring bank (you will receive the iDEAL payments directly at your account at this bank), then make sure your Issuer-list list is connected to the Directory protocol. When you have a contract with a CPSP for iDEAL, often an iDEAL issuer list API is provided. Keep your issuer selection list up-to-date by automatically executing the iDEAL Directoryprotocol or API call on a daily or weekly basis.

• Do you use a plug-in for iDEAL (in e.g. Woocommerce or Magento)? Then make sure that you regularly check that you have implemented the latest version of this plug-in.

• Do you opt to manually adjust the issuer selection list? Then make sure that the needed technical resources are available in your organization to do this within the required time period (one month). This adjustment is usually small, but does require some programming skills. Contact your software provider or CPSP in case you have any questions about the manual adjustments of your iDEAL issuer selection list.

  • Please also make sure that with a manual adjustment, you also remove issuers that do not offer iDEAL anymore (e.g. Friesland bank)

10.2 iDEAL transaction status – verify the final status in time

• Make sure that you at least have two triggers in place for collecting the iDEAL transaction final status (status Sucess, Canceled, Expired or Failed):

  1. The return of the user after payment to your merchant environment (via the MerchantReturnURL)

  2. Expiring of the iDEAL transaction expirationPeriod (which is configurable in your transaction request, and by default set to 30 min)

• Not having the second trigger in place can lead to mismatches between your order system and the iDEAL end status. This can result in situations where customers have paid for an order but no confirmation of payment is administered in your order system and, as a result, no product is delivered to the consumer.

• Also make sure that you retrieve the final status of the iDEAL transaction before your order system has automatically timed-out the order. 

• Make sure you do not make delivery solely based on the return of the consumer to your merchant environment (via the MerchantreturnURL) but solely after receipt of the final status "Success". 

• The final end status can only be determined in the following ways:

  • Execute the Query protocol (sending the iDEAL StatusRequest), after which you will receive the StatusResponse which includes the status of the iDEAL transaction, or;

  • In the dashboard of your iDEAL contracting party (if present) look up the final status of the iDEAL transaction.

10.3 iDEAL in your mobile app – wrongful use of in-app-browsing via webview

• When you as a merchant have an app in which you offer iDEAL as a payment option, specifically mind the following aspects regarding the Issuer redirect:

  1. The consumer must be able to check the URL and https “lock” icon of the Issuer webpages at all times

  2. The browser in which the redirect to the Issuer takes place, must be securely safeguarded for the Merchant (the Merchant should not be able to eavesdrop on user typing

  3. The browser, in which the redirect to the Issuer takes place, must be able to open bank-apps (app schemes like “bank://ideal/12392”).

• To be able to comply to the above requirements, we strongly advise you to always offer the IssuerAuthenticationURL to the operating system of the mobile device. As a result, the IssuerAuthenticationURL will be opened within the browser of choice of the user or directly in the bank-app

• It is strictly forbidden to make use of custom made in-app browsers for the redirect to the Issuer, because by doing this the above requirements are not complied to!

• In case you chose to make use of an in-app browser for opening the IssuerauthenticationURL, you must make use of  SafariViewController for Apple iOS and Chrome Custom Tabs for Android, so that you comply to the above requirements.

Appendix A: Data dictionary 

The table below contains all data elements that appear in iDEAL messages relevant to the Merchant, together with information about the format and permitted values:

^{Data elements in iDEAL messages}

Character set

• In all iDEAL messages the Unicode character set must be used. Only the MES-2 subset must be supported.

• Encoding must be used as indicated in the HTTP and XML headers UTF-8 (Unicode Transformation Format).

• The use of characters that are not part of the Unicode character set will not lead to a refusal of a batch or post, but the character may be changed to a space, question mark or asterisk in transit.

• The Byte Order Mark (BOM) must not be used. The UTF-8 representation of the BOM is the byte sequence 0xEF,0xBB,0xBFs.

Appendix B: Example messages 

The shown examples are not related to each other. For instance, the example DirectoryResponse message is not necessarily the result of the DirectoryRequest example message. Values used in the examples, like the IDs for the Acquirers and Issuers, may differ from those used in the actual iDEAL system.

APPENDIX C: Error codes 

Categories

The Error.errorCode is composed of:

• a category (two letters)

• a number (four digits)

The following categories are distinguished:

^{Error code categories}

Error codes

^{Error codes}

The field errorDetail in the table above contains one of the values shown in the table below. The italic printed words shall be replaced by actual values, as indicated.

^errorDetail 

Words printed in italics are to be replaced by actual values, as indicated.
Explanation regarding indication 3: in the maximum amount in the error detail the Issuer will only state the transaction limit or the day limit which are applicable at the Issuer. No personal limit set by the Consumer will be stated here.
The value of consumerMessage is specified in AcquirerErrorRes (X') by the Acquirer based on the criteria described in the following table. Words printed in italics are to be replaced by actual values, as indicated.

^{consumerMessage}

Words printed in italics are to be replaced by actual values, as indicated.

APPENDIX D: XML messages scheme