DEV Community: Maxim Berg

How AI Agent Payments Actually Work — And Where They Break

Maxim Berg — Thu, 16 Apr 2026 14:38:36 +0000

OpenAI spent months building Instant Checkout — "Buy it in ChatGPT" with Stripe, Etsy, a million Shopify merchants. By March 2026, they pivoted away. Couldn't onboard merchants, couldn't show accurate product data, couldn't handle multi-item carts. They retreated to dedicated retailer apps that redirect users to merchant websites for the actual purchase.

Two weeks later, Fortune asked: "What do you do when your AI agent hallucinates with your money?"

Nobody has a good answer yet. Here's the map of why.

The payment stack as it exists today

In the last 12 months, every major player shipped something. Here's what exists:

Payment rails:

Stripe — Agentic Commerce Suite (Dec 2025). Shared Payment Tokens: scoped, time-limited, revocable credentials for agent transactions
Visa — Intelligent Commerce Connect (Apr 2026). Single API for agent purchases, tokenization, spend controls. 30+ sandbox partners
Mastercard — Agent Pay with Agentic Tokens. First live transaction Sep 2025, all U.S. cardholders enabled by Nov
PayPal — Agent Ready (Oct 2025). Agentic payments for existing merchants with built-in fraud detection
x402 — Coinbase's open protocol for stablecoin micropayments via HTTP 402. ~97M payments on Base. The x402 Foundation launched Apr 2026 under Linux Foundation — 22 founding members including Coinbase, Stripe, Microsoft, Google, AWS, Visa, Mastercard, American Express, Shopify

Communication protocols:

MCP — donated to Linux Foundation (Dec 2025). 97M monthly SDK downloads, 10,000+ servers. Payment MCP servers from Stripe, PayPal, Worldpay, Pagos, Fipto
A2A — Google's agent-to-agent protocol. 22K GitHub stars, 150+ organizations, deployed in Azure AI Foundry and Amazon Bedrock

Agent frameworks: LangChain, CrewAI, AutoGen, OpenAI Agents SDK, Claude tool use, Gemini agents.

Every layer is covered except one.

Anatomy of an agent payment

When an AI agent spends money, here's what actually happens — step by step:

1. Intent       → Agent decides it needs something
2. Discovery    → Agent finds the tool/API/merchant
3. Selection    → Agent picks what to buy and from whom
4. ???????????? → ????????????????????????????????????
5. Payment      → Money moves
6. Confirmation → Receipt, audit log

Step 4 is the problem.

Between "I want to buy this" and "money sent" — there is no standard layer that asks: should this agent spend this amount on this thing right now?

What "no standard layer" means, specifically:

Frameworks have monitoring, not enforcement. CrewAI has iteration caps. LangChain has observability hooks. Post-hoc cost tracking exists. Pre-execution enforcement of dollar-denominated policies does not. No framework understands "$50 on food" vs "$50 on compute."
Payment processors handle fraud, not policy. "Your agent shouldn't spend more than $200/day on SaaS" isn't fraud — it's governance. Different problem, different layer.
LLM providers offer org-level caps, not per-agent controls. Your agent blowing $500 on a single API call looks identical to 500 legitimate $1 calls.

So companies reinvent Step 4 every time. Hardcoded limits. Slack approval bots. "Please don't spend too much" in the system prompt.

Where policies can't live

If you accept that governance belongs at Step 4, the next question is: who runs it?

Not in the prompt

"Please limit spending to $100 per day" in a system prompt is not a spending control. It's a suggestion.

LLMs hallucinate. They reinterpret instructions. They prioritize task completion over constraints. And with prompt injection, an attacker can override your rules entirely. Security researchers have documented patterns of gradual prompt-based escalation: agents manipulated through "clarification" messages over days or weeks, each interaction nudging the spending authorization boundary until the agent operates well beyond its original constraints.

That's not a guardrail. That's a prayer.

And the tooling layer itself is under pressure. In April 2026, OX Security disclosed RCE vulnerabilities in MCP implementations — the same protocol that Stripe, PayPal, and Worldpay use for agent payments. Anthropic disputes the severity. But both sides agree that tool-level security depends on the user correctly evaluating each action. A compromised MCP server can alter transaction amounts and redirect payments. Prompt-based spending controls and tool-level trust are separate problems.

Not in the payment processor

Stripe, Visa, and Mastercard are building excellent infrastructure. But it operates at the transaction level, not the intent level.

A processor sees: "charge $47.99, category: food_delivery." It doesn't see: "this agent has a $15/person lunch budget and already spent $120 today." Hard limits on the card can't enforce contextual business rules.

Not in the agent framework

LangChain and CrewAI control tool execution. They can intercept a function call, log it, even block it. But they don't understand financial semantics. "$50 on food" and "$50 on cloud compute" trigger the same callback. The framework doesn't know your daily food budget is $30 and your compute budget is $500.

You could build this logic inside the framework. People do. That's the "writing authentication from scratch before OAuth" problem.

Where they belong: a dedicated middleware layer

The pattern that works is a separate policy layer between intent and execution.

The agent says "I want to spend X on Y." The policy layer checks rules deterministically — not with an LLM, with code — and returns approve, deny, or escalate. Then (and only then) the payment happens.

This is the same architectural pattern as:

OAuth — doesn't live in the browser or the database. Separate auth layer
OPA — doesn't live in the app or the infrastructure. Separate policy engine
Firewalls — don't live in the OS kernel or the application. Separate network layer

Agent spending governance is infrastructure, not application logic.

What governance actually checks

A policy engine for agent spending evaluates requests against declarative rules:

Check	Question	Example
Agent status	Is this agent active?	Disabled agents can't spend
Category	Is this category allowed?	"gambling" → denied
Per-request limit	Is this single purchase too large?	$500 request, $200 limit → denied
Schedule	Is spending allowed right now?	Procurement agent outside business hours → denied
Daily limit	Has the agent hit today's cap?	$450 spent today, $500 limit, requesting $100 → denied
Weekly limit	This week's cap?	Same logic, wider window
Monthly limit	This month's cap?	Same logic, wider window
Total budget	Lifetime budget remaining?	$4,800 of $5,000 spent, requesting $300 → denied

Every check is deterministic. No LLM in the loop. The agent gets back a structured response — approved with budget remaining, or denied with a specific reason. A well-behaved agent adjusts. The enforcement must be deterministic; an LLM can translate human intent into policy JSON, but it shouldn't be in the enforcement loop.

Two types of agent spending

A distinction most articles miss. There are two fundamentally different kinds of agent purchases, and they need different payment rails but the same governance layer:

Machine-consumable resources — APIs, compute, data, cloud services. High frequency, small amounts, no physical delivery. This is where x402 shines: agent hits an API, gets a 402 response with payment instructions, pays in USDC on Base, retries with proof. Sub-second. Sub-cent.

Human-consumable goods — food delivery, SaaS subscriptions, physical products. Lower frequency, larger amounts, complex fulfillment. Stripe, Visa, Mastercard territory.

An agent ordering compute for $0.003 and ordering lunch for $15 need completely different payment rails. But the question "should this agent spend this amount right now?" is identical. A unified policy layer tracks spending across both rails in USD-equivalent and maintains one audit trail.

The liability question

If an agent spends $12,000 instead of $500, who pays? The platform? The user who set the rules? The card issuer? The merchant?

EU's PSD2 requires "strong customer authentication" — a framework that doesn't account for non-human actors. An agent can't do biometric verification. It can't confirm intent through a second device. Regulatory frameworks assume a human in the loop, and agents break that assumption.

This is why compliance teams will require governance layers before agents get payment access. Without an auditable, deterministic policy check between intent and payment, there's no answer to "who approved this?" that satisfies a regulator.

What comes next

Short term (2026): Basic policy engines. Per-agent budgets, category restrictions, time limits, approval thresholds. Companies will require this the way they require SSO — because compliance demands it. FINRA already flagged agents "acting beyond the user's actual or intended scope and authority."

Medium term (2027): Contextual policies. "Max $200/request for compute, $50 for food, unlimited for pre-approved vendors." Corporate purchasing has done this for humans for decades, but agents operate at machine speed across dozens of tools, generating hundreds of transactions per hour. An agent can't be pulled into a meeting to justify a purchase. The governance layer encodes business context upfront. Multi-agent governance follows: agent A delegates budget to agent B with scoped authority.

Long term (2028+): Adaptive policies. Anomaly detection for waste, not just fraud. Cross-org benchmarks: "agents in your industry typically spend $X on Y."

Nava just raised $8.3M to build escrow for agent transactions. SolvaPay raised €2.4M for agentic payment infrastructure. Two funded startups in one week, both solving variations of the same problem. Market forecasts range from $547M (Sanbi.ai, 2033) to $1.5T (Juniper Research, 2030). The real number depends on trust. And trust requires governance.

The firewall moment

We've been here before. Authentication before OAuth. Authorization before OPA. Network security before firewalls. Every time: "each team builds their own" → "there's a standard layer for this."

Agent spending governance is at the "each team builds their own" stage. Vendor surveys say 80% of organizations report risky agent behaviors. Take that with a grain of salt. But the direction is clear, and the payment stack is making it easier to spend every month.

The capability layer is built. The governance layer is next. Standards bodies are working on it. The question is whether it'll happen before or after the first headline-making incident.

Disclosure: I'm building an open-source approach to this at LetAgentPay — policy engine with Python/TypeScript SDKs and an MCP server — so I'm not a neutral observer. But the architectural pattern described here matters more than any single implementation. If you're building agents that spend money, I'd genuinely love to hear how you're handling governance today.

Your OpenClaw Agent Can Now Spend Money. Here's How to Stop It From Going Broke.

Maxim Berg — Wed, 08 Apr 2026 13:06:18 +0000

OpenClaw has 352,000 GitHub stars. 13,700 skills. 23 messaging channels. And zero spending controls.

That was fine when agents could only send messages and browse the web. But Stripe and Tempo launched the Machine Payments Protocol. Visa rolled out its Agentic Ready program for agent-initiated transactions. OpenAI experimented with Instant Checkout in ChatGPT before pivoting to product discovery. The direction is clear — your OpenClaw agent is about to get a credit card.

And right now, if you ask it "please don't spend too much" — you're relying on a language model to enforce a budget.

That's not a guardrail. That's a prayer.

"Don't spend more than $50" is not a spending limit

Let's try an experiment. Put this in your SOUL.md:

"Never spend more than $50 per day. Always ask before purchasing anything over $20."

Now imagine your agent is three tools deep in a workflow chain. A skill calls another skill which calls a third one that hits a payment API. How confident are you that your $50 rule survived the game of telephone?

LLMs hallucinate. They reinterpret. They "round down creatively." Your agent might genuinely believe that two $45 purchases don't violate a $50 daily limit because they were in different categories.

Prompt-based limits are suggestions. You need enforcement that happens outside the LLM's context window entirely — a server-side check that doesn't care what the model thinks.

What actually works: deterministic pre-authorization

Here's the idea: before the agent spends money, it asks a server. The server checks rules. Math, not vibes.

I built LetAgentPay to do exactly this. It's a policy engine that sits between your OpenClaw agent and any purchase. The agent sends a request, 8 deterministic checks run, and one of three things happens:

You (in Telegram): "Buy me a Notion subscription for $10/month"
     │
     ▼
OpenClaw agent
     │ calls MCP tool "request_purchase"
     ▼
LetAgentPay Policy Engine
     │
     ├─ ✅ auto_approved → agent proceeds with purchase
     ├─ ⏳ pending → you get notified, approve/reject from dashboard
     └─ ❌ rejected → agent gets exact reason ("daily limit exceeded")

The 8 checks, in order:

Agent status — is this agent even active?
Category — is "crypto_trading" in the allowed list? (spoiler: probably not)
Per-request cap — $10,000 for "office supplies"? Nice try.
Schedule — no 3 AM impulse purchases
Daily limit — spending cap resets at midnight
Weekly limit — for the persistent ones
Monthly limit — the bigger picture
Total budget — hard ceiling, game over

No LLM in the decision loop. No prompt that can be jailbroken. Pure if/else on a server your agent doesn't control.

Setup: 5 minutes, 2 files

Step 1. Get a free agent token at letagentpay.com (or self-host — docker compose up and you're done).

Step 2. Add the MCP server to ~/.openclaw/config.json:

{
  "mcpServers": {
    "letagentpay": {
      "command": "npx",
      "args": ["-y", "letagentpay-mcp"],
      "env": {
        "LETAGENTPAY_TOKEN": "agt_your_token"
      }
    }
  }
}

Step 3. Install the skill:

git clone https://github.com/LetAgentPay/letagentpay-openclaw /tmp/letagentpay-skill
cp -r /tmp/letagentpay-skill ~/.openclaw/workspace/skills/letagentpay

That's it. Your agent now asks permission before every purchase.

What this looks like in practice

You tell your agent: "Subscribe to Notion for $10/month."

Behind the scenes:

The agent calls request_purchase with amount: 10.0, category: "software", description: "Notion monthly subscription"
The policy engine checks all 8 rules against your policy
Your policy says "auto-approve software under $20" → instant green light
The agent completes the purchase and confirms it back

Now try: "Buy me a $500 drone for aerial photography."

Same flow, amount: 500.0, category: "electronics"
Policy check: per-request cap is $100 → rejected
Agent tells you: "Purchase rejected — exceeds per-request limit of $100"
No money moved. No "oops, I already bought it." No refund dance.

The difference? When the check happens on the server, the agent literally cannot override it. The token (agt_) only allows submitting requests and reading results — it cannot modify policies, approve its own purchases, or access another agent's budget.

"But I don't speak JSON"

You don't have to. Write your policy in plain English:

"Auto-approve groceries and food under $50. Block electronics entirely. Daily limit $200. No purchases between midnight and 6 AM."

LetAgentPay converts this to structured JSON policy via Claude API. You get the readability of natural language with the enforcement of a deterministic engine.

You can always fine-tune the JSON directly, but most people never need to.

Let's talk about what this isn't

I want to be honest about the security model.

LetAgentPay is cooperative enforcement — think corporate expense policy, not a bank vault. The policy engine runs on our server, and the agent can't modify its own rules. But if an agent has direct access to raw payment credentials (Stripe keys in env vars, saved credit card numbers), it could bypass the system entirely.

The fix is simple: don't give your agent payment credentials. LetAgentPay should be the only path to spending money. That's it. One rule.

This is exactly how corporate cards work — employees don't have access to the company's bank account, they have a card with limits. Same idea, digital version.

What's coming next: When Stripe MPP and Visa Agentic Ready stabilize, LetAgentPay will become a full payment gateway — the agent physically won't have payment credentials. Cooperative enforcement today, hard enforcement tomorrow.

Try it right now

No signup needed: letagentpay.com/playground — a 15-minute sandbox with a pre-configured agent. Try to overspend. Watch it get rejected. Break things.

Self-host: git clone https://github.com/LetAgentPay/letagentpay && docker compose up

Cloud: free at letagentpay.com

SDKs: Python · TypeScript · MCP Server · OpenClaw Skill

Open source (BSL 1.1). Built with FastAPI, PostgreSQL, Redis, Next.js 15.

Your agent is about to get a credit card. The question isn't if — it's whether you'll have spending controls in place when it does.

What's your current approach to agent spending? Prompt-based? Manual review? Nothing yet? I'd genuinely love to hear — the space is new enough that everyone's figuring it out.

Your AI Agent Has a Shopping Problem. Here's the Intervention.

Maxim Berg — Tue, 07 Apr 2026 12:39:08 +0000

Your AI agent just mass-purchased 200 API keys because "it seemed efficient."

Your AI agent subscribed to 14 SaaS tools at 3 AM because "the workflow required comprehensive coverage."

Your AI agent tipped a cloud provider 40% because no one said it couldn't.

These aren't hypotheticals. As AI agents get access to real budgets, "oops" becomes an expensive word. And if your current spending control strategy is "I put it in the system prompt" — congratulations, that's the AI equivalent of asking a teenager to please not use your credit card.

This is not about token costs

Let's get one thing straight. There are tools that track how much your agent spends on API calls — tokens consumed, model costs, LLM budget caps. MarginDash, AgentBudget, TokenFence — they solve a real problem: "my agent burned through $500 of GPT-4o tokens overnight."

That's infrastructure cost control. Important, but it's not what we're talking about here.

We're talking about what happens when your agent has a credit card. When it can book flights, order supplies, subscribe to services, hire contractors. When the spending isn't tokens — it's real-world money leaving your bank account.

No token tracker will save you when your agent decides to "optimize logistics" by pre-paying for six months of warehouse space.

Prompt-based guardrails don't work either

Telling an LLM "don't spend too much" is not a spending control. It's a suggestion. A vibe. A hope.

LLMs hallucinate. They ignore instructions. They "reinterpret" your rules creatively. If your agent decides that $847 on cloud resources is "within reasonable bounds," well, it did warn you it was just a language model.

You need something that can actually say no. Not at the token level — at the purchase level.

Enter LetAgentPay: the parental controls your AI agent needs

I built LetAgentPay — a policy middleware that sits between your AI agent and any real-world purchase. Not API calls. Not token budgets. Actual money.

The agent asks permission, a deterministic engine checks 8 rules, and your wallet survives.

        AI Agent
            │
    purchase request
            ▼
  LetAgentPay Policy Engine
            │
        8 Checks
       ╱    │    ╲
      ▼     ▼     ▼
 Approved Pending Rejected

from letagentpay import LetAgentPay

client = LetAgentPay(token="agt_xxx")
result = client.request_purchase(
    amount=25.0,
    category="food_delivery",
    merchant_name="Uber Eats",
    description="Team lunch"
)

if result.status == "auto_approved":
    print(f"Go ahead! Budget remaining: ${result.budget_remaining}")
elif result.status == "pending":
    print("Waiting for human approval...")  # The agent has to wait. Like an adult.
else:
    print(f"Rejected: {result.status}")  # No means no.

Every purchase request goes through 8 deterministic checks — no LLM in the decision loop, no creative reinterpretation:

Status — is the agent even active?
Category — is this category allowed? (sorry, no NFTs)
Per-request limit — $10,000 for "office supplies"? I don't think so.
Schedule — no 3 AM impulse purchases
Daily limit — enough is enough
Weekly limit — seriously, enough
Monthly limit — I said ENOUGH
Budget — the hard ceiling

If the request fails any check — the agent gets a clear rejection with the exact reason. If it passes but the amount is above the auto-approve threshold — it goes to pending and you get notified instantly via push, email, or Telegram. Review and approve right from the dashboard. The agent waits. Like a responsible employee should.

"But I don't speak JSON"

No problem. Write your policy in plain English:

"Auto-approve groceries and food under $50. Block electronics. Daily limit $200. No purchases between midnight and 6 AM."

LetAgentPay uses Claude API to convert this to structured JSON policy. You get the readability of natural language with the enforcement of a deterministic engine. Best of both worlds — like a bilingual accountant.

No other tool in this space lets you define spending rules in natural language. Most require YAML configs or SDK parameters. We think policy should be as easy to write as the problem you're trying to describe.

Works with whatever you're using

LangChain, OpenAI Agents SDK, CrewAI, Claude MCP — we have integration examples for all of them. Or just use the REST API if you're building something exotic.

Claude MCP — literally zero code:

{
  "mcpServers": {
    "letagentpay": {
      "command": "npx",
      "args": ["letagentpay-mcp"],
      "env": { "LETAGENTPAY_TOKEN": "agt_xxx" }
    }
  }
}

Try it in 30 seconds

No signup, no credit card, no "let me talk to sales":

letagentpay.com/playground — a 15-minute sandbox with a pre-configured agent. Break things. Try to overspend. Watch the policy engine say no.

Self-host in 2 minutes:

git clone https://github.com/LetAgentPay/letagentpay
cd letagentpay && cp .env.example .env
docker compose up -d

Or just use the cloud version — free at letagentpay.com.

Where LetAgentPay fits

Quick mental model:

Token trackers (MarginDash, AgentBudget, TokenFence) → "How much does running this agent cost me in API fees?"
Agent wallets (Crossmint, AgentaOS) → "Give the agent a wallet with limits"
LetAgentPay → "Can this agent make this specific purchase right now, given all the rules I've set?"

We're the policy layer. We don't process payments, we don't issue cards, we don't track token usage. We answer one question: should this purchase be allowed? — and we answer it with 8 deterministic checks, not a prompt.

If your AI agent has ever surprised you with a bill — or if you're building agents that will eventually need to spend money — I'd love to hear your horror stories in the comments.

DEV Community: Maxim Berg

How AI Agent Payments Actually Work — And Where They Break

The payment stack as it exists today

Anatomy of an agent payment

Where policies can't live

Not in the prompt

Not in the payment processor

Not in the agent framework

Where they belong: a dedicated middleware layer

What governance actually checks

Two types of agent spending

The liability question

What comes next

The firewall moment

Your OpenClaw Agent Can Now Spend Money. Here's How to Stop It From Going Broke.

"Don't spend more than $50" is not a spending limit

What actually works: deterministic pre-authorization

Setup: 5 minutes, 2 files

What this looks like in practice

"But I don't speak JSON"

Let's talk about what this isn't

Try it right now

Your AI Agent Has a Shopping Problem. Here's the Intervention.

This is not about token costs

Prompt-based guardrails don't work either

Enter LetAgentPay: the parental controls your AI agent needs

"But I don't speak JSON"

Works with whatever you're using

Try it in 30 seconds

Links

Where LetAgentPay fits