Calling our Webservice

We have two different 'flavors' available for our webservice: SOAP and REST. Funtionally these two flavors are identical. Technically there are some differences which will be explained on their respective page. In addition to the SOAP and REST services we also offer a PHP and .NET API. These API's act as a wrapper for the REST webservice, but offering only a subset of all functions.

Logically we can distinguish the following groups of functions:

  • Payment functions - used to initiate a standard payment
  • Recurring Payment functions - used to initiate recurring payments and use them
  • Refunds - used for initiating, cancelling and getting status information for refunds
  • Reporting - used for providing you with reporting information regarding your account


The ICEPAY API uses two layers of security to ensure two-way authentication of sender and receiver.
To prevent interception of messages and tampering, SSL is used for transport security.
All calls to the API must be done over HTTPS TLS1.1 or 1.2, ensuring end-to-end encryption of the message and authentication of ICEPAY as the recipient of your requests.
A custom checksum algorithm is used to sign requests and responses. Using a pre-shared secret code, this algorithm authenticates the sender of requests and ensures that any response you receive really came from ICEPAY.


Field level documentation of our API is available at our Apiary site. Although this site is primarily focused on our REST API the field level descriptions apply to all our API's.

The Apiary site allows you to get sample code for webservice calls for many programming languages and platforms: RAW, cURL, Java, JavaScript, Node.js, Perl, Python, PHP, Ruby, Go, C#, Visual Basic, Groovy, Objective-C and Swift. 

You can also send requests directly from the Apiary site and inspect the response!

Important considerations during implementation

  • ICEPAY’s services are hosted in Microsoft Azure where we employ multiple geographical locations to optimize performance. This means that calls from your webshop might be assigned to a specific geographic location. The public IP address from which ICEPAY communicates to your webshop may therefore vary. Do not employ any form of IP whitelisting in your implementation. To verify the authenticity of responses and Postbacks from ICEPAY, the checksum should always be used.
  • All of ICEPAY’s payment services make use of secured connections. This means ICEPAY has an up to date SSL certificate that needs to be renewed every year. Do not cache any data regarding the SSL certificate as we may need to renew or replace the SSL certificate at any moment. To verify the identity of the ICEPAY service, validate the certificate itself with its root CA.
  • To comply with PCI standards, ICEPAY only accepts TLS1.1 and TLS1.2 connections. SSLv3 and TLS1.0 are considered unsafe and are therefore not accepted.
  • As our service continuously improves, we may need to add more parameters to request and response messages. Whenever possible any new request parameters will always be optional, but new response parameters may be added at any time. Ensure that your implementation does not break when receiving previously unknown parameters in the response.