1. What we hold, and for how long
Four kinds of sensitive material pass through this service: voucher codes, identity documents and the details read from them, the order record, and the audit log that records who touched what. The order record holds the voucher brand, the face value, the payout destination you gave us, the outcome of verification, and the timestamps around it.
Each has a different life. A voucher code lives the shortest life of the four. It exists from the moment you submit it until the order settles, and then it is destroyed. Everything else is a record, and records are retained for five years, because an operator in this business must be able to reconstruct what it did and why.
We do not hold anything that would let money leave your accounts. A payout destination is an address, not a credential: a wallet address, an IBAN, a PayPal address. We do not ask for a card number, an online-banking password, a PIN, or a one-time code sent to you by your bank. Anyone who asks you for one of those in our name is not us.
2. A voucher code, from submission to destruction
A code follows one path, and it is short.
- You submit it. The code travels from your browser to our servers over an encrypted connection. It is typed into the order form on this site and nowhere else.
- It is encrypted on arrival. Before the code is written to storage it is encrypted. It is not written to an application log, an error report, a backup of a log, or an email.
- One operator takes the order. The code is readable by the operator working that order, and only while the order is open. It is not visible to other staff, and it is not visible on any screen you can reach.
- Every read is recorded. Each time the code is decrypted and shown, an entry goes into the audit log: which operator, which order, what time.
- The operator verifies it with the issuer. Verification is done by a person, by telephone or through the issuer's own channel, before any money moves. How we check a voucher sets out that step in detail.
- Two people, not one, settle it. The operator who approves the order cannot be the operator who releases the payment.
- The code is destroyed. Once the order settles, the code is removed from storage. What survives is the record of the order, not the code that funded it.
One thing here deserves plain speech: a human being does read your code. Verification means reading the code to the issuer, so it cannot be otherwise. The question is not whether anyone sees it. The question is how few people, for how long, and with what record — and the answers are one, until settlement, and every access logged.
3. Encryption at rest, and what it does not do
Encryption at rest means that what sits in storage is ciphertext. A copy of the database, a backup file, or a disk taken out of a machine is unreadable without the key, and the keys are held apart from the data they protect, so obtaining one is not obtaining the other.
That is the whole of what it does, and it is worth being clear about what it leaves untouched.
Encryption at rest does not protect data in use. A running application has to be able to decrypt a code in order to show it to the operator verifying it, so an attacker who takes control of the running application is inside the same boundary the application is. It does not protect against a person with legitimate access misusing that access. And it does nothing at all about what happened to a code before it reached us.
Those gaps are why the other controls exist. Narrow access, a logged read, a short life, and two people on the money are not decoration around the encryption. They are the parts that cover what encryption cannot.
4. Why we keep a fingerprint of a document number, not the number
Because we need to recognise a document again without holding the number that identifies it.
A fingerprint is the output of a one-way calculation. The same document number always produces the same fingerprint, and the fingerprint cannot be turned back into the number. That is enough for the work we actually need to do: to see that the same passport has been presented on two different accounts, or that a document we previously refused has come back, or that the document on file is the document in front of us.
There is an obvious attack on that idea, and we should name it. A document number is short and follows a predictable format, so someone holding a table of plain fingerprints could work through every possible number, fingerprint each one, and look for a match. That is why the calculation includes a secret value kept separately from the database. Without it, a stolen table of fingerprints is a table of values that mean nothing.
The fingerprint is not the whole story, because the document image itself still exists. That is the subject of the next section.
5. How identity documents are stored and served
They are stored outside the web root, which is the practical part of the answer.
A web server publishes files from one directory. Anything inside that directory is one guessed or leaked URL away from being public, whatever the intention. Identity documents are not in that directory. No web address points at them, so no address can be shared, forwarded, indexed or brute-forced.
To view a document, a member of staff must be signed in, and the request passes through a route that checks the session, checks whether that person is entitled to see that document, writes an entry to the audit log, and only then returns the image. The entry is written whether or not anyone ever reads the log. The files are encrypted at rest as well.
We do not use unguessable links for documents. A link that works for anyone holding it is a link that works for anyone it is forwarded to, including by accident. Every view goes through the authenticated, audited route or it does not happen.
Documents are held as required by our verification process.
6. The audit log, and why it is append-only and hash-chained
The audit log records who looked at what, and it is built so that entries cannot be quietly removed or altered.
Append-only means entries are added and never updated or deleted. There is no ordinary path in the application that edits a past line, because the value of the log is that it says what happened rather than what someone would prefer had happened.
Hash-chained means each entry carries a fingerprint computed over its own contents together with the fingerprint of the entry before it. The entries form a chain. Alter one line and its fingerprint no longer matches, and every fingerprint after it no longer matches either. The chain can be recomputed from end to end and checked.
This does not make tampering impossible. Someone with deep enough access could rewrite the entire chain from the altered point onwards. What it makes hard is silent tampering — a single quiet edit that leaves no trace — because a single edit is not a possible shape for the damage.
What goes into the log includes every access to a voucher code, every view of an identity document, every approval, every release of funds, session events, and compliance decisions. The log is part of the five-year record.
7. Four eyes on settlement
The operator who approves an order cannot be the operator who releases its money. Two people, two accounts, two audit entries.
The reason is narrow and practical. A single compromised staff account, or a single dishonest one, cannot move money on its own. It can get an order to the edge of settlement, and there it stops, in front of somebody else who has to look at it.
A second rule sits alongside that one: an open compliance case freezes settlement. While a case is open, nothing is released on that order — not by the person who raised the case, not by anyone else. Freezing is easy, and unfreezing requires the case to be closed on its own terms.
Money that one person can move alone is money one mistake can move.
8. Sessions, and why they can be revoked
A session here is a record on our server, not a self-contained ticket carried in your browser. The cookie in your browser holds a random identifier that means nothing on its own; the meaning lives on our side, attached to that identifier.
That design has one property that matters more than any other: because the record is ours, we can end it. Logging out ends a session rather than asking your browser to forget something. Changing your password ends the other sessions on your account. When a member of staff loses access, their sessions end at that point, not whenever a token would have expired. A self-contained token cannot be recalled once issued; it stays valid until its clock runs out, which is the wrong behaviour on the day you need it gone.
The session cookie is marked so that page scripts cannot read it, so that it is sent only over an encrypted connection, and so that other sites cannot cause your browser to send it. Sessions end after a period of inactivity and again at an absolute limit regardless of activity. Staff sessions are held to tighter limits than customer sessions, and staff access to an order ends when the order does.
9. What is yours to protect
Some of this only works if you hold up your end.
- Use a password that you use nowhere else. A password reused elsewhere is only as safe as the weakest site holding it, and no control on our side can tell a correct password from a stolen one.
- Protect the email account attached to your account here. It is the recovery path, which makes it the softest way in. Turn on whatever second factor your email provider offers.
- Submit a code once, in the order form, on this site. Never in an email, a chat message, a screenshot or a phone call — including to us.
- Look at the address bar before you type a code, and reach the site from your own bookmark rather than from a link someone sent you.
- Nobody here will ask for your password. Nobody here will ask you to buy a voucher and read out the code. Nobody here will telephone you and ask you to move money to keep it safe. Who never asks for vouchers is worth reading before you need it.
- If you think someone else has reached your account, write to [email protected] at once. If you think you have been defrauded, write to [email protected].
10. What this does not protect against
A code that has already left your hands. A voucher code can be spent by anyone who has read it. If you gave it to someone before you came here, encryption on our side cannot recall it, and verification may find the value already gone. I have already sent a voucher code explains what can still be done.
A customer who is tricked into submitting a code themselves. Every control described above behaves correctly in this case, which is what makes it hard. The right person is signed in, on their own account, with their own document, holding a voucher they bought themselves. Verification confirms the voucher is good. It cannot confirm why you are selling it. Fraudsters coach people through exactly this — the tax office that must be paid today, the support technician who found a virus, the person you have been speaking to for weeks who has an emergency abroad. Our questions and our checks catch some of it. They do not catch all of it. If an operator asks why you are selling, that is not nosiness, and a short honest answer is the fastest way through. Voucher scams sets out the patterns.
Your own device. Malware on your computer or phone sees what you see, including a code as you type it.
A convincing fake of this site. An encrypted connection tells you the connection is private. It does not tell you who is at the other end of it.
Us. No operator can honestly promise its systems will never be breached, and we are not going to be the first. What we can do is limit how far a breach reaches: codes that exist for a short time, access narrowed to one person and logged, keys kept apart from data, a log that resists quiet editing, and two people required to release money.
11. What we do not claim
We hold no security certification, and none is claimed anywhere on this page. No independent audit of these systems has been completed. No penetration test result is being reported. No standard is being implied by the way any of this is worded. If that changes, this page will name the certification, the standard or the firm, and the date.
The activity is not subject to licensing, and no authorisation is claimed.
This page describes how the service is built to work. It does not describe a history, because there is not one yet. Nothing here should be read as a claim about volumes handled, frauds prevented, or customers served.
We do not serve France, jurisdictions subject to the FATF call for action, comprehensively sanctioned jurisdictions, or markets where we hold no local authorisation.
12. Telling us something is wrong
If you have found a flaw in this site, write to [email protected] with enough detail to reproduce it. We do not run a paid bug bounty and we are not going to pretend otherwise. What we will do is read what you send, act on it, and not send a lawyer after you for reporting it in good faith.
For suspected fraud on an order, write to [email protected]. For questions about what we hold about you and what you can ask us to do with it, see privacy or write to [email protected]. To complain about how something was handled, write to [email protected]. General questions go to [email protected].
VoucherPay LLC operates from the United States at 1801 Peninsula Verde Dr.