Services
Page
Lazy Ants · Web3 · Agentic Payments

Agentic PaymentsWallets, rails and spending boundaries for software that pays on its own.

We build agent payment infrastructure, and we connect the rails that already exist. The first thing an agent needs is a limit that still holds when the agent is wrong. For API and SaaS companies that want to be paid by software, and for crypto products whose agents move money.

Illustration · an agent wallet and its three rules

We build what has to be yours, and connect what already works.

We build

Agent wallets and the policy that constrains them. The settlement ledger, with budgets enforced in accounting rather than in application code. Idempotency, attribution and the audit trail underneath both.

We connect

x402, MCP, and the wallet provider you already run on. Rebuilding a rail that already works spends the budget on nothing. We will say so before you do it.

Agentic payments, live on CPAY

CPAY

The crypto payment gateway our team built and operates. Its agentic layer runs on the same platform, and AI agents pay on CPAY today, on the same rails as every payment counted below.

Agent walletslimits, allowlists, human approval
MCP serverscoped tools for AI agents
Machine paymentssettled inside the request
5 yearsIn production, without interruption
$1BTotal volume processed
0Security breaches

Agents pay on the same rails as merchants · real users, not a pilot · absolute on-chain finality since launch

Our MCP servers are public: Hetzner, Lexware and Transkribus on GitHub.

An agentic wallet is a wallet with rules. Agentic payments are what it does with them.

Agentic wallet

What it is

  • Its own money

    A wallet that belongs to the agent, funded with a set amount. That amount is the most it can ever lose.

  • Rules it cannot break

    Who it may pay, how much per payment and per day, and when a human has to approve.

  • A record of everything

    Every action signed and logged, so you always know which agent paid what, and why.

Agentic payments

What they do

  • Pay per use

    Per call, per request, per item: amounts far too small for a card.

  • Settles in seconds

    In stablecoin, across any border, with no bank in the middle.

  • No account, no invoice

    Payment happens inside the API request, paying out or getting paid.

Four pieces, and they are all containment

Two we build, two we connect.

Agent wallets and policyWe build

Spending limits, allowed assets and networks, approved counterparties, and approval flows above a threshold. We are specific about which controls are tamper-proof and which are not, because that decides the architecture. Where enforcement is weak, we contain by funding rather than by rule.

Settlement ledger and auditWe build

Budgets enforced in double-entry accounting rather than in application code. Idempotency keys on every write, so a retried transfer is one payment and not two. Attribution to agent, task and mandate on every posting.

MCP tool surfaceWe connect

A fixed tool surface with scoped permissions instead of a bespoke integration per model. Your orchestration stays yours. What changes is that an agent can only take the actions you exposed on purpose.

x402 machine paymentsWe connect

Payment inside the HTTP request: the endpoint answers 402, states its price, the caller pays in stablecoin, the call completes. No account, no contract, no human in the path.

Six protocols, most need one

x402Settlement
MCPTool access
AP2Mandates
ACPTokens
UCPCatalogues
TAPCards

Which of them your product needs follows from whether your agent is buying from you or spending on your behalf. We settle that on the first call.

From a demo to an agent that can spend

Four steps. The first one is free.

  1. Draw the boundary

    What the agent may spend, and when a human says yes.

  2. Build or connect

    Which pieces we build, which rails we plug in.

  3. Wire it in

    Wallets, policy and ledger, inside your product.

  4. Break it on purpose

    We find the failures before your agent does.

What we need from you
  • What the agent decides
  • What it should be able to pay for
  • Who approves the exceptions
  • Where the money sits today
What we need from you
  • What the agent decides
  • What it should be able to pay for
  • Who approves the exceptions
  • Where the money sits today

Questions we get before booking

If yours is not here, ask on the first call. We would rather talk you out of this than build an agent that can spend when it should not.

Do you build the agent wallet, or connect one that already exists?
Both, and settling which is the first thing we do. Where a provider's controls are strong enough for your boundary, we connect one. It is faster, and it is someone else's uptime to carry. Where the limit has to be absolute, or where your policy model does not fit anyone's product, we build it. You will hear which case you are in on the call, with the reasoning.
What is x402?
A way to put payment inside an HTTP request. Your endpoint answers with 402 Payment Required and a price, the caller pays in stablecoin, the request completes. It makes an API, a dataset or a report purchasable by software that has no account with you and never will.
How is an agent wallet different from a normal one?
By what it is not allowed to do. Per-wallet policy: limits, allowed assets, approved counterparties. Plus approval flows above a threshold and a record of every action it took. The difference is enforcement, and enforcement is exactly where these systems vary most.
Can you actually stop an agent overspending?
Within limits you should understand before relying on them. Most policy conditions are enforced tamper-proof inside a secure enclave; transfer-size limits usually are not, because they require transaction simulation and run at the API layer. Where the cap has to be absolute, we contain by funding a separate budget wallet rather than by writing a rule. That is an architectural decision and we make it with you, explicitly.
Which protocol should we support?
Probably one. AP2 for signed mandates, ACP for tokenised card credentials, x402 for on-chain settlement, MCP for tool access. The answer follows from whether your agent is buying from you or spending on your behalf, which is the first thing the call establishes.
Do agentic payments work on cards, or only crypto?
Both exist. Cards have deeper acceptance and a correction path when something goes wrong; stablecoins settle instantly, cross-border, and at amounts too small for a card to carry economically. We work on the stablecoin side, and we will tell you when your use case belongs on a card rail instead of ours.
What do you need from us to start?
Four answers: what the agent decides, what it should be able to pay for, who approves the exceptions, and where the money sits today. If you can answer those on the call, the scope writes itself. If you cannot, that is worth knowing before anyone builds anything.
When is this the wrong project?
When the agent is not really deciding anything. If the amounts, recipients and timing are fixed in advance, that is a scheduled payment, and you need neither agent wallets nor mandates nor x402 to run it. We would rather say that on the call than six weeks into a build.

Tell us what the agent is for

What it decides, what it should be allowed to spend, and who has to approve the exceptions. If it turns out to need none of this, you will hear that on the first call.

Agentic Payments Development | x402 Wallets | Lazy Ants