Stripe's [real-time authorization docs](https://docs.stripe.com/issuing/controls/real-time-authorizations) give your endpoint two seconds to approve or decline a purchase, after which your timeout setting answers for you. No person fits inside two seconds, which is why a human approval path is a separate build from a spending limit. That's one of four costs that land around month six of a do-it-yourself agent spend stack.
Stripe Issuing plus a wallet plus a fraud tool is a sound first move. It ships in days, and every component is a vendor your finance team already knows how to buy. Here's what it does well, and what it costs after the integration is done.
What does the DIY stack get right?
It gets more right than a vendor pitch admits. [Stripe Issuing's spending controls](https://docs.stripe.com/issuing/controls/spending-controls) allow or block merchant categories and merchant countries, restrict card-present transactions, and cap spend per authorization or per interval, applied to a single card or across all of a cardholder's cards. A wallet holds the float. A fraud tool scores each transaction. Every piece is production infrastructure.
For one agent buying from a predictable set of merchants under a monthly ceiling, that combination is enough. [What each of Stripe's agentic primitives was designed to do](/blog/stripe-agentic-primitives-explained) is worth reading before you decide you've outgrown it.
The stack stops being enough when you can't answer a question about one agent from one system.
Where do three vendors leave seams?
The seams show up at the join. Your issuer knows a card, a merchant and an amount. Your wallet knows a balance and a transfer. Your fraud tool knows how a charge scores against a population of human cardholders. Which agent ran which task, on whose instruction, lives in your orchestrator, and none of the three payment components can see it.
| Component | Answers | Can't answer |
|---|---|---|
| Card issuing API | did this card breach a limit or hit a blocked category | which agent, running which task |
| Wallet | what the balance is and where the funds moved | whether anybody intended the transfer |
| Fraud tool | how this charge scores against human cardholder behaviour | whether an odd agent pattern is a compromise or a Tuesday |
| Your orchestrator | which agent ran which task | anything about the money until the statement lands |
The join is a service you write. It starts small and grows every time a vendor adds a field, a new agent needs its own funding path, or someone asks for a per-team view. Nobody owns it on your org chart, which is what makes it a month-six problem.
Who assembles the per-agent record, and does it hold up?
You do, from three exports, into a store your own service writes to. That's the difficulty. A record stitched together after the fact, by the same system that spent the money, answers what your logs say rather than what happened, and a security reviewer will draw that distinction before you do.
Evidence carries requirements a log doesn't. Immutable, scoped to the agent rather than to the card, and covering approvals alongside transactions, so "who signed off on this" has an answer that doesn't depend on a Slack search.
Timing sits underneath it. [Control at the authorization moment and reconciliation after the statement](/blog/authorization-time-control-vs-reconciliation) are different products, and a stitched stack tends to deliver the second while the architecture diagram promises the first.
What does the approval path cost once a person is in it?
The expensive half is staffing. Two seconds is the documented window for an authorization response, so human approval has to live somewhere else: a queue, a notification path, a rota covering nights and weekends, and a rule for what the agent does while it waits. That last one is a product decision and it lands on your roadmap.
An approval queue nobody answers at 2am is a decline queue with extra steps. Stripe documents two fallbacks: an account-level timeout setting that approves or declines for every agent on every purchase, or Autopilot, which applies a predefined rule set instead. Neither one knows which agent was spending, or what it was told to do.
What breaks in year two?
Version drift arrives, on three schedules at once. Stripe ships monthly backward-compatible releases plus a [semiannual named major release](https://stripe.com/blog/introducing-stripes-new-api-release-process) that can break existing code. Your wallet and your fraud vendor keep their own calendars. The service joining all three has to track every one of them.
Preview features add a second kind of drift. Merchant ID spending controls sit in private preview, and Stripe's Autopilot fallback in public preview, both gated behind a conversation with Stripe. Assuming a preview capability looks the same in a year is where the maintenance bill comes from.
None of this is a knock on the vendors. Each is doing the correct thing for its own surface, and the cost lands on you because you're the only party keeping four moving parts in agreement.
Shatale is the control plane over that seam. Agent-scoped virtual cards, your spending policy enforced at the authorization moment, purchases outside policy blocked or escalated to a person for approval, and one immutable per-agent record covering approvals as well as transactions. You keep your issuer. What you stop maintaining is the service in the middle.
What to ask
- Which system answers "what did this agent spend, and who approved the outliers" without a join we maintain?
- At what moment is our spending policy evaluated, and what happens if our endpoint doesn't respond in time?
- When a purchase falls outside policy, is it blocked, escalated to a named approver, or logged for us to find later?
- Who covers the approval queue at 2am, and what does the agent do while it waits?
- Is the record immutable, scoped per agent, and does it cover approvals as well as transactions?
FAQ
Can you build agent payment controls with Stripe Issuing?
Yes. Issuing's spending controls cover merchant categories, merchant countries, card presence and amount limits per authorization or per interval, set on a card or a cardholder. Real-time authorizations let your endpoint approve or decline each purchase inside a two-second window. What it doesn't carry is which agent ran which task.
How long does a DIY agent spend stack take to build?
The first version takes days. Card issuance, a funding path and a fraud check are well-documented APIs, and a competent engineer will have a card spending under a limit inside a week. The cost sits after that: the join between three vendors, the approval workflow with people behind it, the per-agent record, and three upgrade schedules.
What does a fraud tool miss on agent transactions?
Fraud scoring is built on how humans buy. An agent making hundreds of small API purchases overnight is either working correctly or compromised, and both look the same from outside. Fraud tools catch card testing and stolen-card behaviour well. They can't tell you whether a purchase matched the task the agent was given.
Does a control plane replace Stripe Issuing?
No. A control plane sits above card issuing and governs how your agents use it. You keep your issuer relationship and your rails. What changes is where the spending policy lives, when it gets evaluated, how a purchase outside it is blocked or escalated for approval, and where the per-agent record is kept.
---
For the three questions a stitched stack keeps blurring together, [identity, payment authorization and audit are separate problems with separate failure modes](/blog/agent-identity-vs-authorization-vs-audit). Early access is free for publishers.
Shatale is the control layer for AI-agent payments. Its authorization architecture is the subject of European patent application EP26194994.5 (filed; priority 28 July 2026).