What a card verification pattern is
A card verification pattern is the fixed sequence of checks a payment system runs on card data before it approves or declines a transaction. The pattern starts with format validation (Luhn checksum, length, BIN range), moves to data matching (expiry, CVV/CVC, cardholder name, billing address), and ends with risk scoring (velocity, geo mismatch, device reuse). Issuers run a version of this order. No step is skipped, and a failure at any step stops the chain.
Prerequisites
- A PCI DSS compliant environment, or a tokenized vault so raw card data never touches your servers.
- Access to a BIN database for issuer, country, and funding type lookups.
- A merchant account with AVS and CVV checking enabled.
- A log pipeline that records each check result as a separate field.
How to run a card verification pattern
- Strip spaces and dashes from the number, then confirm the length matches the detected brand: 15 for American Express, 16 for Visa and Mastercard, up to 19 for some co-branded ranges.
- Run the Luhn checksum. Double every second digit from the right, subtract 9 from any result above 9, and require a total divisible by 10.
- Read the first six to eight digits as the BIN. Match the BIN to an issuer, country, and card type. Reject any card whose brand, length, and BIN disagree.
- Check the expiry month is 01 through 12 and the date is not past. Treat an expired card as a hard decline, not a retry candidate.
- Verify the CVV/CVC. Visa, Mastercard, and Discover use three digits from the back; American Express uses four from the front. Send it once, never store it, and read the issuer response code.
- Submit the billing address for AVS. Record the street and ZIP results as separate flags instead of a single pass or fail.
- Apply 3-D Secure when the issuer requests a challenge. Authentication shifts liability, so log the result before capture.
- Score velocity and reuse: count attempts per card, per IP, and per device in a rolling window. Block patterns that repeat across unrelated accounts.
- Map every decline to the exact failed step. A CVV mismatch, an AVS mismatch, and a do-not-honor code carry different meanings and require different follow-up.
CVV and CVC format rules
The verification value is a 3-digit code (4 for American Express) that the issuer prints but does not encode on the magnetic stripe or chip. It proves the person holding the card saw the physical plastic. PCI DSS forbids storing it after authorization in any form, so a verification pattern that logs the CVV has already broken compliance. The correct behavior is to pass the value to the processor inside the authorization request and discard it.
Why the order matters
Running checks out of order wastes authorization attempts and inflates decline rates. A Luhn failure means the number is malformed and no issuer call is needed. A CVV mismatch on a valid number means the data was likely copied, which is a different risk signal than an AVS mismatch on a cardholder who moved recently. Keeping each result separate lets you tune rules without disabling verification wholesale.
Common verification failures
- Length and BIN conflict: a 16-digit number starting with a 15-digit brand prefix.
- Luhn failure: a single transposed digit, which is the most frequent data entry error.
- CVV not present: the issuer did not participate or the merchant account lacks the check.
- AVS unavailable: international issuers that do not support address matching.
- Velocity block: a legitimate customer retrying after a soft decline.