This guide will review the different environments for the PayConex API, considerations that you may need to make in your environment, and some best practices for persistent HTTP connections.

PayConex API Environments

There are two PayConex API environments, one for testing (certification) and one for processing live transactions (production). Below you will find the base URL for each environment.

Certification Environment

The certification (AKA: cert, or test) environment is available for use when testing or developing software.

• The base URL for the PayConex certification environment is: https://cert.payconex.net

Production Environment

The production environment is what merchants use for processing live transactions.

• The base URL for the PayConex production environment is: https://secure.payconex.net

PayConex API Endpoints

There are four endpoints in the PayConex API Library:

📘

Note

In the following guides within this section where things like processing transactions, creating reports, or scheduling recurring transactions are coverd the relevant API end-point/paths that will be noted there as well.

PayConex IP Address Ranges

PayConex utilizes a web application firewall (also known as a Cloud WAF) to help bolster security and accessibility to PayConex. This means PayConex can communicate via a number of different IP addresses.

If a software or application environment integrating with the PayConex API is using (or requires) an allow/white list, firewall, or access control list to block illegal requests or access to the network then the PayConex IP ranges below will need to be included as allowed traffic for the application to work.

Here is a list of IP address ranges that are used by Cloud WAF PayConex:

199.83.128.0/21
198.143.32.0/19
149.126.72.0/21
103.28.248.0/22
131.125.128.0/17
45.64.64.0/22
185.11.124.0/22
192.230.64.0/18
107.154.0.0/16
45.60.0.0/16
45.223.0.0/16
2a02:e980::/29

The ranges below have been converted using the above values to simplify the IP ranges for convenience:

199.83.128.1 - 199.83.135.254
198.143.32.1 - 198.143.63.254
149.126.72.1 - 149.126.79.254
103.28.248.1 - 103.28.251.254
185.11.124.1 - 185.11.127.254
45.64.64.0 - 45.64.67.255
192.230.64.1 - 192.230.127.254
107.154.0.0 - 107.154.255.254
45.60.0.1 - 45.60.255.254
45.223.0.1 - 45.223.255.254
131.125.128.1 - 131.125.255.254

Best Practices for Persistent HTTP Connections

Overview

Persistent HTTP connections, also known as HTTP keep-alive, are a mechanism that allows the same TCP connection to send and receive multiple HTTP requests and responses. This can significantly reduce latency for consecutive requests, as well as lower CPU and memory use since there's no need to set up a new connection for each request.

However, we strongly recommend against setting up persistent HTTP connections to our platform with an indefinite keep-alive timeout.

Why Not to Use Indefinite Keep-Alive Connections

DNS-based Traffic Routing

Our platform uses DNS-based traffic routing for maintenance, vulnerability scans, and code deployments. An indefinite keep-alive connection can interfere with this routing strategy, causing your application to miss real-time updates and possibly send requests to retired or less optimal endpoints.

Latency

While persistent connections can initially be advantageous for reducing latency, they can become less efficient over time. Your initially optimal network path might become suboptimal, increasing the latency of the http requests.

Security Risks

Longer-lived connections offer an extended window for potential attackers to exploit vulnerabilities, leading to unauthorized access or data breaches.

Our Recommendations

5-Minute Timeout

Please set a 5-minute timeout on all persistent connections to our platform.

Stagger Connection Pooling

If your application uses connection pooling, stagger your persistent connections. This helps ensure that you always have some connections that are "fresh" and more likely to be routed optimally.

Sample Request with 5-minute Timeout

Here is how you can configure your HTTP request to have a 5-minute keep-alive timeout:

POST /api/device/validate HTTP/1.1
Host: secure-prod.decryptx.com
Connection: keep-alive
Keep-Alive: timeout=300
Content-Type: application/json
Content-Length: 86

{
    "partnerId" : "bluefin",
    "partnerKey" : “<REDACTED>"
}

By setting the Connection header to keep-alive and specifying a Keep-Alive: timeout=300 (300 seconds is equivalent to 5 minutes), you can maintain a persistent connection while adhering to our platform's guidelines.

Inactivity Termination

Note that all connections to our platform will be terminated after 5 minutes of inactivity. Please design your applications to handle this gracefully.

By following these guidelines, you help ensure that your interactions with our platform are efficient, secure, and reliable.