Agentic PaymentsWallets, rails and spending boundaries for software that pays on its own.
We build what has to be yours, and connect what already works.
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.
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
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.
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.
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.
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
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.
- Draw the boundary
What the agent may spend, and when a human says yes.
- Build or connect
Which pieces we build, which rails we plug in.
- Wire it in
Wallets, policy and ledger, inside your product.
- Break it on purpose
We find the failures before your agent does.
- 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?
What is x402?
How is an agent wallet different from a normal one?
Can you actually stop an agent overspending?
Which protocol should we support?
Do agentic payments work on cards, or only crypto?
What do you need from us to start?
When is this the wrong project?
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.