A test BIN number is the first six to eight digits of a card number used in a sandbox. Payment processors publish these digits next to test card numbers. The numbers work against test endpoints for that processor and nowhere else.
What a BIN carries
The BIN is the leading segment of the primary account number. Under ISO/IEC 7812 the issuer identification number runs eight digits. Most systems read six. The digits identify the issuing bank, the card network, the card type and the country of issue. A BIN holds no cardholder name, no expiry date and no CVV.
Where test BINs come from
Processors and gateways publish test card numbers in developer docs. Stripe lists numbers for Visa, Mastercard and American Express with fixed BINs such as 4242. Adyen, PayPal and Authorize.net do the same. Each number triggers a set response: approve, decline or a specific error code. Test BINs are documented data, not secrets.
How sandbox testing works
- Send the test card number to the sandbox API endpoint.
- Use any future expiry date and any three digit CVV.
- Read the response code and confirm the integration handles it.
Test BINs fail against live endpoints. A live authorization checks the full account number, the expiry date and the CVV against the issuer. A test BIN alone passes no check.
Why live BIN data differs
Live BIN tables from Visa and Mastercard are licensed data. Access requires a contract with the network or a provider. Public BIN lookup sites show partial ranges, and those ranges go stale as issuers reissue portfolios.
Legal boundary
Guessing live card numbers from a BIN is card fraud in the US under 18 U.S.C. 1029 and carries prison terms. PCI DSS sets rules for storage of account data for merchants that handle live cards. Sandbox test data sits outside that scope because it maps to no real account.