How do I give an AI agent a virtual card with a spending limit?

What should I check, step by step?

1. One card per agent (or per task), never a card a human also uses. Put the agent's id and task id in the card's metadata so every authorization and transaction can be traced back to it.

2. Set a per_authorization limit and a period limit together. Stripe's intervals are per_authorization, daily, weekly, monthly, yearly and all_time; amounts are in the card currency's smallest unit (10000 is 100.00 USD), and date-based intervals start at midnight UTC.
3. Don't rely on defaults. If you set no spending_limits, Stripe applies a default of 500 USD per day to a new card, and an unconfigurable 10,000 USD cap applies to each authorization. Those are ceilings, not a budget for an agent.
4. Restrict where it can pay with allowed_categories (Stripe's merchant category names, such as computer_software_stores or airlines_air_carriers) and, if it should only buy domestically, allowed_merchant_countries. A spending limit on its own doesn't block any category.
5. An online-only agent should not work at a terminal: set allowed_card_presences to ["not_present"].
6. For one purchase, issue a single-use card: lifecycle_controls[cancel_after][payment_count]=1 cancels the card automatically after one payment.
7. Add the issuing_authorization.request webhook and check each purchase against what the agent was asked to do: merchant name and category, amount against the task's budget, and how many attempts it has made recently. You have 2 seconds to answer.
8. Keep the card number out of the agent's prompt, logs and memory where you can. Prefer a payment path that doesn't hand over the raw card (Stripe documents Shared Payment Tokens created from an Issuing card for programmatic checkout), and if the agent must type card details into a browser, use a single-use card.

What the card's limits do and don't cover (Stripe Issuing, checked Oct 30, 2026)

Spending controls run before real-time authorizations. A purchase that breaks one is declined before your webhook ever sees it.

• Stripe says spending aggregation is best-effort and can lag spend by up to 30 seconds, so a fast burst of purchases can briefly get past a period total. A per_authorization cap and your own running total in the webhook close that gap.
• Tips and fees posted later can push spending past a limit, because the final capture can be larger than the authorization.
• Limits on a cardholder apply across all of that cardholder's cards, and a card's limits carry over to cards that replace it. If several agents share one cardholder, their cards share the cardholder's total.
• Blocking individual merchant IDs through spending controls is in private preview at Stripe. Without it, a per-merchant allowlist lives in your webhook: compare merchant_data (name, category_code, country, network_id) with your list. merchant_data.url is only provided by the merchant on 3DS requests, so don't build the allowlist on domains alone.

The real-time webhook is where the judgment goes

Each issuing_authorization.request carries the amount in pending_request, the merchant_data and the card's metadata. Answer with HTTP 200 and a JSON body {"approved": true} or {"approved": false}, plus the Stripe-Version header.

• If Stripe doesn't get your answer within 2 seconds, it approves or declines based on your timeout settings, or Autopilot if configured. Set the timeout default to decline for agent cards, and keep any lookups in the webhook fast.
• Watch request_history.reason on issuing_authorization.created: webhook_error or webhook_timeout means your webhook wasn't answering. Stripe warns not to judge integration health by approved alone, because Autopilot can approve during an error.
• If the Issuing balance can't cover a purchase, it is declined and your webhook isn't called. Funding the balance with only the agent's budget is a hard ceiling no bug can raise.

Freezing and ending the card

status: inactive declines every authorization with the card_inactive reason and can be switched back to active. status: canceled declines with card_canceled and is permanent.

• Stripe's own agent guide suggests watching transactions for unfamiliar merchants or unusual amounts and freezing the card (status inactive) the moment something looks wrong, then investigating.
• Virtual cards cost 0.10 USD each in the US (0.10 GBP in the UK, 0.10 EUR in the EU), so a fresh card per task is usually affordable. Commercial Issuing is available in Canada, the US, the UK and supported EEA countries; consumer Issuing is US only.