# Fixing "agent cancelled the wrong subscription: matched on name instead of id"

## TL;DR

Never cancel by name. Resolve the exact subscription id first, then show the customer name, plan, and amount back for confirmation before cancelling. The cancel call itself takes only the id. Name matching is the bug.

```text
agent cancelled the wrong subscription: matched on name instead of id
```

## Steps

1. Change the cancel flow to require a subscription id (for example sub_xxx) as input, never a name or email.
   Expected: The code cannot compile or run a cancel without an id in hand.
2. Add a lookup step: given a customer, list their subscriptions and pick by id, displaying plan name, amount, and status for each.
   Expected: The agent sees exactly which subscription it is about to cancel.
3. Add a confirmation gate showing customer name, plan, billing amount, and next renewal date, requiring explicit approval.
   Expected: A wrong pick is visible to a human before anything is cancelled.
4. Log the id, the actor, and the confirmation for every cancellation.
   Expected: Any wrong cancel is traceable to the exact decision point.

## Prevention

Names are not unique and plan names repeat across customers. Design the flow so the id is resolved once, early, and carried through; every later step references the id, never a re-derived name search.

## Detection

Watch cancel webhooks and compare each cancelled id against the intended id in your task log. Alert when a cancel targets a subscription whose customer name differs from the one in the request. Review any cancel that happened without a logged confirmation.

## Recovery

Most providers let you reactivate a recently cancelled subscription within a grace window; do that immediately. If reactivation is not possible, recreate the subscription with the same plan and price, backdate the start if the provider allows, and notify the customer with an apology and a service credit. Fix the flow before the next cancel.

## When this applies

- A cancel request named a customer and the wrong one of their subscriptions was cancelled
- The agent searched subscriptions by plan name or customer name
- Two subscriptions share a name and the agent picked the first result

## When it doesn't

- The right subscription was cancelled but the customer disputes wanting it cancelled (that is a consent problem)
- The provider failed to cancel after receiving the correct id
- You are cancelling all of a customer's subscriptions on purpose

## Compatibility

Stripe API (subscription ids, cancel and reactivate), Adyen (recurring contract disable by reference), PayPal REST API v2 (subscription suspend and cancel by id), Chargebee and Recurly subscription ids.

### agent cancelled a subscription by customer name

### wrong subscription cancelled when a customer had two plans

### cancel matched the plan name instead of the subscription id

## Why it happens

Language is name-shaped: customers say "cancel my pro plan," so the agent searches by the words it heard. Search returns the first match, which is often another customer's subscription or the customer's older, already-cancelled one that still matches the name.

## Edge cases

- Customers with multiple active subscriptions on the same plan: the list-and-confirm step is mandatory, not optional
- Recently cancelled subscriptions still appear in searches; filter to active and trialing before presenting choices
- Test-mode ids and live-mode ids look alike; confirm the environment matches before cancelling

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LgDjxlK6vikSnzIDnLoM7g