Card Test Generator: Safe Sandbox Testing Guide
Use a card test generator only for sandbox payment testing. Learn safe steps, processor test cards, validation, and compliance limits.
Redeem your gift cards at any of our Merchants
You can purchase a gift card from any of these locations
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.
You don't generate test card numbers. Your payment processor already did, and the ones they publish are the only ones that behave the way you need. Stripe, Adyen, and Braintree each ship a fixed list of sandbox numbers where a specific digit pattern triggers a specific response: approval, decline, insufficient funds, expired card, CVC mismatch, processing error. A number you invent will pass the Luhn check and then do nothing useful, because the gateway has no rule attached to it.
If your goal is a working checkout test, pull the published numbers for your processor and move on. If you're after something else, keep reading, because the answer changes.
Gateways in test mode don't check whether a card exists. They pattern match. Stripe sees 4000000000009995 and returns insufficient_funds. It sees a random Luhn-valid 16 digit string and returns a generic result, which tells you nothing about whether your error handling actually works.
That's the whole point. Test numbers are a control panel, not a randomizer. When I'm building an error state, I want to know exactly which input produces it, every single run.
The only genuine generation step is the Luhn algorithm, also called the mod 10 check. Take the digits, double every second one from the right, subtract 9 from anything above 9, sum it all, and the total has to end in zero. That checksum is baked into every card number ever issued. It catches typos. That's it.
A number that passes Luhn is not a valid card. It's a number that is formatted correctly. That gap matters, and it's where people wander into trouble. Using a self-generated number against a live gateway is card testing, it's fraud, and processors spot it within a handful of attempts. None of what follows works for that, and none of it is meant to.
These are Stripe's, and most other processors publish a near-identical set:
Any future expiry date works. Any three digit CVC works, or four digits for Amex. The 0127 card is the exception: it only fails when you feed it the wrong CVC, so it doubles as a positive test too.
The practical move is to hardcode these into a constants file in your repo, keyed by scenario name. I want to read DECLINE_INSUFFICIENT_FUNDS in a test, not a magic number, and I want one place to update when a processor retires a card. Named fixtures also survive a code review, which a helper function that spits out random digits will not.
If you need volume, for load testing or seeding a local database, write a small utility that produces Luhn-valid strings. Keep it sandbox only. A generated number that reaches a live endpoint is either a failed charge or a fraud flag on your merchant account, and I've watched the second one take a week to unwind.