iDEAL 2.0

iDEAL transactions can be processed via the Saferpay JSON API. However, as iDEAL is a third party provider, there are a few things to consider.

General requirements

The handling of iDeal payments with Saferpay requires:

• A corresponding license and thus a valid identification with a username and password for the Saferpay system.

• Availability of at least one active Saferpay terminal via which payment can be carried out, and availability of the associated Saferpay TerminalId.

• An iDeal contract with Worldline. Others are not supported.

For iDeal activation on the Saferpay terminal, please contact your sales contact.

Technical requirements

The general integration of iDEAL can only be done via the Payment Page and requires the following things to be noted:

• The notification URLs, inside theNotification conatiner are mandatory, in order to avoid missing payment successes. See the Payment Page process for further information.

• The parameter Payment.Payernote is mandatory. If it is not set, Saferpay will set the Saferpay Transaction.Id as its value.

• The Payment.OrderId is limited to a length of 18 and no special characters. Saferpay will automatically filter any special character, to prevent issues.

• iDEAL does not support the Iframe integration. Saferpay will break out of the IFrame, if necessary.

• Refunds are technically not directly supported by iDeal. Due to that, Saferpay will perform the refund through other means. Thusly, the payer will not see the refund in their iDeal-App. Aside that, the refund is processed normally.

Furthermore, for other flows (Refunds etc.), please refer to the table Below

Supported features

Feature	Support
Capture/Cancel	❌
Multipart Captures	❌
Secure Card Data	❌
Refunds	✅ (needs attention)
Recurring Payments	❌
3D Secure	❌
Dynamic Currency Conversion (DCC)	❌
Mail Phone Order	❌
Testing	✅
Omni-Channel	❌

Payment Page integration

The Payment Page integration requires the following things to be considered:

Session Timeouts

Due to special technical restrictions of the iDEAL platform, you have to be very careful using it in time-sensitive scenarios.

iDEAL transactions usually are finished within the Saferpay Payment Page timeout of 20 minutes. However, due to processing limitations, iDEAL response times can be way higher than this time frame. So if your session runs into a timeout during this window, it could be that the transaction is successful, even though your system does not recognize it as such!

We generally recommend setting the timeout to 35 minutes, however the processing can take up to 12 hours on iDEAL-side!

If you are running a time sensitive process, that requires your session to be lower than this time frame, we recommend not using iDEAL!

We highly recommend using the NotifyUrls for the Saferpay Payment Page, which will be called, once Saferpay gets a successful response from iDEAL. This way your shop does get the necessary information in case of a success, even after 12 hours, and can initiate further processing.

In the case, that Saferpay does not recieve a response in due time, Saferpay will display a failure-message and call the Fail NotifyUrl! You can then call the Payment Page Assert, to get the result.

The user however won't be redirected back to the merchant shop.

Should this transaction be pending, due to a prolonged processing, Saferpay will throw a "TRANSACTION_IN_WRONG_STATE" - "Transaction still in progress or abandoned by the payer." error message, indicating, that the processing is still ongoing! The Success NotifyUrl (see above) will then notify you about a successful payment, if possible and you can then use the Payment Page Assert as usual, to get the transaction details. Could the NotifyUrl not be recieved until your session timeout, you can also call the Payment Page Assert proactively.

Testing

Please refer to this chapter, if you want to test iDEAL.