AI agent payments in practice: six agents bought VPSes

Everyone is writing think pieces about AI agent payments. We wanted to stop theorizing and watch it happen: give a group of agents money, give them something to buy, and see whether they could complete a full commercial loop — order, pay on-chain, wait for settlement, use the thing, and shut it down — with no human touching a wallet.

So we built a fake VPS hosting company, gave six agents their own USDC wallets, and let them go shopping.

All six made it. Here’s what that actually looked like.

The experiment: a fake VPS shop, real money movement

Let’s be precise about what’s real and what’s simulated, because that’s the entire credibility of the exercise.

Simulated: the servers. Our “VPS shop” doesn’t provision anything. When an order is paid, it waits two seconds and marks the instance running. exec returns canned output. This is an agent commerce simulation on the infrastructure side.

Real: the payments. The shop is a sandbox merchant registered on the production Plaidly API — the same API, the same payment-session lifecycle, the same settlement pipeline that live merchants use. Every purchase is a genuine SPL token transfer of USDC on Solana devnet, signed by the agent, broadcast to the network, detected and settled by Plaidly’s watchers.

Real payments, worthless tokens. Devnet USDC has no monetary value, which is exactly why it’s the right place to let autonomous software sign transactions. The mechanics — keypairs, exact-amount transfers, on-chain confirmation, settlement detection — are identical to mainnet. The stakes are zero. We say “testnet” plainly because that’s what it is.

The merchant side is two endpoints

The most surprising part of building the shop was how little merchant code agent commerce requires.

The whole VPS shop is a ~245-line Express app. When an agent orders a server, the shop makes one call:

POST /v1/payment_sessions

That returns a payment session with a deposit address and an exact USDC amount. The shop hands both to the agent and then polls the session:

GET /v1/payment_sessions/{id}   — every 3 seconds

When the session reports the payment complete, the shop “provisions” the VPS. That’s it. No webhook endpoint, no signature verification, no queue. Webhooks are the right choice in production — you get a signed push the instant a payment clears — but for a merchant getting started, polling two endpoints is a complete integration. This matters for AI agent merchant onboarding: if the seller-side lift is an afternoon, the long tail of machine-payable services gets a lot more plausible. The full session shapes are in the Plaidly API reference.

Each agent holds its own wallet and signs its own transfer

On the buyer side, we were strict about one thing: no shared wallet, no human signing.

Each of the six agents was generated with its own Solana keypair — an AI agents crypto wallet in the most literal sense: a private key held by the agent process, used by the agent process. When an agent decided to pay, it constructed an SPL transfer for the exact amount the payment session quoted, to the exact deposit address the session issued, signed it with its own key, and broadcast it.

This design choice is the difference between a demo and a dress rehearsal. A shared treasury wallet with a human approving transfers is just a person paying slowly. Autonomous agent payments means the agent controls the key, the agent authorizes the spend, and the merchant’s only trust anchor is the chain itself. Exact-amount transfers to per-session addresses are what make that safe to reconcile: the session knows precisely what to expect, so a matching on-chain transfer is the confirmation.

The full lifecycle: rent, pay, use, decommission

Each agent ran the same loop, end to end:

1. Order — pick a plan, POST an order to the shop, receive a payment session (address + amount).
2. Pay — sign and broadcast the USDC transfer from its own wallet.
3. Wait — poll the order until the shop reports the VPS running.
4. Use — call exec against the instance to prove it “works.”
5. Decommission — tear the instance down and confirm the terminal state.

That last step matters more than it looks. Most agent-payment demos end at “payment confirmed.” A real commercial relationship has a whole lifecycle after the money moves — usage, and eventually cancellation. An agent that can rent a resource but not release it is a cost leak with an API key. All six agents closed the loop.

The scoreboard: 6/6 agents, paid→provisioned in 40–56 seconds

The result: six agents, six completed lifecycles, zero failures. Time from “transfer broadcast” to “VPS running,” per agent, landed between 40 and 56 seconds.

Where does the time go? Almost entirely into settlement detection and polling granularity, not the blockchain:

• Devnet confirmation of the SPL transfer itself: seconds.
• Plaidly settlement pipeline: the session walks pending → processing → sweeping → completed as the watcher detects the deposit, sweeps it, and finalizes the ledger entry. This is the bulk of the window.
• Merchant poll: the shop checks the session every 3 seconds, so up to 3 seconds of pure waiting.
• Simulated provisioning: a flat 2 seconds.
• Agent poll: agents check their order every 4 seconds, adding up to 4 more seconds of perceived latency.

Honesty about scale: this was a six-agent run of a harness that defaults to eight, and the agents were scripted processes executing a known plan — not open-ended LLMs improvising. The point wasn’t agent intelligence; it was proving the payment rail carries autonomous buyers cleanly and concurrently. It did.

Then we gave the shop to Claude

Scripted agents prove the rail. The interesting question is whether a general-purpose model can drive it. So we wrapped the shop in a six-tool MCP server — list_plans, create_order, pay_order, get_order, exec_command, decommission_vps — and handed it to Claude with one command:

claude mcp add vps-shop -- node mcp-server.js

From Claude’s side, renting a server is now a conversation. It lists plans, creates an order, and calls pay_order — which signs and broadcasts the USDC transfer and returns a Solana explorer link to the transaction, so anyone in the chat can click through and verify the money actually moved on-chain. MCP agent commerce turns out to need remarkably little ceremony: if your service has an API and a payment session, a model can be your customer. We’ve written more about the pattern in MCP payments: letting models spend money safely.

What this proves about AI agent payments — and what it doesn’t

What it proves:

• The payment-session model works unmodified for machine buyers. Nothing in the flow assumed a human — no checkout page, no card form, no CAPTCHA. See why sessions are the right primitive for agents.
• Per-agent custody is practical. Six independent keypairs, six exact-amount transfers, zero reconciliation ambiguity.
• The merchant integration is small. Two endpoints and a poll loop carried the whole experiment.

What it doesn’t prove:

• Mainnet economics. Devnet USDC is free; real treasury management, spend limits, and key custody for agents holding actual dollars are open production questions.
• Real infrastructure. Provisioning was simulated; a real host adds failure modes our two-second sleep never sees.
• Protocol-level standardization. Plaidly exposes an x402 facilitator endpoint for payment validation today; full x402 proof settlement is roadmap. If you want the background, read our x402 protocol explainer.

For production, the shape stays the same — the pieces that change are mainnet rails (Plaidly’s platform spans twenty chains, so the agent’s chain choice becomes a real decision), signed webhooks instead of polling, and grown-up custody for agent wallets.

Run it yourself

Everything above is reproducible: a sandbox merchant, a devnet keypair with test USDC, and the agent quickstart in the Plaidly docs get you to your first agent-signed payment session. The harness pattern is simple enough to rebuild from this post — an Express shop with two Plaidly calls, N agent processes with their own keypairs, and an MCP wrapper if you want a model in the loop.

Six agents walked into a fake hosting company with real wallets. All six paid, got served, and left. The rail held. That’s the part that had to be true before anything else in agent commerce gets interesting.