Agentic Commerce Protocol (ACP): Shared Payment Tokens, Link Wallets, Agent Checkout

Stripe shipped agent commerce in April 2026. The Agentic Commerce Protocol (ACP) is now production-ready. Stripe’s Link wallet supports agent-initiated purchases. Most sites are not prepared to accept these transactions, and the gap is structural, not technical. The four surfaces an ACP-ready site needs total maybe a thousand lines of code. The decision to add them is the work. This post walks through what each surface does, why each is load-bearing, and includes a working receivable endpoint stub you can adapt.

The framing matters because the conversation around “preparing for AI agents” has been mostly vapor for two years. ACP changes that. There is now a deployed standard, an SDK, and a reference agent that walks through the full purchase flow. The companies that adapt first will see agent-driven traffic convert. The companies that do not will see agents recommend competitors instead, mirroring the pattern in AI answer engine optimization where structured, extractable content wins over unstructured pages.

Why Is ACP Different From Previous Agent Commerce Hype?

Agent commerce has been promised since 2022 in some shape, mostly framed as “AI assistants will buy things for you.” The implementations were brittle: a wrapper around web scraping, a screen-reading model that broke when the merchant’s CSS changed, or a paid integration with one specific marketplace. None of these scaled because the underlying problem was that merchants and agents had no shared protocol for the transaction itself.

ACP is the shared protocol. The launch in April 2026 was Stripe co-publishing the spec with OpenAI and Meta as initial implementers. The architecture is OAuth-shaped: the user delegates a scoped capability to the agent (a Shared Payment Token) for a specific purchase or session, and the merchant accepts the token through the same Payment Intent API merchants already use. The merchant does not need a new payment integration. What the merchant needs is a way for the agent to discover, compare, request, and receive proof of purchase without the agent having to read HTML pages designed for humans.

This is why the work is not “add Stripe Link” (you may already have Stripe Link). The work is the four surfaces around the payment that make the agent’s path to a successful purchase short, deterministic, and idempotent.

The Four Surfaces

Every ACP-ready site exposes four surfaces. Together they let an agent complete a purchase in a single coordinated flow. Missing any one of them forces the agent to fall back to scraping or to skip the merchant entirely.

Surface 1: The Agent-Receivable Endpoint

The first surface is a structured catalog endpoint. The agent needs to know what you sell, what each item costs, what variants exist, what fulfillment looks like, and which jurisdictions you serve. None of this can be reliably extracted from product page HTML at agent scale. The pattern is a JSON endpoint at a stable well-known path, returning your catalog in a structured shape:

GET /.well-known/products
{
  "merchant": {
    "name": "Acme",
    "id": "acme_co",
    "jurisdiction": ["US", "CA", "EU"],
    "currency": "USD"
  },
  "products": [
    {
      "id": "prod_widget_v3",
      "sku": "WIDGET-V3-LG-BLU",
      "title": "Widget v3, Large, Blue",
      "description": "Description here, written for humans, parsed by agents.",
      "price_cents": 4900,
      "currency": "USD",
      "available": true,
      "fulfillment_eta_days": 3,
      "image_url": "https://acme.com/images/widget-v3.webp",
      "variants": [...]
    }
  ],
  "next_cursor": "eyJzdGFydCI6MTAwfQ"
}

Two implementation notes that matter. First, paginate with cursors, not page numbers; agents may pull catalogs in chunks during comparison and cursor-based pagination survives concurrent inventory changes. Second, expose the same data in JSON-LD on the corresponding human pages so search engines, LLMs training their corpora, and agents-without-ACP-support all see consistent semantics. Schema.org Product markup is the long-standing pattern; the JSON endpoint is the agent-specific addition.

Surface 2: Shared Payment Token Acceptance

The second surface is the modification to your Payment Intent creation code that accepts a Shared Payment Token. The token is a string the agent passes you. Your code passes the token to Stripe via the payment_method_options.shared_token field on the Payment Intent. Stripe validates the token against the user’s authorized scope (amount range, merchant id, time window) and, if valid, processes the payment.

intent = stripe.PaymentIntent.create(
    amount=4900,
    currency="usd",
    payment_method_types=["card"],
    payment_method_options={
        "shared_token": agent_supplied_token,
    },
    metadata={
        "agent_id": agent_id,
        "agent_session": session_id,
    },
)

The most common failure mode here is not adding the field. It is your existing Payment Intent code stripping unfamiliar metadata. Many internal libraries that wrap Stripe whitelist known fields and silently drop the rest. The Shared Payment Token then never reaches Stripe. The Payment Intent confirms but the user is charged via their default payment method instead of the agent-authorized scope, which violates the spec and breaks the audit trail. The fix is a one-line change in the wrapper. The diagnostic is that the Payment Intent’s payment_method field shows the user’s default card instead of the agent-token-derived method.

Surface 3: The Structured Receipt Response

The third surface is what your code returns after the Payment Intent succeeds. The default Stripe webhook gives you the data you need to construct the receipt. What ACP requires is that you send a JSON receipt back to the agent (synchronously, in the response to the Payment Intent confirmation, or asynchronously, via a webhook to an agent-supplied URL). The receipt has a standard shape:

{
  "order_id": "ord_01HXK9F2",
  "items": [{"id": "prod_widget_v3", "quantity": 1, "unit_price_cents": 4900}],
  "subtotal_cents": 4900,
  "tax_cents": 392,
  "total_cents": 5292,
  "currency": "USD",
  "ts": "2026-06-15T14:33:21Z",
  "fulfillment_eta": "2026-06-18",
  "signature": "sha256-hmac-base64=..."
}

The signature is an HMAC over the canonical-JSON body using a key the agent can verify against your published JWKS at /.well-known/jwks.json. Without the signature the agent cannot prove to the user that the receipt is real. With it, the agent can pass the receipt back as proof of purchase and the user can independently verify the signature. This is the same pattern citability.dev uses for AI citation receipts: signed, verifiable, replayable.

Surface 4: The Scoped Audit Trail

The fourth surface is for the user, not the agent. Users who delegate purchasing capability to agents need a way to audit what the agents have purchased on their behalf. The pattern is a /agent-activity endpoint scoped to the user’s account that lists agent-driven transactions with the agent identifier, the token scope, the timestamp, and the outcome.

This endpoint is what makes agent commerce trust-feasible at scale. Without it, users have no way to detect a misbehaving agent or a compromised token. With it, users can spot the misuse, revoke the token, and request a chargeback. The audit trail is also where you log the agent’s identifier (most agents will identify themselves; some will not, and the spec allows merchants to refuse anonymous agents). The handful of merchants that refuse anonymous agents become the trusted-by-default destinations for agent-driven traffic, which is a competitive moat that compounds.

Why Are Most Sites Not ACP-Ready?

The ACP launch is recent (April 2026). The implementation cost is low (the four surfaces total perhaps a thousand lines of code on a well-built site). But the architectural shift is real. Most sites’ product data lives in proprietary CMSes that do not expose JSON endpoints. Most sites’ Stripe integrations strip unknown fields. Most sites have no concept of an agent identifier in their analytics. The gap between “we have Stripe” and “we can accept ACP transactions” is the gap between checkout-as-form-submission and checkout-as-API.

There is a category of competitor that figured this out earlier (Shopify shipped ACP-compatible storefronts in beta in March 2026; some headless commerce platforms are ACP-native). For sites built on those platforms, ACP readiness is a configuration toggle. For sites built on traditional CMSes or custom monoliths, ACP readiness is an engineering project that is small in absolute terms but politically larger because it requires the team to think of itself as an API provider, not a website.

The shift in framing is the load-bearing change. A site that thinks of itself as an API provider exposes machine-readable surfaces by default and treats human-readable HTML as one rendering of the underlying data. A site that thinks of itself as a website renders HTML and adds JSON endpoints reluctantly when forced. ACP makes the second framing structurally uncompetitive in the agent-driven traffic segment.

What Should You Audit Before You Ship?

Before you go live with ACP, run through the diagnostic in the HowTo above. Stripe’s reference agent will catch most spec violations. The questions the reference agent does not catch are about your specific catalog: are prices accurate against your inventory system, are variants exposed completely, do you have a fulfillment-eta calculation that survives the agent asking for fifty items at once, can your Payment Intent code handle a token request that arrives 28 minutes after the user authorized it (the spec allows up to 30).

For the broader agent-readiness audit (the ACP surfaces are one of six modules in the Agent Readiness framework, alongside WebMCP setup, llms.txt structure, schema completeness, and the action-callable-tool inventory), citability.dev runs a free agent-readiness scan that produces the per-module remediation list with specific code-path references. Start at citability.dev/assess for the scan. The scan output includes the same calibration receipt format described in The 0% ChatGPT Citation Trap, so the numbers in the report are verifiable.

The window of opportunity is wider than it looks. ACP launched in April 2026 but the long tail of merchants migrating will run through 2027. The first cohort to ship ACP-compatible surfaces is positioning itself as the agent-preferred destination in their categories. The second cohort will ship in response to losing share. The third will ship after a customer publicly complains. Decide which cohort the team wants to be in before agents become a meaningful share of the traffic, not after.