ACP · THE CHECKOUT SESSION · STAGED · STRIPE TEST KEYS NOT PLACED

Agentic Commerce Protocol — a feed, a checkout session, a delegated payment

The Agentic Commerce Protocol (ACP) is the checkout specification a merchant implements so an agent platform can buy on the buyer's behalf: a product feed, checkout session endpoints (create, update, complete, cancel, retrieve) versioned by an API-Version header, and a delegated payment — the platform hands the merchant an encrypted payment token from a payment service provider and the merchant charges it with its own processor. This surface implements the checkout session endpoints at API-Version 2025-09-12 as the specification read on 2026-09-19.

Financial Comptroller
Agentic KG Holdings → agent-kg.ai
/api
THE PAID DOOR · X402 ON EVERY HOST
§1 · THE RAIL

What Agentic Commerce Protocol (ACP) is

The Agentic Commerce Protocol (ACP) is the checkout specification a merchant implements so an agent platform can buy on the buyer's behalf: a product feed, checkout session endpoints (create, update, complete, cancel, retrieve) versioned by an API-Version header, and a delegated payment — the platform hands the merchant an encrypted payment token from a payment service provider and the merchant charges it with its own processor. This surface implements the checkout session endpoints at API-Version 2025-09-12 as the specification read on 2026-09-19.

The specification defines no discovery file at a well-known path; the feed is submitted to the platform. This surface serves its two-offer feed at /acp/feed.jsonl only once the rail can settle. Until the office's Stripe test keys are placed the feed answers a real 404, sessions can be created and read, and completing one answers a typed refusal.

§2 · HOW AN AGENT PAYS HERE

How an agent pays here

  • 1 — POST /checkout_sessions with items from /offers.json and the API-Version, Idempotency-Key and Request-Id headers — 201 with the session.
  • 2 — POST /checkout_sessions/{id} to update; GET to retrieve.
  • 3 — POST /checkout_sessions/{id}/complete with payment_data (a delegated token, provider stripe, test mode): charges once the rail is enabled; until then a typed refusal.
  • 4 — POST /checkout_sessions/{id}/cancel closes it.
§3 · THE OFFERS

Two offers, both placeholder prices

  • One metered call on the office door — $0.01 · x402 — USDC on Base mainnet · placeholder price
  • A block of 100 calls on the office door — $1.00 · the card rails, test mode, once the office's Stripe test keys are placed · placeholder price — card processors do not take a one-cent charge
  • Product — the office door: the statement of record at agent-kg.ai/facts.json, read at the call, never copied.
  • Machine copy — /offers.json
§4 · THE RECEIPT CONTRACT

The receipt contract

Every receipt carries the payer, the transaction, the amount and asset, the resource, the rail, the host that issued it and the notice; the jwt verifies against /x402/jwks.json (kid fc-x402-2026-09) and the receipt resolves forever at /x402/receipt/{nonce}. A card-rail receipt, when those rails settle, carries the test-mode charge reference in the same shape.

This surface implements the rail it is named after. Nothing here is endorsed by any protocol's owner. Prices are placeholders set by the office.

§5 · THE FOUR RAILS

The other three

  • agent-x402.ai — x402
  • agent-mpp.ai — Machine Payments Protocol (MPP)
  • agent-ucp.ai — Universal Commerce Protocol (UCP)
  • Every .ai host answers all four rails; each site explains the rail it is named after. Beta runs at the office first; working things move to the companies after.