You have the option to add security measures to protect your payment processes further. This page describes the optional measures you can implement.

IP whitelisting

Add our IP addresses to your IP whitelisting list. Below is the list of our IP ranges.

193.16.220.0/24 
91.223.186.0/24
185.253.204.0/22

2a0c:40c0::/29

Content security policy

To protect yourself against cross-site scripting (XSS), clickjacking, and other code injection attacks, we recommend adding strict content security policy directives. Below we have listed which directives are required in order for our payment solutions to work correctly. This list only applies if you have a restrictive content security policy in place. Once a content security policy header is sent, all internal and external resources must be named. In order to avoid CSP violations, make sure to declare further script, style, and frame sources involved in your project. The directives below are required when using our Redirect & Lightbox or Secure Fields integration.

For the script-src and frame-src directives, you may add these URLs here:

• pay.datatrans.com
• pay.sandbox.datatrans.com

And for the style-src directive, you may add this item here:

• 'unsafe-inline'

📘

Allow any URL in frame-src if you use Lightbox mode and card payments!

If you use our Lightbox integration, you will have to allow any URL in frame-src to fully support redirects to 3D-Secure. This means you will have to specify a * within the frame-src directive. You can leave the script-src as is since the sources will always remain the same for our scripts.

Content-Security-Policy: default-src 'self'; script-src 'self' pay.datatrans.com pay.sandbox.datatrans.com; style-src 'self' 'unsafe-inline'; frame-src 'self' *

Signing your webhooks

To protect our webhooks from being tampered, add an additional security layer by signing our webhooks. To get your HMAC key sign, login to our dashboard and navigate to the Security settings in your merchant configuration. Datatrans will use this key to calculate a signature. Once the checkbox is active, we will generate a new HMAC key and add two parameters within the HTTP request header Datatrans-Signature: A unique timestamp t and the expected signature s0.

To calculate the expected signature, concatenate the timestamp as a string with the webhook payload. Convert the resulting string to bytes and finally create a signature with your HMAC key using SHA256. Finally, compare your calculation to the expected signature s0. If your calculated signature equals s0, the webhook payload is valid and was not modified.

# hey bytes of the key
key_hex_bytes = bytes.fromhex(key)

# Create sign with timestamp and payload
sign = hmac.new(key_hex_bytes, bytes(str(timestamp) + payload, 'utf-8'), hashlib.sha256)

// hex bytes of the key
byte[] key = Hex.decodeHex(key);

// Create sign with timestamp and payload
String algorithm = "HmacSha256";
SecretKeySpec macKey = new SecretKeySpec(key, algorithm);
Mac mac = Mac.getInstance(algorithm);
mac.init(macKey);
mac.update(String.valueOf(timestamp).getBytes());
byte[] result = mac.doFinal(payload.getBytes());
String sign = Hex.encodeHexString(result);

# Create sign with timestamp and payload
echo hash_hmac('sha256', $timestamp . $payload, hex2bin($key));

To verify if you calculated the signature in the right way, the example below can be used. When testing locally, beware of pretty formatting the webhook payload, as it will result in a different signature than expected.

Given the key:
861bbfc01e089259091927d6ad7f71c8b46b7ee13499574e83c633b74cdc29e3b7e262e41318c8425c520f146986675fdd58a4531a01c99f06da378fdab0414a

Given the payload:
HELLO

Given the timestamp:
1605697463367

Then the signature is:
t=1605697463367,s0=82ef9a8178dcb4df0b71540fa06d7da826ecb26e1977e230bdc8c9d6f9f1af84

Additional static signature in webhooks

Add a static signature to your webhook by defining a signature in your webhook URL. Simply add the parameter to your webhook URL: https://example.com/webhook?param1=value1.