An “already redeemed” error means the value on the code was claimed before your customer tried to use it. For a seller, the whole dispute reduces to one question: was the code redeemed before you delivered it, or after? Before points at your supplier; after points at your customer, and the evidence you need for either answer is a delivery log you should already be keeping.
Nearly everything written about this error is consumer support advice: contact the retailer, keep the receipt. The seller’s side of the desk is a different job. (Orders that fail before a code is even issued are a separate class, covered in gift card API order failures.)
The causes, ranked honestly
The customer redeemed it and claims otherwise. The uncomfortable one first: in most sellers’ case files this is the largest bucket. Sometimes it is deliberate first-party fraud, sometimes a household member used the code, sometimes the customer redeemed it weeks ago and forgot. Assume nothing, but build your process knowing the base rates.
A leak between delivery and redemption. The code was intercepted after you sent it: a compromised email account, a code shown during a screen share, a screenshot forwarded to the wrong chat. The longer a code sits undelivered or unredeemed in an inbox, the wider this window gets.
An upstream double-sale or recycled stock. The supplier problem. The same code sold to two buyers, or stock pulled from cancelled orders and grey channels. One case proves little; a cluster in the same batch or SKU is a pattern, and the mechanics behind revoked and resold stock are the same ones described in why game keys get revoked.
Triangulation fraud. A buyer purchases from you, resells the code on a marketplace, the second buyer redeems it, and the original buyer then disputes the purchase as “never worked”. The delivery log usually shows a redemption suspiciously soon after delivery, from a party who was never your customer.
The investigation: build a timeline
- Pull the delivery record. Timestamp, channel (email, API, on-screen reveal) and recipient for the exact code reference. This record either exists before the dispute or it never will.
- Check every display event. When did your system first show or send the code, and to whom? Include support-panel views: if three staff members can open raw codes, your timeline has three extra suspects.
- Ask the platform for the redemption date. Some issuers’ support will confirm when and sometimes where a code was redeemed, at least to the account holder. Even a date with no detail settles most disputes.
- Compare the two timestamps. Redemption before your delivery time is supplier-side by definition. Redemption after delivery moves the conversation to the customer.
The decision tree
Redeemed before delivery: claim upstream. Invoke the written replacement policy you agreed before funding the supplier, with the delivery log and the redemption evidence attached. If no such policy exists, this dispute is the reason supplier vetting insists on getting one in writing before money moves.
Redeemed after delivery: talk to the customer with evidence. Show the delivery timestamp and channel, state the redemption date if you have it, and ask for their account of the gap. Honest customers often solve it themselves (“my brother used it”); dishonest ones go quiet. Refund decisions here are commercial judgement, not obligation.
Redemption time unknown: weigh what you have. Customer history, the age of the code, whether the batch has other complaints, the supplier’s track record. A first dispute from a two-year customer reads differently from a fresh account’s third claim this month.
Publish the rules before the first dispute
A dispute policy written during a dispute convinces nobody. Publish, in your terms: the reporting window (seven to fourteen days from delivery is common), the evidence you require (order number and the exact error message), and the remedies you offer. Internally, log code references rather than raw codes, so an investigation never requires opening the vault; how to structure that is covered in storing gift card codes securely.
Prevention is mostly storage discipline. Codes that are never persisted cannot leak from your side, masked logs keep them out of error trackers, and tight support access shrinks the suspect list to the customer and the supplier, which is exactly where a clean dispute should sit.
Frequently asked questions
What does code already redeemed mean?
It means the value on the code was claimed before this redemption attempt. The code itself was valid; someone got there first. The open question is who and when: the customer earlier, a third party who obtained the code after delivery, or a previous buyer if the supplier sold the same code twice.
Who is responsible when a gift card code is already used?
Whoever controlled the code at the time it was redeemed. If the redemption predates the seller’s delivery timestamp, the supplier shipped a dead code and owes a replacement under the agreed policy. If redemption came after delivery, responsibility sits with the customer or with whoever obtained the code from them, and the seller decides on goodwill, not liability.
How do sellers investigate a redeemed-code claim?
They build a timeline: the delivery log (timestamp, channel, recipient), every event where the code was displayed or sent, and the redemption date from the platform’s support where available. Comparing redemption time against delivery time decides the direction of the claim. Sellers who keep no delivery log have no investigation, only an argument.
How can sellers prevent already-redeemed code disputes?
Mostly through storage discipline. Codes that are never persisted cannot leak from your side, masked logs keep them out of error trackers, and tight support access shrinks the suspect list to the customer and the supplier, where a clean dispute belongs. Publish the rules before the first case: a reporting window, the evidence you require, and the remedies on offer. A policy written during a dispute convinces nobody.
Will a supplier replace an already redeemed gift card code?
Under a written replacement policy, yes, when the evidence shows redemption before your delivery timestamp. That is supplier-side by definition: they shipped a dead code. Bring the delivery log and the redemption date, and expect a cluster of cases in one batch to carry more weight than a single claim. If no replacement policy exists in writing, agree one before funding a balance, not during your first dispute.