You have the option to add security measures to protect your payment processes further. This page describes the optional measures you can implement.
Add our IP addresses to your IP whitelisting list. Below is the list of our IP ranges.
220.127.116.11/24 18.104.22.168/24 22.214.171.124/22
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.
frame-src directives, you may add these URLs here:
And for the
style-src directive, you may add this item here:
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-srcto fully support redirects to 3D-Secure. This means you will have to specify a
frame-srcdirective. You can leave the
script-srcas 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' *
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
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
Add a static signature to your webhook by defining a signature in your webhook URL. Simply add the parameter to your webhook URL:
Updated 4 months ago