CVV test data is a set of card numbers and verification values that payment processors publish for sandbox use. The numbers pass format checks, including the Luhn check, and return scripted responses from a test API. They never reach a card network and never move money.
No card network publishes a standard called "CVV test data v4." The v4 label maps to a revision of a vendor list or to PCI DSS v4.0, the standard that governs how card verification values are handled in production.
What sits in a test data set
- Account numbers from ranges set aside for testing. Stripe publishes 4242 4242 4242 4242 for Visa and 5555 5555 5555 4444 for Mastercard.
- A CVC field. Most sandboxes accept any 3 digits. American Express uses a 4-digit CID.
- An expiry date in the future.
- A postal code or ZIP, which some sandboxes accept as any value.
Which CVC values pass
In a sandbox, the CVC is a field with a length rule and a character rule. It is not a secret. Stripe accepts any 3-digit CVC with its test PANs. Adyen, Braintree and Checkout.com follow the same pattern in test mode.
A few processors publish one PAN per failure case: a card that returns a CVC mismatch, a card that returns a decline, a card that returns insufficient funds. Those PANs live in the processor's own test documentation.
Numbers such as 123 or 000 appear in examples across the web. They carry no authority. The sandbox decides the response, not the digits.
Where v4 fits
PCI DSS v4.0 was published in March 2022. Future-dated requirements took effect on 31 March 2024. Version 4.0.1 followed in June 2024. PCI DSS v3.2.1 retired on 31 March 2024.
Requirement 3.3.1 of PCI DSS v4.0 states that sensitive authentication data is not retained after authorization. CVV, CVC, CVV2 and CID are sensitive authentication data. Storage is barred even when the value is encrypted. A test PAN pair in a sandbox sits outside that scope, because no cardholder account exists.
What test data cannot do
- Test PANs are declined in live mode. They fail issuer lookup or return a scripted decline.
- A real PAN with a real CVV is not test data. Feeding one into a sandbox sends live card data to a third-party system and breaks PCI DSS scope rules.
- Repeated trials on live keys trip fraud controls. Issuers and processors flag runs of low-value authorizations as card testing.
Checks before you use a list
- Confirm the numbers come from the processor's test documentation, not a forum post.
- Run a Luhn check. Test PANs pass it.
- Set the expiry in the future.
- Use test API keys and confirm the key prefix, such as sk_test_.
- Keep CVC out of logs and databases in both test and live code paths.
Some lists circulating as "CVV test data v4" mix sandbox PANs with live BIN ranges. Treat any list without a vendor name and a revision date as unverified.