WPG best practice

Worldpay's payment gateway (WPG) is designed to be simple to integrate to, and flexible enough to meet your needs. To make the most of your integration with WPG, and to ensure you're always up to date, follow our best practice. Changes to our infrastructure are made with these best practices in mind. Follow this guide to ensure you do not experience issues connecting to the gateway now, and in the future.

Certificates

You must ensure that any systems that connect to the WPG (either server software or browsers) trust certificates signed by the following Certificate Authority (CA) root:

• DigiCert Global Root G2
• Serial: 03:3a:f1:e6:a7:11:a9:a0:bb:28:64:b1:1d:09:fa:e5

You can obtain a copy of the DigiCert root certificate from the DigiCert website: https://www.digicert.com/kb/digicert-root-certificates.htm

Ensure that you do:

• Perform validation based on root certificates alone. Intermediate certificates should never be trusted directly because they can change at any time

Ensure that you do not:

• 'pin' SSL certificates. Pinning Worldpay certificates should be avoided. Worldpay regularly renew and update certificates during standard maintenance practices. If you 'pin' Worldpay SSL certificates your integration will break every time we update our certificates

Ciphers

Please ensure your platform is configured with a set of current and secure ciphers. You must update them regularly to ensure your platform is using the most secure cipher sets when communicating with the WPG. The most common cipher currently used by our customers when connecting to our gateway is:

• ECDHE-RSA-AES256-GCM-SHA384

To see the current set of supported ciphers, use www.ssllabs.com to query the WPG endpoints.

WPG endpoints

A list of common WPG endpoints/fully qualified domain names (FQDN):

• secure-test.worldpay.com
• secure.worldpay.com
• futurepay-test.worldpay.com
• futurepay.worldpay.com
• dtd.worldpay.com

Additional hostnames may be communicated to you for specific purposes. Only use these hostnames for the purpose specified by Worldpay.

Ensure that you:

• Send messages to FQDNs. IP address-based messaging is not supported. Worldpay firewalls reject any direct IP communication that has not routed via a FQDN.
• Use only the hostnames listed above when sending information to the WPG.
• Only cache domains within the published Time To Live. This ensures that you respond to DNS changes in a timely manner.
• Do not make any assumptions about 'redirect' URLs presented by us, or the naming of cookies.

Server Name Indication

Server Name Indication (SNI) is required on all requests into the WPG. You must ensure your HTTP client library fully supports TLS SNI.

Firewall and IP addresses

To ensure stable and consistent communication with WPG you must not lock down your firewalls to a set number of individual IP addresses.

• The ingress IP addresses for the FQDNs are part of a global network. You must not whitelist or implement firewall restrictions to any of the ingress IPs. These IPs are subject to change at any time.
• The outbound IP addresses WPG pushes content from are currently limited to a range of IPs. The IPs are subject to future change and we recommend you do not whitelist them.
• We do not support Raw access to our services by IP address. Worldpay firewalls block any requests it receives of this type. All traffic must route via an FQDN.
• We do not support static DNS or 'hosts' files within the customer's environment.

HTTP Headers: Expect: 100-Continue

When an HTTP connection is made to WPG, the client software can set certain request headers. These headers can include Expect: 100-Continue. Historically this was used to reduce transmitting request bodies if the server was not going to accept it, useful for very large request bodies such as file uploads. For interaction with WPG--which typically has a relatively small request body--there is no real benefit to using Expect: 100-Continue headers.

Most modern software no longer make use of Expect: 100-Continue headers as they serve limited purpose now that bandwidth is less of a scarce resource. However, some older software libraries set the Expect: 100-Continue headers by default when they establish a connection. Although this is a legitimate part of the HTTP specification, in practice it has very little value, and the Web Application Firewall (WAF) that protects the WPG platform does not support Expect: 100-Continue headers.

If you use these headers, you may experience timeouts during the connection attempt, or possibly slow, with intermittent success, connection attempts.

If your software is using Expect: 100-Continue headers, the best course of action is to upgrade to a more recent version. If upgrading is not possible, you may be able to reconfigure. If the software is based on PHP/libcurl, use this as a possible fix:

Find a line similar to:

• CURLOPT_HTTPHEADER => array('Content-Type: application/xml')

and change it to:

• CURLOPT_HTTPHEADER => array('Content-Type: application/xml', 'Expect: ')

Web Application Firewall + Timeline

WPG is in the process of migrating behind a Web Application Firewall (WAF). If the best practice guide is followed, this migration activity is seamless for you.

These endpoints are scheduled to be migrated during May 2022:

• futurepay.worldpay.com
• worldaccess.worldpay.com

These endpoints are scheduled to be migrated during June 2022:

• dtd.worldpay.com
• secure.worldpay.com

Our customer-facing ‘test’ endpoint is fully protected behind the WAF. We strongly recommend you validate against secure-test.worldpay.com now to ensure your systems are still able to connect and process test/dummy payments. The secure-test.worldpay.com endpoint is reflective of how the above URLs will behave once they are migrated behind the WAF.

If your system is unable to connect to this ‘test’ endpoint, then this is a sign your system is configured in a way that goes against the Best Practice guide. Please review the guide to help identify the changes required for your environments.

Successful verification against the ‘test’ endpoints helps to ensure little or no impact when the above live payment endpoints are migrated.