Every protocol, explained twice.

Think of the gateway as a shop front with several doors. HTTP, MCP, A2A and ACP are the doors — different ways for an agent to walk in and ask for something. Whichever door it uses, the same cashier handles the sale: x402 is how the agent pays, and AP2, when you ask for it, is the signed note proving a human approved the purchase. Your backend stays behind the counter and never has to learn any of these protocols.

HTTP, MCP, A2A and ACP are protocol adapters: each translates its wire format into one CanonicalRequest and hands it to the ExecutionPipeline, which never knows which adapter called it. x402 is a PaymentProvider that creates the requirement, verifies the proof and settles; AP2 is an AuthorizationProvider that runs between payment verification and settlement. No adapter contains payment logic or calls the backend, so every rule applies identically on every surface. ACP is the exception on payment: its checkout resources are free at the gateway layer, because the purchase is paid through the merchant's own checkout.

MCP is the standard way AI assistants find and use tools. The gateway lists each of your endpoints as a tool, with its price written in the description, so the assistant knows what it costs before it asks. When it calls a paid tool, it first gets the bill instead of the result — it pays, then calls the same tool again with the payment attached.

Resources with expose: [mcp] are served as MCP tools over Streamable HTTP at protocols.mcp.mountPath (default /mcp). Tool name = resource id, inputSchema = the canonical input schema; a paid tool gains an optional _payment string and its price in the description. An unpaid tools/call returns isError: true with a PaymentRequiredEnvelope in structuredContent; the client retries with _payment set to the base64 x402 payload. The adapter normalises into a CanonicalRequest and holds no payment logic of its own.

The most ordinary way in: a normal web request. Anything that can call a URL — a script, a backend, an agent framework — can use your resources without learning an agent protocol. A free resource just answers. A paid one first answers “payment required” with the price, and the caller repeats the same request with the payment in a header.

Every resource exposed with http is invocable at POST /api/resources/{id}/invoke; the JSON body is the input, validated against the resource's closed schema. An unpaid call to a paid resource returns 402 with a PaymentRequiredEnvelope body and the x402 v2 PaymentRequired document base64-encoded in PAYMENT-REQUIRED. The retry carries the proof in PAYMENT-SIGNATURE (and an AP2 envelope in Agent-Authorization where required); the backend's status and body are relayed with a base64 PAYMENT-RESPONSE summary.

A2A is how agents work with other agents. The gateway introduces itself with a public business card — the Agent Card — listing what it can do; each of your resources is one “skill” on it. Another agent sends a single message naming the skill and the input, and gets back a finished task: either the result, or a bill to pay first.

The Agent Card at GET /.well-known/agent-card.json lists every expose: [a2a] resource as an AgentSkill (skill id = resource id; paid skills tagged paid). JSON-RPC 2.0 SendMessage is served at protocols.a2a.mountPath (default /a2a) and requires A2A-Version: 1.0. A request carries one message with one data part, { resource, input }, with _payment inside the input. Every outcome is a terminal task — TASK_STATE_COMPLETED with the response as an artifact, or TASK_STATE_FAILED carrying the payment or error envelope. JSON-RPC errors are reserved for requests malformed or unsupported as A2A.

ACP is a standard checkout for agents: open a checkout, change it, look at it, complete the purchase or cancel it. The gateway speaks that standard to agents and passes each step to the checkout you already run. The buyer pays through your own checkout — the gateway does not take a second payment for these calls.

Five operations — create, update, get, complete and cancel CheckoutSession — under /acp/checkout_sessions, each mapped in protocols.acp.checkout.operations to one free resource with expose: [acp]. Every checkout route requires Authorization: Bearer and API-Version: 2026-04-17; every POST requires an Idempotency-Key, durable for at least 24 hours and scoped by token digest, path and key. Bodies are validated against the vendored schema in both directions; payment_data reaches the merchant unchanged and is never turned into an x402 payment.

x402 puts the web's long-unused “402 Payment Required” answer to work. When an agent asks for something paid, the gateway replies with a price tag: how much, in which token, to which wallet. The agent signs a permission slip for exactly that amount to exactly your wallet and sends the request again with the slip attached. The money goes from the buyer straight to you — the gateway can check the slip, but it cannot redirect it.

Scheme exact on EVM via EIP-3009 transferWithAuthorization. The provider builds x402 v2 PaymentRequirements with extra: { name, version, assetTransferMethod } to pin the EIP-712 domain. verify checks scheme, signature, recipient, amount, validity window, balance, network and asset without moving funds; a replayKey derived from (chainId, asset, payer, nonce) is reserved under a UNIQUE constraint before settle; the facilitator broadcasts, and the transaction hash becomes the receipt's settlement reference.

AP2 answers a different question: did a person actually approve this purchase? Before the payment goes through, the agent shows a signed note from the buyer's side saying “yes — buy exactly this, at this price, from this shop”. The gateway checks the signature and that the note matches the purchase, and each note works only once. It never pays for anything by itself: the payment still has to happen.

A closed Checkout Mandate (vct: mandate.checkout.1) presented as an SD-JWT, ES256 over P-256, signed by an issuer and key listed statically in authorization.ap2.trust. It binds a merchant-signed checkout JWT whose agent-commerce/ap2/checkout/v1 claims must match the resolved resource, the RFC 8785 input hash, the amount as a string, currency, method, destination, network and asset. It is verified and reserved after payment verification and before settlement, and spendable once — keyed on the issuer-signed token and the checkout jti in its own SQLite store.