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 an ACP checkout session. The money goes straight to your wallet: the gateway never holds it, and never holds your keys.

text
Your existing API  →  Agent Commerce Gateway  →  AI Agent
       MCP · A2A · ACP · x402 · AP2 · receipts · doctor

Start here

What you get

One pipelineEvery protocol converges on one execution pipeline, so payment enforcement is a property of the system, not of each adapter.
Non-custodialThe buyer pays your payTo address directly on chain. No funds or keys pass through the gateway.
Fail closedMissing, malformed, expired, replayed or wrong-amount payments never deliver a resource.
ReceiptsEvery request, payment attempt and delivery is recorded in SQLite under one requestId.
DoctorOne command checks config, gateway, backend, protocols, payments and storage.
OpenAPI importGenerate reviewable resource definitions from the API description you already have.

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.

text
┌─────────────────────────────────────────────────────────────┐
│                          AI Agent                           │
└──────────────────────────────┬──────────────────────────────┘
                               │  MCP · A2A · ACP · HTTP
                               │  PAYMENT-SIGNATURE · Agent-Authorization
┌──────────────────────────────▼──────────────────────────────┐
│               Agent Commerce Gateway (yours)                │
│                                                             │
│          protocol adapters  →  ExecutionPipeline            │
│                                       │                     │
│      ┌──────────────┬─────────────────┼──────────────┐      │
│      ▼              ▼                 ▼              ▼      │
│  Authorization   Payment          Backend         Receipt   │
│  Provider (ap2)  Provider (x402)  Executor        Store     │
└──────────────────────────────┬──────────────────────────────┘
                               │
                    ┌──────────▼─────────┐
                    │  Your backend API  │
                    └────────────────────┘

Read Architecture for the model and Payment flow for the paid round trip.

Protocol status

ProtocolStatusPinned revision
MCPSupported@modelcontextprotocol/[email protected]
x402Supportedx402 v2, scheme exact, EVM
HTTPSupportednative routes
A2AExperimentalA2A v1.0.0, JSONRPC, SendMessage
ACPExperimentalACP 2026-04-17, REST checkout + discovery
AP2ExperimentalAP2 v0.2.0, Direct Checkout Mandate verification
UCP · MPPPlanned
“Planned” means no code ships for it. Each adapter reports its own supportedSpec, capabilities and unsupported list at runtime through GET /.well-known/agent-commerce and agent-commerce doctor, so the claim is checkable.

Project facts

Package@devlab.group/agent-commerce
RuntimeNode.js ≥ 22, npm ≥ 10
LanguageTypeScript, strict
StorageSQLite (receipts, events, payment attempts)
LicenceApache-2.0
Sourcegithub.com/devlab-group/agent-commerce