Deleting a Stripe Coupon Does Not Remove Existing Discounts

1. Decide whether to close the offer or end a benefit

Deleting a Stripe coupon stops it from being applied to future subscriptions or invoices. It does not remove a discount from a subscription or invoice that already has it.[1] A campaign can therefore be closed to new applications while existing subscribers continue receiving the benefit.

These are different objects: a coupon defines the discount logic; a promotion code is a customer-facing code associated with a coupon; a Discount represents an application of that coupon.[1] Recommendation: write down the desired customer outcome before selecting a delete operation. “Stop accepting this offer” and “stop discounting these subscribers” require separate decisions.

The distinction addresses a real integration question. A developer asked how to remove a coupon during a subscription update and reported that passing Ruby nil omitted the field from the request.[4] This historical question demonstrates qualitative demand, not current Stripe behavior or a universally valid SDK workaround.

2. Choose the narrowest shutdown operation

• End new applications of the underlying offer: delete the coupon. Stripe documents DELETE /v1/coupons/{COUPON_ID}; successful deletion returns its ID and a deleted flag, not proof that existing discounts were removed.[2]
• Stop one customer-facing code: use the promotion code’s active control rather than deleting a coupon shared by other codes. Multiple promotion codes can reference one coupon.[1]
• End an already applied subscription benefit: remove or update discounts on the affected subscription. Stripe separately documents a subscription discount removal endpoint.[3]

Coupons cannot simply be deactivated; deleting one archives its associated promotion codes. If the underlying coupon becomes invalid, its promotion codes become permanently inactive and cannot be reactivated.[1] Recommendation: inventory associated codes before deletion and do not treat it as a reversible pause button.

3. Remove one benefit without losing the others

For a subscription discount, Stripe documents DELETE /v1/subscriptions/{SUBSCRIPTION_ID}/discount. The endpoint removes the currently applied discount and can return an error if no discount exists.[3] Do not interpret that singular endpoint description as instructions for selectively editing a stack.

For subscriptions using discounts, omit that parameter if existing discounts should remain unchanged. When updating it, pass every previously set coupon, promotion_code, or discount that you intend to keep. Pass discounts = "" to clear all subscription-level discounts.[1]

Illustrative decision: a subscription has a campaign discount and a negotiated loyalty discount. If only the campaign benefit must end, prepare an update retaining the loyalty entry, not a blanket clear. Preserve the intended order: Stripe warns that applying percentage and fixed-amount discounts in different orders changes the result.[1]

Recommendation: inspect your SDK’s actual request encoding in a sandbox. Do not assume an omitted parameter, null, an empty collection, and the documented empty string are interchangeable. Once multiple discounts have been set through discounts, Stripe disallows updating that subscription using the deprecated coupon or promotion_code parameter.[1]

4. Check the customer and invoice, not just the subscription

Clearing subscription-level discounts is not proof of an undiscounted next invoice. Stripe states that when a subscription has no discounts, the customer-level discount, if any, applies to invoices. It also supports discounts on subscription items.[1] Recommendation: inspect customer, subscription, item, and invoice-level discount information before declaring the benefit ended; handle any additional scope through its own documented operation.

An empty subscription discount list is also not proof that a coupon never applied. For a duration=once coupon, Stripe removes the consumed discount from the subscription’s list after the invoice finalizes, while the consuming invoice retains the applied discount.[1] Support should inspect the relevant invoice rather than infer history from the current subscription alone.

5. Keep invoice timing separate from campaign retirement

Updating discounts alone does not incur prorations or generate an invoice; the new discounts apply the next time the subscription creates an invoice. Combining a discount change with a proration-triggering change, such as an item quantity change, uses the updated pricing and discounting state for proration calculations.[1] Recommendation: isolate a discount-only change when that is the actual business request, and separately review any accompanying plan or quantity migration.

Illustrative case A: a campaign closes today but existing subscribers were promised the redeemed benefit. Delete the coupon to block future applications and leave their existing discounts alone; deletion does not withdraw them.[2]

Illustrative case B: an approved subscription benefit must end. Update that subscription’s discount state, preserve any other agreed benefits, and inspect the next invoice calculation and customer-level fallback.[1] Treat customer notice and authorization as separate business controls. Neither example is a procedure for correcting finalized invoices or recovering historical discounts.

6. Verify the intended boundary before production

The following are recommended checks, not tests performed for this article:

1. Record the coupon ID, associated promotion code IDs, affected subscriptions, retained discounts, and approved effective date.
2. In a sandbox, separate two checks: a fresh attempt to apply the retired coupon, and retrieval of a subscription that already used it. Expected behavior is blocked new application without automatic withdrawal of the existing discount.[1]
3. Exercise a selective stack update and an all-discounts clear separately. Compare the retained entries and their order with the approved result.
4. Inspect customer-level fallback, subscription items, and the relevant invoice. Include a once-only coupon already consumed by a finalized invoice.[1]
5. Record actual request encoding and responses. A repeated coupon deletion can error because the coupon is already deleted; discount removal can error because no discount exists. Reconcile the current state rather than reporting every retry as a new successful change.[2][3]

7. Scope, sources, and dates

This is documentation research checked on 2026-09-23, not a live-account test, a PayIn capability claim, or legal, tax, or financial advice. The cited documentation does not establish a country-by-country availability matrix. Confirm account support, API version, SDK encoding, and customer commitments before production. Open Checkout Sessions, scheduled future changes, historical invoice corrections, and bulk migrations need separate review; no behavior for those cases was tested here.

Official Stripe documentation supports technical statements. The community question supports qualitative demand only. Retrieval dates are not publication dates; unstated publication and update dates remain unknown.

1. [1] Coupons and promotion codes — Publication and update dates not stated. Checked 2026-09-23.
2. [2] Delete a coupon — Publication and update dates not stated. Checked 2026-09-23.
3. [3] Delete a subscription discount — Publication and update dates not stated. Checked 2026-09-23.
4. [4] Remove Coupon from Stripe Subscription in Update — Published 2019-10-30; update date not stated. Checked 2026-09-23.