— Use case · E‑commerce

Transact without waiting for an API.

Aggregators need inventory they can book. Suppliers need distribution without building an API. A3 learns checkout from the live website and exposes a transactional REST API or UCP — so both sides move faster.

UCP for agent commerce →
Hotels Flights Retail Other
"Winged Victory" — conversions that land.
— The API gap

Most commerce still runs on websites, not partner APIs.

Aggregators need bookable inventory. Suppliers need distribution. Both get stuck waiting for a transactional API that was never built, was never offered, or is locked behind a partner programme that never lands.

Why merchants often have no transactional API

A working consumer checkout is not the same as a partner integration. Many retailers, hotels, and airlines never ship the second — and some actively avoid it.

How A3 closes the gap

A3 starts from the checkout path shoppers already use. An agent learns each step once; the runner drives it at scale — then you expose the result to partners.

Standard API integration

No capacity — small teams, legacy stacks, or no dedicated integration engineering.

With A3

No API team — learn from the live checkout; an agent writes stages instead of staffing an integration programme.

Standard API integration

PCI and payments — a transactional API that accepts cards pulls you into scope, audits, and ongoing compliance work.

With A3

PCI stays on the merchant — checkout runs on the existing payment page; card data does not move into your boundary.

Standard API integration

Hard to build — carts, pricing rules, inventory, idempotency, webhooks, and per‑partner onboarding multiply fast.

With A3

Learn once, run many — stages and playbook.md capture the flow without building a parallel API surface.

Standard API integration

Commercial friction — channel conflict, preferred direct bookings, or APIs reserved for a handful of strategic partners.

With A3

One consumer path — partners transact against the same checkout shoppers use; no separate API per channel.

Standard API integration

Access denied — rates or content APIs exist, but booking keys are withheld or partner programmes stall in legal review.

With A3

The public checkout — onboard suppliers from the path end users already take when partner access never arrives.

— Common concerns

Website automation sounds risky. Production commerce needs more.

Partners compare browser-driven checkout to a native API and worry about breakage, latency, and payments. A3 is built for transactional workloads: deterministic replay at runtime, self-healing when sites drift, and payment infrastructure that keeps card data out of your boundary.

— Reliability

Self‑healing when the site changes

A broken selector should not take down an integration. Each checkout step is a typed stage with findings in playbook.md. When a page stops matching, the learning agent auto‑fixes the stage in real time — so production keeps moving without waiting for a manual patch.

— Speed

Nearly as fast as a well‑built API

Learning uses an agent once; runtime does not. The runner replays compiled Playwright stages with no LLM in the loop — highly optimised paths that keep latency close to what you'd expect from a partner API, without the integration programme that usually precedes it.

— Security

PCI Level 1 infrastructure, tokenisation, and 3DS

Checkout runs on PCI Level 1 compliant infrastructure. Built‑in card tokenisation and 3‑D Secure support let partners pass payment instruments without raw card data crossing their boundary — the same handler model UCP uses to keep aggregators out of PCI scope.

— Operability

Traceable runs at production scale

Stages and playbooks live in git; the runner scales with configurable concurrency — locally or in the cloud. Every execution records structured logs and Playwright traces, so a failed booking points at the exact stage, not a black box.

— Agent commerce

The next channel is the chat assistant.

Shoppers are moving from websites and apps to conversational agents — compare options, configure a trip or cart, and complete purchase without leaving the thread. That only works if suppliers expose inventory agents can actually transact against, not just read about. Most still only have a consumer website.

— In conversation

Discovery and checkout in one thread

Users ask a travel, shopping, or booking agent for options — then say "book that one." The assistant needs live availability, pricing, and a path to confirmation inside the chat, not a hand-off to a supplier site that breaks the flow.

— For platforms

Agents need a typed commerce API

Assistant builders integrate against protocols like UCP — search, select, pay, confirm over REST or MCP. Without a transactional surface per supplier, the agent can summarise the web but cannot close the sale.

— For suppliers

Be bookable where agents shop

Hotels, airlines, and retailers do not need to rebuild for every assistant. A3 learns the existing checkout once and stands in as a UCP server — so your inventory is available in agent commerce without a multi-year API programme.

— For aggregators

Breadth of supply in every assistant

OTAs, metasearch, and shopping agents win on coverage — but most suppliers still have no bookable API. A3 learns each checkout once so you onboard sites into UCP fast, and your assistant can transact across hotels, flights, and retail in the same thread.

— Across verticals

The same model in every vertical.

Hotels, flights, and retail look different on the surface — but the shape is the same: search, select, configure, pay, confirm. A3 learns that checkout path once and exposes it to partners the same way, whether you are filling rooms, selling seats, or completing a cart.

— Hotels

Fill rooms through OTAs and metasearch

Properties and chains depend on OTAs and metasearch for occupancy — especially independent hotels with no connectivity programme. Distribution is essential; a transactional partner API often is not.

  • Why distribute — reach travellers where they search, compete on rate comparison, and reduce reliance on direct-only demand.
  • No connectivity team — many properties run on consumer booking engines with no B2B integration roadmap.
  • Rate and policy rules — board basis, cancellation windows, and parity commitments are difficult to expose as a simple API.
  • Channel tension — hotels want distribution but fear undercutting direct; partner programmes stall or stay invite-only.
  • Agent commerce — travellers will book from chat assistants; expose rooms via UCP so properties are in the conversation, not just on the website.
— Flights

Sell seats beyond the airline homepage

Airlines and OTAs need metasearch and aggregator reach for fare shopping — but building and maintaining a bookable partner API sits behind long IT backlogs, legacy stacks, and accreditation processes.

  • Why distribute — appear in fare comparison, capture corporate and leisure demand, and partner on packages without owning every channel.
  • Fare family complexity — baggage, seats, and branded fares are hard to normalise into a partner contract.
  • Accreditation and access — partner feeds are restricted, slow to approve, or withheld from all but the largest aggregators.
  • Legacy booking engines — the bookable path lives in a consumer UI that was never designed as an integration surface.
  • Agent commerce — passengers will shop and book inside travel assistants; A3 puts airline inventory in those threads without a native partner API.
— Retail

Reach shoppers where they compare and buy

Retailers and brands want presence on comparison sites, marketplaces, and affiliate channels — incremental sales without sending every visitor to a single storefront. Standing up a partner API for each channel is rarely the priority when the consumer checkout already works.

  • Why distribute — meet customers on aggregators, win basket share on price comparison, and test new channels without rebuilding checkout.
  • Variant complexity — size, colour, and bundle rules are hard to mirror in a clean API without duplicating cart logic.
  • Promos and loyalty — member rates, discount codes, and regional pricing do not map cleanly to a generic partner feed.
  • Payments and PCI — accepting cards through a new API surface expands compliance scope most retail teams want to avoid.
  • Agent commerce — shoppers will buy from comparison and shopping agents; make your catalogue transactable in chat, not only on your storefront.
— Other

Any checkout that ends in a confirmation

Car hire, events, insurance, subscriptions — suppliers in every category face the same trade-off: they need distribution, but building a transactional API per partner or vertical is slow, expensive, and fragile when the website changes.

  • Why distribute — reach customers on the aggregators and agents they already use, without a separate platform project per channel.
  • Same blockers — PCI scope, partner onboarding, and keeping an API in sync with a live consumer journey.
  • Form-heavy flows — eligibility, add-ons, and multi-step wizards that resist a tidy partner API contract.
  • Same answer — learn the checkout once; partners integrate against one workflow, not a bespoke build per vertical.
  • Agent commerce — car hire, insurance, and subscriptions will move into assistants; the same learned checkout makes any supplier bookable from a chat thread.
— UCP

One protocol for hotels, flights, retail, and beyond.

Every vertical above ends the same way: search, select, configure, pay, confirm. A3 learns each supplier's checkout from the live website, replays it deterministically, and exposes the result as a UCP server — so agents and aggregators transact against one typed contract, whether they are booking a room, a seat, or a cart.

How A3 maps to UCP →