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, plus the rail's native challenge in _meta; the client retries with _payment set to the base64 x402 payload, or with the rail's own _meta proof. The adapter normalises into a CanonicalRequest and maps payment carriers, but never verifies or settles a payment. MCP 2026-07-28 is served natively; 2025-era clients that send initialize still work.

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. An agent that speaks the x402 extension can instead pay inside the same task.

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 accepts A2A-Version: 1.0 in a header or, when the header is absent, a query parameter. A request carries one message with one data part, { resource, input }, with _payment inside the input. Without the x402 extension, the gateway returns a terminal task: TASK_STATE_COMPLETED with a response artifact or TASK_STATE_FAILED with a payment or error envelope. The x402 extension instead holds an unpaid call in TASK_STATE_INPUT_REQUIRED for payment through task metadata. Requests A2A cannot serve get its JSON-RPC error codes.

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 deployment, endpoint path and key, never by bearer token. Bodies are validated against the vendored schema in both directions; payment_data reaches the merchant unchanged and is never turned into an x402 payment. A fixed set of caller headers, such as Request-Id and Signature, is forwarded to the merchant; the bearer token never is.

When an agent requests a paid resource, the gateway answers “402 Payment Required” with the amount, token and destination wallet. The agent signs a payment for those terms and retries with the proof. Funds move directly from the buyer to you; the gateway cannot redirect them. You can offer the same price on several networks, such as Base, Polygon and Solana, and the agent chooses one.

Scheme exact on EVM via EIP-3009 transferWithAuthorization or, per offer, Permit2; on Solana via a token transfer whose fee the facilitator pays; and on NEAR, still partial, via a NEP-366 delegate holding one ft_transfer. EVM requirements name the method in extra.assetTransferMethod, and EIP-3009 also pins the token's EIP-712 domain. verify checks scheme, signature, recipient, amount, validity window, balance, network and asset without moving funds, and refuses a proof whose accepted terms differ from the offer; with several offers, that echo selects the one being paid. A replayKey derived from the authorization ((chainId, asset, payer, nonce) for EIP-3009, the Permit2 owner and nonce, the Solana message hash or the NEAR access-key nonce) is reserved under a UNIQUE constraint. The default paymentFlow: authorization calls the backend before settlement; upfront settles first. The facilitator broadcasts the transfer, and its transaction hash, or signature on Solana, becomes the receipt's settlement reference. x402 v1 is refused.

MPP is a second way for an agent to pay, from the standard Tempo and Stripe published for machine payments. The shape is the one you already know from x402: the gateway names the price, the agent authorises exactly that amount to exactly your wallet, and the request goes through. Choose a rail for each resource. Both pay directly to a wallet you control, with the same pricing and receipts.

[email protected], intent charge on method evm with EIP-3009 transferWithAuthorization, USDC on Base Sepolia and Base, or a local token on eip155:31337. It settles through an x402 facilitator and derives the same replay key as x402, so one authorization cannot be spent through both rails, and its receipts share the same store. The challenge names the canonical Permit2 address in methodDetails.permit2Address, following the draft-evm-charge-00 format. Unlike x402, it settles before the backend runs by default (paymentFlow: upfront): the charge intent counts a backend call before payment as partial access. A resource lists the rails it accepts — payments: [x402, mpp] — and the first enabled one serves the request. Off by default: doctor reports INFO Payments (MPP) MPP not configured until a rail is configured.

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 in AP2's Trusted Agent Provider shape, with the mandate inside delegate_payload, 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, and the destination, network and asset of the offer being paid. 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 the receipt database.