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.
A card number test generator produces fake card numbers that pass the Luhn checksum so developers can exercise payment forms in a sandbox. Those numbers are mathematically valid but tied to no real account, so they cannot move money. Payment processors publish fixed test sets, and most generators just recombine those values with a reserved test prefix.
A generator outputs a digit string with a correct check digit, plus placeholder expiry, CVC, and ZIP values. The output is designed for staging environments, not for live authorization. Nothing in the string identifies a real cardholder.
Luhn doubles every second digit from the right, subtracts 9 from any result above 9, sums the digits, and checks whether the total divides by 10. A generator picks the leading digits, computes the check digit, and appends it. A random 16-digit string passes Luhn about one time in ten, which is why a checksum pass says nothing about whether a card is real.
A real authorization needs an issuer record, a live BIN, and matching address verification data. A generated number can look well formed and still return "invalid card" or "do not honor" from the processor. Sandbox endpoints accept test numbers by design, and production endpoints reject them by design.
Stripe, PayPal, and Adyen each publish a fixed list, and the values repeat across providers.
Most sandboxes map specific card values or charge amounts to outcomes such as insufficient funds, expired card, or authentication required. Triggering those cases tells you whether your error handling and retry logic behave under failure. Test the happy path and at least one hard decline before you ship.
Generating numbers for your own sandbox testing is ordinary engineering practice. Pointing generated numbers at a live merchant, or buying real card data such as CVVs, is payment card fraud under 18 U.S.C. 1029 and breaks card network rules. Buying stolen card data is never a shortcut to a working integration.
Use the processor's official test card list, send requests to the sandbox base URL, and confirm that only tokens reach your servers. Real card numbers should never appear in a test environment, a log file, or a support ticket. If you need production-like data, let the processor tokenize it.