MCPA2AACPx402AP2UCPMPP

Your API. Their agents.
Every transaction controlled.

Name: Agent Commerce Gateway
Author: DevLab

Agent Commerce Gateway turns your existing API into a service agents can request and pay for — while your backend, pricing and settlement controls stay yours.

Get started View on GitHub

v1.4.04,386 DownloadsUpdated 6 days ago

01Request receivedExample flow · sample data

The agent requests a paid capability. The Gateway resolves the resource, validates the input and locks the configured price.

Scout Analytics → company.enrich1 / 6

Commerce Activity 6

Every request. Every payment. Every outcome.

Sep 16, 2026

Settled volume0.660 USDC

Delivered3 / 6

Paid · not delivered1

Settlement uncertain0

Category	Channel	Amount	Outcome	Time
Business	HTTP	0.080 USDC	Received	now
Finance	MCP	0.250 USDC	Delivered	14:30:58
Language	MCP	0.040 USDC	Delivered	14:30:35
Media	HTTP	0.020 USDC	Delivered	14:30:04
Business	MCP	0.060 USDC	Replay blocked	14:29:58
Research	HTTP	0.350 USDC	Paid · not delivered	14:29:12

Demo outcome

Demo · Base Sepolia · x402 v2

START WITH WHAT YOU ALREADY HAVE

What can an agent buy
from your business?

Start with one capability your business already provides. Make it discoverable, callable and payable by agents without rebuilding the service behind it.

Data

The insight you already have.

Market intelligence
Company enrichment
Proprietary datasets

Example purchaseA market report

The requested dataset, ready to use.

Pricing unitper result

APIs

The service you already run.

Search & verification
Document processing
Business intelligence

Example purchaseA verified company profile

Structured data returned by your API.

Pricing unitper request

Compute

The work your systems can do.

Model inference
Image transformations
Bounded calculations

Example purchaseA transformed image

The output of a completed compute job.

Pricing unitper execution

Transactions

The action your business enables.

Availability checks
Quotes & reservations
Checkout capabilities

Example purchaseA reservation quote

Availability and terms for a booking.

Pricing unitper operation

ONE INTEGRATION

One integration.
Many agent channels.

Connect your backend once and keep that integration stable. New agent channels can plug into the same commerce layer as the ecosystem changes around it.

Commerce Gateway

Same resource. Same commercial rules.

PriceProtectReceipt

Your existing APIcompany.enrichOne backend integration

MCP x402

An MCP tool call becomes a canonical request. Your business logic stays in the backend you already run.

AP2 policy

ONE COMMERCE CORE

One commerce core.
Every channel.

Different channels can enter in different ways. Pricing, authorization, payment, execution and receipts still follow the same transaction rules on each.

Validated against resource schema

A request your backend can trust.

Resolve the resource, check channel exposure and validate the input before any business action.

WHY IT MATTERS

Malformed input and requests for an unpublished capability stop at the edge. Your backend receives a canonical request only after these checks pass.

STEP OUTPUTCanonical request

A schema-valid resource call is ready for pricing.

request / req_demo_001Illustrative

{
  "request_id": "req_demo_001",
  "channel": "MCP",
  "resource": "company.enrich",
  "input": {
    "company": "Acme",
    "region": "EU"
  },
  "schema": "company.lookup.v1",
  "channel_exposure": "allowed",
  "validation": "passed",
  "backend_invoked": false
}

0.080 USDC · merchant configured

Your price. Resolved up front.

Use the merchant-configured price to establish what this request costs and which payment requirement applies.

WHY IT MATTERS

The agent does not choose the amount. The quote comes from your resource configuration and carries the asset and payment destination that later proof must match.

STEP OUTPUTMerchant quote

Amount, asset and destination are fixed for this request.

request / req_demo_001Illustrative

{
  "request_id": "req_demo_001",
  "resource": "company.enrich",
  "pricing_model": "fixed_per_request",
  "quote": {
    "amount": "0.080",
    "asset": "USDC"
  },
  "payment_rail": "x402",
  "destination": "merchant_controlled",
  "payment_requirement": "issued",
  "backend_invoked": false
}

Checked when configured

Permission before payment.

Apply configured authorization policy where required. AP2 mandate checks are a policy extension, separate from the channel and the payment rail.

WHY IT MATTERS

Access rules stay independent of MCP, HTTP or any payment rail. When mandate checks are configured, the audit trail keeps a reference rather than the raw credential.

STEP OUTPUTPolicy decision

An allowed request can proceed to payment verification.

request / req_demo_001Illustrative

{
  "request_id": "req_demo_001",
  "resource": "company.enrich",
  "policy": "merchant_configured",
  "principal": "agent_demo_01",
  "decision": "allowed",
  "ap2_mandate": "reference_only",
  "raw_credentials_stored": false,
  "payment_status": "pending"
}

Verified · funds unchanged

Check the proof. Don’t move the money.

Verify that the payment proof matches the amount, recipient, asset and network. Verification has no settlement effect.

WHY IT MATTERS

A valid-looking proof is not enough: it must match this exact quote. This step confirms the evidence only; funds stay where they are and your API remains idle.

STEP OUTPUTVerified proof

Matched evidence moves to replay protection; funds stay put.

request / req_demo_001Illustrative

{
  "request_id": "req_demo_001",
  "payment_rail": "x402",
  "proof": "verified",
  "amount": "0.080 USDC",
  "recipient": "merchant_destination",
  "network": "matched",
  "settlement": "not_started",
  "backend_invoked": false
}

Reserved before settlement

One authorization. One delivery.

Durably reserve the verified authorization against replay. A duplicate or a storage failure stops the request before settlement.

WHY IT MATTERS

The Gateway reserves a provider-derived identity before any charge. If it has been used already, the same authorization cannot trigger a second settlement or delivery.

STEP OUTPUTReserved authorization

The payment identity is locked against a second use.

request / req_demo_001Illustrative

{
  "request_id": "req_demo_001",
  "proof": "verified",
  "replay_identity": "provider_derived",
  "reservation": "confirmed",
  "duplicate_request": false,
  "storage_result": "durable",
  "settlement": "not_started",
  "backend_invoked": false
}

Confirmed · 0.080 USDC

Confirm payment before execution.

For the direct-payment flow, settle to the merchant-controlled destination and retain the external transaction reference.

WHY IT MATTERS

The external payment rail remains the financial source of truth. If confirmation is uncertain, execution waits while the payment result is reconciled.

STEP OUTPUTSettlement reference

Confirmed payment unlocks merchant-side execution.

request / req_demo_001Illustrative

{
  "request_id": "req_demo_001",
  "payment_rail": "x402",
  "settlement": "confirmed",
  "amount": "0.080 USDC",
  "destination": "merchant_controlled",
  "external_ref": "0x91e...42c",
  "source_of_truth": "payment_rail",
  "backend_invoked": false
}

200 OK · 239 ms

Your backend does the actual work.

Invoke the existing merchant backend within bounded time and response limits. A successful payment alone does not mean successful delivery.

WHY IT MATTERS

A backend timeout after settlement is a paid but undelivered transaction, not a failed payment. Keeping those facts separate makes recovery possible.

STEP OUTPUTBusiness result

The execution and delivery outcome moves into the receipt.

request / req_demo_001Illustrative

{
  "request_id": "req_demo_001",
  "settlement": "confirmed",
  "handler": "company.enrich",
  "backend_status": 200,
  "duration_ms": 239,
  "execution": "succeeded",
  "delivery": "company_profile",
  "response_body_stored": false
}

Delivered · receipt recorded

One request. An explainable outcome.

Record payment, execution and delivery summaries together. Keep secrets and full response bodies out of the audit record.

WHY IT MATTERS

The receipt links the request, external payment reference and delivery result. It provides an audit trail without storing credentials or the full business response.

STEP OUTPUTCorrelated audit record

The transaction can be explained without stored secrets.

request / req_demo_001Illustrative

{
  "receipt_id": "rcpt_demo_001",
  "request_id": "req_demo_001",
  "payment": "settled",
  "settlement_ref": "0x91e...42c",
  "backend_status": 200,
  "delivery": "confirmed",
  "outcome": "delivered",
  "secrets_stored": false
}

For a paid resource: proof verified → replay reserved → settlement confirmed → backend invoked.

KEEP PROTOCOLS AT THE EDGE

Why wire protocols
into your backend?

A direct integration rarely stays small. Each new protocol can bring request mapping, payment logic, replay rules, state and tests into your application.

A new protocol arrives. Add an illustrative UCP adapter (planned) and see what changes on each side.

Direct integration

One new protocol touches the application.

Merchant applicationyour codebase

MCPcoreACPexperimentalx402core+ UCPplanned

Protocol routingadapter logic

Request mappingschema

Authorization mappingpolicy

Payment handlingrail logic

Replay protectionstate

Transaction statelifecycle

Error mappingtransport

Receipts & auditoutput

ConfigTestsDocsDeploymentMonitoring

New protocol → changes across the application boundary

Routing is only the first change. Request mapping, payment handling, replay rules, state, errors, receipts and operations all become part of the app.

Gateway architecture

Add one adapter. Keep the backend.

Agent Commerce Gatewaycommerce edge

MCPcoreACPexperimentalx402core+ UCPplanned

Payment enforcementTransaction stateReplay protectionReceiptsAuthorizationError outcomes

Existing backend

Your business logic

unchanged

New protocol → one adapter at the edge

The adapter maps the protocol to the same capability contract. The commerce core and the merchant backend keep the same responsibilities.

OPERATIONAL READINESS

Know if the Gateway
is actually ready.

Check the deployment before paid traffic reaches it. One command verifies configuration, backend reachability, protocols, payments, storage and live runtime state.

$ agent-commerce doctor

human-readable resultIllustrative

passConfiguration valid3 resources · 2 protocol surfaces

passGateway healthy127.0.0.1:8402

passGateway ready

passMerchant backend reachablecompany.enrich

passProtocol surfaces enablednative HTTP · MCP

passProtocol descriptors consistent

passx402 configuredbase-sepolia · USDC

passSettlement destination validmerchant-controlled

passFacilitator reachable

passStorage healthyschema current · writes ok

infoA2A experimental

infoMPP planned

10 / 10 required checks passedReady · exit 0

WHAT IT CHECKS

ConfigurationRequired sections, resources and the effective deployment
Gateway healthReachable, healthy and reporting itself ready
Merchant backendThe service behind the Gateway actually answers
Protocol exposureEnabled, experimental, planned or unavailable
Protocol descriptorsRevision and capability profile the runtime advertises
Payment railsNetwork, asset and provider status
Settlement destinationWhere funds are expected to land
FacilitatorRemote payment dependency is reachable
StorageSchema, writes, replay reservations and events
ReceiptsOperational records can be read back
Runtime vs configLive Gateway reports what the local file claims

A failed required check exits non-zero, so the same diagnostic contract can gate a deployment instead of a first failed agent transaction.

Initial setupBefore a demoBefore testnet trafficAfter a config changeTroubleshootingCI/CD

The backend result was delivered after confirmed settlement. A compact receipt links the request, external payment reference and delivery outcome without storing secrets or full response bodies.

Gateway response

Return the result and make the transaction explainable later.

RUN IT YOUR WAY

Open source.
Choose how you run it.

Inspect the architecture, tests and transaction flow before you deploy. Run the Gateway in your own environment or work with DEVLAB on the operational side.

YOUR ENVIRONMENT

Self-hosted

Run the gateway alongside your existing API, with infrastructure and configuration under your control.

Deploy in your infrastructure
Control configuration and operational data
Control your settlement destination

npx @devlab.group/agent-commerce --help

Explore on GitHub

WITH OUR TEAM

Managed by DEVLAB

A managed deployment and integration service. DEVLAB helps your team deploy, configure and run the gateway around your existing business.

Backend integration and configuration
Deployment in an agreed environment
Operations and support, scoped with your team

Discuss requirements, availability and support with us.

Talk about managed deployment

Source code Architecture Quickstart Examples

THE ECOSYSTEM IS MOVING

Agent commerce is
being built now.

Protocols, authorization models and payment rails keep evolving. Absorb those changes in one integration layer instead of rebuilding your backend each time.

GoogleProtocol · Authorization

A2A · AP2

OpenAICommerce standard

ACP

StripeCommerce standard · Payment rail

ACP · MPP

CoinbasePayment rail

x402

CloudflareProtocol infrastructure

x402 Foundation

TempoPayment rail

MPP

SOFTWARE ARCHITECTURE

Every decision,
written down.

See the system boundaries, runtime model, security assumptions and delivery decisions in one place.

The architecture document shows how the Gateway is designed to work before you trust it with transactions.

Why every protocol goes through one pipeline
The system as C4 diagrams
Quality attributes, SLOs and a STRIDE threat model
How it deploys, recovers and stays compliant

Read the architecture PDF · v1.3 · 34 pages

AGENT COMMERCE GATEWAY

Build the layer before
the channel arrives.

Start with one real capability you already operate. Keep your backend, pricing and settlement under your control while the agent ecosystem grows around it.

View on GitHub

Architecture and development by DevLab.group

Your API. Their agents.Every transaction controlled.

Commerce Activity 6

What can an agent buyfrom your business?

Data

APIs

Compute

Transactions

One integration.Many agent channels.

One commerce core.Every channel.

A request your backend can trust.

Why wire protocolsinto your backend?

One new protocol touches the application.

Add one adapter. Keep the backend.

Existing backend

Know if the Gatewayis actually ready.

Built for the casesthat don’t go well.

Unknown is its own payment state.

Open source.Choose how you run it.

Self-hosted

Managed by DEVLAB

Agent commerce isbeing built now.

Every decision,written down.

Build the layer beforethe channel arrives.

Your API. Their agents.
Every transaction controlled.

What can an agent buy
from your business?

One integration.
Many agent channels.

One commerce core.
Every channel.

Why wire protocols
into your backend?

Know if the Gateway
is actually ready.

Built for the cases
that don’t go well.

Open source.
Choose how you run it.

Agent commerce is
being built now.

Every decision,
written down.

Build the layer before
the channel arrives.