Get Started

To start using our platform, you have to:

  1. Submit an application here;
  2. Coordinate with the technical support the right solution for your business needs, the process and timing of the integration, testing, and going live. When coordinating the process of testing, you can coordinate the possibility of testing procedures, involving the usage of payment cards or alternative payment methods;
  3. Update the code of the merchant's web service to implement the integration;
  4. Test and put in production mode the updated web service code with specialists from the technical support;
  5. Once the testing and active monitoring phase is successfully completed, support team specialists will provide you regular technical assistance.



Authentication is handled, using OAuth Bearer tokens.

  1. To generate your token, login into your Merchant Portal account and navigate to the E-commerce & API tab;
  2. Choose Explore Sandbox for Free to enter the sandbox mode for the API testing;
  3. Enter a title for your new key set and select the default terminal this key set will interact with. If you wish to only run some test requests using this key set, set test key set to true. Then click the Add Key button below.

You will also need to add the info to the e-commerce key fields:

  • Field Brand: contains the list of all brands, connected to the merchant. Default value for existing api keys is All;
  • Field Website: contains the list of all websites, connected to the merchant. Default value for exisiting API keys is All;
  • Field 3D authentication: by default set to On;
  • Field Default terminal: contains all terminals of the chosen website;
  1. Find your newly-created key in the Key sets list and click the pencil next to it;
  2. Insert the token in the Secret key field as a HTTP header in all API requests as follows: Authorization: Bearer $secret_key.

By default, a newly created key has no restrictions; namely, all restrictions are in “off” mode.

Request Format

All HTTP requests, submitted through Gate, must use the following methods​: POST GET PUT PATCH DELETE

Each HTTP request to the payment platform must include the following elements:

  • Method, URI, protocol;
  • Headers;
  • The message body, or payload, that contains JSON string in the form of UTF-8 with request data, including the signature.


POST /api/v0.6/orders/ HTTP/1.1
Accept-Language: en-US.
Content-Type=application/json; charset=UTF-8


The requests the merchant web service generates must include the basic and the relative addresses.

Response Format

Depending on the method used ( POST GET PUT PATCH DELETE ), you will receive a response in JSON format, which will describe the object that you modified or created.

Each HTTP response to the web service includes the following elements:

  • The status line that contains the following: the protocol and its version, status code, and reason phrase;
  • Header fields;
  • The message body, or payload, that contains JSON string in the form of UTF-8 with response data;
  • Status codes are used in the status line to inform about successful or failed request acceptance or execution, as well as the error causes.

Status codes:

200: The request has been successfully executed. The response body has the requested data 400: The request can not be accepted because of missing mandatory parameters in JSON string 403: Wrong authorization token


access-control-allow-origin: https://gate.decta.com/
access-control-expose-headers: content-disposition 
content-language: en
content-type: application/json
date: Thu, 12 Mar 2020 11:27:55 GMT
server: nginx
status: 400
vary: Accept-Language, Origin, Cookie
x-frame-options: DENY


Webhooks Format

Gateway provides the option to configure receiving webhooks for a wide range of possible results, when conducting various transactions. You can create webhooks for any product to send automatic notifications to your chosen destination, with a note that the event occurred on your payment page.

Each webhook from the payment platform must include the following elements:

  • The start line which contains the following: the HTTP method which always is POST PUT PATCH DELETE the web service endpoints for webhooks with results, the protocol, and its version;
  • The header with the Host field that contains the domain name of the web service;
  • The message body, or payload, that contains JSON string in the form of UTF-8 with result data including the signature.


Host: ddt.requestcatcher.com
Accept: /
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 11440
Content-Type: application/json
User-Agent: python-requests/2.7.0 CPython/3.5.9 Linux/4.15.0-76-generic
X-Webhook-Event: card.created
X-Webhook-Version: v0.6

    "cardholder_name":"GATE TEST1",
    "product_type":"Consumer - credit",

More information about webhooks can be found here.

Domains and IP Addresses

Your integration must be able to communicate with DECTA for it to function properly. Depending on how your integration operates, you may need to whitelist our network. To ensure that your integration operates securely, it must communicate with DECTA domains through appropriate IP addresses. If your integration also receives webhooks from us, ensure that these events originate from a DECTA webhook IP address.

DECTA Domains

If your network configuration allows domain whitelisting, then include these DECTA domain names:

  • gate.cy.decta.com
  • transactions.cy.decta.com
IP Addresses

You must systematically resolve our IP addresses. To do so, perform DNS lookup for both domains mentioned above. We recommend that you check every hour. We do not provide a list of IP addresses for whitelisting. IP addresses change over time due to various reasons, hence hard-coded IP addresses may disrupt interactions.

Webhook Notifications

For webhooks, we use static IP addresses. Webhook notifications may come from the following IP addresses:


Jump to
  • Get Started
  • Setup