Additional security
Ensuring the security of your API should be a top priority in any production environment. At IXOPAY, we understand this need and provide a robust security system to safeguard your data. Our API security includes basic measures such as TLS 1.2 and HTTP Basic Authentication to establish secure communication. Additionally, we offer a signature mechanism that offers an extra layer of protection for API requests and callbacks. The authenticity of messages is guaranteed by utilizing HMAC with SHA2-512 as the hashing algorithm in the signature mechanism.
Here is a summary of the security measures that our APIs offer:
- TLS 1.2 or later: This cryptographic protocol provides secure communication between the client and server by encrypting all data transmitted over the network.
- HTTP Basic Authentication: This authentication mechanism requires a valid username and password combination for access to the API.
- Signatures: HMAC-SHA512 is used to generate signatures for each message sent over the API. These signatures help to ensure the authenticity and integrity of API requests and callbacks.
Signatures
An aspect of the security measures offered by the IXOPAY platform API is the signature mechanism. Signatures are a way of ensuring the authenticity and integrity of API requests and callbacks. A signature is a hashed value that is included in all API responses and callbacks from the platform. Merchants can also sign their own requests to the APIs, which the IXOPAY platform will attempt to verify. It is recommended (but not required) that merchants check the signature of callbacks since this is the only form of communication where no TLS certificate can prove the identity of IXOPAY.
The signature is sent and received in the X-Signature HTTP header. To generate the signature, HMAC (Hash-based Message Authentication Code) using SHA2-512 as the hashing algorithm is used. The secret key for the HMAC is the shared secret configured on your connector.
To validate or create signatures, a correct RFC 7231 HTTP Date header is required. As a fallback for certain HTTP libraries, an equivalent X-Date header can be used on the request as well and will take precedence over the Date header.
To implement the signature mechanism, merchants need to compute the signature, validate callback signatures, and sign requests. These steps will be covered in the following sections.
Computing the signature
To compute the signature for a request or callback, you need to follow a specific process. Here are the steps you need to take:
-
Construct the message string : To construct the message string, you need to concatenate several values together in a specific order. The values are the HTTP method, the SHA512 hash of the request’s body, the Content-Type header value, the timestamp as sent in the Date header, and the Request URI.s
- Shell
- Python
- PHP
- Java
-
Calculate the HMAC : Once you have the message string, you need to calculate the HMAC using the shared secret provided by your connector.
- Shell
- Python
- PHP
- Java
-
Base64 encode the HMAC : The final step is to Base64 encode the binary HMAC value.
- Shell
- Python
- PHP
- Java
After following these three steps, you should have a valid signature that can be included in the X-Signature header of your API request.
Validating callback signatures
To validate the signature of a callback notification, you need to rebuild the signature using the shared secret provided to you, along with any other credentials, as explained in the Computing the signature section. This calculated signature must be compared to the one provided in the X-Signature header of the notification request.
It is recommended (but not required) that merchants check the signature of callbacks since this is the only form of communication where no TLS certificate can prove the identity of IXOPAY.
To verify the signature, first, obtain the required data from the notification request and compute the signature following the steps outlined in the Computing the signature section. If the resulting signature matches the X-Signature header provided in the notification request, you can trust the callback.
Here’s an example that shows how to validate the signature of a callback:
- Shell
- Python
- PHP
- Java
In some situations, our API may generate callbacks with signatures calculated using legacy methods, involving MD5 hashing the body as signature payload instead of the standard SHA2-512. This section details this legacy behavior and how to manage it effectively.
- Callbacks associated with a legacy signature will by default use the same signature type as the initial or related transaction.
- If the initial or related transaction request used an MD5 sum of the body, corresponding callbacks will also employ MD5 signature calculation.
- This behavior is governed by the setting Postback Format Version , by default set to Inherit from Request.
For new integrations we strongly recommend adopting the current signature generation method using SHA2-512. For existing integrations, if compatible, we encourage updating your integration to leverage the recommended signature standard.
Signing requests
Signing requests is an optional step that merchants can take to add an additional layer of security to their API requests. To sign a request, you need to follow the same process as described in the Computing the signature section.
Once you have computed the signature using the steps described in Computing the signature, you need to include it in the request headers as the value of the X-Signature header. Here is an example code snippet in PHP that demonstrates how to sign a request:
- Shell
- Python
- PHP
- Java
By including the X-Signature header in your requests, you instruct the IXOPAY platform to verify the request’s authenticity. The signature verification process is handled as follows:
- PCI Transaction API: Signature verification is mandatory for all requests sent to this API. The IXOPAY platform will only accept requests that have been properly signed with the shared secret provided to you during integration.
- Transaction API: Signature verification is conditional. It will only be performed if the connector setting API: Enable Request Signing is enabled for your connector. If this setting is active, the IXOPAY platform will only accept requests that have been properly signed.
Signature testing
To evaluate the correctness of your signature algorithm implementation, it is recommended to employ the signature testing tool presented below. Utilizing this tool, you may execute tests to verify the accuracy of your signature algorithm in a controlled environment. The signature testing tool can be found displayed below.
Signature testing tool
Input your signature details in the “Signature parameters” section and check if the signature output in the “Signature output” matches your generated signature.
This tool does not verify the validity of the API key, shared secret or the payload itself.
Securely use your real API keys and shared secret without any data being submitted to our servers. The testing tool operates exclusively within your browser using JavaScript.
Signature parameters
Shared secret
HTTP method
HTTP request body
Content-Type header
Date header (format)
Invalid timestamp!
Request URI
Invalid endpoint!
Hashing algorithm
SHA-512MD5 (deprecated)
Signature output
SHA-512 hash of HTTP request body
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
HTTP method
POST
Content-Type header
application/json; charset=utf-8
Date header
Wed, 23 Sep 2026 14:07:52 GMT
Request URI
/api/v3/transaction/YOUR-API-KEY-HERE/debit
Hash HMAC Input
Based on your input, note the line breaks.
POSTcf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3eapplication/json; charset=utf-8Wed, 23 Sep 2026 14:07:52 GMT/api/v3/transaction/YOUR-API-KEY-HERE/debit
Expected signature
Data is hashed using HMAC-SHA512 , and the resulting binary encoded using Base64.
d80hriLuCEzzsaxdGk031HNJqAG18Dc+GU1NGj4JZ9xPJkzO0iQOQ4SX0sVz2fMBEscOztBeOVCQKEgyHGkDyQ==
Expected headers
X-Signature: **d80hriLuCEzzsaxdGk031HNJqAG18Dc+GU1NGj4JZ9xPJkzO0iQOQ4SX0sVz2fMBEscOztBeOVCQKEgyHGkDyQ==** Date: Wed, 23 Sep 2026 14:07:52 GMT Content-Type: application/json; charset=utf-8
Fix the errors, in order for the signature output to be shown!