Quick answer

A fake CVV for testing is any 3 digit value (4 digits for American Express) entered alongside a payment processor's published sandbox test card number. In test mode the CVV field is not checked against an issuer, so the digits you type do not need to match anything. Processors accept arbitrary values for approved test cards and reserve specific documented values for forcing a CVV mismatch decline. The card number, not the CVV, decides whether a test authorization succeeds.

What a fake CVV is and is not

The CVV is a 3 or 4 digit code printed on a physical card and never stored on the magnetic stripe. It is not produced by the Luhn algorithm. Luhn applies to the primary account number only, which is why a random 16 digit number can pass a format check while still failing at the gateway. Structurally, any 3 or 4 digits are a valid CVV. What makes those digits meaningful is the account behind the card number. A test card number belongs to a sandbox account with no real funds and no real cardholder.

Using test values against a live gateway to push a real authorization is card fraud, not testing. Sandbox accounts exist so you never need to touch live credentials.

Where legitimate test values come from

Payment processors publish their own test card tables: Stripe, PayPal, Cybersource, Adyen, and Authorize.Net all maintain them in developer documentation. Each table lists card numbers tied to specific outcomes such as approval, insufficient funds, expired card, or CVV failure. Use the table from the processor you integrate with, because decline values differ between providers.

Steps to run a CVV test in a sandbox

  1. Create a sandbox or test mode account with your payment processor.
  2. Open the processor's test card documentation page and copy one approval card number.
  3. Copy a second card number flagged for a CVV mismatch decline.
  4. Set the expiry field to any future date listed in the same table.
  5. Enter any 3 digit CVV for the approval card, or 4 digits if the test card is American Express.
  6. Submit the form and record the response code your application receives.
  7. Repeat with the mismatch card and confirm your checkout shows the correct error message.
  8. Confirm your server and logs never persist the CVV value after the request completes.

Common CVV test scenarios to cover

  • Approved authorization with a matching format CVV.
  • CVV mismatch decline and the message shown to the shopper.
  • Missing CVV field on a card type that requires one.
  • CVV supplied for a card type that does not use a CVV, such as some corporate cards.
  • Retry behavior after a decline, including whether your form clears the card fields.

Compliance boundary

PCI DSS Requirement 3.2 prohibits storing sensitive authentication data, including the CVV, after authorization, even in an encrypted form. That rule applies to sandbox systems as much as production ones. Never write CVV values to a database, a log file, an analytics event, or a support ticket. Capture the value in memory, pass it to the processor, and drop it.