An AI agent that can pay is an agent that can overspend, pay the wrong party, or be talked into paying by a cleverly written web page. When people imagine agentic payments, they usually picture the payment: a signed transaction, a token moving on a chain. In my experience the payment is the easy part. The hard part is everything that has to be true before the payment is allowed.

To find out what that takes in practice, I built Dualwire: an independent, working prototype of a payments gateway for AI agents. At the time of writing it has 45 shipped features, 527 passing tests and four payment rails: stored value, cards and real-time payments, cross-border payouts, and a stablecoin. Everything runs on simulated rails or public test networks, and no real money moves. Its tagline is the whole idea: agents pay, people stay in charge.

Nobody’s at the checkout

Card payments have a human in the loop at the moment of purchase. That person sees the price, recognises the merchant and presses the button. With an agent, that moment disappears. So the gateway has to check four things on its own, in order, and stop at the first one that fails:

  1. Mandate. The person sets the limits: how much, on what, for how long. The agent can’t spend outside them, whatever it is told. In Dualwire a mandate can be signed on the person’s own device, so it is verified before it exists. That is the same idea as the intent mandates in Google’s Agent Payments Protocol (AP2).
  2. Identity. The agent proves who it is acting for, and the seller learns only the facts it needs.
  3. Payment. A machine-readable price and a signed payment: x402 for pay-per-call, payment intents for cards, bank rails and stablecoins.
  4. Accountability. A rulebook decides before any rail is called, every decision comes with its reason, and a double-entry ledger records every cent.

The order matters. A payment protocol without a mandate in front of it is a faster way to lose money.

Prove, then pay

The clearest demo is deliberately small. An agent asks for an age-restricted photo. The seller doesn’t answer with a price. It answers 401 with a proof request: “Show me over 18. Nothing else.” The agent responds with one signed fact, bound to this request, this seller and its own key. Only then does the seller answer 402 with a price, 25 cents in test tokens. The agent pays inside its mandate, and the photo is delivered.

The seller learned one fact: over 18, yes. Not a name, a birthday or an ID number. If the credential says under 18, the request is refused with the seller’s reason and nothing is charged.

Dualwire handles the identity step with x401, a companion to x402. Pairing them answers a question I kept hitting: many things you’d want an agent to buy need some proof first, such as age, a licence or a verified business. Today that means collecting far more personal data than the seller needs. Selective disclosure flips that. You can try the demo yourself at dualwire.com: prove your age and pay to see a cat, either on the web or from the Claude app.

Stablecoins in the middle, not at the edges

The stablecoin rail shows up in several of Dualwire’s ten payment types. Two make the point. Pay-per-call APIs settle each call on-chain with x402. In a cash-out, a USDC-style token held on-chain is collected and paid out in local currency, so a balance in digital dollars arrives as pesos in a mobile wallet. The chain settles one leg, the payout network the other, and the ledger ties both together. The rail also prefunds payout partners in seconds.

What surprised me is how little of the gateway is about crypto. The stablecoin rail is one adapter behind the same five verbs as every other rail: mandate, authorise, settle, payout and dispute. That’s the design I’d argue for anywhere: stablecoin settlement added as one more rail, not as a separate product with its own rules.

When things go wrong

Most payment demos skip the failure cases. Production systems are mostly failure cases. Dualwire handles several:

  • A person can pause, refund or dispute an agent’s payment.
  • A bank can revoke or re-limit an agent from its own app.
  • A lost reply is looked up, never paid twice.
  • Every request to the API carries an idempotency key, so a retry can’t create a second payment.

Disputes are where mandates pay for themselves. If the record shows exactly what the person authorised and what the agent did, deciding who is liable becomes cheap.

Protocols will multiply

At least four agent payment protocols are live or in pilot: Stripe’s Agentic Commerce Protocol, Google’s AP2, x402 and Visa’s Trusted Agent Protocol. Nobody knows which will win, and it may be several. My conclusion from building this is to speak every protocol at the front door and keep one rulebook behind it. A new protocol should be a new front-door module, not a new set of rules about what an agent may spend.

The technology for software to pay software is here. What decides whether people trust it is the boring part: limits they set, facts they choose to share, and a record that explains every decision.

Dualwire is an independent prototype. Rails are simulated or on test networks, and no real money moves. Views are my own and do not represent my employer.