Testing is a critical component of your payment integration process across in-person, online, and mobile channels. To provide the best customer experience possible, everything within each transaction must work consistently to deliver fast, accurate, and secure payments.
Part of the value of working with Worldpay’s payment APIs is that we have several eCommerce testing and certification platforms that are optimized for different applications that your company may use.
There are three testing environments available: Sandbox, Pre-Live, and Post-Live. This article describes each environment, including how they are used and any roadblocks or issues that arise during the testing process.
Pre-Production Testing Environments
Pre-production testing environments include Sandbox and Pre-Live.
The Sandbox environment is a simulator to test your payment integration process. It has a basic interface that allows you to conduct functional level cnpAPI, Chargeback API, and the Merchant Provisioner API (V13 and above) message testing. While it’s typically used with cnpAPI Software Development Kits to gauge basic functionality, you can also test XML messages for the aforementioned three supported APIs.
You do not need a password to use the Sandbox. You can find it online at
In terms of any limitations, it’s important to remember that the Sandbox is not made for testing full functionality. As a stateless simulator, there is no historical transactional data. Therefore, the Sandbox is not for certification or regression testing.
Next, the Pre-Live test environment is used for all merchant certification testing. It is recommended for new Worldpay eCommerce merchants that may be coding a direct XML integration for the first time. It is also applicable for existing Worldpay eCommerce merchants who want to include additional features or functionality as part of their XML integrations.
Although this testing environment provides a working version of the Worldpay production system, it operates using simulators rather than communicating directly with the card associations.
The Pre-Live environment gives you the ability to undertake self-provisioning of a basic test account through www.testvantivcnp.com/prelivemid. This account lets you submit most standard transaction types. However, you cannot test many of the Worldpay eCommerce Value Added Services (VAS).
Other limitations include the number of merchants configured per organization. You’ll only be able to use as many as necessary to perform the required certification testing. Also, data retention is limited to 30 days.
The post-production testing environment is known as Post-Live. This environment is a copy of the merchant’s production and matches your Worldpay eCommerce Production profile, which is set up for VAS and their MIDs. It’s also where you can perform regression testing to ensure you are prepared to start accepting payments.
You can use this testing environment after becoming fully certified and submitting transactions to the Worldpay production platform. When you complete the initial certification and on-boarding process, we migrate you to the Post-Live environment so you can complete any ongoing testing needs.
The Post-Live system provides a working version of the Worldpay production system. However, it still operates using simulators rather than communicating with the card associations. Unlike the Pre-Live platform, though, all merchant accounts/IDs are in sync with the Worldpay production environment.
There are some limitations to keep in mind beyond just the simulators used during this testing environment. It can only process a daily limit of 1,000 online transactions and 10,000 batch transactions.
In terms of common roadblocks for Sandbox, this is primarily an independent testing environment where we do not get involved. This is because we do not have any logging or merchant interactions within that environment.
For Pre-Live and Post-Live, common roadblocks include IPs that are not properly identified and are accessing these testing environments. Therefore, they are not whitelisted, which prevents them from gaining access to the environment.
Additionally, using the incorrect URL/Credential/MID combination can create issues. Each environment has its own URL to post transactions and XML credentials and MID(s).
Transactions and Response Codes
All testing environments include data you can use to test your transaction processes. This includes card numbers, expiration dates, and transaction amounts, which enables you to generate structured requests that match the required cnpAPI schema. Our Implementation Consultants will work with you to create and access your test account.
Remember that it is important to determine which transaction types you will use according to your business needs before you begin using the aforementioned testing environments. Basic transaction types include Authorization, Capture, Sale, Credit, and Void. However, there are others to consider. For example, if you offer Direct Debits as a alternate payment method, there will be specific certification tests. Or, if you use the Insights feature set, there are more Authorization tests to undertake.
For example, you’ll want to test authorization as part of a payment. This Includes AVS Only, Capture, Credit, Sale, and Void Transactions. Just related to authorization testing, there are 26 data sets you can use. There are standard authorization tests as well as those for partial authorization, prepaid indicator, affluence indicator, and declined or duplicate transactions.
You can also opt to receive information like the issuer country for the card that will help you detect any potential fraud and verify the origin for the purchase. Response elements will send back messages like approved or declined, the type of payment like prepaid, available balance, and approved amount.
There are other test transactions, such as reversal transactions, direct debit transactions, token transactions, and query transactions. Processing tests include stored credentials and online duplicate transaction. You’ll also be able to test for refund authorization.
Numerous optional tests provide a way to customize the payment testing environment to your business needs. For example, you can test address responses, international cards, security code no-match, tax billing, recurring payments, advanced fraud tools, and convenience fees. Other test address specific alternative payment transactions like gift cards, MasterPass, Apple Pay and Google Pay.