Ticketing and live events

The problem

A ticket is a bearer instrument. Whoever holds it gets in. That was tolerable when tickets were paper and hard to copy, and it stopped being tolerable the moment a ticket became an image on a phone.

A screenshot is indistinguishable from the original. It can be sold four times over on a resale site, forwarded to a group chat, or printed. The first person through the gate wins and everybody after them argues with your staff. Meanwhile the organiser cannot see any of it happening, because a barcode does not report home until it reaches the scanner at the door, by which time the money has changed hands and the reputational damage is done.

How VCode is deployed

Each ticket is issued with its own VCode: not one code per event or per tier, but one per seat, per person. The code is generated by the platform, so it cannot be manufactured by anyone else, and it is bound at issue to the rules the promoter chooses.

• Holder binding, so the code resolves for its registered holder and refuses for anyone else.
• A validity window, opening at doors and closing when the event ends, down to the hour.
• A geofence, so the ticket only resolves inside the venue boundary.
• Single use, once only, so the second presentation of the same ticket is refused.
• Controlled transfer, so a ticket can be legitimately reassigned to a new holder by the issuer, and the original stops working at that moment.

What happens when it is scanned

The gate scans the symbol. The reference goes to the platform, which identifies that individual ticket and tests its rules against the context of this scan: who is presenting it, where, when, and whether it has been used before. An answer comes back, and the attempt is written to history whether it succeeded or not.

The screenshot case is worth following through. The buyer photographs their ticket and sends it to four people. All four arrive. The first legitimate holder is admitted. The other four are refused, not because the image is degraded or the barcode is malformed, but because the code is bound to someone else and has already been used. Each refusal is recorded with time and location, which is a fraud signal you can act on rather than a queue argument.

Why a QR code or NFC alone is not enough

A QR ticket carries its own payload, so the image is the entitlement. Rotating barcodes in an app help, but they solve the screenshot problem by requiring the app, which is the same adoption cost as VCode while still leaving the code itself as a data carrier with no per-scan policy.

NFC wristbands are genuinely strong at the gate, and for a closed venue with hardware at every door they are a good answer. What they do not give you is the pre-event lifecycle: an NFC wristband is not issued to a named buyer at the point of sale six weeks out, and it does not let you revoke a specific ticket after a chargeback while the buyer is still holding the physical item.

VCode adds the part neither has: the entitlement is decided at the moment of the scan, by the issuer, against rules the issuer can change after the ticket has been sold.

What it changes commercially

• Touting becomes uneconomic. A resold screenshot does not admit anyone, so the secondary market has nothing to sell that works.
• Transfer becomes yours. If a ticket can only change hands through you, the transfer is a product rather than a leak, and you keep the buyer relationship.
• Chargebacks get an answer. Revoke the ticket, keep the record of every attempt to use it.
• You see the door in real time. Refusals concentrated at one entrance, or a cluster of attempts from outside the geofence, are visible while the event is running.

Integration

Tickets are minted through the platform API at the point of sale, with rules and actions attached per ticket. Gate scanning is added to your existing steward or box-office application through the SDK, so there is no separate hardware estate. Scan history is available for reconciliation and for fraud analysis after the event. See the developer documentation.