Official site — always check you are on kripicard.comVerify
Free tool · Development & QA
Test Card Generator
Generate test payment card numbers for development and QA. Every number comes from a range the card networks and gateways reserve for testing — none of them is a real, usable card.
These are not real cards
Every number on this page sits in a range the card networks and payment gateways have reserved for testing and published openly. None maps to a bank account, an issued card, or a person, and all of them are rejected in live mode. They exist so you can exercise a checkout flow without touching real money.
A number that passes the Luhn check is only well-formed, not valid. Luhn is a typo-catching checksum, not proof an account exists — which is why this tool never lets you generate against a real issuer BIN, and why it cannot produce a usable card.
For development and QA in sandbox environments. Attempting to use generated numbers against live payment systems is fraud, and it will not work.
Generate test numbers
Luhn-valid numbers drawn only from ranges the gateways reserve for testing. Useful when you need many distinct cards — bulk imports, deduplication, form validation.
Published scenario cards
Generated numbers only ever succeed. When you need a specific outcome — a decline, a 3-D Secure challenge — you need the exact number the gateway documents, because the behaviour is tied to that number and not to the range.
Successful payment
| Number | Network | Result in test mode | |
|---|---|---|---|
4242 4242 4242 4242 | Visa | Payment succeeds | |
4000 0566 5566 5556 | Visa | Succeeds — Visa debit | |
5555 5555 5555 4444 | Mastercard | Payment succeeds | |
2223 0031 2200 3222 | Mastercard | Succeeds — 2-series range | |
5200 8282 8282 8210 | Mastercard | Succeeds — Mastercard debit | |
3782 822463 10005 | American Express | Payment succeeds | |
3714 496353 98431 | American Express | Payment succeeds | |
6011 1111 1111 1117 | Discover | Payment succeeds | |
3566 0020 2036 0505 | JCB | Payment succeeds | |
3056 9300 0902 0004 | Diners Club | Payment succeeds | |
6200 0000 0000 0005 | UnionPay | Payment succeeds |
Declines & errors
| Number | Network | Result in test mode | |
|---|---|---|---|
4000 0000 0000 0002 | Visa | Declined — generic | |
4000 0000 0000 9995 | Visa | Declined — insufficient funds | |
4000 0000 0000 9987 | Visa | Declined — lost card | |
4000 0000 0000 9979 | Visa | Declined — stolen card | |
4000 0000 0000 0069 | Visa | Declined — expired card | |
4000 0000 0000 0127 | Visa | Declined — incorrect CVC | |
4000 0000 0000 0119 | Visa | Declined — processing error | |
4100 0000 0000 0019 | Visa | Blocked — flagged as fraudulent |
3-D Secure authentication
| Number | Network | Result in test mode | |
|---|---|---|---|
4000 0025 0000 3155 | Visa | Requires 3-D Secure authentication | |
4000 0027 6000 3184 | Visa | 3-D Secure challenge on every payment | |
4000 0084 0000 1629 | Visa | 3-D Secure authentication fails |
Use any future expiry date and any CVC of the right length. Numbers above are reproduced from public gateway documentation; check your own provider's docs, since outcomes differ between sandboxes.
Frequently asked questions
Are these real card numbers?
No. Every number is drawn from a range the card networks and payment gateways have reserved for testing and published in their developer documentation. None corresponds to a bank account, an issued card, or a person, and all of them are declined in live mode.
What does it mean that a number is Luhn-valid?
Luhn is the checksum every card number satisfies, designed to catch typos and mis-keyed digits. Passing it means a number is well-formed, not that an account exists behind it. Payment forms use it for instant client-side validation before anything is sent to a gateway.
Why can't I enter my own BIN to generate from?
That is a deliberate limit. Running the Luhn algorithm against a real issuer prefix would produce plausible live card numbers, which is card generation for fraud whatever the page is called. Generation is restricted to reserved test ranges, so the tool cannot output a usable card.
Why do the generated numbers always succeed?
Generated numbers exercise the happy path. Specific outcomes — an insufficient-funds decline, a 3-D Secure challenge — are tied to exact numbers the gateway documents rather than to the range, so those are listed separately as scenario cards.
What expiry date and CVC should I use?
Any future expiry date and any CVC of the correct length: three digits for most networks, four for American Express. The generator fills in valid values already, so a test never fails for the wrong reason.
Will these work in a live payment system?
No. Reserved test ranges are rejected outside sandbox mode by design. Attempting to use them against live payment systems is fraud, and it will not succeed.