# Valet Parking Ticket Scanner App in React Native

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-07. 6 min read.
> Source: https://vp0.com/blogs/valet-parking-ticket-scanner-app-react-native

The ticket is a bearer token for someone's car. Everything in the build follows from matching it to the right person, honestly.

**TL;DR.** A valet ticket scanner app is an operations tool wrapped around a claim check: the stub carries a random QR ID that resolves server-side, the session runs a six-state machine (issued, parked, requested, retrieving, ready, closed) where Ready is always a runner's curb-side confirmation rather than a timer, and intake photos at issue time settle damage disputes before they start. Guests never install anything: SMS codes, a web session page, and an iOS App Clip cover requests, while the full app serves the stand and the runners. A free VP0 design gives the agent this genre's screens to generate from, scanner-first.

## What makes a valet ticket different from a parking ticket?

It is a claim check, not a citation. A [municipal enforcement app](/blogs/municipal-parking-ticket-scanner-payment-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](https://github.com/mrousavy/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](/blogs/paytm-qr-scanner-ui-clone-react-native/): 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](https://developer.apple.com/documentation/appclip)** 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](https://en.wikipedia.org/wiki/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](https://vp0.com) 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.

## 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 six-state session machine: issue with intake photos, park with spot logging, request, retrieve, confirm ready at the curb, close on handoff. react-native-vision-camera handles QR scanning, and the guest side stays install-free via SMS and a web session page.

### What should a valet ticket QR code contain?

Only a random ticket ID that resolves server-side to the live session. Never print the plate, name, or phone number on the stub: guests photograph and share tickets, so the stub must be worthless on its own, with every claim validated against the session state.

### How do guests request their car without downloading an app?

Three install-free paths: texting the stub's code, scanning the stub's QR to open a web session page with a Request button and live status, or an iOS App Clip that adds native status states and Apple Pay. The full app install belongs to staff.

### How does the app prevent handing a car to the wrong person?

The handoff scan: the runner scans the guest's stub or screenshot at the curb and the app matches it to the requested session before allowing the close. A mismatch blocks the handoff and alerts the stand manager.

### Why take photos of the car at intake?

Four corners plus the dashboard at issue time become timestamped evidence attached to the session. Damage disputes usually end the moment both sides see the intake set, which makes the ten-second habit the cheapest insurance in the operation.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*