Answer first

CVV test tokenization v4 is a test run of card tokenization against a version 4 API. The run sends a test card number with a CVC value and checks the response. No live card data is involved. The CVC is validated, then discarded. It is not stored and it is not placed inside the token.

cvv test tokenization v7

The version number belongs to the provider, not to a standard body. Version 4 at one processor is not version 4 at another. Confirm field names, required parameters, and error codes in the provider changelog before the run.

cvv test tokenization v10

What tokenization does with the CVV

A network token replaces the card number (PAN). The token is bound to a device or a merchant and carries a cryptogram per transaction. The original CVV does not transfer to the token. A token request that returns a stored CVV is a defect, not a feature.

CVV Test Tokenization V7: The Ultimate Guide

  • PCI DSS Requirement 3.2 forbids storage of sensitive authentication data after authorization. That data includes the CVC, the full track, and the PIN block.
  • Requirement 3.2 applies even when the value is encrypted.
  • Merchants keep the token, the last four digits, and the expiry. They do not keep the CVC.

What changes in a v4 API

Version changes in payment APIs tend to move the same items: idempotency keys, token request objects, cryptogram fields, and decline code lists. Read the migration note and list every field the token call sends. Rename or drop the fields the note marks as removed.

cvv test tokenization v10

Sandbox values

Test PANs are published by each provider. Common patterns in US sandboxes:

  1. 4242 4242 4242 4242 with a future expiry and any three digit CVC returns an approval.
  2. 4000 0000 0000 0002 returns a decline.
  3. A dedicated CVC mismatch PAN returns a CVC failure code.

Test PANs work in sandbox only. A live PAN in a sandbox is a PCI incident and needs a report.

Test run checklist

  1. Set the API key to the sandbox key.
  2. Send the token request with the test PAN and CVC.
  3. Confirm the response returns a token and no CVC field.
  4. Confirm the stored record holds the token, last four, and expiry only.
  5. Log the decline cases and the CVC failure case.
  6. Run the same cases against the prior API version and compare.

Limits

A test suite does not prove production behavior. Issuer responses differ by bank and country. A plain tokenization test does not cover 3D Secure step-up, partial approvals, or network token provisioning to a wallet. Those need separate cases.