The check that decides whether a voucher order settles is a lookup in a merchant portal or a telephone call, made by a person, to the company that issued the voucher. It is the slowest part of the service and the part everything else rests on.
What the issuer actually holds
The plastic card or the printed slip in your hand is a receipt. The instrument is the code, and the code means something only because the issuer keeps a record for it. That record carries a small number of facts:
- whether the code exists at all
- its face value and currency
- its status: never used, partly spent, fully redeemed, or blocked
- the balance remaining on it
- whether anything is attached to it — an activation record, a freeze, a fraud report
Only the issuer's record can say whether a code is live. A receipt, a photograph of a receipt and a customer's word cannot, however honest all three are.
What happens before the issuer is contacted
Four things happen first, and none of them involves a human reading the code.
The code is encrypted the moment it arrives. It is held in its own table, separate from the order, encrypted with AES-256-GCM. Somebody with a view of the database sees ciphertext and the last four characters.
It is fingerprinted and checked against every code ever submitted. The fingerprint is a one-way function of the code combined with a secret value, and it carries a uniqueness constraint across the whole system. The same voucher presented twice — on one account, on two accounts, weeks apart — collides on that fingerprint and is refused. The comparison happens without decrypting anything, so duplicate detection costs nobody a look at their code.
The format is checked against the brand. Each brand has a characteristic length and structure. A code that cannot be that brand's code is almost always a transcription error, and catching it here saves a pointless call to the issuer and a day of the customer's time. The brands are listed on supported vouchers.
The order's gates are evaluated. Identity established at the tier the running total requires and, where a document was needed, unexpired; screening current, country served, limits not exceeded, no compliance case open. An order that could not settle even with a perfect voucher does not consume an issuer check.
The check itself
An operator opens the order and decrypts the code. That decryption is recorded — who did it, when, and how many times the code has been viewed in total — so no reading of a customer's voucher is anonymous.
They then use whatever channel the issuer provides for that brand. Some issuers run a merchant balance-check page. Some run a merchant support line where a person reads the code out and waits. Some answer definitively only by telephone, in their own business hours, in their own time zone. The questions are the same in every case: does this code exist, is it live, what is left on it, and is anything attached to it.
What comes back is recorded against the order — the outcome, the channel, the time, any reference the issuer gives, and the name of the operator who made the check. The code itself is not copied into that record.
Why a person does this instead of software
There is no common interface. Six brands mean several issuers, several channels, several sets of merchant terms and no shared API to write against. A single automated checker covering all of them does not exist, because the thing it would call does not exist.
Issuers restrict checking to merchants, and often to humans, deliberately. An automated process submitting codes at speed is indistinguishable from a card-testing attack — the technique of running stolen or guessed codes in bulk to find the live ones. Issuers watch for that pattern and cut off the source. A business that automated the check aggressively would lose the ability to check at all.
A person also notices what a status field does not carry: a note on the account the portal does not display, an inconsistency between a till receipt and a code, a support agent who hesitates before answering. None of that arrives as data.
And the check is the product. The 5% commission set out on rates and limits pays for a person spending real time establishing that one code is what it claims to be, so the payment afterwards can be final.
What the answer can be
There are four, and they are not variations on a theme.
- Live, full balance, nothing attached. The order proceeds. An operator releases the settlement and records the transaction reference against the order, where the customer can see it.
- Live, but the balance is lower than declared. The voucher has been partly spent. It cannot settle at the declared face value, so it is re-priced to the balance the issuer confirms or rejected, and the customer decides which.
- Already redeemed, or no such code. The order is rejected with the reason stated.
- Blocked, frozen, or carrying a fraud report. The order is not rejected and closed; it is frozen, and a compliance case is opened. What happens when a voucher fails verification sets out all four in full, including this one.
How long it takes
Hours rather than seconds, and sometimes longer. It depends on which issuer, what time it is where that issuer answers the telephone, and whether the first answer was definitive. A voucher submitted on a Friday evening may be waiting for the issuer's Monday.
This is not a step that can be made fast without being made worthless. Every fast alternative — trusting the receipt, trusting the customer, settling first and checking later — moves the risk onto whoever is paid next.
What happens to the code afterwards
The encrypted code is purged once the order settles, and also when it is rejected. The row survives, carrying the last four characters, the fingerprint and the access history, because that is what a record has to keep. The code is not part of it.
One practical consequence: your code cannot be read back to you later. Photograph the receipt before you submit it, and keep the photograph somewhere you will find it again.
What makes a check go cleanly
- Do not spend any part of the voucher after submitting it. A balance that drops mid-check reads as a partial redemption.
- Do not give the code to anyone else while the order is open, including anyone who telephones claiming to be from the exchange. No operator here will ever ring and ask you to read out a code you have already submitted.
- Enter the code exactly as printed. Confusions between the digit 0 and the letter O, or 1 and I, are the usual cause of a format failure.
- Keep the till receipt. It shows where and when the voucher was bought, and it is the only useful evidence if the code turns out never to have been activated at the till.
- Declare the face value that is actually on the voucher, not the price you paid for it.
Where this currently stands
Voucher intake is not open. The licence application is in progress, and each brand's product stays disabled until the position on redeeming that issuer's codes as a third party is settled in writing — issuers' terms commonly restrict transferring a code, and that is a question to answer before trading rather than after.
The sequence a live order follows is set out in how it works, and the approach to identity is explained in why no KYC is required here.