Please try searching something.
Setup and Integration
Get Started
To start using our platform, you have to:
- Submit an application here;
- 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;
- Update the code of the merchant's web service to implement the integration;
- Test and put in production mode the updated web service code with specialists from the technical support;
- Once the testing and active monitoring phase is successfully completed, support team specialists will provide you regular technical assistance.
Setup
Authentication
Authentication is handled, using OAuth Bearer tokens.
- To generate your token, login into your Dashboard account and navigate to the E-commerce & API tab;
- Choose Explore Sandbox for Free to enter the sandbox mode for the API testing;
- 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
totrue
. 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 isAll
; - Field
Website
: contains the list of all websites, connected to the merchant. Default value for exisiting API keys isAll
; - Field
3D authentication
: by default set toOn
; - Field
Default terminal
: contains all terminals of the chosen website;
- Find your newly-created key in the Key sets list and click the pencil next to it;
- 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.
Example:
POST /api/v0.6/orders/ HTTP/1.1
Authorization=Bearer
3a2240923bd202c7ccbc1d2a872afb7dac4ea1872a51b8d6f800817bfe25e78c
Accept-Language: en-US.
Accept=*/*
Content-Type=application/json; charset=UTF-8
{
"client":{
"email":"test@test.com"
},
"products":[
{
"price":0.3,
"title":"test"
}
]
}
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
Example:
access-control-allow-origin: https://gate.decta.com/
access-control-expose-headers: content-disposition
allow: GET, POST, HEAD, OPTIONS
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
{
"type":"tax",
"id":"ed791b76-4f80-4f80-a107-318f9c4b56d1",
"name":"name",
"percent":23.0
}
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.
Example:
POST / HTTP/1.1
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
{
"id":"265ce7ef-8aba-41e4-ab78-08af7e6854f8",
"transaction_type":"DEBIT",
"client":"54562e96-b466-4468-9575-deec251b69c5",
"merchant":"a9804a42-12db-44a5-a44f-d96a5d91686a",
"masked_pan":"429555******1591",
"exp_month":7,
"exp_year":20,
"is_default":false,
"cardholder_name":"GATE TEST1",
"product_type":"Consumer - credit",
"issuer_country":"Latvia",
"region_card_issuer":"EU",
"card_type":"Visa"
}
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.decta.com
-
transactions.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:
-
18.157.244.107
-
3.67.43.46
Jump to
- Get Started
- Setup