What a CVV test data example actually is
A CVV test data example is a fake security code paired with a fake card number that a payment processor publishes for its sandbox. Nothing about it points to a bank account, a cardholder, or a line of credit. You type it into a test-mode checkout, the gateway checks it against a list it owns, and it returns a scripted answer: approved, declined, wrong CVC, expired card. That is the entire point. You get to watch your error handling work without putting anyone's real card anywhere near your code.
CVV Test Data Comparison Guide
The phrase gets thrown around loosely, so it helps to be blunt about the boundary. Test data comes from a processor's public documentation. A list of numbers sold as fresh or live has nothing to do with testing, and pasting one into a sandbox tells you nothing useful. Stick to published values.
Format rules the test values follow
Good test data mimics real formatting, which means your input masks and validation paths get exercised instead of bypassed.
- Visa, Mastercard, Discover: 3-digit CVV, printed on the back of the card
- American Express: 4-digit CID, printed on the front
- Card length: 15 digits for Amex, 16 for most other brands
- Luhn check: published test numbers are built to pass it, so a Luhn failure in your form points at your code, not the data
- Expiry: any future date works in most sandboxes, and several gateways also publish a deliberately expired number
Where the specific values come from
Stripe, Adyen, Braintree, and Authorize.Net each keep their own table, and the values do not transfer between them. A number that approves in one sandbox may be unrecognized in another.
CVV Test Data Script: How to Use and Why It's Essential
Stripe's most quoted line is 4242 4242 4242 4242 with any future expiry and any 3-digit CVC. Its Amex-style test card is 3782 822463 10005 with a 4-digit code. Adyen's test set uses 4111 1111 1111 1111 for Visa and 5555 4444 3333 1111 for Mastercard, and its Amex case expects the specific 4-digit value 737. Braintree's sandbox runs on 4012 8888 8888 1881 and 5555 5555 5555 4444, taking a standard 3-digit CVC for those and a 4-digit code for Amex. Check the current docs before you hardcode anything, since processors retire numbers.
Decline and error tests
The failure cases are where test data earns its keep. Many gateways map a specific card number to a specific decline reason, so you can force the exact branch of code you want to review.
- Generic decline: 4000 0000 0000 0002
- Insufficient funds: 4000 0000 0000 9995
- Expired card: 4000 0000 0000 0069
- Incorrect CVC: 4000 0000 0000 0127
- Processing error: 4000 0000 0000 0119
- Authentication required: 4000 0000 0000 3220
Run each one through your checkout and confirm two things. First, that the customer facing message matches the actual reason. Second, that your retry logic stops after the retries you intended instead of hammering the endpoint.
Keep test values and live values apart
This is the rule that matters most. Test CVV values belong in sandbox mode only, and PCI DSS forbids storing the CVV or CVC after a transaction is authorized, in any environment. If someone builds a fixture by copying numbers out of production logs, they have created a compliance problem, not a test. My own habit is boring and it works: one fixtures file per gateway, a comment naming the source doc, and a check that refuses to load test values when a live key is present.
Checklist before you ship
- Confirm each test number against the processor's current documentation.
- Cover approval, generic decline, wrong CVC, expired card, and insufficient funds.
- Test the 4-digit Amex path separately from the 3-digit path.
- Verify your form rejects a bad Luhn checksum with a clear message.
- Make sure no test value can reach a production endpoint.
Do that and your integration handles the boring cases, which are the ones that break in production.