Valet Parking Ticket Scanner App in React Native

What makes a valet ticket different from a parking ticket?

It is a claim check, not a citation. A municipal enforcement app scans tickets to collect fines; a valet app scans them to give a car back to the right person. That single difference rewrites the whole build: the ticket is a bearer token for a $40,000 object, the scanner’s job is matching rather than charging, and the worst failure mode is not a lost payment but a car handed to the wrong guest.

So the ticket needs to be cheap to issue and hard to spoof. A QR code on a paper stub (or an NFC tag on a reusable fob) carrying a random ticket ID works; the ID resolves server-side to the session, and the stub itself stores nothing sensitive. Guests photograph theirs anyway, so the claim flow has to survive a screenshot of a screenshot, which the random-ID design does and a license-plate-printed-on-the-stub design does not.

How does the session state machine run?

Six states, each owned by a specific human, each visible to the guest in honest terms:

State	Who acts	The guest sees
Issued	Valet scans a fresh ticket, snaps intake photos	A digital copy of their ticket
Parked	Runner logs spot, lot, and keys hook	”Your car is parked”
Requested	Guest taps Request (or texts the code)	An honest wait estimate
Retrieving	A runner accepts the job	”Marco is bringing your car up”
Ready	Runner confirms at the curb	”Your car is at the front” with tip + pay
Closed	Ticket invalidated on handoff	The receipt

Two integrity rules carry the table. “Ready” is a human confirmation, never a timer: an optimistic “your car is ready in 5 minutes” that the runner has not confirmed trains guests to stand at an empty curb, and the trust never comes back. And the intake photos at “Issued” are the dispute insurance: four corners and the dashboard, ten seconds of the valet’s time, attached to the session forever. Damage claims resolve in one tap instead of one argument.

The scanner side is standard camera work: react-native-vision-camera (9,440 stars, 683,689 weekly downloads) reads the QR in poor garage light, and the scan resolves the session in one round trip. Scan-first beats search-first at a busy stand, the same lesson as every payment QR scanner: the camera is the home screen of the operational app.

How do guests request their car without installing anything?

This is the genre’s real UX problem: nobody installs an app for a two-hour parking relationship. Three request paths, in order of friction:

• SMS: the stub prints “text READY to this number with code 4821.” Works on every phone ever made, and the reply carries the honest wait estimate. This is the floor, and many operations need nothing more.
• A web link behind the QR: scanning the stub with the phone camera opens a session page with a Request button and live status. No install, no account.
• An App Clip for iOS: the same scan opens a native lightweight slice with the status states, Apple Pay for the fee, and the tip flow, still without a full install. This is where the polish budget goes once the SMS floor works.

The full app is for the operation itself: the valet stand’s scanner, the runner queue, the manager’s board with cars-in/cars-out counts and average retrieval time. Guests get the install-free paths; staff get the real tool.

What does the money flow look like?

Tied to the Ready state, not before. Fee plus tip presents when the car is confirmed at the curb, through the session’s web page or App Clip, with cash remaining a first-class button the runner can tap on the guest’s behalf (valet parking remains a cash-heavy trade, and an app that pretends otherwise gets worked around at the stand). Card payments ride a hosted payment page so no card data touches the app, and the tip splits to the runner who pulled the car, which is the feature that makes the staff actually scan tickets instead of ghosting the system.

A free VP0 design covers this genre’s screens, scanner-first home, session status states, the runner queue, so an agent generates the operational app from real structure instead of improvising a consumer app where an ops tool should be.

Key takeaways: valet ticket scanner app

• The ticket is a claim check: a random-ID QR resolving server-side, cheap to issue, useless to forge, survivable as a screenshot.
• Six states, human-owned: Ready comes from a runner’s confirmation at the curb, never a timer.
• Intake photos are the dispute insurance: ten seconds at Issued saves the argument at Closed.
• Guests never install: SMS floor, web session page, App Clip polish; the full app belongs to the stand and the runners.
• Money lands at Ready: hosted payment plus first-class cash, with tips routed to the runner who pulled the car.

Frequently asked questions

How do I build a valet parking ticket scanner app in React Native? Start from a free VP0 design for the scanner-and-status genre and have Claude Code or Cursor generate the session state machine: issue with intake photos, park with spot logging, request, retrieve, confirm ready, close on handoff. Vision-camera handles the QR scanning; the guest side stays install-free via SMS and a web session page.

What should the valet ticket QR code contain? Only a random ticket ID that resolves server-side to the session. No plate, no name, no phone number: the stub gets photographed and shared, so it must be worthless on its own and the claim must validate against the live session.

How do guests request their car without downloading an app? Three paths: texting a code from the stub, scanning the stub’s QR to open a web session page with a Request button, or an iOS App Clip that adds native status and Apple Pay. The full install is for staff, not guests.

How does the app prevent giving a car to the wrong person? The handoff scan closes the loop: the runner scans the guest’s stub (or screenshot) at the curb and the app matches it against the requested session. A mismatch blocks the close and flags the stand manager.

Why photograph cars at intake? Four corners and the dashboard at Issued become the evidence layer for damage disputes. The photos attach to the session, and most claims end the moment both sides see the timestamped intake set.