Payment Card Check: What Merchants Can and Cannot Verify

The strongest payment card check most merchants can run is a layered sequence rather than a single lookup: a format test covering length and the Luhn check digit, a BIN lookup to identify the issuing bank and network, an address verification (AVS) response, a card security code check performed by your processor, and issuer authentication through 3-D Secure on higher-risk orders. The criteria that matter when you choose among them are what each layer actually proves, where the data is permitted to live, and how much friction it adds at checkout. This guide is written for merchants, developers, and fraud teams verifying cards they are authorized to charge. It does not cover validating card numbers you do not own or have permission to bill.

payment card verification

Format checks: length and the Luhn algorithm

A format check is the cheapest gate you can put in front of a payment form. It confirms the entered digits match the expected length for the brand and that the final digit satisfies the Luhn mod-10 checksum, which catches most single-digit typos and transposed pairs. It runs in the browser or on your server in microseconds and never touches a payment network.

payment card verification

• Pros: instant, free, no network call, no sensitive data leaves your infrastructure, cuts failed authorization attempts caused by mistyped numbers.
• Cons: proves formatting only. A number that passes Luhn can still be closed, stolen, or never issued. A number that fails Luhn is almost always wrong, but passing tells you nothing about the account behind it.

Use it for: pre-submit form validation on every checkout, so obviously malformed entries never reach your processor and inflate your decline rate.

payment card check

BIN and IIN lookup

The first six to eight digits of a card form the issuer identification number. A BIN lookup returns the card brand, card type (credit, debit, prepaid, commercial), and the issuing country or bank, depending on the data provider. Merchants use it to route transactions, apply brand-specific rules, and score risk before authorization.

Payment Card Check Tool

• Pros: fast, inexpensive, useful for routing and for flagging mismatches such as a billing address in one country with an issuer in another.
• Cons: BIN ranges are reassigned and repurposed, so stale tables produce wrong answers. Country of issue is not country of the cardholder, and prepaid BINs appear in both legitimate and abusive traffic.

Use it for: routing and soft risk signals, never as a standalone approve or decline decision.

Card security code verification

The three-digit code on the back of most cards, or four digits on the front of American Express cards, is verified by the issuer through your processor during authorization. You send it, you get a match, no-match, or not-supported response, and then it must be gone.

• Pros: strong evidence the person submitting the order physically holds the card, and one of the better predictors of fraud in card-not-present traffic.
• Cons: not available on every card or region, cannot be retried in the same form after a failed attempt, and PCI DSS prohibits storing it after authorization under any circumstances.

Use it for: every card-not-present transaction you can, with a rule that a no-match on a high-value order triggers manual review rather than an automatic retry.

Address Verification Service

AVS compares the street address and postal code you collect against what the issuer has on file, returning codes such as full match, postal-only match, or no match. It is a US-centric tool, and international issuers frequently return unsupported responses.

• Pros: cheap, included in most authorization responses, effective at catching bulk card testing where addresses are invented.
• Cons: high false-positive rate on legitimate customers who moved recently, use a business address, or bank abroad. Strict AVS rules reject good revenue.

Use it for: risk scoring with weights, not binary rejection. Treat a partial match as a signal to add authentication, not to void the sale.

3-D Secure and issuer authentication

3-D Secure shifts liability for fraud chargebacks to the issuing bank when the authentication completes successfully. The cardholder is challenged, or passes silently through a risk-based decision by the issuer.

• Pros: meaningful liability shift, strong defense against stolen-card use, increasingly expected in cross-border commerce.
• Cons: adds checkout friction, can reduce conversion, requires integration work, and liability shift does not cover every dispute reason code.

Use it for: high-value orders, new customers, cross-border traffic, and any category with elevated chargeback exposure.

What a card check cannot prove

No combination of these checks proves the person at the keyboard is authorized to use the card. A checksum-valid number with a matching code and address can still belong to someone whose details were compromised, and a mismatched response can come from an honest customer. Card checks reduce risk; they do not transfer it. That distinction matters legally as well as commercially: buying, selling, or using card data you are not authorized to charge is fraud in the United States and most other jurisdictions, regardless of whether the number passes a format test.

Choosing a stack by use case

1. Low-ticket digital goods, low chargeback history: Luhn check, BIN lookup, security code verification. Skip AVS hard rules.
2. Physical goods with shipping: add AVS and require a full or postal match before fulfillment.
3. High-ticket or cross-border: layer all five, force 3-D Secure, and route anything short of a full match to manual review.
4. Subscriptions and card-on-file: tokenize at first authorization, run account updater services, and re-verify on any card change.

Whatever stack you pick, keep raw card data out of your own systems wherever a processor or vault can hold it instead. The checks above are only worth running if the data feeding them is handled in a way that survives an audit.