Admissions

Ticket Pass

Anti-scalping door passes: short-lived rotating QR against an AffixIO ticket proof, one-scan gate consume, and door OTP when staff need a code instead of a camera.

What a door needs from AffixIO

The hard problem in ticketing is presentment: a code that is fresh enough to frustrate screenshots, bound to a real eligibility proof, and spent the moment a door accepts it.

Ticket Pass uses AffixIO carriers that already exist in production: link for QR presentment, OTP for staffed doors, and gate verify in consume mode so the same proof digest cannot walk in twice.

Nearby venues are pulled from OpenStreetMap only when they publish an official website. The list links to that site, never the map tile provider.

Static barcode

One image for the whole night. Easy to forward. Hard to revoke mid-queue without a private ticket stack.

Screenshots travel

AffixIO door pass

Short-lived link QR rotates on a timer. Gate consume spends the proof digest. OTP covers staffed lanes. Same AffixIO key as the ticket circuits.

TTL presentment · one-scan admit

Anti-scalping with AffixIO and npm

Screenshot resale thrives on static barcodes. AffixIO separates the lasting proof from a short-lived presentment carrier, then spends the proof once at the door.

Scalpers do not need your ticketing database. They need a code that still works after it leaves the buyer’s phone. Ticket Pass closes that path with three production AffixIO surfaces already available to @affix-io/sdk-light and @affix-io/sdk: link issue for rotating QR, OTP for staffed lanes, and gate verify in consume mode.

What a static ticket allows
AffixIO door pass defence

Screenshot resale path

Static barcode screenshot path Buyer phone shows a static QR. An arrow goes to a screenshot that is sold. Two scanner icons both accept the same code. Buyer phone static QR Screenshot still valid Door A admit Door B admit Same code works twice. Scalper keeps the margin. No proof spend · no TTL presentment

AffixIO one-scan path

AffixIO rotating QR and consume path Proof digest issues a TTL QR. After door consume, a second scan is rejected with double spend detected. Proof digest ticket circuits TTL link QR sdk-light render First scan · ADMITTED Reuse · DOUBLE_SPEND Presentment rotates. Proof digest spends once. Expired screenshot fails link verify

Wire it from npm

Ticket Pass on this site uses the same carriers. Your Node service installs the SDK, keeps the AffixIO API key server-side, and presents only the short-lived QR or OTP to the buyer.

Install

npm install @affix-io/sdk-light

Optional UltraHonk prove

npm install @affix-io/sdk

Presentment sketch

import { renderQrSvg } from "@affix-io/sdk-light";

// 1) Prove ticket_* circuits → proof_digest
// 2) POST /v1/link/issue { proof_digest, ttl_seconds: 45 }
// 3) const svg = await renderQrSvg(https_link);
// 4) Door: POST /v1/link/verify then
//    POST /v1/gate/verify {
//      policy_id: "gate.ticket",
//      proof: proof_digest,
//      mode: "consume"
//    }
  • Rotating QR expires on TTL. Auto-rotate issues a fresh link carrier against the same digest.
  • One-scan admit spends the digest. A second door returns double_spend_detected.
  • Door OTP covers staffed lanes without a camera. OTP verify then follows the same consume path.
  • Docs: sdk-light, sdk, OpenAPI, developers.
Integration stack
  1. Your ticketing app

    Holds order state. Never ships the AffixIO API key to the browser.

  2. @affix-io/sdk-light

    Local Affix Light prove, renderQrSvg, carrier helpers on Node.

  3. api.affix-io.com

    Link, OTP, gate verify, ticket circuits, Merkle audit.

  4. Door scanner

    Verifies presentment, consumes proof, returns admit or double spend.

Live ticketing interest

Seven-day Wikipedia traffic for ticket resale, box office and QR codes. AffixIO signs an audit of each refresh.

Sources: Wikimedia Pageviews, AffixIO carriers.

Door workspace

Issue a pass, rotate the QR, scan once, or look up venues that publish an official site.

Issue door pass

Prove admission, mint a short-lived AffixIO link QR, and issue a door OTP against the same proof digest.

Door scanner

Paste a scanned AffixIO link or enter the door OTP. Consume mode admits once on the proof digest.

Venues with official sites

Theatres, cinemas and stadiums near a postcode that publish a website in OpenStreetMap. Links open that official site.

Questions

How does AffixIO stop ticket screenshot scalping?

Presentment uses a short-lived AffixIO link carrier rendered as a QR. The frame expires on a timer. Door admit consumes the underlying proof digest once, so a forwarded screenshot cannot open a second gate.

How does the rotating QR work?

AffixIO issues a short-lived link carrier for the ticket proof digest. Ticket Pass encodes that HTTPS link as a QR with renderQrSvg from @affix-io/sdk-light. Refresh or the auto-rotate timer issues a new presentment token against the same proof.

What stops a second scan?

Door scan verifies the link or OTP, then calls AffixIO gate verify in consume mode on the proof digest. A second admit returns double_spend_detected.

What is the door OTP for?

Staffed doors can take a six-digit AffixIO OTP instead of scanning. OTP verify consumes that OTP carrier, then the gate consume path admits once on the proof.

Why do venue links go to official websites?

Venue search uses OpenStreetMap only to discover places that publish a website or contact:website tag. Ticket Pass lists those venues and links to the official site, not the map provider.