Voucher QR code verification: what the scan should prove

Voucher QR code verification works when the code opens a page on the issuer's own system that answers one question from live records: does this booking still stand? The page should say valid, cancelled, replaced by a newer version, or not found, with the reference, the lead guest's name and the date. Nothing else: no prices, no contact details.

Why fake and edited vouchers reach the desk

A voucher is a PDF, and a PDF is easy to change. The trouble at the desk comes in a few shapes:

• An edited copy. Dates moved, a night added, an extra person or a second room typed in, the meal plan upgraded. The logo and layout are real, because the file was.
• A cancelled booking, still printed. The paper does not know the booking was cancelled last week.
• An old version. The booking was amended, and the guest kept the first printing.
• A forgery. A document made to look like a known company's, from someone who holds no booking at all.
• An honest mismatch. Names in the wrong order, or the booking held under a wholesaler's name; the hotel voucher fields prevent many of these.

Without a check, the desk judges by fonts and logos, or phones you at night. A QR that opens your live record replaces that judgement with a fact, but only if the page reads the booking as it stands now. What the paper printed is what it claimed at the time; the check has to ask the live record.

What one scan should answer

Four answers are enough, and each tells the desk what to do.

"Replaced" is the answer that is easiest to leave out, and it catches a common real problem: a guest holding the printing from before an amendment. Without it, an old copy of a live booking scans "valid" and the desk honours last month's dates.

One subtlety. An itinerary is not a promise about one service, so cancelling one tour should not make the whole itinerary "cancelled". It makes it out of date: re-issue it, and the old printing reads "Replaced". A voucher, by contrast, is about one service, and cancelling that service makes it "Cancelled".

What the check page shows, and what it never shows

A QR on a voucher is a public link. It gets photographed, forwarded in chats and left in lobbies. Design the page as if a stranger will open it, because one will.

Show only what lets a supplier match the paper to what they hold:

• the answer: valid, cancelled, replaced or not found;
• the trip reference and the document number, with which copy it is and its version;
• the lead guest's name and the travel date;
• who issued it, and when the check was made, on the issuer's clock with the time zone named, so a screenshot of yesterday's check looks like yesterday's.

Never show prices, the guest's phone or email, the rest of the party, the supplier's rate, internal notes or anything about payment. The desk does not need them to decide, and a stranger should not get them from a photograph. Keep the page out of search engines as well.

That is the design in iTravel's travel voucher software. The QR on a document opens the check page of the account that issued it, which answers valid, cancelled, replaced or not found with the reference, the document number, its copy and version, the lead guest and the date. The check time is the account's own clock with its zone, and the page asks search engines not to index it. A voucher whose service was cancelled or removed from the trip checks as cancelled, and so does an invoice reversed by a credit note.

Sequential numbers or a random token

The voucher number is sequential, and it should be: VOU-2026-00418 follows 00417, which is what your accountant needs. That is exactly why it must never be the address of the check page.

If the QR opened a page at /verify/VOU-2026-00418, anyone holding one voucher could type 00419, 00420 and onwards, and read the name, dates and status of every booking you ever issued. Security people call this an insecure direct object reference, and the OWASP guidance on it uses the same example of changing one number to the next. A check page is public by design, so no login stands in the way; the address itself has to be unguessable, and the page has to show little enough that a stray link does no harm.

So the QR carries a random token. In iTravel it is 40 random letters and digits, made when the document is issued and different for every printing. It opens the issuing account's check page and nothing on another account's, and the page limits how fast anyone can ask. The number stays printed for people; the token is for the scanner.

Desks without a scanner still need a way in. The pattern airlines use for managing a booking works: the printed reference and the lead guest's surname together, never the reference alone, because a reference is printed, read out and photographed. A miss says only "not found", never which of the two was wrong. iTravel's check page offers that look-up, with a stricter limit on attempts.

Who scans, and what each needs

An attraction gate is different: it scans each ticket's own code into its own system, and that code is not the voucher's check QR. The full set of travel documents shows which copy each of these readers holds.

Each reads in their own language. The page should answer in the language of the phone that scanned it, not the language the voucher was printed in: the desk is in one country, the guest from another, the issuer often in a third. iTravel's check page follows the scanner's browser language, in any of its 32.

White-label copies: when the QR stays off

A DMC selling through a partner agency has a problem a direct seller does not. The traveller's copy carries the agency's name and logo, and the agency's client must not learn who the DMC is. A QR that opens the DMC's own check page would tell them.

So a traveller's copy issued on a partner's behalf should carry no check QR and no check address. The supplier's copy, which the hotel desk holds, and the agency's own copy keep theirs, because the hotel honours the company that pays it. iTravel draws the papers that way: a copy issued on a partner agency's behalf has no check QR, no check line in its footer and no link to your terms, and the supplier and agent copies keep all three.

A worked example: three scans at one desk

Say a hotel desk checks in three arriving parties one evening. Every detail is illustrative.

1. The first guest shows a printed voucher. The scan says Valid: reference 7HQK-2MWX, document VOU-2026-00418, traveller copy, the lead guest's name matching the passport, arrival today. Check-in takes a minute.
2. The second guest shows a voucher printed at home a month ago. The scan says Replaced: the stay was amended from two nights to three and re-issued as version 2. The guest opens the voucher link on their phone, which always shows the latest printing, and that copy scans Valid. The desk checks them in for three nights, not two.
3. The third guest shows a voucher with the right logo and a plausible number. The scan says Not found. The desk does not ring the number printed on the paper; it rings the issuer on the number in its own contract file, which confirms there is no such booking. The room is not given against that paper.

The traveller's trip page is what spares the second guest the argument: the latest papers are always one tap away on the phone.

What a scan cannot prove

A good check is honest about its limits.

• It does not prove who is holding the paper. The passport does that; the page gives the lead name to compare.
• It does not prove the hotel has the room. It says the issuer stands behind the booking; the hotel's own system says whether the room is allocated. Reconfirming before arrival closes that gap, as the hotel reconfirmation process sets out.
• It is only as current as your records. A cancellation agreed on the phone and never entered still scans valid. Enter it at once, and re-issue after every amendment, the itinerary included.

A checklist for vouchers that can be checked

• A QR on every document, opening a page on your own system.
• A random token per printing in the QR's address, never the document number.
• Four answers: valid, cancelled, replaced, not found.
• Reference, number, copy, version, lead name and date, and nothing more: no prices, no contacts.
• The check time on your clock, with the zone named.
• The page in the scanner's language, kept out of search engines.
• A look-up by reference and surname for desks without a scanner, limited, answering only "not found" on a miss.
• No QR on a traveller copy issued under a partner agency's brand; the supplier copy keeps it.
• Cancellations entered the moment they are agreed; papers re-issued after every amendment.
• Suppliers told what each answer means, and which number to ring when the answer is "not found".