CVV test data is a fake card verification value that developers pair with test card numbers inside a payment sandbox. It does not belong to any real cardholder, it cannot authorize a real transaction, and it exists only so you can check how your checkout code handles the CVV field.

cvv test data v4

What CVV test data actually is

The card verification value is the short code printed on a card: three digits on the back of Visa, Mastercard, and Discover cards, four digits on the front of American Express cards. A test CVV mirrors that format but carries no account behind it. Payment providers publish these values next to their test card numbers, so any developer can copy them into a staging environment.

CVV Test Data V9: A Comprehensive Guide to Buying CVV Online

  • Format: three digits for most brands, four for Amex.
  • Scope: sandbox and test mode only, never production.
  • Ownership: nobody. There is no card, no bank, and no balance.

How sandbox gateways treat the CVV field

Behavior depends on the provider, and that is the part most developers get wrong. Some gateways validate the CVV loosely in test mode and accept almost any three-digit number alongside a published test card. Stripe, for example, documents that its test cards accept any three-digit CVC together with any future expiration date. Other gateways ignore the CVV entirely in their test environment and return an approval regardless of what you send. A third group uses a fixed "magic" value, commonly 123, and rejects anything else with a validation error.

cvv test data v1

Read the provider documentation before you write assertions. A test suite that assumes one gateway's behavior will break the moment you switch processors or upgrade an SDK.

cvv test data v5

Common CVV test values

  • 123 and 1234 are the most widely published test values for three-digit and four-digit fields.
  • 000 and 999 appear in some provider test suites.
  • Sequences like 111 are useful when you want an obviously synthetic value in screenshots and logs.

None of these are universal. Treat them as defaults to try, not as a standard.

Testing CVV failure paths

A happy-path checkout proves very little. Most providers publish dedicated test card numbers that trigger specific decline responses, including a CVV mismatch decline, so you can confirm that your error messaging, retry logic, and order state transitions behave correctly when verification fails.

  1. Trigger a CVV mismatch and confirm the customer sees a clear, non-technical message.
  2. Confirm the order is not marked as paid and inventory is not committed.
  3. Check that your logs record the decline reason without recording the CVV itself.
  4. Verify the retry flow works when the customer corrects the code.

Rules for handling CVV test data safely

  • Never test with live card numbers. Use published test data even in staging.
  • Never store the CVV. PCI DSS forbids retaining the verification value after authorization, and that rule applies to your test harness too, since code has a habit of reaching production.
  • Keep test keys and live keys in separate configuration. A live key pointed at test data produces confusing failures and can look like fraud to the processor.
  • Do not log request payloads containing the CVV field. Mask it at the edge of your application.

One clarification matters here. Test CVV data is published, public, and harmless. Anything offered for sale as "working CVV data" for real cards is not test data at all; it is stolen card information, and using it is payment fraud with criminal exposure for everyone involved. Legitimate testing never requires a real card's verification value.

Mistakes to avoid

  • Expecting a test CVV to work against a production endpoint.
  • Assuming every gateway accepts any value in test mode.
  • Hardcoding a test CVV into a shared staging environment that others use for demos.
  • Building assertions on a provider's current test behavior without pinning the SDK version.

Used correctly, CVV test data is a small but useful part of a payment integration checklist: it lets you exercise validation, decline handling, and logging without ever putting a real cardholder at risk.