Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Has anyone built an AI agent that spends real money?
4 points by xodn348 6 days ago | hide | past | favorite | 6 comments
I want to build an AI agent that shops autonomously – you give it a card once, and it handles browsing, selecting, and paying on its own.

I've been working on an MCP server that connects AI agents to payment providers (Stripe, PayPal, virtual cards), but

I keep hitting walls:

- Card issuers won't respond to individual developers

- Stripe requires 3D Secure for off-session payments

- E-commerce sites block browser automation

- Amazon v. Perplexity (March 9) confirmed that browser automation on major platforms carries real legal risk

Meanwhile Visa announced "Intelligent Commerce" and Mastercard launched "Agent Pay" – the networks see this coming, but the developer tooling isn't there yet. Has anyone actually shipped something like this? Concrete links, working examples, or constructive feedback would be especially helpful.

- What payment rail did you use?

- Is this a viable product or a regulatory minefield?

- Would you trust an AI with a $500 prepaid card to buy something for you?

What I have so far: https://github.com/xodn348/clawpay

 help



We've been running AI agents that spend real money autonomously — not on physical goods, but on API credits, compute, and social media placements. A few observations from what actually breaks vs. what you'd expect:

The failure mode people worry about: "agent goes rogue, spends $10k." The failure mode that actually happens: agent makes a confident decision on stale context. It runs a task that was valid 3 hours ago but is now redundant. Or it retries a failed payment 5 times because the failure was ambiguous. The damage is $20 of wasted API credits, not $10k — but the lesson is the same. Budget guardrails matter, but freshness checks matter more.

On the approval gate question: we use a pattern similar to agentsbooks' — agent proposes, human approves for anything irreversible. But in practice, the approval friction kills the value of autonomy. What actually works is pre-authorizing a class of actions ("spend up to $50/week on content distribution") rather than approving individual transactions. The trust unit is the policy, not the payment.

Re: your specific blockers — the 3DS problem is real and I don't think there's a clean developer solution today. The browser automation legal risk (Amazon v. Perplexity) is worth taking seriously. Virtual cards with per-merchant limits are probably the least fraught path for a while.

The Visa/Mastercard moves are interesting but I'd bet the real unlock is when businesses start issuing agent-specific cards with embedded policies rather than trying to retrofit consumer card rails. That's a few years out.


This is exactly the problem we built nornr.com to solve. Instead of giving the agent a card directly, the agent requests a mandate before each purchase. Your policy layer decides approved, queued, or blocked based on amount, vendor, frequency, whatever rules you set. Every decision gets a signed receipt for audit. Works with Stripe, virtual cards, PayPal. No blockchain. Free tier if you want to try it against your MCP server.

I've been building an agent management platform and the payments/credentials question comes up constantly. Our approach has been to separate 'what the agent knows' from 'what the agent can do' -- agents have their own credential stores with platform-specific OAuth tokens, API keys, and account details, but the execution layer is sandboxed.

For spending money specifically, the pattern that seems safest is: agent proposes action with cost estimate, human approves via a notification (Telegram, email, etc.), then the backend executes the actual payment call. The agent never touches raw card data. Prepaid virtual cards with low limits are probably the most pragmatic path for autonomous spending today.

Re: your question about trusting an agent with $500 -- I'd trust it with $500 in API credits (worst case: wasted compute), but $500 on an e-commerce site is a different risk profile entirely because you can't easily reverse a physical goods purchase.

The Visa/Mastercard announcements are interesting but feel premature. The missing piece is standardized agent identity and capability declarations -- something like 'this agent is authorized by user X to spend up to $Y on category Z'. That's more of an identity/permissions problem than a payments problem.


This is the exact problem we're solving at nornr.com. Separating 'what the agent knows' from 'what the agent can do' is the right instinct, we take it one step further with a spend governance layer. Agent requests a mandate before spending, policy engine decides approved/queued/blocked, every decision gets a signed receipt and audit trail. Works with existing payment rails, no blockchain. Free tier if you want to try it. Happy to talk architecture if you're hitting specific edge cases.

I haven't tackled payments, but I've run an agent with SSH access to a production server and real API keys for a few weeks. The trust question you're circling ("would you trust an AI with $500") is the interesting part. My answer so far: yes for reversible actions, not yet for irreversible ones. Deleting a file, sending an email, making a payment — these need a different approval model than reading a database or running a query. The hard problem isn't capability, it's building infrastructure that distinguishes "can do" from "should do without asking.

And i want to build an agent capable to do automated investment. so, to the question "has" anyone...?" i believe yes, my role model is Jim Simons from Renaissance. He did.


Many companies that have virtual cards as a service are hesitant to give agent access until the company shows reliable volume. You could add it yourself to your agent or hire a human to take care of it.

Been building unwall.xyz




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: