Skip to content

PATTERN Cited by 1 source

Protocol-agnostic commerce layer

Intent

When a domain is serviced by multiple emerging protocols that are actively changing — new RFCs, new transport mechanisms, new competing specs — a seller who integrates directly with any one protocol risks a zombie integration: ship it for this quarter's spec, watch it go obsolete when the spec pivots, then have to rewrite.

This pattern inserts a vendor-owned commerce layer that presents a single stable API to the seller and implements every incoming protocol (and every version thereof) behind that facade. Seller integrates once, with the vendor layer; the vendor absorbs all protocol churn.

Canonicalised in the 2026-03-12 Stripe retrospective's framing of the Agentic Commerce Suite: "sellers can't afford to rebuild their stack every time a protocol changes. We built the Agentic Commerce Suite as a protocol-agnostic commerce layer that works across standards, including Google's UCP, so sellers don't have to bet their roadmap on any single spec... Integrate with Stripe once, and we'll keep you compatible across agents as protocols evolve."

Applicability

Applies when:

  • Multiple open protocols exist for the same transaction type (e.g. ACP + Google UCP
  • future standards for agentic-commerce checkout).
  • Protocols are evolving rapidly — ACP shipped four major releases in its first six months (payment handlers, scoped tokens, extensions, built-in buyer auth, native MCP transport).
  • The transacting party (the seller in this case) does not want to staff a team dedicated to tracking protocol changes.
  • A vendor exists with a commercial incentive to absorb the churn — in agentic commerce that's payment processors (ACP co-author Stripe) for whom keeping the seller on-platform is a strategic priority.

Shape

            ┌──────────────┐
  Agent A ──┤              │
  (ACP)     │   Vendor     │
            │   commerce   ├──── Seller's fulfilment +
  Agent B ──┤   layer      │     customer-management systems
  (UCP)     │              │
            │  (Stripe ACS)│
  Agent C ──┤              │
  (future)  │              │
            └──────────────┘
                   ▲
                   │ single integration point
                   │ seller's stable API

The vendor layer speaks:

  • Every incoming protocol at whichever version each agent is currently on.
  • A single seller-facing API that doesn't change as protocols churn underneath.
  • Cross-protocol primitives (SPT, ACP scoped tokens, UCP equivalents) translated into one internal representation.

Why the vendor absorbs churn, not the seller

The layer depends on the vendor having (a) direct spec-level participation — in Stripe's case, ACP co-authorship with OpenAI; (b) commercial reach across the agent ecosystem — integrated with OpenAI and Google surfaces at payment layer regardless of protocol preference; and (c) ongoing engineering investment in keeping translations fresh, which is a shared cost across all sellers rather than a per-seller cost.

Seen in

Last updated · 476 distilled / 1,218 read