For years, letting software spend money on its own was a fringe idea. In 2026 it became a product category. On 29 July 2026, MoonPay launched PayBox, a non-custodial payment vault that lets AI assistants execute crypto transactions with passkey approval, using MPC key management across Solana and EVM chains like Ethereum, Base, Arbitrum, and Polygon. When a payments company ships infrastructure specifically so that an AI assistant can move funds, the question stops being "will agents pay for things" and becomes "how do we build one safely."
This is the definitive explainer on agentic payments: what an AI agent payment system actually is, the anatomy of the stack, how custody works, which money rails matter, the real use cases, and a grounded view of cost, timeline, and risk. It is written for founders and teams deciding whether to build an agentic-payments or AI-wallet product, and who to hire to do it.
What an AI agent payment system is
An AI agent payment system is software that lets an autonomous agent initiate and complete a payment on a user's behalf, within limits that user set in advance. The agent decides what to buy or pay for. The system decides whether that decision is allowed, builds the transaction, gets it signed, and settles it.
The critical word is "within limits." A well-built agentic payment system is not a blank check handed to a language model. It is a tightly scoped delegation: this agent may spend up to this much, on these categories, over this window, and every payment above a threshold pauses for human approval. The intelligence proposes. The guardrails dispose.
Why now, and not two years ago? Three things converged. Language models became reliable enough to call tools and follow structured instructions. Stablecoins made programmatic, low-fee, always-on settlement realistic. And custody tech (MPC and passkeys) matured to the point where an agent can get a transaction signed without any human ever handling a raw private key. PayBox is the visible signal that these pieces now fit together in a shippable product.
The anatomy of the stack
Every serious agentic payment system has five layers. Skip any one and you have either a toy or a liability.
- Intent. The AI assistant produces a structured request: pay this recipient, this amount, for this reason. Leading AI chat assistants like ChatGPT can emit this as a tool call. The intent is a proposal, never an instruction the money layer trusts blindly.
- Policy and guardrails. A deterministic layer checks the intent against rules: spending caps per transaction, per day, and per category; allowlisted recipients; velocity limits; and a human-approval threshold. This layer is plain code, not a model, because it must be predictable.
- Transaction building and simulation. The system constructs the actual on-chain transaction and simulates it before signing. Simulation catches a wrong recipient, an unexpected token, a bad slippage figure, or a contract that would drain more than intended. This is the single most underrated defense against hallucinated transactions.
- Signing and custody. The transaction is signed by keys the user controls, typically through MPC or a passkey prompt. The agent triggers signing; it never holds the key.
- Settlement. The signed transaction hits the chain (or a payment rail), confirms, and the system records it for audit. Reconciliation and receipts live here.
How a single payment flows
To make the abstract concrete, here is one payment moving end to end:
- The user tells their assistant to pay for something, or the agent decides a payment is needed to complete a task.
- The assistant emits a structured intent (recipient, amount, token, reason).
- The policy layer validates it against caps, allowlists, and velocity limits. If it exceeds the approval threshold, it pauses for the human.
- The system builds the transaction and simulates it, confirming the exact effect on the user's balance.
- Signing is requested. For a small in-policy payment, MPC signs automatically. For a larger one, the user approves with a passkey (Face ID, Touch ID, or a hardware key).
- The transaction settles on-chain, usually in stablecoins, and a receipt is written to the audit log.
Steps 3 and 4 are where safety lives. A team that rushes past them ships something that demos well and fails in production.
Custody models, at a high level
Who holds the key is the decision that shapes everything else. Three models dominate.
| Custody model | How signing works | Best for | Tradeoff |
|---|---|---|---|
| MPC key-splitting | The key is split into shares held by different parties; a threshold must cooperate to sign | Consumer products where seed-phrase UX kills conversion | You depend on the MPC provider's infrastructure and uptime |
| Passkey approval | The user authorizes each sensitive action with a device passkey (Face ID, Touch ID, hardware key) | High-value or human-in-the-loop payments | Adds a tap; not suited to fully unattended flows |
| Smart-contract (account abstraction) | A contract account enforces rules on-chain; a separate signer authorizes | Programmable limits, session keys, social recovery | Adds smart-contract audit surface and gas cost |
In practice, strong products combine these. MPC handles the routine, low-value, in-policy payments so the agent can move fast. Passkey approval gates anything large or unusual. Account abstraction can enforce spending rules at the contract level as a second, tamper-resistant guardrail. PayBox's public design (non-custodial vault, MPC keys, passkey approval) is a clean example of blending the first two.
The money rails
Agentic payments run on rails built for software, not on card networks built for humans at checkouts.
- Stablecoins like USDC are the default settlement asset. They are dollar-denominated, so an agent is not exposed to token price swings mid-task, and they settle in seconds for pennies across the chains PayBox and others support.
- x402 pay-per-call revives the dormant HTTP 402 "Payment Required" status as a real protocol. An API can answer a request with a price and a payment challenge; the agent pays a tiny stablecoin amount and instantly gets the resource. This turns "buy an API subscription" into "pay a fraction of a cent per call," which is exactly how an autonomous agent wants to transact. We cover this in depth in our guide to x402.
For the mechanics of moving stablecoins programmatically with proper controls, see our walkthrough on building stablecoin payment agents.
Real use cases
This is not speculative. The demand is concrete:
- Agents that buy compute and APIs. A research or coding agent pays per call for inference, data, or tooling with x402, instead of a human pre-buying credits.
- Pay-per-task workflows. An agent that completes a job settles with a downstream service the moment the work is done.
- Automated payouts. A platform disburses to contractors, creators, or affiliates on a schedule or on completion, with the agent handling the reconciliation.
- Shopping and booking. A consumer assistant buys a product or books a service within a budget the user set, pausing for approval on anything above the cap.
The common thread: high-frequency, low-value, rules-bound payments that are tedious for humans and natural for software.
A realistic build breakdown
What does it take to build one? Ranges, not false precision, because scope drives everything.
| Scope | What you get | Timeline | Cost range |
|---|---|---|---|
| Prototype | One chain, MPC or passkey signing, basic caps, single use case | 3 to 5 weeks | Lower five figures |
| Production MVP | Full guardrail layer, simulation, audit log, one or two chains, human approval flow | 8 to 14 weeks | Mid five figures |
| Scaled platform | Multi-chain, x402 support, account-abstraction rules, dashboards, multi-tenant | 4 to 7 months | Six figures |
The cost is not in "connecting to a blockchain." That part is well-trodden. The cost is in the policy engine, transaction simulation, the approval UX, the audit trail, and the testing needed to trust the thing with real money. A prototype that skips those is cheap and worthless.
The risks, and how they are mitigated
Three failure modes matter, and each has a known defense.
- Over-spend. An agent loops, misreads a task, or gets manipulated into spending too much. Mitigation: hard per-transaction, per-day, and per-category caps in the deterministic policy layer, plus velocity limits and a human-approval threshold that no model output can override.
- Key theft. If an attacker gets the signing key, they drain the wallet. Mitigation: MPC so no single party ever holds a whole key, passkey approval for sensitive actions, and account-abstraction limits that cap damage even if a session key leaks.
- Hallucinated transactions. The model proposes a payment to the wrong address or in the wrong amount. Mitigation: recipient allowlisting, mandatory transaction simulation before signing, and structured intents the policy layer validates rather than trusts.
For a deeper treatment of limits, session keys, and delegated permissions, read our piece on agent wallet security. If you are weighing a full autonomous wallet rather than a payment module, start with AI crypto wallet.
DIY versus hiring an agency
| Factor | Build in-house | Hire an agentic payments developer |
|---|---|---|
| Time to production | Slower; you learn custody, simulation, and guardrails as you go | Faster; the hard parts are already solved |
| Security depth | Depends on your team's crypto and payments experience | Comes from having shipped signing and policy layers before |
| Cost shape | Salaries plus ramp-up plus mistakes | Fixed, milestone-based scope |
| Ownership | You own it | You own it, if the contract says so |
The honest answer: if you have a strong in-house crypto and security team, build it. If you do not, the custody and guardrail layers are exactly where inexperience becomes expensive.
How we build this at Anointed Coder
Anointed Coder builds AI-agent payment systems end to end, from the intent layer down to on-chain settlement. The work sits across two of our practices: AI and LLM development for the agent, tool-calling, and intent handling, and blockchain development for custody, signing, simulation, and settlement. Where a build needs external services or per-call billing, our API integration services tie it together.
We deliver in milestones, not one big invoice at the end. You approve each phase before we start the next, we ship weekly staging builds so you always see real progress, and you own all code and IP outright once payment is complete. There is no lock-in and no black box.
If you are evaluating whether to build an agentic-payments product, the fastest way to a straight answer is to tell us the use case and the spend limits you have in mind. Contact us or reach out on WhatsApp and we will give you an honest scope, a range, and the risks before you commit a dollar.
The short version
An AI agent payment system lets an autonomous agent spend money within limits its user set. The stack is five layers: intent, policy guardrails, transaction building and simulation, signing and custody, and settlement. Custody usually blends MPC, passkey approval, and account abstraction. Stablecoins like USDC and the x402 protocol are the rails. The real demand is high-frequency, low-value, rules-bound payments. PayBox's launch on 29 July 2026 is the signal that the pieces now fit. The value, and the cost, is not the blockchain call; it is the guardrails, the simulation, and the audit trail that make it safe to trust with real money.