Solutions — agentic payments

Sell parking to software
that books trips.

An AI assistant planning someone's journey can find your event, pay for parking and receive a valid pass, without a card, an account or a person. This works today.

The flow

Discover, quote, pay, verify

An agent asks what is on sale, receives a price and a payment requirement, signs a stablecoin transfer, and gets a pass back. Four steps, no browser, no human. 

1 GET  /api/v1/x402/events            what is on sale
2 POST /api/v1/x402/pay/{code}        402 + payment requirements
3 POST /api/v1/x402/pay/{code}        signed authorization
4      → 200, pass issued, on-chain hash returned
Standard

x402, not a bespoke API

An open protocol over HTTP 402, so an agent that can pay anywhere can pay here without integration work on either side.

Discoverable

Agents find it themselves

/.well-known/x402 and llms.txt describe the service where agents already look, so nobody has to be told it exists.

Settled

Money before the barrier

USDC clears in seconds. The transaction hash is on the dashboard and links to a block explorer.

Same pass

No separate inventory

An agent's purchase issues the same pass, against the same tier and the same capacity, as a person buying on the site.

Why bother. Almost no parking operator is reachable this way. When an assistant plans a trip end to end, the parking it can actually buy is the parking that gets booked — and being early is free, because the same passes and the same gate serve both kinds of buyer. The agent documentation is here.
Before you open an event to agents. A pass admits one car, and an agent purchase now returns a single-use claim link rather than the pass — whoever signs in through it owns it from then on, so the same link cannot be sold twice. The paying wallet is recorded. What is not yet in place is a per-buyer limit, so one wallet can still acquire in bulk. Set a deliberate crypto allocation per event rather than opening your inventory. What we would build, and in what order.