Security best practices

This document describes our secure ciphers, qualified domain names and appropriate certificate checks you should complete to ensure the services are authentic.

Domain Names

See below our Access Worldpay endpoints/Fully Qualified Domain Names (FQDN):

Test domain

try.access.worldpay.com

Production domain

access.worldpay.com

Considerations:

• Ensure you only use the FQDN listed above when sending information to Access Worldpay

• IP address-based messaging is not supported. Worldpay firewalls reject any direct IP communication that has not routed via a FQDN

• Do not make any assumptions about 'redirect' URLs presented by us

• We provide all cookies in full and they must be stored in full

DNS and time to live

The Edgekey network we utilize for DNS is made up of thousands of dynamically changing IP addresses. Our DNS entries have a 20-second Time-To-Live (TTL), and you should ensure your TTL is as closely aligned to this as possible. This ensures you can respond to any DNS changes in a timely manner.

Server Name Indication

Server Name Indication (SNI) is required on all requests for Access Worldpay. You must ensure your HTTP client library fully supports TLS SNI.

Firewall and IP addresses

• Do not whitelist or implement firewall restrictions to any ingress IPs - the ingress IP addresses for the FQDNs are part of a global network. These IPs are subject to change at any time and are routinely taken offline for maintenance.

• All traffic must route via an FQDN - we do not support raw access to our services by IP address. Worldpay firewalls block any requests it receives of this type.

• Use DNS to obtain an active and available IP address. Do not create static DNS or 'hosts' files within your environment.

• Do not whitelist the Access Worldpay outbound IP addresses - The outbound IP addresses, Access Worldpay pushes content from, are currently limited to a range of IPs. The IPs are subject to future change.

Web Application Firewall

Access Worldpay is protected by a Web Application Firewall (WAF). Our WAF inspects the HTTP payload and detects potentially malicious activity.

On 8th June 2023 we migrated try.access.worldpay.com to a new WAF. This allows testing against the new WAF before access.worldpay.com is updated.

We are migrating access.worldpay.com to the new WAF. This will be done in two stages:

1. Soft Launch - the new WAF was enabled between 09:00 (UTC) and 11:00 (UTC) on 25 July 2023
2. Full Launch - the new WAF will be fully enabled at 09:00 (UTC) on 16 August 2023

Our customer-facing ‘test’ endpoint - try.access.worldpay.com - has been moved to the new WAF. We strongly recommend you validate against try.access.worldpay.com now to ensure your systems are still able to connect and process test/dummy payments. The try.access.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 the try.access.worldpay.com 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 try.access.worldpay.com helps to ensure little or no impact when the above live payment endpoints are migrated.

Ciphers

Ensure your platform is configured with a set of current and secure ciphers. You must update them regularly to ensure you communicate securely with our Access APIs.

We accept and support:

Certificate handling

All Access Worldpay services use HTTPS and provide an X509v3 certificate when you connect. This certificate allows the connecting client (typically yours) to authenticate that the service you are talking to is owned by us.

Historically we have used DigiCert as its Certificate Authority (CA). However, through 2023 our domains will switch to presenting certificates signed by Sectigo.

Customers must add the following Sectigo CA root to their environment to prepare for this change:

• CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
• Serial Number: 01:fd:6d:30:fc:a3:ca:51:a8:1b:bc:64:0e:35:03:2d
• You can obtain a copy of the Sectigo root certificate from their website:Sectigo Root Certificates

Ensure that you perform validation based on root certificates alone.

You should not trust intermediate certificates directly because they can change at any time. Trusting the root alone is sufficient.

Appropriate checks

The following lists the appropriate checks you MUST make on the certificate provided by the service.

Certificate subject matches hostname

The service must return a certificate with the domain name, the client is trying to connect to, in the subject alternative name (subjectAltName) field. The value type for this field must be DNS as this indicates a fully-qualified domain.

For example:

To connect to Access Worldpay: The field subject alternative name or subjectAltName with value type DNS, must be https://access.worldpay.com

Certificate expiry dates

A certificate contains a notBefore and notAfter field that defines the dates outside of which the certificate is invalid. Therefore, only dates inside this window are valid.

Certificate chain validity

The client should verify each signature on the certificate chain and ensure that the certificate adheres to the policies defined by the certificate authority. All good implementations of TLS are doing this automatically. Please refer to the documentation of your library/framework for more information.

Every client has a list of trusted roots/trust anchors that are usually built into the operating system, browser or application framework. These are certificates from well-known companies such as DigiCert, Comodo, Microsoft, etc.

Access Worldpay certificates are currently signed by DigiCert - soon to be signed by Sectigo certificates. The root certificate is therefore most likely already in the client software's runtime.

Inappropriate checks

The following are checks that the client should NOT complete because the below values are NOT constant.

Certificate DN

You must not cache or store the certificate's "Distinguished Name (DN)" and check this against a provided certificate.

The DN for our certificate currently looks like this: C=GB, L=London, O=WorldPay (UK) Ltd, OU=GW2.0, CN=access.worldpay.com

Certificate fingerprint/thumbprint

You must not cache or store the certificate's fingerprint and check this against a provided certificate.

The fingerprint is unique to a certificate because it's calculated by taking all properties of the certificate and generating a single number based on those values.

Public key

You must not cache or store the public key and check this against a provided certificate.

While not mandatory, we change our public key as part of the renewal as it's a security best practice.