How to store gift card codes safely: a voucher code is cash, treat it that way

Nobody would keep a stack of banknotes in a note-taking app. A gift-card code is the same thing in fewer bytes, and most voucher apps store it as if it were a shopping list.

Why is a gift card code like cash?

A voucher code has no owner. The till does not check who is presenting it; it checks that the code is valid and has balance. That is why gift cards are the payment method scammers ask for: the FTC's data spotlight on gift-card fraud found them the most reported payment method for scams for several years running, precisely because a code read over the phone is money gone. An app that holds your codes holds a stack of cash, and it should be designed by people who believe that.

The losses have not gone away. The FTC's Consumer Sentinel data book for 2024 records 41,120 fraud reports where a gift or reload card was the payment, with $212 million reported lost; 2023 was $217 million and 2022 $228 million. Those are only the people who reported. The scams themselves, and what to do in the first hour, are covered in the gift card scams guide.

Where do codes leak from?

Rarely from a broken cipher. They leak from a screenshot in a synced photo gallery, a note that backs up to three clouds, a debug log, a URL in a browser history, an API that returns every code in one response, and a shared link forwarded one step further than intended. Each is ordinary software behaviour. The rules below exist to close each one.

PeakVoucher does this from your own data. A wallet for the vouchers buried in your messages. Join the free beta →

Rule one: never list codes in bulk

The obvious design fetches the whole wallet, codes included, in one request, because it is simpler. It also means one intercepted response, one screenshot of a debug log, or one leaked cache is the whole wallet. The list should carry names, values and expiry dates. A code should be fetched only when you open that one voucher, and only that code.

The same rule applies to you. A photo of the back of every card in the gallery is a bulk list that syncs, backs up and is readable by any app with the photos permission. Keep the amount and the expiry in a list you can actually sort, and the code somewhere that fetches it on demand.

Rule two: keys in headers, never in the address

Anything in a URL's query string ends up in server logs, proxy logs, browser history and the Referer header of the next page you visit. An access key belongs in a request header. When a share link has to carry a key, it belongs in the fragment after the #, which RFC 3986 says browsers never transmit; the app reads it once and rewrites the address bar.

Rule three: roles decided on the server

Sharing a wallet with a partner is the whole point of a household wallet, and a viewer should be able to read codes and mark a voucher used without being able to add, delete or share on. Hiding the buttons in the app is not enforcement. The server has to know which key it was given and refuse the write, so that a modified client gets a 403 rather than a new voucher.

Rule four: fail closed

If the server is misconfigured, if the secret is missing, if a request arrives with no key, the answer is a refusal, not a best effort. An API that returns the wallet when it cannot tell who is asking has one failure mode, and it is the expensive one.

Failing closed also has to be visible. An app that quietly shows an empty wallet when the server refuses it teaches you that the wallet is empty; an app that shows the refusal tells you something is wrong before you re-enter forty vouchers by hand.

The same principle governs how an app reads your messages. An importer with the SMS permission can see everything, so it should read nothing until you open it, and send nothing off the phone until you pick a message; the SMS import guide lists the rules a careful importer follows.

Rule five: an assistant gets read-only tools

An assistant that can answer which of these can I use for lunch? is useful. To be safe it needs the wallet as context without the codes, a single tool that fetches a code only when a code is actually asked for, capped to a handful of vouchers per call, and no tools that write. Its transcript should live in memory and nowhere else.

This is the wallet-sized version of the argument that approval gates are the safety feature in any agent: the model proposes, a human with the authority acts. An assistant that could mark a card used, or delete one, on the strength of a message someone pasted in is an assistant that can be talked into it.

How PeakVoucher does it

Every rule above is a description of PeakVoucher's server. The list endpoint withholds codes, a code is fetched one voucher at a time, the key travels in a header, share links carry theirs in the fragment, owner and viewer are separate keys enforced before any read or write, a missing secret makes every route return 503, and the assistant has one read-only tool.

The barcode is drawn on the device from the code you just fetched, and on the watch the screen goes to full brightness while it is showing, then back.

Hen Eytan · Founder, UPeak

Builds the UPeak apps and writes up the research behind them.