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.
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.
Supported features
Feature | Support |
Capture/Cancel | ❌ |
Multipart Captures | ❌ |
Secure Card Data | ❌ |
Recurring Payments | ❌ |
3D Secure | ❌ |
Dynamic Currency Conversion (DCC) | ❌ |
Mail Phone Order | ❌ |
✅ | |
Omni-Channel | ❌ |
Integration
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 the
Notification
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 SaferpayTransaction.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 above.
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.
Last updated