The short answer
A card number tester checks structure, not money. It runs the Luhn checksum, confirms the digit count falls inside the ISO/IEC 7812 range, and reads the leading six to eight digits to see which issuer range and brand the number belongs to. That is the whole job. It cannot confirm an account is open, funded, or able to authorize a charge. If your goal is to verify a checkout form or a payment integration, use the sandbox test numbers your processor publishes and point them at a test endpoint. If you want to know whether a real account will approve a charge, run an authorization through your own merchant account. Buying, selling, or testing card numbers you do not own is a federal crime in the United States, and no legitimate tool exists for that purpose.
What a legitimate tester does
- Luhn check: a mod-10 checksum over the digits that catches typos and transposed pairs.
- Length check: 12 to 19 digits, with 13, 15, 16, and 19 as the common formats in circulation.
- BIN or IIN lookup: maps the leading digits to an issuer range, country, and card type.
- Format check: groups digits the way your checkout field expects them.
What to look for before you pay for one
- Offline operation. A tester that runs in the browser or on your own server keeps the number out of someone else's logs.
- No retention. The tool should not write submitted numbers to a database, a message queue, or a third-party analytics service.
- Published test data. It should ship with the card numbers processors already publish for sandbox use.
- Readable logic. An open Luhn implementation you can inspect beats a closed black box.
- Clear scope. The vendor should state that the tool validates format only and does not authorize transactions.
Parameter bands to check
Digit length sits between 12 and 19, most often 16. The issuer identification number occupies the first six digits, and newer ranges extend to eight. The Luhn check digit is a single digit calculated mod 10 over the rest of the string. Security codes run three digits, or four for American Express. Under PCI DSS, sensitive authentication data must not be stored after authorization, so no compliant tool keeps CVV values at all. Any tool that asks for a CVV outside a live payment flow is a red flag.
Pitfalls
- Confusing a passing checksum with a valid account. Random digits satisfy Luhn roughly one time in ten.
- Typing real card numbers into a third-party site. That pulls you into PCI scope and exposes cardholders.
- Trusting balance or live check claims. Only the issuer or your own authorization request can answer that.
- Logging full account numbers in test environments. Test data should stay test data.
- Treating BIN data as exact. Issuer ranges shift and shared ranges exist.
FAQ
Is a card number tester legal?
Testing your own form with processor-published test numbers is routine engineering work. Validating numbers you do not own, or that you acquired from someone else, is not.
Can it tell me whether a card is active?
No. Only an authorization request to the issuer answers that, and you may only send one for a cardholder who has given you permission to charge.
Do I need real numbers to test my checkout?
No. Every major processor publishes test card numbers that trigger specific responses, such as approval, decline, or a required 3D Secure step.
What does a BIN database actually give me?
Issuer range, card brand, card type, and country. It helps you route and format input, and it says nothing about account status.