What is a Worldpay test CVV?
A Worldpay test CVV is any three- or four-digit value you type into the security code field while running a transaction against the Worldpay sandbox. The sandbox does not ask an issuing bank to check that code, so a fixed value such as 123 passes with most test cards. The field is there to prove your checkout form, your API request, and your error handling work, not to verify a real cardholder.
That difference matters. In production the CVV result arrives from the issuer as a response code. In test mode the response comes from Worldpay's simulator, and the outcome depends on the card number you use.
How does Worldpay handle the CVV field in test mode?
Worldpay routes sandbox traffic to a simulator, not to a live acquirer. The simulator reads the card number, looks it up in a table of test cards, and returns the result code attached to that card. Your CVV digits have no effect on the outcome.
This is why two runs with the same test card and different CVV values return the same approval. It is also why you cannot trigger a CVV mismatch decline by typing a wrong number. To test that path, you pick a test card configured to return that response.
- The test card number drives the result.
- The CVV field is checked for format only, if at all.
- Amount, currency, and card brand still follow normal rules.
Where do you get Worldpay test card numbers?
Use the test card table published in Worldpay's developer documentation. Each entry lists a card number, an expiry date, and the response the simulator returns. Your Worldpay integration profile or account manager can confirm which table applies to your account setup.
Copy those numbers into your test fixtures and label them as sandbox-only. Never place a test card number in a production config file, and never place a live number in a sandbox file.
Which CVV value should you send with a test card?
Send a value that matches the card brand format, because that is what your form and your gateway library expect. Three digits for Visa, Mastercard, and Discover. Four digits for American Express.
- Use 123 for three-digit brands and 1234 for Amex in sandbox requests.
- Skip 000 and 0000 if your own form validation rejects them before the request leaves your server.
- Keep the value in a config constant so no one mistakes it for real data.
- Confirm your logs mask the field on the way out.
Does the Worldpay sandbox test everything the CVV touches?
No. The sandbox confirms that your request is shaped right and that your page handles a response. It does not reproduce issuer-side CVV checks, 3-D Secure challenges from a real bank, or network declines that start outside Worldpay.
Plan separate tests for those paths. Use decline-simulation cards for the basic cases, a certified 3-D Secure test setup for authentication flows, and your own mocks for anything the simulator cannot produce.
Can you buy a CVV for testing?
No. CVV data is not something you buy. Sellers that advertise fresh CVVs trade in card numbers stolen from real cardholders, and buying or using them is a federal crime in the US under identity theft and access device statutes. A test environment never needs one.
If a supplier tells you a CVV is required to verify a Worldpay test account, that is a fraud pitch. Worldpay's sandbox runs on published test cards and settles no money. End the conversation there.
How do you test CVV declines without real card data?
Use the decline-simulation cards in the Worldpay test table. Those cards return the same response codes a live issuer would send, including CVV and address verification failures, so your error paths get real coverage.
- Pick the test card mapped to the CVV or AVS decline you want.
- Run the transaction through your checkout flow, not a raw API call, so the UI path is covered too.
- Check that your page shows a clear message and offers a retry.
- Confirm the decline creates no order, no shipment, and no retry loop.
- Search your logs for the CVV digits and remove any hit.
What should you never do with CVV data?
Never store it, log it, or send it to analytics. PCI DSS treats the CVV as sensitive authentication data, and Requirement 3.2 forbids keeping it after authorization, even in encrypted form. Sandbox values are harmless, but the habits you build in test carry into production.
Mask the field in your debug output. Set your error tracker to drop the parameter. Add a test that fails the build if a CVV-shaped value shows up in a log line.
Frequently asked questions
Is the Worldpay test CVV always 123?
No single value is required. 123 shows up in sample code because it fits the three-digit format. Any correctly formatted value works with a sandbox test card.
Can I use a live card number in the Worldpay sandbox?
Do not. Live cards in test mode create confusion at reconciliation time and expose real cardholder data to systems that were never audited for it. Sandbox work uses sandbox cards, with no exceptions.
Why does my sandbox transaction fail on CVV?
Look at the card number first. Most failures blamed on the CVV come from a test card that is configured to return that decline, or from a mismatch between the card brand and the number of digits your form accepts. Check the response code against the Worldpay test table before you change code.