Get started
Introduction
A self-hosted, non-custodial gateway that makes your existing API discoverable, callable and payable by AI agents.
You already have an HTTP API. AI agents want to discover it, call it and pay for it — over protocols you did not write and do not want to maintain. Agent Commerce Gateway sits in front of your existing API, in your infrastructure, and does that for you.
You describe an endpoint in a YAML file — or generate that description from an OpenAPI document you already have — and agents get an MCP tool and an x402 paywall. Switch on the experimental adapters and the same resource is also an A2A skill, or a dedicated resource serves an ACP checkout operation. A paid resource can take experimental MPP instead of x402, and can also require an AP2 mandate proving the buyer approved the purchase. The money goes straight to your wallet: the gateway needs neither the buyer's nor your private key.
Your existing API → Agent Commerce Gateway → AI Agent
MCP · A2A · ACP · x402 · MPP · AP2 · receipts · doctorStart here
config.yaml and every rule the loader enforces.API referenceThe HTTP surface: invoke, discovery, receipts, events, MCP, A2A and ACP.What you get
requestId.How it works
Agents talk to the gateway over the protocol they speak. Every adapter translates the call into one canonical request and hands it to the same pipeline, which resolves the resource, validates input, enforces payment, calls your backend and writes a receipt.
┌─────────────────────────────────────────────────────────────┐
│ AI Agent │
└──────────────────────────────┬──────────────────────────────┘
│ MCP · A2A · ACP · HTTP
│ payment proof · Agent-Authorization
┌──────────────────────────────▼──────────────────────────────┐
│ Agent Commerce Gateway (yours) │
│ │
│ protocol adapters → ExecutionPipeline │
│ │ │
│ ┌──────────────┬─────────────────┼──────────────┐ │
│ ▼ ▼ ▼ ▼ │
│ Authorization Payment Backend Receipt │
│ Provider (ap2) Provider Executor Store │
│ (x402, mpp) (bounded HTTP) (SQLite) │
└──────────────────────────────┬──────────────────────────────┘
│
┌──────────▼─────────┐
│ Your backend API │
└────────────────────┘Read Architecture for the model and Payment flow for the paid round trip.
Protocol status
| Protocol | Status | Pinned revision |
|---|---|---|
| HTTP | Supported | native routes |
| MCP | Supported | 2026-07-28 and 2025-11-25, @modelcontextprotocol/[email protected] |
| x402 | Supported | x402 v2, scheme exact, EVM and Solana; NEAR partial |
| MPP | Experimental | [email protected], charge + evm + EIP-3009, USDC on Base Sepolia and Base |
| A2A | Experimental | A2A v1.0.1, JSONRPC, SendMessage, x402 extension |
| ACP | Experimental | ACP 2026-04-17, REST checkout + discovery |
| AP2 | Experimental | AP2 v0.2.0, Direct Checkout Mandate verification |
| ERC-8409 | Experimental | draft SergeevDmitry/ERCs@0ee33230: signed quotes on x402 EVM offers |
| UCP | Planned | no implementation |
supportedSpec, capabilities and unsupported list at runtime through GET /.well-known/agent-commerce, and agent-commerce doctor prints the unsupported lists for A2A, ACP and AP2 when they are enabled, so the claim is checkable.x402 supports Base, Base Sepolia and the other built-in EVM networks, Solana and, partially, NEAR, each in its own USDC, and a resource can offer several of them at once. See Networks & facilitators.
agent-commerce import openapi, PaymentProvider.reconcile, the ReceiptStore methods and types added in 2.6.0, and ./testing. Since 2.6.0, the journal's Transaction type, journal store methods and /api/transactions response are supported, alongside transactionId, receiptCommitted and the reconcile/resolve flags. Pin an exact version and test experimental integrations before upgrading.Project facts
| Package | @devlab.group/agent-commerce |
| Runtime | Node.js ≥ 22, npm ≥ 10 |
| Language | TypeScript, strict |
| Storage | SQLite (receipts, events, payment attempts, transaction journal, AP2 holds, ACP claims, A2A pending tasks) |
| License | Apache-2.0 |
| Source | github.com/devlab-group/agent-commerce |