Ultimate Guide to Credit Card Test Numbers
Discover how to use credit card test numbers safely and effectively.
Our Cards
Choose from any of our gift cards to give to your loved ones
Choose from any of our gift cards to give to your loved ones
Redeem your gift cards at any of our Merchants
Onyx Gift Cards is a Grenadian company designed to introduce, market and manage gift cards systems in Grenada for retailers and corporations. We are enthusiastic about the effect and influence we will have on the local market. We intend to expand our systems regionally with a range of product offerings and services.
Gift cards are the preferred way of giving and receiving gifts. They carry a monetary value that can be redeemed for gifts at your favorite store.
Onyx GiftCards are “Open Gift Cards” which means that they can be redeemed at multiple merchant locations. They are standard credit card size, can fit into the average wallet and made of PVC plastic. Onyx GiftCards are Barcoded for security and safety for the consumer and bear a disclaimer at the back.
Onyx Giftcards can be bought with a branded Card backer which is black in colour and is designed to fit the card. There is an area to write a brief message to the recipient as well.
Card test data is a published set of card numbers, expiry dates, CVVs, and expected responses that a payment processor gives developers. Each number passes a Luhn check and routes to a sandbox endpoint, so you can run an approval, a decline, a 3DS challenge, or a refund without touching a real account. Stripe, Adyen, Braintree, and most gateways ship a table of these numbers and map every entry to a specific result.
The key point: test data is not random digits. It is a contract. The processor promises that a given PAN will produce a given outcome, and your job is to prove your code handles that outcome.
A random 16-digit string usually dies at validation before it reaches the logic you wanted to test. You end up testing your own regex, not your decline handling. Published test PANs are built to trigger specific branches in the issuer simulation: one number returns a generic decline, another forces a 3DS2 challenge, another passes the challenge and settles. That control is the whole value.
I look for a sandbox that documents each number next to its response code. If the table only says "test card" with no outcome, the sandbox is thin and you will spend a day guessing.
Cover the boring cases first. Most production incidents I have seen came from a partial refund or an expired-card path, not from the happy path everyone demos.
Numbers alone do not simulate settlement, chargebacks, or payout timing. For those you need the processor's test merchant account and its clock controls. Some sandboxes let you fast-forward a capture or force a dispute. Use those when you are validating reconciliation and reporting, because that is where test data and real money start to look different.
PCI DSS treats card data as out of scope only when it cannot be mistaken for a real PAN and never appears in a live environment. I keep sandbox credentials in a separate vault, label every fixture as test, and add a lint rule that blocks known test BINs from production config. Logs are the usual leak. A stack trace that prints the request body puts card-shaped strings into a log aggregator, and now you have a compliance question on your hands.
Never test with a real card number, even your own. Running live PANs through a staging system expands your PCI scope and is usually a policy violation at the processor.
Do this once and the checkout code stops surprising you.