Choose from any of our gift cards to give to your loved ones
Expiry Date Test Numbers: Sandbox Card Guide
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.
Test card expiry is the future expiration date attached to a fake card number in a payment sandbox. It exists so a test transaction passes the same expiry check a live checkout runs. In most gateways any month and year ahead of today will authorize, and any date behind today returns an expired card decline.
Test card expiry has nothing to do with a real account. It is a validation field, not a credential.
A card expiry field is required on every checkout form, so a test card without one cannot exercise the full flow. Gateways therefore ship sample numbers paired with sample dates, such as 4242 4242 4242 4242 with any future expiry. The pairing keeps form validation, client-side formatting, and server-side checks in the same test path.
Developers who skip the expiry field end up testing a form that never reaches the authorization step. The result is a checkout that looks healthy in staging and fails on the first real transaction.
A sandbox transaction with a past date fails before authorization and returns an expiry-specific error. The exact code depends on the processor, but the common ones cluster around three values:
These codes are useful. Each one lets you assert a different branch of your error handling without touching a real account.
Most APIs accept a two-digit month and a four-digit year sent as separate fields, while the on-screen form usually shows MM/YY. The two-digit year on the form is the most common source of bugs, because the pivot point for turning 34 into 2034 is set by the client library, not the API.
Send the month zero-padded. A value of 3 instead of 03 gets rejected by strict validators even though the month is valid.
Test fixtures that hardcode a date eventually go stale, and that is the main maintenance task around test card expiry. A fixture written as 12/25 works until December 2025 and then starts returning expired card errors in CI.
The fix is to set the expiry relative to the current clock at test runtime, such as today plus three years. Teams that pin a literal date should expect a scheduled failure at some point.
No. Sandbox card numbers are not issued to anyone and have no account behind them. The date is a form input, so the number itself never lapses.
Use a date generator rather than a fixed string. Build cases for the current month, the last day of the current month, next month, and the month after the two-digit year rollover.
Watch the timezone. A card that expires this month is valid through the end of the month in the processor's timezone, which may already be the next day where your test runs. Pin the clock in CI to keep results repeatable.
You can enter it, and the gateway will decline the charge with an expired card code. That is the intended way to test your decline path.
It is safe only while 2034 is in the future and only if your fixtures resolve the two-digit year the same way the gateway does. A runtime-computed date avoids the question.
No. Expiry and CVV are validated independently, so a wrong CVV returns its own code even when the date is valid. Test them as separate cases.
Check the year format first, then the month padding, then the request timezone. A four-digit year sent into a two-digit field is the most common cause.
