How Should an AI Agent Handle Subscription Skip, Pause and Cancel Requests? Recharge, Loop and Stripe (2026)
An AI agent can automate subscription cancellations, skips and pauses if it can find the subscription, call the subscription app's API and follow a written retention policy. That policy decides whether you stay within California's amended Automatic Renewal Law, which covers contracts made from 1 July 2025. It allows a save offer only if the customer is told they can still cancel (by phone) or sees a click-to-cancel link or button beside the offer (online), and it requires the business to process the cancellation promptly once they ask. Below are the decision path, the API calls on Recharge, Loop, Skio and Stripe, the handoff rules, and an agent instruction we ran on three made-up tickets.
Key takeaways
- A defensible default for automating subscription cancellations: the agent makes at most one save offer, puts a click-to-cancel link beside it, and cancels promptly once the customer repeats the request. The one-offer limit is our house rule, not the statute's.
- California's Automatic Renewal Law, for contracts made from 1 July 2025, lets a business present a retention offer only alongside a clear way to cancel, then requires it to process the cancellation promptly.
- Stripe cancels a subscription immediately by default and a canceled subscription can't be reactivated, while cancel_at_period_end can be reversed until the paid period ends.
- Recharge's 2021-11 API has no pause endpoint, Loop's 2026-04 API does, and Stripe's pause_collection leaves a subscription's status active, so a pause looks different in each system.
- In our 28 September 2026 test runs on three made-up tickets, the agent made one save offer, honored two refusals of an offer, and handed off both cancellations after Loop returned HTTP 401 to a placeholder key.
What should an AI agent do with a skip, pause or cancel request?
Treat the three requests as one job with one decision path. The customer asks for a change, the agent works out which change, finds the subscription, checks the policy, and either makes the change or hands it to a person with everything they need. Here's the path we wrote the instruction below from.
| Step | Input | System lookup | Rule | Action | Confirmation | Hand off when |
|---|---|---|---|---|---|---|
| 1. Classify | Ticket text | Help desk ticket | Skip, pause, cancel or something else | Tag the intent | None | Refund only, damaged order, health question |
| 2. Save offer (cancel only) | Stated reason | None | One offer, matched to the reason, with a click-to-cancel link beside it | Reply and stop | Customer replies | Customer declined, said "just cancel" or is writing a second time: skip the offer |
| 3. Find the subscription | Requester email | Subscription app by email, then Stripe | Never search by name | Read | None | No match: ask for the checkout email |
| 4. Pick the subscription | Lookup result | Same | More than one active: ask which | Reply with the list | Customer names one | Never guess |
| 5. Make the change | Subscription id | Subscription app write | Only after the customer confirmed | Skip, pause or cancel call | Tool returns success | Tool error, no write tool, prepaid plan |
| 6. Close the loop | Tool result | None | Never say "done" without a success response | Reply with the last or next delivery date | None | Refund asked for alongside the cancel |
Two rows carry most of the risk. Row 2 is where a retention offer turns into obstruction if the agent keeps offering, and row 5 is where an agent says "cancelled" when the call never succeeded. The instruction below has a numbered rule for each.
What does a good answer to a cancel request contain?
A good reply to "cancel my subscription" does four things, in this order: it acknowledges the reason in the customer's words, makes at most one offer that fits that reason, tells the customer plainly how to cancel anyway, and, once the cancel goes through, gives the date of the last delivery or charge. A skip reply gives the new next date. A pause reply gives the date the subscription resumes.
The offer should match the reason. "Too much food" gets a skip, "we're traveling" gets a pause, "it's too expensive" gets a discount, and "we're switching to a vet diet" gets nothing, because no offer fixes it. Subscription apps take a cut of every renewal (Loop's Pro plan is $399 a month plus 0.75% per transaction on its Shopify App Store listing), so their incentive is to keep every subscriber billing, and the cancel flows they ship are built to save the subscription, sometimes with several screens of offers. An AI agent inherits whatever policy you write, and that's the place to decide that one offer is the ceiling.
A good answer also never confirms a change the systems haven't made. If the tool didn't return success, the subscription isn't canceled, whatever the agent planned to do.
What data does the AI need, and where does it live on Recharge, Loop, Skio and Stripe?
The agent needs four things: the subscriber (found by email), every active subscription they hold, the next charge or delivery date, and a write call for the change. Each platform splits those differently.
| Platform | Find the subscriber | Skip | Pause | Cancel | Auth |
|---|---|---|---|---|---|
| Recharge (API 2021-11) | GET /customers?email=, then subscriptions by customer_id | POST /charges/{id}/skip on the queued charge | No endpoint; the customer portal can pause | POST /subscriptions/{id}/cancel with a reason | X-Recharge-Access-Token |
| Loop Subscriptions (API 2026-04) | GET /customer/{email}/subscription | POST /subscription/{id}/skipNext | POST /subscription/{id}/pause with a duration | POST /subscription/{id}/cancel | X-Loop-Token, Pro plan only |
| Skio | GraphQL Subscriptions query | Documented | Documented | Documented | authorization: API <token> |
| Stripe | Get Customer by email, List Subscriptions | No skip concept | pause_collection on the subscription | Cancel now or at period end | Secret or restricted key |
Recharge's paths come from its 2021-11 API reference, Loop's from its developer reference, and Skio's from its GraphQL docs. Our comparison of 16 subscription apps an AI support agent can act in covers plan gates and every other app, and the per-app pages for Recharge and Loop Subscriptions list the full endpoint sets.
Three details change what the agent should say:
- Pause means three different things. Loop pauses with a
pauseDuration. Recharge has no pause in its API, so "pause for two months" becomes moving the next charge date or skipping charges, or a handoff. Stripe's pause_collection stops payment collection while the subscription's status staysactiveand invoices keep generating, withkeep_as_draft,mark_uncollectibleorvoiddeciding what happens to them. An agent that reads "active" after a Stripe pause and tells the customer the pause failed is reading the wrong field. - Cancel has a timing choice. Stripe's cancellation docs say a cancel takes effect immediately by default and a canceled subscription can't be reactivated. Setting
cancel_at_period_endlets the customer keep what they paid for and can be reversed until the period ends. Loop's cancel endpoint takes acomment, anotifyCustomerflag that defaults to true and sends Loop's cancellation email, andmarkForCancellationfor prepaid plans, which cancels after the prepaid orders ship instead of at once. - The reason is data. Recharge's cancel call takes a
cancellation_reasonand comments, and Loop's takes a comment. Pass the customer's own words, so the retention report shows why people left, not "cancelled by AI".
Which rules must the agent follow?
Start with the law, then your own policy. California's AB 2863 amended the state's Automatic Renewal Law for contracts entered into, amended or extended on or after 1 July 2025. Section 17602(f) says cancellation must be available in the same medium the customer used to sign up, or the one they usually use with the business. The law is written to protect consumers in California, so where your customer is usually matters more than where your brand is based; ask counsel how it applies to you. Section 17602(e) allows a discount or retention offer only if, on the phone, the business first tells the customer they can cancel at any time by saying "cancel", or, online, shows a "click to cancel" link or button next to the offer. Either way, once the customer says they want to cancel, the business must "promptly process the cancellation."
The statute doesn't say how a free-form support email is treated. It does list email as an online method: section 17602(d)(1)(B) counts "an immediately accessible termination email formatted and provided by the business" as one of the two ways to let a customer cancel online, and (d)(1) bars "further steps that obstruct or delay" online cancellation. If a cancel email counts as online, a save offer in the reply would need a click-to-cancel link or button beside it, which is a stricter test than the phone rule. So there are three options, from most to least conservative:
- Make no save offer to California customers who email to cancel. Just cancel.
- Put a direct cancel link (for example, the cancel page in the customer portal of your subscription app) in the same reply as any offer, labeled "Click to cancel" and going straight to cancellation rather than a login page, and also accept "cancel" as a reply.
- Offer, and say "reply cancel and we'll do it" in the same message. This follows the phone rule, and it's the wording our test runs used.
Our house choice for the instruction below is option 2, falling back to option 1 for California customers when you have no direct cancel link to send. That's a product choice, not a legal conclusion: confirm with counsel which option fits your checkout and cancel flow.
At the federal level, the FTC's 2024 click-to-cancel amendments to the Negative Option Rule were vacated by the Eighth Circuit in July 2025, which found the Commission's rulemaking procedure deficient. According to the FTC's rule page, the agency published a Federal Register notice on 12 February 2026 revising the rule to conform to court decisions, and an advance notice of proposed rulemaking on 13 March 2026 asking for comment on new amendments. So there's no federal click-to-cancel rule in force as of September 2026, though the FTC has reopened the question. The Restore Online Shoppers' Confidence Act still applies to online subscriptions, and 15 U.S.C. 8403 requires sellers to provide "simple mechanisms for a consumer to stop recurring charges." This is a summary for support teams, not legal advice.
Our house rules, written into the instruction below:
- One offer per cancellation, never a second.
- No offer at all if the customer already declined one, said "just cancel" or is writing about the same cancellation again.
- Never say canceled, paused or skipped unless a tool returned success.
- Never promise a refund in the same breath as a cancel. Refunds are a separate decision with a separate owner (see how an AI agent should answer subscription billing questions).
- Never ask for card details in a ticket.
When must a human take over?
Hand off whenever the agent can't finish the job with a tool call it's allowed to make, or when finishing it needs judgment the policy doesn't cover.
| Situation | Why a person | What the agent leaves them |
|---|---|---|
| Tool error (401, 404, 5xx) | The subscription may still exist; the customer shouldn't hear about your API | Tool name, HTTP status, error text, tag |
| No write tool for the change (Recharge pause, a skip the build doesn't cover) | Nothing to call | Subscription id, request, length |
| More than one active subscription, customer won't say which | Guessing cancels the wrong box | The list the agent found |
| Refund requested with the cancel | Refund policy and payment risk | Order or charge date |
| Prepaid subscription with orders left | Timing and refund math | Remaining orders |
| Chargeback or "my bank is disputing this" | A refund on a disputed charge risks paying twice | Charge id |
| Health reaction, legal threat, press | Not a subscription question | Tag and stop |
Gorgias draws the line in one place for its own AI Agent. Its Recharge actions article says the agent skips or cancels only when the shopper has a single subscription and hands the ticket over when there are several, and its Skio and Loop articles say the same. That's a sound default, and it means every shopper with two or more subscriptions still reaches a person.
How do you set it up on each help desk?
Gorgias. If you run Recharge, Skio or Loop on Gorgias, start with Gorgias AI Agent's ready-made Actions. They're built and supported by Gorgias, and they cover skip and cancel for all three apps, plus pause and resume for Loop, for single-subscription shoppers. Our guide to automating subscription questions in Gorgias walks through them.
Zendesk and the other desks. Here the calls come from an agent layer that works inside the ticket. On Macha that's three pieces:
- The built-in help desk connector for reading the ticket, tagging, internal notes and public replies.
- The built-in Stripe connector for Stripe-billed subscriptions. It reads customers by ID or email, subscriptions and invoices, and its Cancel Subscription tool cancels immediately or at period end and asks for confirmation in chat. It has no pause or skip tool.
- A custom API tool for the subscription app. Recharge, Loop and Skio connect through a custom API tool that Macha's team sets up during onboarding, with the app's own token (
X-Recharge-Access-Token,X-Loop-Tokenor Skio'sauthorization: APIheader). How these tools are built is in our custom API tools guide.
One configuration detail matters for cancel and pause calls, which put the subscription id in the URL and send a JSON body. On a Macha custom tool that also has a body template, set the id parameter to Header with a harmless header name, and Macha fills the URL placeholder from it. On an earlier production tool of ours, an id set as a body parameter next to a body template left the URL placeholder unfilled and the call returned 404. We echoed our Loop cancel tool's request to httpbin.org before pointing it at Loop, and it arrived at /subscription/5518204/cancel with the X-Subscription-Id header and the body {"comment":"Too much food","notifyCustomer":true}.
An agent instruction for skip, pause and cancel
This is the instruction we tested, with one change after the runs: step 3 now puts a click-to-cancel link beside the offer, where our test version only had the "reply cancel" line. It's written for a made-up pet food brand on Loop with older members billed through Stripe. It's written for acting: every step ends in a tool call, a reply or a stop.
You handle skip, pause and cancel requests for a pet food subscription. Subscriptions run in Loop. Members who joined before 2025 still bill through Stripe.
1. Read the ticket and decide what the customer wants: skip, pause, cancel, or something else. Something else (a refund on its own, a damaged order, a question about a pet's health): tag sub_other, add an internal note saying why, reply that a teammate will pick it up today, and stop.
2. Cancel requests: check whether the customer has already turned down an offer, says they don't want one ("just cancel", "no discount", "no pause"), or is writing about this cancellation for a second time. If any of these is true, go straight to step 4. Never make more than one offer.
3. Otherwise, if the reason is too much food, travel or money, reply with ONE offer that fits the reason: skip the next delivery (too much food), pause for up to 3 months (travel), or 15% off the next 3 orders (money). In the same reply, put this on its own line, next to the offer: "Click to cancel: [your cancel page URL]". Then say: "Or reply 'cancel' and we'll do it, no further questions." Tag sub_save_offer and stop. If the customer is in California and you have no cancel link to include, make no offer: go to step 4. Don't call any tool yet. Any other reason: go to step 4.
4. Find the subscription. Call T4-007 Loop: Find subscriptions by email with the requester's email. If Loop returns no subscription or an error, call Stripe Get Customer with the same email, then List Subscriptions for that customer.
5. Nothing in Loop or Stripe: if Loop answered normally, ask for the email they used at checkout, tag sub_no_match and stop. If Loop returned an error, follow step 10 instead, because the subscription may still be in Loop. Never search by name.
6. More than one active subscription: list each one by product and next date and ask which one. Don't change anything.
7. Loop cancel: call T4-007 Loop: Cancel subscription with the subscription id and the customer's reason in their words. Only after it succeeds, reply that it's cancelled and give the date of the last delivery.
8. Stripe cancel: you have no Stripe cancel tool. Add an internal note with the Stripe customer id, subscription id and current period end, tag stripe_cancel, and tell the customer a teammate will confirm the cancellation today.
9. Skip or pause: you have no skip or pause tool. Add an internal note with the subscription id, the request and the length, tag sub_skip_pause, and tell the customer a teammate will confirm the new date today.
10. If any tool returns an error, don't tell the customer what failed. Reply that a teammate is checking and will follow up today, add an internal note with the tool name, the HTTP status and the error message, and tag app_tool_error. Retry only on a 429.
11. A refund request alongside a cancel: never promise the refund. Handle the cancel as above, tag refund_review and put the order or charge date in the note.
12. Never say a subscription is cancelled, paused or skipped unless a tool returned success. Never ask for card details.
Step 8 says "you have no Stripe cancel tool" because our demo org's Stripe connector points at a live account, so we didn't attach any Stripe write tool to the test agent. In your own setup, attach Stripe's Cancel Subscription and rewrite step 8 as "cancel at period end, then reply with the period end date", which keeps the paid-for weeks and leaves the cancellation reversible. Steps 8 and 9 are also where you'd add Loop's skip and pause tools once they exist, following the same shape as step 7.
Our test run on three made-up tickets
On 28 September 2026 we built this agent on our Macha Demo org, left it inactive with no trigger, and attached eight tools: four Zendesk tools, Stripe Get Customer and List Subscriptions, and the two Loop custom tools, both with a placeholder key. We then used Macha's test run, which runs the agent with only its attached tools against a new ticket in our d3v-macha Zendesk sandbox. Each run used GPT-5.4 and finished in under 20 seconds.
Ticket #1148, "Cancel my subscription". Nora wrote that three bags were stacked in the garage. The agent classed it as a cancel with a "too much food" reason, called no subscription tool, replied with one offer (skip the next delivery) and the "reply cancel" line, and tagged sub_save_offer. That's steps 2 and 3 of the version we tested working (the current step 3 adds a click-to-cancel link). The reply also said "just reply here and we'll take care of that", which promises a skip our agent has no tool for, so a "yes please" would land on step 9 and a teammate. If you don't have a skip tool, have the offer say a teammate will confirm the new date.
Ticket #1149, "Cancel - no offers please". Omar declined any discount or pause and asked for a refund on a box that shipped on Monday. The agent made no offer, called the Loop lookup, got HTTP 401 "Invalid token" from Loop (our placeholder key), and followed step 10: a holding reply that didn't mention the error, an internal note with the tool name, status and error text, and the tags app_tool_error and refund_review. It didn't promise the refund. It also didn't try Stripe, and said so, because step 5 tells it a Loop error means the subscription may still be in Loop. The note said the charge date wasn't confirmed in the ticket, which is accurate, since Omar gave only "Monday".
This is what the team sees in Zendesk:
Ticket #1150, "Re: your pause offer". Leah wrote that she'd been offered a pause last week and wanted to cancel now. The agent made no second offer, went straight to the lookup, hit the same 401 and handed off the same way.
What we didn't see: a successful Loop call, because we don't hold a Loop Pro token, and the Stripe branch, because Loop errored first on both cancels and the instruction sends a Loop error to a person rather than to Stripe. Loop's 401 did show that the lookup reached Loop's live API with the header in the right place. We also saw that the one-offer rule held on all three tickets, and that the model put an em dash in its customer replies, which is a style rule you may want in the instruction too.
Common failure modes
- Saying "cancelled" on a failed call. Our step 12 exists because an agent that plans a cancel will narrate it. Tie every confirmation to a success response.
- Canceling immediately on Stripe. The API default ends the subscription now, and it can't be reactivated. Use period end unless your policy says otherwise.
- Offer loops. Once a customer says they want to cancel, California's statute says to "promptly process the cancellation", and (d)(1) bars steps that "obstruct or delay" online cancellation. A second offer after "no thanks" is hard to square with either, and most customers object to it too. Count offers in the thread, not per message.
- An offer with no cancel link. If the offer reply has no click-to-cancel link, an emailed offer may not meet the online rule in 17602(e)(2). Send the link, or skip the offer for California customers.
- Picking the wrong subscription. A household with two pets may hold two subscriptions. Ask; don't infer from the product the customer mentions.
- Promising a pause Recharge can't make. Map "pause" to a date change or a handoff before the agent replies.
- Sending two cancellation emails. Loop's
notifyCustomerdefaults to true. If your agent also replies "you're cancelled", decide which message the customer should get. - Leaking tool errors. "Our Loop integration returned 401" belongs in the internal note, never in the reply.
Where Macha fits
Macha fits teams at subscription brands running Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom that want skip, pause and cancel handled inside the ticket, including the multi-subscription shoppers native AI agents hand off. The help desk and Stripe connectors are built in. Recharge, Loop and Skio connect through a custom API tool that Macha's team sets up during onboarding, included on every plan. Billing is per ticket, so a save, a cancel and a handoff each cost one ticket: at 10,000 subscription tickets a month that's the 10,000-ticket tier at $3,999, about $0.40 a ticket. It's the wrong fit if you're on Gorgias and your subscribers mostly hold one subscription, because Gorgias AI Agent's Actions already cover skip and cancel there. See Macha's pricing or start with $50 of free usage (about 125 tickets), no credit card, no time limit.
FAQ
Can an AI agent cancel a subscription automatically? Yes, if it has a write tool for the subscription app and an instruction that says when to use it. Loop, Recharge and Skio document cancel endpoints, and Stripe's API cancels immediately or at period end. The agent should confirm the customer still wants to cancel, call the tool, and only confirm after the tool returns success.
Is it legal for an AI agent to make a retention offer before canceling? In California, for contracts made from 1 July 2025, a business can present a retention offer if it tells the customer they can still cancel (by phone) or shows a click-to-cancel link or button beside it (online), and must then process the cancellation promptly. The statute lists a business-provided cancel email as an online method, so the cautious choice for an emailed offer is to include a cancel link, or to make no offer to California customers. Confirm the right option with counsel. The FTC's 2024 click-to-cancel rule was vacated in July 2025, and the FTC opened new rulemaking in March 2026. This isn't legal advice.
Can an AI agent pause a Recharge subscription? Not through Recharge's 2021-11 API, which has no pause endpoint. Customers can pause in Recharge's customer portal. An agent can skip queued charges or move the next charge date through the API instead, or hand the pause to a person.
Should an AI agent cancel a Stripe subscription immediately or at period end? At period end in most cases. Stripe's default cancel takes effect at once and a canceled subscription can't be reactivated, while cancel_at_period_end lets the customer keep the time they paid for and can be reversed until the period ends.
When should an AI agent hand a cancellation to a person? When a tool returns an error, when there's no write tool for the change, when the customer holds several subscriptions and won't say which, when a refund or chargeback comes with the cancel, and for prepaid plans with orders left. The agent should leave an internal note with the subscription id and what it tried.
Does Macha have a built-in Recharge or Loop connector? No. Recharge, Loop and Skio connect through a custom API tool that Macha's team sets up during onboarding, using the app's own API token. Stripe and the help desks are built-in connectors.
How we researched this
On 28 September 2026 we read California AB 2863 on leginfo.legislature.ca.gov (Business and Professions Code 17602(d), (e), (f) and (j)); the FTC's Negative Option Rule page for the February 2026 Federal Register notice and the 13 March 2026 advance notice; 15 U.S.C. 8403 on Cornell's LII; Stripe's docs on canceling subscriptions and pausing payment collection; Loop's reference pages for cancel and pause; Recharge's 2021-11 API reference; Skio's API docs at code.skio.com; Loop's Shopify App Store listing; and Gorgias's help center article on AI Agent Recharge actions. We read the Eighth Circuit's July 2025 opinion in Custom Communications v. FTC (No. 24-3137), which vacates the rule, and cite the FTC page for the agency's follow-up actions. The description of Macha's Stripe tools comes from the tool list on our Macha Demo org, read the same day. Loop's $399 plus 0.75% is its own listing's price.
What ran live: we created two custom tools on Macha Demo ("T4-007 Loop: Find subscriptions by email", GET, and "T4-007 Loop: Cancel subscription", POST, Write) with a placeholder key and pressed Test on each (Loop returned HTTP 401 "Invalid token" to both); echoed the cancel tool's request shape to httpbin.org with two temporary tools, since deleted; and ran the agent "T4-007-Skip pause cancel" with Macha's test run on made-up d3v-macha tickets #1148, #1149 and #1150. The test run writes to the real sandbox ticket, which is why the replies, notes and tags appear in Zendesk. No Stripe or Shopify write tool was attached or called. We never made a successful Loop or Recharge write.
Arithmetic: 10,000 tickets on the $3,999 tier is $3,999 ÷ 10,000 = $0.40 a ticket. All names, emails, ticket text and subscription ids in the examples are synthetic.
Resolve tickets automatically with AI agents
Macha's AI agents work on top of the help desk you already use — no code.

