A stored gift card code is stored money: whoever can read it can spend it, and a leaked database of undelivered codes has no chargeback path and no recovery. The safest architecture is the one that holds codes for the shortest time, which puts pass-through delivery first, encryption at rest second, and plain storage nowhere on the list.
Codes deserve the handling banks give card numbers, with one difference that makes them worse: a card number can be blocked after a breach, a redeemed code cannot be un-redeemed.
Option 1: never store (pass-through)
Order the code from your distributor at the moment the customer pays, deliver it immediately, and persist only an order reference. The code exists in your system for seconds, in memory, and there is nothing to breach afterwards. This is the zero-inventory pattern described in zero-inventory digital commerce, and its security property is the strongest argument for it: an attacker who owns your database finds order metadata, not money.
The price is a hard dependency on delivery working first time. If the email bounces or the customer closes the tab, you need a re-delivery path that fetches the code again from the provider rather than from your own storage, which is where webhooks for code delivery earn their keep.
Option 2: encrypt at rest, decrypt at delivery
When you must hold codes (pre-purchased batches, promotions with guaranteed stock), encrypt them at rest and decrypt only at the moment of display or delivery. The details decide whether this is real protection or decoration:
- Keys live in a managed key service, not in the application config or the same database as the ciphertext.
- Decryption happens per code, on demand, and every decrypt is written to an audit log with the acting user or service.
- Bulk export of decrypted codes is not a feature anyone has.
Encryption protects against a stolen database copy. It does not protect against a compromised application with legitimate key access, which is why the audit trail matters as much as the cipher.
Option 3: tokenised references
Some providers hold the codes themselves and give you a reference token; the customer claims the code on the provider’s page, or your system fetches it once at claim time. Your database stores tokens with no monetary value, and custody stays with the party already built to guard it. The trade-off is coupling: the claim flow depends on the provider being up, and the customer experience is partly out of your hands.
The three architectures compared
| Architecture | Exposure window | Operational cost | Fits whom |
|---|---|---|---|
| Pass-through, never stored | Seconds, in memory | Low, but needs solid delivery and re-fetch flows | API storefronts with on-demand fulfilment |
| Encrypted at rest | Days to months, until purge | Key management, audit logging, access reviews | Sellers holding pre-purchased stock |
| Tokenised references | None on your side | Provider dependency, less delivery control | Teams without a security function |
Log hygiene: where codes leak in practice
Breaches of the code table are rare; codes wandering into side channels are common. Mask codes the way you mask card numbers, everywhere:
- Application logs and debug output.
- Error trackers, which happily capture the request body of a failed delivery.
- Analytics events and session-replay tools.
- Webhook payload logs, both yours and any third-party relay in the middle.
A useful test: grep every log store for a known test code after a full order cycle. Any hit is a leak path, and the fix belongs in serialisation (mask at the boundary), not in developer discipline.
Access and retention
Support staff need order status, delivery address and timestamps; they almost never need the code. Make code reveal a separate, logged, rate-limited permission, and the suspect list in an already-redeemed dispute shrinks from “everyone with admin” to a named few.
Delivered codes age into pure liability: the customer has the value, you hold the risk. Purge or archive them on a fixed schedule, keeping the code reference, delivery log and order metadata for disputes and reconciliation. Thirty to ninety days of retention covers most dispute windows; the broader integration context is in the gift card API integration guide.
Frequently asked questions
How should gift card codes be stored?
Ideally not at all: order on demand, deliver immediately and keep only an order reference. When codes must be held, encrypt them at rest with keys in a managed key service, decrypt per code at delivery only, and audit every decrypt. Plain-text storage, including in “internal” spreadsheets, treats money as if it were data.
Should I delete codes after delivery?
Yes, on a fixed schedule. A delivered code in your database is risk with no remaining benefit: the customer already has the value. Keep the code reference, delivery timestamp and order metadata for disputes and reconciliation, and purge the code itself once the dispute window has passed, typically after 30 to 90 days.
What happens if a code database leaks?
Undelivered codes get redeemed by whoever reads them first, and there is no chargeback or freeze to claw the value back; the loss is immediate and final. Beyond the direct hit, customers whose codes die at redemption flood support, and the incident usually surfaces publicly. This asymmetry is why exposure windows, not breach probability, should drive the architecture.
Should gift card codes be encrypted at rest or tokenised?
Tokenisation is the stronger option when your provider supports it, because the codes never enter your systems at all: you store a reference with no monetary value and the provider keeps custody. Encryption at rest is the fallback for stock you must hold yourself, and it only counts as protection when keys sit in a managed key service, decryption happens per code, and every decrypt is audited.
Is it safe to keep gift card codes in a spreadsheet?
No. A spreadsheet of live codes is plain-text storage with none of the controls that make holding codes tolerable: no per-code access, no decrypt audit trail, and easy duplication through email, shared drives and backups. Anyone who opens the file can spend the lot, and a redeemed code cannot be recovered. If codes must be held, encrypt them in a proper store and treat reveal as a logged, restricted action.