OPEN-SOURCE PROTOTYPE · SEEKING PARTNERS

The Payment Layer for the AI Agent Economy

AgentPay is a payment layer for AI agents, making it possible to integrate your agents, move money between them, and test real payment flows end to end.

AgentPay gives every AI agent a wallet, a cryptographic identity, and governed spending - so your platform can monetize every agent action, automatically.

Open API Explorer See the 3-call flow Share feedback

Active Agents

Transactions Processed

$13.25

Volume Settled

Payment Rails

<2ms

Auth Lookup

ACID guaranteed transactions

NUMERIC(20,8) - zero float drift

Ed25519 agent signing

100% idempotent API

MIT licensed · no lock-in

Built on 🐘 PostgreSQL 16 🔑 Ed25519 ⚙️ Node.js 20 🐟 Docker ⚛️ ACID Transactions 📋 Audit Log 🔁 Idempotent APIs ⚖️ Policy Engine

Wallet state Agent identity and balance stay in sync Managed wallets, signer state, and policy context travel together instead of living in separate systems. Identity + funds

Policy gate Every payment moves through one review surface Spend limits, velocity, and approval requirements are evaluated before any settlement path is chosen. Deterministic control

Rail orchestration Route the same request across multiple payment rails Internal, x402, ACH, card, and crypto routes share the same policy and audit envelope. One payment plane

Observability Receipts, ledger writes, and webhooks post as one event chain Operators can reason about payment effects without stitching multiple dashboards together. Event trace

Deployment fit Open source core, commercial integration path Partners can fork the stack, self-host the runtime, and still plug into a shared go-to-market motion. MIT + partner model

What AgentPay is

Connect your agents and move money between them

AgentPay gives developers one payment layer for agent identity, wallet state, policy checks, settlement routing, and receipts. Instead of stitching together separate systems, you integrate once and watch the full payment path in one place.

Register Create a wallet-backed agent identity and get the credentials needed for the next call.

Fund Load a sandbox wallet so the agent can make a payment under real balance and policy rules.

Pay Move money from one agent to another and inspect the ledger, receipt, and webhook effects.

Open API Explorer See payment flow

3 calls to first payment lightweight integration path

1POST /v1/agents {"name":"ResearchAI","operator":"acme"}

2POST /v1/wallets/:wallet_id/fund {"amount":1000,"source":"bank_transfer"}

3POST /v1/payments {"to_agent":"MarketDataAPI","amount":0.42,"rail":"x402"}

Result: the payer balance updates, the payee receives funds, the ledger posts the transaction, and a receipt event is ready for downstream systems.

Why agents need a payment layer

Agents can call tools.
They still need a way to pay.

Calling tools is easy. Paying another agent, buying an API, and returning a receipt with policy and audit controls is the missing part. AgentPay closes that gap with one runtime.

Every autonomous agent needs to purchase APIs, data, compute, and services. Today they can't. AgentPay is the missing financial layer — and it's open for partners to build on.

Buying patternAPIs · data · compute

Tool accessAgents need to pay for APIs, data, compute, and services at the exact moment a task runs.Runtime spend

Budget controlEach agent needs wallet state and policy checks available before funds move.Approval path

Receipt trailFinance and platform teams need ledger entries, receipts, and replay-safe audit history.Review ready

Agent-to-agent transferMoney needs to move from one agent to another without manual billing handoffs.A2A payment

Platform economicsPayment capability should create margin and control for the platform, not more glue code.Business layer

API

Pay for tool calls and data requests when the agent actually needs them.

Metered services

A2A

Move money between payer and payee agents inside the same governed payment flow.

Agent-to-agent transfers

Audit

Return receipts, webhooks, and ledger history without stitching extra systems around the payment.

Operator visibility

What AgentPay includes

Wallets, policy, settlement, and ledger in one runtime

Instead of stitching together wallet logic, approvals, rail routing, and receipts, AgentPay keeps the full payment path in one system.

Every payment request passes through a deterministic 7-stage pipeline. No shortcuts, no silent failures — every step is logged.

System posture

Pipeline7 ordered stages

State modelACID + append-only audit

Rail fit5 settlement targets

Request Pipeline

🤖

AI Agent

Ed25519 identity
Bearer token

→

🔒

Auth

API key lookup
partial index

→

✅

Validate

Joi schema
idempotency

→

⚖️

Policy Engine

spend limits
velocity · lists

→

⚛️

Atomic Tx

BEGIN · debit
credit · COMMIT

→

📋

Audit Log

immutable
timestamptz

→

🔔

Webhooks

HMAC-signed
event dispatch

Payment Rails

⚡ Internal - instant

🌐 x402 HTTP - instant

🏦 ACH - 1-3 days

💳 Card - 2 days

🔗 Crypto - minutes

Data Layer

PostgreSQL 16 · ACID · NUMERIC(20,8) · JSONB · TIMESTAMPTZ

Partial indexes · sparse unique idempotency index · pg Pool

Live API proof

Inspect a real read-only response

This calls the running server, not a mock. Use it to confirm the API surface before opening the full Explorer.

This isn't a mock - it's calling the real running server. Select a read-only endpoint, click Run, and inspect the actual JSON response.

Select an endpoint

Choose from health check, dashboard stats, or the public A2A agent card.

Click Run

Live fetch against this server - real data, real latency, no write side effects.

See the response

Full JSON with syntax highlighting. No mock, no fixture.

AgentPay Live Terminal

$ GET /health

Click Run to make a live request...

Full API Explorer →

How it works

How a payment moves through AgentPay

Every payment follows the same visible path from agent request to posted transaction. Pick a scenario and replay the flow.

Pick a scenario and watch the payment packet move through policy, across the selected rail, and into the audit and webhook side effects in real time.

Replay cues

RequestBudget + identity payload

DecisionAuto approval or hold

EffectsLedger + receipt dispatch

Request laneIdentity, amount, and payee context leave the calling agent as one packet.Step 1

Policy laneRules inspect budget, velocity, and allowlists before any funds are released.Step 2

Rail handoffApproved requests are stamped and routed across the selected settlement rail.Step 3

Balance effectWallet state updates alongside the transfer instead of after the fact.Step 4

Ops traceReceipts, webhooks, and audit events complete the same visible transaction story.Step 5

Cinematic replay

A four-act payment story inside the AgentPay runtime

The stage below keeps the same runtime anatomy as the explorer: origination, policy, settlement, and side effects. Switch scenarios to watch the system approve, hold, reroute, or block a payment without leaving the home page.

AgentPay / how a payment moves

ACT I

Origination

The agent drafts a payment instruction and signs it.

00:00 / 00:00

Act I - Origination

The agent signs a payment instruction

A terminal types the request, the packet folds into a signed envelope, and the payment story begins before a single rail is touched.

Act II - Policy

Three rules evaluate in parallel

Budget, velocity, and allowlist checks resolve in sequence. Depending on the scenario, policy approves, holds for review, or blocks the packet before any funds move.

Act III and IV - Settlement and effects

The selected rail carries the value stream while the stage keeps payer, payee, amount, and route visible.
Ledger writes, balance changes, and webhook dispatches happen as one transaction story instead of separate screenshots.
Fallback and deny scenarios stay explicit, so the runtime behavior is just as visible when money does not take the happy path.

Controls built into the system

Identity, policy, settlement, and audit stay connected

The trust story here is concrete: agent-scoped signing, atomic writes, replay-safe requests, and verifiable outbound events.

Every design decision prioritises correctness, auditability, and non-repudiation - the three things compliance teams ask for first.

Control themes

IdentityAgent-signed actions

StorageAtomic ledger mutation

ReviewReplay-safe event trail

🔑

Ed25519 Agent Identity

Every agent is issued a cryptographic keypair at registration. Payments are agent-signed. Identity is verifiable without a central registry - no shared secrets.

⚛️

ACID Transactions

Every payment is a PostgreSQL transaction: BEGIN → debit → credit → audit → COMMIT. Partial writes are impossible. Failures roll back cleanly.

📋

Immutable Audit Log

Every action - payment, refund, fund, policy evaluation - is appended to audit_log with timestamptz. Designed to meet SOC 2 and financial audit requirements.

🔁

Idempotency by Design

Sparse unique index on idempotency_key ensures retries never double-charge. Safe to retry at any layer of your stack without coordination.

⚖️

Policy Engine

Spend limits, velocity controls, blocklists, allowlists, and time restrictions evaluated before every payment. Rules stored as JSONB - extend without schema migrations.

🛡️

Webhook HMAC Signing

All outbound webhook payloads are HMAC-signed. Recipients can verify event authenticity without trusting the network - no replays, no spoofing.

⚡

Open source - fork it, audit it, own it

AgentPay is MIT licensed. No vendor lock-in, no proprietary black boxes, no usage-based licensing surprises. Read every line of code before you commit to anything. The commercial partnership is about velocity and revenue share - not holding your data hostage.

MIT License PostgreSQL 16 Node.js 20 No vendor lock-in Self-hostable Docker-ready

View on GitHub Try the API Live Dashboard

Repo surface

MIT-licensed payment runtime with self-hostable PostgreSQL core.
Browser explorer, dashboard, and transaction feed share the same live data plane.
Partners can audit the implementation before they decide how deeply to embed it.

From sandbox to production

Start with a seeded sandbox, then wire in your own flow

Start with a sandbox payment, move to a real agent-to-agent flow, then add policy, receipts, and deployment controls as your runtime hardens.

No lengthy onboarding and no proprietary SDK lock-in. The rollout path stays visible from first sandbox payment through deployment review.

Day 1

Sandbox access & first API call

Clone the repo, start Docker, run npm run seed. Two funded agents ready in under 5 minutes.

Week 1

First payment in your platform

Integrate agent registration and wallet funding into your onboarding flow. First real payment processed and logged.

Week 2

Policies & webhooks configured

Spend limits tuned to your use case. Webhooks firing to your dashboard. Audit log flowing to your data pipeline.

Week 4

Production deployment

Docker Compose or Kubernetes. PostgreSQL pool sized for your load. Revenue share flowing from day one.

Quick start

Three API calls to first payment

1. Register

2. Fund

3. Pay

# No auth needed — returns API key + wallet ID curl -X POST /v1/agents \ -H "Content-Type: application/json" \ -d '{"name":"TradingBot","operator":"acme"}' { "api_key": "pk_test_...", "wallet_id": "3ead9e4f-...", "trust_score": 50 }

# Fund from faucet, bank_transfer, or crypto curl -X POST /v1/wallets/WALLET_ID/fund \ -H "Authorization: Bearer pk_test_..." \ -d '{"amount":1000,"source":"bank_transfer"}' { "new_balance": 1000.00, "wallet_id": "3ead9e4f-..." }

# Policy engine runs automatically — ACID guaranteed curl -X POST /v1/payments \ -H "Authorization: Bearer pk_test_..." \ -d '{ "from_wallet_id": "3ead9e4f-...", "to_external": "[email protected]", "amount": 25.00, "rail": "x402" }' { "status": "completed", "fee": 0.022, "policy_evaluation": {"allowed": true} }

Try live in Explorer View Dashboard

What teams build

Three patterns where agent payments show up first

Start with the places where agents already spend money: buying APIs, funding task-specific workflows, and embedding payments into platforms.

Three real operating patterns — before the payment layer existed, and after.

🤖

API and data purchases

Give agents a direct way to buy premium endpoints, reports, model calls, and data feeds when the task requires it.

Metered usage

👥

Operational agent workflows

Fund sub-agents, approve routine vendor spend, and keep policy, ledger, and receipts inside the same runtime.

Workflow control

📡

Platform and marketplace billing

Embed payment-aware agents into your product so usage, margin, and settlement show up as one system feature.

Platform revenue

API platform · metered billing

A data marketplace that billed by the month had no way to charge AI agents by the call

Before Agents consumed premium endpoints freely or were blocked by the same monthly seat model used for human users. Usage tracking happened offline. Finance reconciled manually each month.

After Each agent call triggers an x402 micropayment. AgentPay settles the charge, posts the ledger entry, and fires a webhook back to the billing service — all in the same request lifecycle.

Revenue per agent call instead of per seat

Enterprise · procurement workflow

A supply chain team's procurement bot required human sign-off on every invoice under $5 000

Before Routine vendor invoices queued for days waiting on a manager who was the only approval authority. Agents couldn't pay without a human completing a separate ERP workflow step.

After AgentPay's policy engine holds spend to pre-approved vendors within a velocity limit. Invoices below the threshold settle automatically over ACH. Approvals only fire above the limit.

3-day invoice queue eliminated for routine spend

AI agent framework · multi-agent economy

An orchestrator spawning specialist sub-agents had no way to allocate budget between them

Before Budget was a shared environment variable. Any sub-agent could spend the full allocation. When a task overspent, the only signal was a failed API call at the end of the run.

After Each sub-agent gets its own wallet funded at spawn time. Spend limits are set per agent. When a sub-agent exhausts its allocation it stops cleanly — the orchestrator sees a policy block, not a silent failure.

Per-agent budget enforcement with audit trail

What ships next

The path from working prototype to harder production use

The core runtime is live today. The next work is better developer tooling, more rails, and stronger scale primitives.

Quarter 1Core payments, protocols, and browser explorer are already live.

Quarter 2Developer ergonomics improve with SDKs, specs, and event push.

Connection pooling at scale + partition transactions by month for hot/cold data tiering.

Q4 2026

Deployment and partnership models

Choose the model that matches how you want to ship it

Start with the same runtime, then decide whether you want to embed it, expose it as a platform feature, or run it inside your own environment.

Whether you're embedding payment infrastructure, building on top of it, or deploying at enterprise scale — there's a model for you.

Partner surface

Embednative wallet + policy layer

Monetizeshare fee volume from usage

Deployhosted, private, or enterprise

Shared runtimeThe same payment path can power your sandbox, your product surface, and a private deployment.One core

Configurable controlsWallets, policy, ledger, and receipts stay intact whichever model you choose.Same behavior

Flexible hostingRun it as embedded infrastructure, a platform capability, or in your own boundary.Deployment choice

Open source baseTeams can inspect the runtime before deciding how deeply to integrate it.Low lock-in

Commercial pathSupport, revenue share, and deployment depth can scale with the relationship.Operating model

🔌

Integration Partner

Embed AgentPay wallets directly into your AI agent platform. Your users get payment capabilities without leaving your product.

✓White-label wallet API + UI
✓Revenue share on transaction fees
✓Dedicated sandbox environment
✓Co-branded documentation
✓Priority support SLA

Best for: AI agent frameworks · LLM platforms · no-code AI builders

Feedback form

Name *

Company

Email *

I am sharing feedback as

What should we improve? (optional)

✓

Thanks. Your feedback is in.

We review these notes as we iterate on the explorer, API, and onboarding flow.

Ready to try agent-to-agent payments?

Start in the sandbox, inspect the live API, and decide how you want to connect your own agents.

Open Explorer Share feedback View dashboard

MIT License · No vendor lock-in · PostgreSQL 16 · Node.js 20