Worldpay Test CVV: Sandbox Values Explained

Short answer

The Worldpay test CVV is the card verification value listed next to a sandbox test card number in your Worldpay developer account. It is a fake value that only works against test endpoints. It does not come from a bank, it is not tied to a live account, and it will not work in production. If your integration keeps failing on the security code field, the fix is usually to copy the exact CVV paired with the exact test card number you are using, rather than inventing three digits.

What the test CVV is, and what it is not

In a live payment, the CVV is a 3-digit value on the back of most cards (4 digits on American Express) that the issuer checks during authorization. In a sandbox, no issuer exists, so Worldpay maintains a table of test cards where each entry carries a card number, an expiry date, and a matching security code. The gateway compares what you send against that table instead of querying a bank.

• It is a sandbox credential, scoped to test endpoints and test merchant accounts.
• It is not a real cardholder value and does not belong to any person.
• It exists so you can exercise CVV validation logic without touching live data.
• It changes with the test card you pick, so treat number and CVV as one pair.

Where to find the CVV for your test card

1. Sign in to your Worldpay developer or sandbox account.
2. Open the test card or test data section of the documentation for your integration type (hosted payment page, API, or terminal).
3. Locate the test card table and read across the row for the card number you want to use.
4. Copy the security code column exactly, including leading zeros if present.
5. Store the pair together in your test fixtures so nobody has to look it up again.

Test card tables differ by region and by product, so always read the table that matches your configured merchant account rather than a snippet from a forum post.

Two ways to manage test CVVs

Hardcode the values in your test fixtures

• Pros: fast, deterministic, works offline, easy to read in a pull request.
• Cons: goes stale when the provider updates its test card list, and it spreads card-like strings through the codebase.

Read the values from the developer portal when you set up a run

• Pros: always current, keeps one source of truth, easier to audit.
• Cons: requires access, adds a manual step, and slows down unattended CI runs.

For most teams, hardcoded fixtures for everyday unit and integration tests plus a documented pointer to the portal table is the practical choice. Choose the portal-driven approach when you test in several regions or across several card brands and cannot afford a stale value breaking a build.

How CVV checks behave in the sandbox

Most test configurations accept the CVV printed in the table and return a successful security code match. Some test cards are documented to accept any three digits, which is convenient for form validation but hides real bugs. Sandbox behavior also depends on the risk rules enabled on your test account: if you switched on CVV checks, a wrong value produces a decline or a review result rather than a clean approval. Read the response fields for the security code result, not just the overall status, so you can tell the difference between a bad CVV and a bad card number.

Simulating a CVV mismatch

You need to know what your checkout does when the security code fails. Rather than guessing, use a test card designated in the documentation as the failure case, or deliberately send a value that does not match the table entry for your card. Then confirm three things: your form shows a clear, non-technical message, your order does not move to a paid state, and your logs record the security code result for support. Repeat for the expiry mismatch and the declined authorization cases so the three failure paths are distinct in your UI.

Common mistakes

• Mixing a CVV from one test card row with a card number from another row.
• Testing against live endpoints with sandbox values, which produces confusing errors.
• Trimming leading zeros when the value is copied into a numeric field or a spreadsheet.
• Assuming a passing sandbox CVV check proves your production risk rules are configured correctly.
• Skipping the failure path entirely because the happy path already works.

Handle test card data responsibly

Sandbox values are safe to paste into tickets and repositories. Real cardholder data is not. Never place live card numbers, live CVVs, or data bought from a third party into a test environment or a staging database. That practice violates PCI DSS, which requires that production cardholder data stay out of development and test systems, and in most jurisdictions it is a criminal matter as well. If you need realistic-looking values for volume testing, generate synthetic numbers that no issuer could ever assign, and keep CVV logic pointed at the sandbox table.

FAQ

Does the Worldpay test CVV work in production?

No. Production authorizations go to a real issuer, which validates the real security code on the real card. Sandbox values are rejected.

Is 123 a valid test CVV?

Sometimes, if the table entry for your chosen test card says so. Do not assume it. Read the row for the card number you are using.

Why is my test CVV rejected?

The usual causes are a mismatched card number and CVV pair, a CVV check enabled on the test account with a value that does not satisfy it, or a request sent to a live endpoint instead of the sandbox host.