Agentic checkout for live-events ticketing
Agentic checkout for live-events ticketing
Alyte is the trust layer an agent clears before it can buy. You integrate against a hosted API, no PSP migration, no funds touching us. The same request path runs every check server-side, so an agent can't exceed its mandate no matter what its prompt says.
One request path. Each step a normal REST call with a Bearer token.
# 1 · discover, inventory for a merchant's event GET /v1/merchants/mrc_42/events Authorization: Bearer $TOKEN # 2 · quote, lock the price (returns a quote_id) POST /v1/quotes { "tier_id": "tier_ga", "qty": 2 } # 3 · reserve, one atomic, oversell-proof hold POST /v1/holds { "quote_id": "qt_9f3" } Idempotency-Key: 3b1c… # 4 · confirm, the merchant's own PSP settles the charge POST /v1/holds/hd_7c/confirm { "instrument": "inst_tok_…" }
The important part: the spend cap is resolved server-side from the agent record, never read from the token.
One header. Scopes gate each route.
Cap, scope, ownership and oversell checks all run in the orchestrator. The model cannot raise its own spend cap; that authority is resolved server-side from the agent record.
REST, MCP and A2A all funnel through the same orchestrator, same auth, scopes, tenancy, idempotency, checks.
/v1/payments. Scope-gated, OpenAPI-described.agent:run scope.The cap lives on the server, not the prompt, the model cannot raise it. Spend authority is resolved server-side from the agent record. Money settles merchant to merchant's PSP; Alyte moves instructions, never funds.
Whichever surface an agent uses, the purchase clears the same server-side gauntlet, known agent, within mandate, seat free, price locked, before any money moves.
Straight about maturity: surfaces and policy checks are live and tested. Scheme attestation adapters (TAP, Visa Intelligent Commerce) are wired and enforced in shape, but live signature verification and the production agent are roadmap. The sandbox agent runs as a deterministic script. We label real, mock or stub honestly.
Claimed atomically before any charge work, per-tenant. Two concurrent same-key requests never both authorize. Retry freely.
Typed codes, stable shape. An ambiguous PSP result halts to reconcile, never a silent decline you would retry into a double-charge.
The four calls above are the buy side. To make a merchant's tickets available to agents, two things get wired, both real today, through the merchant console.
Register your PSP rails and store credentials as an opaque reference, never the secret, resolved at charge time. Charges settle to your own PSP account. Alyte is never a payee.
Create events and tiers, set price and availability. The mutable inventory that quotes price-lock against and holds decrement atomically, the source of the oversell-proof guarantee.
Straight about the supply API: PSP linking and catalog management are live in the merchant console today, an admin surface you operate. A server-to-server inventory-sync API, for merchants who run their own ticketing system and want to push inventory programmatically, plus outbound webhooks (payment.succeeded, hold.expired), are on the roadmap, not shipped. If you have your own inventory source, that adapter is what we build with design partners next.
The quickstart, machine-readable OpenAPI spec, preview SDK, and full endpoint and error reference are coming to a hosted docs site. Talk to us in the meantime and we will walk you through the API directly.
