Technical and Security Aspects

Security Considerations
All API requests must be made over HTTPS. Calls made over plain HTTP will fail. 
API requests without Authentication will also fail.
You will be able to hit our APIs only from the IPs you have previously whitelisted on the Merchant Panel.
​
Environments
All the integration must be performed on our TEST environment, where you can perform your tests freely without risks of any kind.
When you sign up with us, we will generate you an account on our STG environment where you will be able to:
See the transactions created
Approve and cancel transactions
Retrieve your API Keys
Whitelist your IPs, and more
Endpoint domains
Each environment has its own domain. The path of the endpoints doesn't change.
Environment
Domain
Testing
https://api-stg.directa24.com/
Production
Provided once you complete the testing
Notes:
You will use the STG endpoints to integrate.
The STG and PROD environments are not communicated in any way. 
No transaction created on the STG environment will be reflected on the PROD environment or vice versa. 
The API Keys and configurations between environments are also different.
​
API Keys
Our Deposits APIs uses API Keys in all of the requests to authenticate. Your API Keys can be retrieved from the Merchant Panel by going to Settings -> API Access.
The API Keys on the STG and PROD environments are different.
There are basically two set of credentials:
One API Key and one API Signature for POST operations.
One API Key key for read-only endpoints.
Authentication to the API is performed via HTTP Basic Auth. You must provide your API Key in all the requests as the basic auth username value. You do not need to provide a password.
Your API Key must be sent in all the API calls using the X-Login field on the header of the request.
Your API Keys, along with your IP Addresses are your way to authenticate yourself, therefore, do not share your secret API keys in publicly accessible areas such as GitHub, client-side code and so forth.
​
Headers
All the requests sent through the API of Deposits v3 must have the following headers.
Header
Format
Mandatory
Description
Authorization
String
Yes
"D24 " plus a hash HMAC256 to verify request integrity
X-Login
String
Yes
Merchant API Key
X-Date
String
Yes
 ISO8601 Datetime: yyyy-MM-dd'T'HH:mm:ssZ. E.g.: 2020-06-21T12:33:20Z
Content-Type
String
Yes
application/json
X-Idempotency-Key
String
No
Unique value generated by the client which the server uses to recognize subsequent retries of the same request
​
Authorization Signature
All the requests you send must contain the Authorization header with an HMAC256 control string signature using your own API Signature. This is used to verify the request integrity as we will calculate the same Signature and compare it with the one you send. In case of mismatch we will decline the request.
In the case of the notifications given by our APIs, those will also contain an Authorization value which you should calculate and compare to make sure the content was not altered by a Man in the Middle attack.
Check the following page for instructions on how to calculate the Control Signature.
Calculating the Signature
​
X-Login
All the requests you send must contain the header X-Login with your own API Key value used to authenticate yourself. Check API Keys.
​
X-Date
All the requests you send must contain the header X-Date with the time in which the request was created. The format is in ISO8601 Datetime: yyyy-MM-dd'T'HH:mm:ssZ. E.g.: 2020-06-21T12:33:20Z. 
Make sure you use UTC as the timezone specified and not your client's local timezone.
If the date you send differs in more than 5 seconds with the time in our servers, we will block the request for security reasons.
Example of how to generate the correct X-Date value
Java
PHP
source: JAVA SDK > src/main/java/com/directa24/client/util/ClientUtils.java
1
import java.time.LocalDateTime;
2
import java.time.ZoneOffset;
3
import java.time.format.DateTimeFormatter;
4
​
5
public class ClientUtils {
6
​
7
   private static final String DATE_PATTERN = "yyyy-MM-dd'T'HH:mm:ss'Z'";
8
​
9
   private static final DateTimeFormatter DATE_TIME_FORMATTER = DateTimeFormatter.ofPattern(DATE_PATTERN);
10
​
11
​
12
   public static String now() {
13
      return LocalDateTime.now(ZoneOffset.UTC).format(DATE_TIME_FORMATTER);
14
   }
15
​
16
}
17
​
Copied!
source: PHP SDK > src/util/Helpers.php
1
<?php
2
​
3
namespace Directa24\util;
4
​
5
class Helpers 
6
{
7
    private static $DATE_TIME_FORMATTER = "Y-m-d\TH:i:s\Z";
8
​
9
    public static function getCurrentDate()
10
    {
11
        date_default_timezone_set('UTC');
12
        return date(self::$DATE_TIME_FORMATTER);
13
    }
14
}
15
​
16
print(Helpers::getCurrentDate());
17
​
Copied!
Check our SDK in JAVA and PHP for the full code of how to generate the X-Date and the full request.
​
Idempotent Requests
Our API supports idempotency for safely retrying requests without accidentally performing the same operation twice. This is useful when an API call is disrupted in transit and you do not receive a response. For example, if a request to the Deposit Creation Endpoint  does not respond due to a network connection error, you can retry the request with the same idempotency key to guarantee that no more than one deposit is created.
In order to perform an idempotent request you need to send the X-Idempotency-Key: <key> header with a random and unique string.
Idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeded or failed. Subsequent requests with the same key return the same result, including 500 errors.
An idempotency key is a unique value generated by the client which the server uses to recognize subsequent retries of the same request. How you create unique keys is up to you, but we suggest using V4 UUIDs, or another random string with enough entropy to avoid collisions.
All POST requests accept idempotency keys. Sending idempotency keys in GET and DELETE requests has no effect and should be avoided as these requests are idempotent by definition.
​
Content-Type
All of our Deposits APIs are designed to receive and respond the information in JSON format.
This header won't change across the requests, and shall always be: application/json
​
IP Whitelisting
For security purposes, you need to whitelist the IPs from where you will call our API.
In order to whitelist your IPs and make the process as smoother as possible, you should go to Settings -> API Access and add the list of IPs you will possibly use under the Deposit IP Address section.
Reach out to [email protected] if you need to whitelist our servers IPs on your firewall. 
​
Best Practices
We recommend you follow this list of technical and security practices to maximize the security of the information end-to-end.
1.Always ensure to verify the Signatures control string sent in the notifications to validate its veracity.
2.We convert all the data we receive to UTF-8. Make sure you are also converting it into UTF-8 to make sure both parties have the same details. 
3.Always validate that a deposit is not released more than once based on the deposit_id (The notifications can be sent multiple times).
​
​
​
Go to the next page to learn how to generate the requests signatures control string to verify the requests' you send and receive integrity.