Card Test Refund Transaction Guide
Learn how to perform a card test refund transaction with our comprehensive 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.
A test card refund is a refund you run in a payment gateway sandbox or test mode. No real money moves. The gateway still walks the full refund lifecycle: it creates a refund object, moves it from pending to succeeded, updates the original charge or payment intent, and fires webhooks. That makes it the cheapest way to check your own code before live keys ever touch it.
When you refund a charge made with a test card, the processor simulates the request. You get back a refund ID, an amount, a currency, and a status. Most gateways settle test refunds in seconds instead of the three to ten business days a real card refund takes, though some hold them in pending for a moment so you can test that state. The card sees nothing. There is no issuer, no statement descriptor, and no bank posting.
This is the mistake I see most. A charge created with a live secret key cannot be refunded with a test key, and the reverse fails too. The API returns something like "no such charge" because each environment keeps its own database of objects. If a refund call comes back not found, check which key your client initialized with before you debug anything else.
Test refunds raise real errors for bad input: refunding more than the original amount, refunding the same charge twice, a bad idempotency key, or a currency mismatch. Those paths are worth testing because the validation logic is the same code you run in production.
Issuer-driven failures, such as a closed account or a returned refund, are harder to reproduce. There is no issuer to say no, so build that branch with a mock or use a forced-error flag if your gateway offers one.
Webhooks fire in test mode the way they do live. Point your endpoint at staging, send a refund, and confirm you handle duplicate events, out-of-order events, and retries without double-counting.
One last point: never put a real card number into a test environment. Test PANs are not live account numbers, and using real card data where it does not belong creates a compliance problem that is painful to unwind. Separate credentials, separate data, and a separate database will save you a long cleanup.