Security

API Communications

Communication between the e-shop and the Comgate API takes place in three ways:

• E-shop🠖Comgate
  • Server2Server - the server part of the e-shop solution connects to the server part of the payment gateway and calls, for example, methods for creating a payment, obtaining the payment status in the background and others. These calls are easy to identify by the endpoint name, where the path starts with /1.0/ or /2.0/. Requests to this API must be made from the server precisely so that the access key (secret) is not disclosed.
  • Client2Server - the client part of the e-shop solution (a mobile application) connects as a client to the server part of the payment gateway and processes the payment directly. An example is calls to the /checkout/ endpoint, where payments are processed through the native Apple Pay and Google Pay implementation, for instance.
• Comgate🠖E-shop - the server part of the payment gateway connects to the server part of the e-shop solution and calls the method for transferring the payment result in the background (PUSH notifications).
• Redirect - the page loaded in the payer's browser is redirected from the e-shop to the payment gateway using the GET method and then from the payment gateway back to the e-shop (also using the GET method).

In all cases, the use of the encrypted HTTPS protocol is necessary. The payment gateway only supports secure TLS/SSL protocol settings with the following allowed ciphers: https://github.com/cloudflare/sslconfig/blob/master/conf

Authentication to the API

In the case of Server2Server communication with the Comgate API, it is necessary to authenticate using the merchant and secret values:

• merchant is the identifier of the e-shop connection to the Comgate API,
• secret is a secret password that is unique for each connection.

These values are generated automatically and are available in the Client Portal in the section:

Integration 🠖 E-shop settings 🠖 e-shop name 🠖 E-shop connection tab 🠖 connection detail

Each e-shop can have several connections, each with different merchant and secret values.

POST protocol

These are calls starting with /1.0/.

Communication is secured using the merchant and secret values, which are sent to the server as submitted form data via application/x-www-form-urlencoded.

REST protocol

For REST, authentication takes place through an added Authorization header.

The header is in the form: "Authorization: Basic " + base64_encode("merchant:secret").

For example: "Authorization: Basic bWVyY2hhbnQ6c2VjcmV0".

Whitelist

Allowed IP addresses can be written in the format IPv4 or IPv4/MASK. Only one value is allowed per line. A comment can be added at the end of each line after the definition itself, separated from the value by at least one space.

If you are unable to determine the range of IP addresses for your system, you can enter the value 0.0.0.0/0, which allows addresses from all over the world. This setting is risky from a security standpoint and it is recommended to avoid it.

These parameters can be set in the client portal environment.

Example:

8.8.8.8 IP Google
1.1.1.1 IP cloudflare
8.8.0.0/16 Subnet Google
1.1.1.0/24 Subnet Cloudflare
0.0.0.0/0 Entire internet

Comgate IP ranges

Cloudflare service precedes the payment initiation. You can find the list of allowed IP addresses of Cloudflare here: https://www.cloudflare.com/ips-v4

The list of Comgate IP addresses is published at http://payments.comgate.cz/ips-v4. This range is only used for transferring the payment result in the background Push Notifications. If an IP whitelist is used, it is sufficient to load the IP addresses from the URL, e.g., once a day; it is not necessary with every request.

Content Security Policy (CSP)

If you use the Content-Security-Policy header on your website and want to display the Comgate payment gateway in an iframe on your page in any way, it is necessary to add a special directive frame-src *; to the CSP header. This specifies valid sources for loading nested contexts using elements such as <frame> and <iframe>.

For the frame-src directive, it is not sufficient to define only the domains of the Comgate payment gateway. All external contexts must always be explicitly allowed, i.e., *.

The reason for this setting is:

• the necessity to display the page with 3D Secure during card payments involving the payer,
• redirection to the web application at some payment method providers.

Example of a CSP header:

Content-Security-Policy:
    default-src 'self';
    script-src 'self';
    style-src 'self';
    img-src 'self';
    connect-src 'self';
    form-action 'self';
    frame-src *;
    frame-ancestors 'none';
    upgrade-insecure-requests

More information about Content Security Policy can be found on the MDN web docs pages.

For correct assembly of the Content-Security-Policy header, we recommend using a tool like Report URI.