Stripe's New Approval Gate Blocks an AI Agent From Cancelling a Subscription or Issuing a Refund on Its Own. It Shipped On by Default.

Every support team that's plugged an AI agent into Stripe over the past year has been running on trust. The agent reads a ticket, decides the customer is owed a refund or wants out of their plan, and calls the API. Most of the time it gets it right. On August 26, 2026, Stripe shipped the feature that assumes it won't — and quietly made it the default for the exact two actions that cost you real revenue: cancelling a subscription, and issuing a refund.

What Stripe actually shipped on August 26

Approvals lets an account admin write a rule that intercepts a sensitive action before it takes effect and routes it to a designated reviewer. If the action matches a rule, Stripe pauses it and creates an approval request instead of executing it. A reviewer — someone other than whoever triggered the action, since a user can't approve their own request — approves or denies it from the Dashboard. Approve, and the action completes automatically with no further steps. Deny, and nothing happens; no partial state, no rollback needed.

That much works the same whether the requester is a human teammate or a piece of software. The part that matters for churn is what Stripe calls an agent-tagged API key: a restricted key you flag, at creation, as belonging to an autonomous agent rather than a person or a plain backend integration. Tag a key this way and Stripe automatically subjects it to approval rules — and ships a default rule set the moment you create your first one, with no setup required. Stripe's own documentation is blunt about why: the rules exist as "a safeguard against agent mistakes, unexpected behavior, and hallucinations — giving you visibility and control without blocking agents from doing their jobs."

Why cancellation and refunds made the default list

Stripe didn't pick these two arbitrarily. They're the actions where an agent's mistake converts directly into lost MRR, and they're also the two actions a support-triage agent is most likely to be trusted with in the first place — "resolve the ticket" for a subscription dispute usually means either "keep them" or "let them go, and maybe refund something." A misread ticket doesn't fail loudly the way a broken API call does. It just executes cleanly, on the wrong instruction.

A developer writing on Isara's blog described exactly this shape of failure: a support agent misread a customer's refund request and issued $708 back — a full year of an annual plan — when the customer had asked for one month, $59. Nothing crashed. No error fired. The agent did precisely what a Stripe API call does when you ask it to refund a charge: it refunded the charge, for the amount it was told. The only thing missing was a second person checking the amount before it moved.

Customer service sits right in that chart at 34% adoption — not the department running the most agents, but nowhere close to the least, and it's the department with the most direct line to your Stripe account's cancel and refund endpoints. Pair that with the CSA/Zenity finding that only 8% of organizations say an agent has never exceeded its intended scope, and the math on why Stripe defaulted these two actions to gated stops being a guess and starts being obvious: this is the department, and the exact pair of actions, where the finding was already true before the feature existed to catch it.

How the gate actually works end to end

The mechanics are async by design, which matters if you're wiring this into an existing support or dunning workflow. When an agent-tagged key attempts an action that matches an approval rule, Stripe doesn't execute it and doesn't leave it pending in limbo — it returns an approval_required error and automatically files an approval request for review. Your integration can attach a justification to that request before a human ever sees it:

curl -X POST https://api.stripe.com/v2/core/approval_requests/apreq_.../update \
  -H "Authorization: Bearer sk_live_..." \
  -H "Stripe-Version: 2026-08-26.preview" \
  --json '{ "reason": "Customer requested refund via support ticket #4821" }'

From there it's a webhook flow, not a polling loop. Listen for v2.core.approval_request.approved or .rejected to know the outcome, and .succeeded or .failed once an approved action actually finishes executing — because approval and execution are two separate steps, and the second one can still fail on its own terms (a card that's since been detached, a subscription already cancelled by another path). An unreviewed request doesn't sit open forever: it expires automatically after 14 days and the action never happens. Every rule change and every request — created, approved, denied — also lands in Security history under Team and security, so the audit trail exists whether or not anyone goes looking for it.

The nuance most teams will miss: this doesn't touch your own cancel flow

It's worth being precise about scope, because it's easy to read "Stripe now requires approval for subscription cancellation" and assume it changes something about the self-serve cancellation flow a customer hits when they decide to leave. It doesn't. Approval rules apply to actions taken by human team members through Stripe's own Dashboard, CLI, or MCP, and to keys you've explicitly tagged as belonging to an agent. The production API key your application already uses to process a customer's own cancellation request — the ordinary, expected path through your app — is neither of those things. It's not a dashboard session and, unless you deliberately tag it otherwise, it's not an agent key either. That request goes through exactly as it does today.

What this actually gates is the newer category of risk: an internal support agent, wired up via Stripe's MCP server or Agent Toolkit and handed an agent-tagged key, deciding on its own initiative to cancel someone's subscription or refund a charge as the resolution to a ticket. That's a meaningfully different failure mode from the one we covered in agentic cancellation churn — a consumer's own agent executing a standing instruction like "cancel anything unused for 30 days." This is the mirror image: your agent, acting on your account, on your customers' subscriptions, based on how well it parsed a support ticket.

What it doesn't solve

Approvals is a checkpoint, not a fix for judgment. A few limits are worth planning around rather than discovering later:

• Volume becomes the reviewer's problem. Every refund and cancellation an agent attempts now needs a human to look at it, which is fine at ticket volumes a support lead can review in minutes and a bottleneck at the volume most teams adopted an agent to handle in the first place. An amount-threshold condition — require approval only above, say, $200 — keeps the gate on the requests that actually carry risk without reviewing every $12 refund by hand.
• "Require approval" and "block" are different tools. A rule set to require approval pauses for review. A rule set to block rejects the action outright, no human involved — useful for an action you genuinely never want an agent to take unsupervised, rather than one you want reviewed case by case.
• It governs the Stripe action, not the ticket that led to it. Approving a $708 refund because the justification field says "customer requested" doesn't catch the case where the agent still misread the amount — a reviewer has to actually check the number against the ticket, not just rubber-stamp the request. The gate creates the opportunity for that check; it doesn't perform it for you.
• Single-person accounts have a real constraint. Two-party approval needs an approver who isn't the requester. On a one-person Stripe account, the only rules you can activate are ones scoped to agent-tagged keys as the actor — you can't require a human teammate to approve another human teammate's action if there's only one of you.

Setting it up without slowing your team down

A few concrete starting points, in the order most teams should tackle them:

1. Tag any support or billing agent's key as an agent key the moment you connect it, rather than reusing a plain restricted key. You get the default rule set for free and lose nothing — agent-tagged keys authenticate and permission identically to any other restricted key.
2. Add an amount condition to the refund rule. The default rule covers every refund an agent creates regardless of size. Splitting it so small, low-risk refunds auto-execute and larger ones route to review — the same tiering logic we laid out for when a retention offer costs more than it saves — keeps the checkpoint where the dollars actually are.
3. Name a specific reviewer, not a role. Only individually assigned reviewers get an email notification when a request needs them. Assigning the rule to "Support specialist" as a role without naming anyone means requests sit until someone happens to check the queue.
4. Write the justification instructions to require the actual evidence. Custom justification instructions can prompt the agent to cite the ticket number and the customer's original ask — the same discipline we've argued for in deciding whether a refund policy is a retention lever or just a finance line item, now enforced at the point the money actually moves instead of after the fact.

None of this replaces a real cancellation flow — Approvals governs what your own account and your own agents can do to a subscription, not the experience a customer gets when they decide, on their own, that they're done. That's still the job CancelFlow is built for: routing the reason, offering the right save, and letting a genuine cancellation complete cleanly. But the two problems sit right next to each other on your books. A wrongly cancelled subscription and a wrongly sized refund both show up as revenue you didn't have to lose, and now there's a rule — on by default, as of August 26 — standing between an agent's mistake and your churn number actually moving.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.