How do I test my AI agent's spending limits before I give it real money?

What should I check, step by step?

1. List every way the agent can spend: card numbers, x402 or other wallet payments, paid API keys, and tools that buy on its behalf. Each rail gets its own test, because each enforces limits in a different place.

2. Cards: in a Stripe sandbox, issue a virtual card with the same spending_controls you plan for production (for example a per_authorization limit, a daily limit and allowed_categories). Fund the test Issuing balance first; test funds aren't real and only work for simulated purchases.
3. Create test authorizations with POST /v1/test_helpers/issuing/authorizations, setting amount and merchant_data.category to match each case. Check which are approved and which are declined, and read the decline reason on the authorization.
4. Test what limits can't stop: increment an approved authorization (POST /v1/test_helpers/issuing/authorizations/{id}/increment) and create a force capture (POST /v1/test_helpers/issuing/transactions/create_force_capture). Stripe's spending-controls docs warn that tips and fees posted later can push spend past a limit, so reconcile captured transactions, not just authorizations.
5. x402: run the agent with a testnet client (the CDP x402 client's development environment uses Base Sepolia) and fund the wallet with test USDC from faucet.circle.com or the CDP faucet. Have a test server quote prices under, at and over your per-request cap, and an upto price whose ceiling is over the cap.
6. Policy layer: sign up for a Rightshold sandbox account (POST /v1/accounts/signup with sandbox: true gives rs_test_ keys), issue a test agent credential, set_spend_policy with your real caps, then call authorize_spend for each case and assert the decision and reasons.
7. Include the edge cases: an amount exactly at the cap (should allow), one minor unit over (should deny), several small purchases that cross daily_max_minor, a subdomain or look-alike merchant, a missing category, and a different currency. Each needs an expected answer written down before you run it.
8. Test retries and resets: retry a purchase and check you don't approve or pay it twice; pause or revoke mid-run and check the next purchase is refused; run cases just before and after the daily reset (Rightshold's daily total resets at 00:00 UTC; Stripe's date-based intervals also start at midnight UTC).
9. Keep one case that must allow and one that must deny in CI, so a test that always passes or always fails gets noticed.
10. Move to live money in steps: small caps first, alerts on, and the same matrix re-run with live keys at amounts you can afford to lose.

Why should I test an AI agent's spending limits with test cards and testnet USDC first?

Spend limits fail quietly. A cap set in the wrong currency unit (dollars instead of cents), an allowlist that is empty and so allows everything, or a retry that pays twice all look fine until real money moves. The only way to know a limit works is to aim purchases at it and watch it refuse them.

• Each rail has its own sandbox. Stripe Issuing's sandbox lets you issue cards and simulate purchases that only work inside your Stripe account. Base Sepolia is a testnet with free test USDC. A Rightshold sandbox account issues rs_test_ keys behind a hard boundary from live work, and none of its work counts toward the public record.

What test cases should I run against an AI agent's spending limits?

Write the matrix as data: purchase amount in minor units, currency, merchant domain or merchant category, time, and the expected decision and reason. Run the same rows against every rail the agent can use.

• Rows that catch the common bugs: at the cap and one unit over, a run of small purchases that crosses the daily cap, merchant and category outside the allowlist, a currency the policy doesn't cover, a retry of the same purchase, the first purchase after a pause or revoke, and purchases on either side of the reset time.
• In Rightshold's spend policy only allowed purchases count toward the daily total, and each authorize_spend call is its own decision. Authorize once per purchase and reuse that receipt when a payment retries; calling authorize_spend again for the same purchase counts the amount again. Make that a test row too.

What can get past a virtual card's spending limit when an AI agent pays?

Stripe says spending controls run before real-time authorizations and can decline a purchase before your webhook sees it, and that later tips and fees can push spending past a limit. Test helpers let you simulate both: increment an approved authorization, and create a force capture that never had an authorization.

• So compare captured transactions with the caps, not just the approve or decline decision, and alert on any captured amount larger than what was authorized.