How to test AI agent payments without real money

Agent payment bugs are rarely in the transfer itself. They are in the agent's behaviour around it: retrying a payment it thinks failed, splitting a payment to fit under a limit, reporting success when a payment is still waiting, or misreading a blocked result. You only see those by letting the agent run, and you don't want to learn them with real funds. The other trap is a test result that looks like a real one. If a simulated payment comes back as plain 'confirmed', sooner or later someone, or the agent, will report it as money that moved.

1. Use realistic limits. Configure the same auto-approve, ask, per-payment and daily limits you intend to use, or scaled-down versions such as 2, 5, 5 and 25.
2. Exercise every decision. Ask the agent for one payment under the auto-approve limit, one in the approval band, one over the per-payment cap, and enough small ones to hit the daily cap.
3. Force a retry. Interrupt the agent mid-payment or tell it the first attempt failed. Check that it reuses the same idempotency key or checks the payment's status, rather than paying twice.
4. Check what the agent tells you. Read the agent's own summary. It should distinguish paid, waiting for approval, blocked, and simulated, and should never present a simulated payment as real.
5. Review the log. Look at the audit trail for the run. Every decision you saw should be there, with the reason.
6. Switch the source, not the code. When you are happy, attach a real source. The agent's tools and your limits should stay exactly the same.

• A simulated payment is not a payment. Nothing moved, and its reference is not a transaction anyone can verify.
• A testnet is not the same as a simulated rail. A testnet exercises real signing and confirmation with valueless tokens; a simulated rail tests your agent and policy logic without any chain.
• Passing on the simulated rail does not prove your wallet is funded or set up for real transfers, which need USDC and a little ETH for gas on Base.

• Veyra docs
• veyra-examples: runnable agent examples (GitHub)
• Base documentation

• Payment intentA payment intent is an object representing a payment that has been requested but not necessarily completed, which moves through defined states such as awaiting approval, submitted, confirmed or cancelled.
• Idempotency keyAn idempotency key is a unique value a client attaches to a request so that, if the same request is sent again with the same key, the server returns the original result instead of performing the action a second time.

• How to let an AI agent make paymentsGive an agent a payment tool, not a key: limits enforced outside the model, a human for larger amounts, and a record of every decision.
• How to stop an AI agent making duplicate paymentsAgents retry when unsure, and retries can pay twice. Idempotency keys, status checks and tool wording that keep one intended payment to one payment.
• How to audit what an AI agent spentWhat an agent payment log should record, from requests and policy decisions to approvals, settlements and permission changes, and how to review it.
• How to set spending limits for an AI agentPer-payment cap, daily cap, an auto-approve band and an ask band, enforced outside the model. How to choose each number and what happens at each edge.

All guides →