What is a CVV dump format in track data?
A CVV dump format is the layout of payment data copied from a card's magnetic stripe, and track data means the character strings on Track 1 and Track 2 that hold the primary account number (PAN), expiration date, service code, cardholder name, and a card verification value. The layout comes from the ISO/IEC 7813 standard, which is why the strings look alike across banks and countries. Online merchants never need this data to accept a payment, and PCI DSS forbids storing it once a transaction is authorized.
What Is a CVV Dump? Card Security Code Risks Explained
What does magnetic stripe track data contain?
A stripe can hold three tracks, and two of them carry payment data. Track 3 exists in the standard, but almost no payment network writes it.
Track 1
- Format code (usually B) and a start sentinel
- Primary account number, up to 19 digits
- Cardholder name
- Expiration date in YYMM form
- Service code, three digits that state what the card can do
- Discretionary data, often holding the CVV1 value
- End sentinel and a check character
Track 2
Track 2 drops the name and packs the same core fields into fewer characters. It carries the PAN, expiration date, service code, discretionary data, and a check character. POS terminals read Track 2 because it is short and fast.
Where does the CVV sit in these formats?
Card verification values come in two forms. CVV1 (also written CVC1) lives in the discretionary field of the stripe tracks and is checked when a card is swiped or dipped at a terminal. CVV2 (CVC2, CID) is the three- or four-digit code printed on the card, and that is what an online checkout asks for.
CVV1 is never printed on the card. That one fact explains why online payments rely on CVV2 and why a file described as dumps with CVV1 can only come from a physical card, a skimmed stripe, or a breached terminal.
Why track data format matters for online stores
An online store runs card-not-present transactions, so it sees a PAN, an expiry date, and a CVV2 at most. Track data has no role in that flow. Trouble starts when a payment page collects more than the checkout needs, or when injected JavaScript copies what a shopper types.
Magecart-style attacks scrape payment forms and ship the data to an attacker-controlled host. If your site passes raw card fields into your own servers, one breach hands over a clean set of PANs and CVVs. Hosted fields, iframes, and tokenization keep that data inside the processor's environment instead.
Card testing is the usual follow-up. Fraud rings run thousands of small charges against a stolen list to learn which numbers still work, and the merchant pays the chargeback fees for every hit.
What PCI DSS says you can and cannot store
Sensitive authentication data, which includes full track data, CVV2, and PIN blocks, may not be stored after authorization, even in encrypted form. The rule applies to every merchant level, from a single Shopify store to a national chain.
- Allowed to store: PAN, cardholder name, expiration date, and service code, kept in a protected form.
- Never allowed after authorization: full magnetic stripe data, CVV2 or CVC2, PINs and PIN blocks.
- PAN display must be masked, showing at most the first six and last four digits.
Keeping sensitive authentication data on file is a finding by itself, so an assessor does not need a breach to fail you.
How to keep track data out of your checkout
- Use hosted payment fields or a redirect so card numbers never touch your servers.
- Tokenize stored cards and keep the token, not the PAN.
- Configure logs to drop any field that matches a PAN pattern.
- Monitor checkout scripts to catch injected skimmers.
- Train support staff to refuse card details sent by email or chat.
- Review your payment page each quarter against a current PCI DSS Self-Assessment Questionnaire.
What shoppers can do
- Use a virtual card number or a mobile wallet for online purchases.
- Read statements for small test charges, often one or two dollars.
- Report a lost or skimmed card so the bank can block CVV1 use in stores.
FAQ: CVV dumps and track data
Is a CVV dump the same as a card number?
No. A card number is a single field. A dump is a set of records taken from stripe tracks and can include the PAN, expiry date, and a verification value. Buying, selling, or using that data is card fraud under federal law and in every US state.
Do online checkouts ever ask for track data?
No. A card-not-present checkout asks for the PAN, expiration date, and the printed CVV2 or CVC2 code. A web form that asks for stripe data is a red flag, not a payment page.
Does tokenization remove the risk?
It removes your storage risk. The processor still holds the account data, so you inherit their security controls and their audit scope instead of your own. Tokenization also shrinks the range of systems covered by a PCI assessment.
Why do attackers want track data if online stores do not use it?
Track data supports cloning a physical card for in-store use, which is a different fraud path from online checkout fraud. That gap is one reason skimming at fuel pumps and ATMs persists.
Can a card verification value be reissued?
Yes. A bank can issue a new card number and a new CVV2 after fraud or a lost card. Blocking the old number stops stripe-based use as well, which is why reporting a compromised card fast limits the damage.