Skip to main content

Security

API request signatures​

Requests to the Financial Line API must contain signatures. This allows you to identify the merchant and ensure the authenticity and integrity of the data. When using signatures in requests, the value of the X-API-AUTH header must contain the name of the corresponding signature generation algorithm.

Signature values are entered case-sensitive (must be in lowercase Hex).

  • HMAC-SHA1 signing algorithm (recommended)
    Authentication header: X-API-AUTH: CPAY-HMAC {API_KEY}:{SIGNATURE}

Example signature:

SECRET=changeme # replace with {API_SECRET}
DATA='{"name":"Joe","age":20}' # replace with raw request
SIGNATURE=$(echo -n "$DATA" | openssl sha1 -hmac "$SECRET")
echo "$SIGNATURE"
# Expected signature
48731878acbb41e6ee70eac5f1e6f8b8031f9484
  • SHA1 signing algorithm
    Can be used if your system does not support the HMAC signing algorithm
    Authentication header: X-API-AUTH: CPAY-SHA1 {API_KEY}:{SIGNATURE}

Example signature:

SECRET=changeme # replace with {API_SECRET}
DATA='{"name":"Joe","age":20}' # replace with raw request
SIGNATURE=$(echo -n "$SECRET$DATA$SECRET" | openssl sha1)
echo "$SIGNATURE"
# Expected signature
8c8a2929897286196bb906216379f84c9ec17573

Using the HTTPS protocol​

To accept payments, your site must support the HTTPS protocol.

Using the 3DS protocol​

Financial Line supports the security protocol 3DS (3-Domain Secure) version 2.1, which provides an additional level of protection of payment card data and reduces the likelihood of fraudulent transactions.

3D Secure requires the payer to take an additional step at the payment stage — payment confirmation. Namely: on the bank's authentication page, the payer must enter a one-time code received in an SMS or confirm the payment in the bank's mobile application.

3D Secure version 2.1 has the following features:

  • Ability to pass authentication in mobile applications.
  • Processing of a number of additional parameters, which allows more effective risk analysis and blocking of a suspicious payment (for example, geolocation, payment history).

The 3D Secure protocol is managed through the order_3ds_bypass parameter. Its valid values are:

supported (default setting) — depends on the support of the 3D Secure protocol by the payment system itself.

always — the payment will be made using the 3D Secure protocol.

never — the payment will be made without using the 3D Secure protocol.

caution

Without additional settings and checks, merchants can only use supported and always values. To be able to make payments with the never option, please contact Financial Line Support.