Here we give recommendations for how to configure your network for point of sale transactions, and how to solve certain network issues.
When you make a point of sale transaction, your cash register, terminal, and Adyen will need to be able to communicate with one another. The flow of this communication depends on whether your integration uses local or cloud communications, and you will need to ensure that your network is configured to allow access to specific ports and addresses.
Network communications flow
When you make a transaction, your integration uses one of the following communications flows:
Configuring your network
To configure your network for point of sale communications:
If you need to whitelist IP addresses, add Adyen's domains to your firewall's whitelist.
Configure your firewall to allow outgoing HTTPS traffic from the IP addresses of your cash registers and terminals to:
Whitelisting should be based on the DNS name of these URLs. Your firewall should dynamically check for IP address updates, at least every 60 seconds.
Do not hard-code Adyen's IP addresses, as these can change over time. We do not share a list of our IP addresses publicly.
Open the ports:
- tcp/443 to the internet.
tcp/8443 on your LAN.
- If your integration uses local communications:
- Ensure that your terminal and cash register are connected to the same local network.
- Secure the communications between your cash register and terminal.
- If you are using a legacy setup where the cash register and terminal communicate over a serial connection, use hardware flow control.
Once you have configured your network to meet these requirements, you should also review our networking recommendations for further information on preventing communication issues.
General networking recommendations
To prevent network issues from interfering with your point of sale transactions, we recommend that you:
- Use a segmented network, dedicated to point of sale communications.
- Define unique static IP addresses for your terminals with a DHCP server.
If you are not able to use a DHCP server, define static IP addresses for your terminals on your local network.
- Make a DNS server accessible from your local network. This should be able to resolve
If you use a caching name-server, the Time to live (TTL) set by Adyen must be honored (60 seconds for Disaster Recovery).
- If you use intrusion detection (IDS) and prevention systems (IPS), ensure they are using up to date firmware and signatures. If these are out of date, the encrypted communications used by your integration may be disrupted.
- Connect your cash registers and terminals to an uninterrupted power supply (UPS).
Use a cellular backup connection by:
- If the network connection is fine but you are noticing issues with terminals and payments that seem to point to network connection problems, refer to Avoid dropping TCP network packets due to MTU size.
If you need more information on configuring your network, contact our POS Support Team.
Using a proxy
Adyen terminals do not support proxy connections. If your network uses a proxy, allow your terminals to bypass the proxy and connect directly to the Adyen payments platform.
To connect your Adyen terminals over Wi-Fi, your access point needs to support:
- WPA2-personal or WPA2-enterprise encryption.
To use WPA2-enterprise encryption, contact our POS Support Team.
- 2.4Ghz or 5Ghz frequencies.
If you use Verifone e285 terminals, your Access Point must support 2.4Ghz channels.
In addition, we recommend that you:
- Use a dedicated private wireless network.
- If your integration uses local communications, disable the Wireless Isolation, AP Isolation, Client Isolation, or other similar features on your access point.
Dropped network packets when the internet connection is available
The internet connection is available, but still you notice issues that seem to point to a problem with the network connectivity:
- A high number of unauthorized payments.
- Payment terminals that fail to go online or that switch to Store and Forward transactions.
- Terminal applications intermittently failing to load.
The cause can be payment packets being dropped because the Maximum Transmission Unit (MTU) is exceeded. The MTU is the largest size packet that can be sent over a network connection. Routers will fragment or drop packets that are bigger.
The default MTU for payment terminals is 1500 bytes. Part of the MTU is reserved for the Transmission Control Protocol (TCP) and Internet Protocol (IP) headers of the connection. This leaves 1460 bytes for the Maximum Segment Size (MSS). The MSS is the maximum amount of data in bytes that is accepted in a TCP session.
As a packet travels along its network path, more header bytes may be added, for example by PPPoE, VPN, or MPLS network protocols you are using. The terminal is not aware of those additional headers and continues to transfer packets with the default MTU. The network router at your store or data center can't fragment the packet because the terminal marks payment packets as "Don't Fragment". As a result, your router drops the packet even though the internet connection is available.
A good technique to avoid packets being fragmented or dropped, is to lower the MSS. Network vendors refer to this as TCP MSS clamping, TPC MSS ceiling, or TCP MSS adjustment. Here are some resources to help you understand this technique:
- Cisco - ip tcp adjust-mss
- Juniper - Configuring TCP MSS for Session Negotiation
- Linux - Circumventing Path MTU Discovery issues wiuth MSS Clamping
Changing the MSS value affects all your network traffic. So before you start lowering the MSS, contact your network support team or the support center of your network vendor.
The standard technique to avoid packets being fragmented or dropped, is Path MTU Discovery (PMTUD). This technique allows network hosts to determine the MTU on a network path. In practice however, most networks don't allow the Internet Control Messages Protocol (ICMP) that this technique relies on.