To secure communications, ConnectPay API Gateway uses several security layers.

Server-to-Server communications

ConnectPay does not have static IP addresses of API servers, nor it is mandatory to whitelist TPP IP addresses.

To secure server-to-server channel, ConnectPay uses mutual TLS (a.k.a mTLS, 2way TLS, etc).

API consumer – acting as communication Client – has to provide CA issued full certificate chain in X509 ASCII Base64 format (PEM) with leaf, intermediate and root certificates. 
Self signed certificates are not sufficient and won’t be accepted.
Certificate chain must be full, starting with leaf and ending with root cert.

ConnectPay technical team will add provided certificate chain to the truststores.

Certificates with reversed order, with incorrect format or with incomplete chain will be rejected.

With each API request Client certificate will be validated at the webserver level (to check if it is not expired, etc) and at the application level (to check if cert in https handshake is same as cert provided by Client, if it not revoked).

Certificates are not required for merchants that are using plug in integration and are using Basic Auth method.

Access mTLS protected APIs via these hostnames:



Browser/Public-to-Server communications

In some cases, ConnectPay APIs must be accessed via public domain – auth redirects, notification webhooks, etc.

To access such APIs use separate 1way TLS API hostnames:



1way and 2way APIs are mutually exclusive – you can’t access cert protected APIs via 1way TLS subdomain and vice versa.

Tip! You will always find proper hostname in our API Reference under each API.

All server-to-server API communications (except for merchant APIs) must use 2way TLS (a.k.a, mTLS, Mutual-TLS). Merchant APIs use RSA public key.

Certificate will be added to API Gateway trust-stores and attached to your DevApp configuration. Depending on your solution, you can use same certificate for multiple DevApps or use separate certificates for each DevApp.

When receiving API request, we will check:

  • If certificate is not expired – by checking the Expiry date.
  • If certificate is not revoked – by contacting issuer’s OCSP service.
  • If Serial Number and Common Name properties are identical in Request certificate and DevApp-attached certificate.

Requirements/Recommendations for certificates:

  • Proper order – Certificate file must start with leaf certificate and end with root certificate.
  • Root included – Certificate file must contain root certificate.
  • Proper format – Certificates must be of X509 ASCII Base64 format.
  • Issued by CA – self signed certificates are not accepted. Use Comodo, DigiCert, BuyPass or similar CA to order certificate.
    • Let’s encrypt certificates will not accepted as they are issued only for 3 months and frequent rotations adds extra load on yours and ours DevOps teams and increases API failure rate – chance to forget rotate certificate is 4 times greater.
  • Not shared – we strongly recommend not to use same certificate for Prod and Stage. But please refer to your Company’s security policies, separation is not a mandatory requirement by ConnectPay.
  • DV – If you are ordering a new certificate and do not have any specific requirements we recommend domain validated (DV) certificates as they are quickest and easiest to get.
  • SSL QWAC for PSD2 – To access PSD2 Open Banking APIs, you, as TPP, have to use extended eIDAS PSD2 certificate with proper PSD2 TPP roles.

API security

APIs that do not require access to ConnectPay Person’s data are protected by http Basic Auth.

Check your DevApp configuration on DevPortal to retrieve ClientKey and ClientSecret

Encode colon separated ClientKey and ClientSecret to Base64 and add to Authorization header:

Authorization: Basic Q29ubmVjdFBheTpFYXN5QmFua2luZw==

In example above, ClientKey is ConnectPay and ClientSecret is EasyBanking :

Authorization: Basic Base64(ConnectPay:EasyBanking)

Data API access

DevApp creation

Scroll to Top