Calling our Webservice

Logically we can distinguish the following groups of functions:

  • Transaction functions - used to initiate and perform actions on standard transactions
  • Authorisation functions - used to initiate and perform actions using the authorise-capture model

Security

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.

Additionally we use custom headers for authentication.

Apiary

Field level documentation of our API is available at our Apiary site

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. 

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.