Stripe coupon duration_in_months vs forever: invoice impact

Not specified by the original author.

TL;DR

A Stripe coupon with durationinmonths discounts exactly that many invoice cycles and then drops off; forever keeps discounting until removed. The invoice impact is identical in the early months, which is why the wrong choice surfaces later as a surprise full-price invoice. Pick durationinmonths for promotions with an end date and forever only for negotiated permanent pricing. Record the choice on the customer record so support can answer 'why did my bill go up' in one look.

The query

Stripe coupon "duration_in_months" vs "forever": invoice impact

Use this when

• Promo pricing that should end after N months
• A customer complaining their bill went up after a promo ended
• Deciding coupon duration for a negotiated deal

Not for

• One-off credits (use customer balance or invoice-level discounts)
• Trials (use trial periods, not coupons)

Steps

1. Decide the commercial intent: fixed-term promo or permanent negotiated price. Expected output: The choice maps to durationinmonths or forever.

2. Create the coupon with duration set to in_months and the count, or forever. Expected output: The coupon object encodes the intended lifespan.

3. Apply it to the customer or subscription and preview the next few invoices. Expected output: You see the discount fall off at the right cycle.

4. Note the coupon and its end date on the customer record or in your CRM. Expected output: Support can explain future bill changes instantly.

5. Set a reminder or webhook check before the final discounted invoice. Expected output: The customer is warned before the price steps up.

Variant phrasings

Stripe coupon durationinmonths vs forever

coupon expires after N months Stripe invoice

Stripe promo pricing end date

Root cause

The duration lives on the coupon because Stripe applies the same coupon object across invoices over time; it needs to know when to stop. durationinmonths counts invoice cycles for that subscription, not calendar months from creation, which matters for paused or irregular billing.

Edge cases

• A coupon applied at the customer level affects all their subscriptions; scope it if needed
• Removing a forever coupon mid-negotiation requires an explicit removal; it never self-expires

Provenance

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

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

Thread query: Stripe coupon "durationinmonths" vs "forever": invoice impact

TL;DR: A Stripe coupon with durationinmonths discounts exactly that many invoice cycles and then drops off; forever keeps discounting until removed. The invoice impact is identical in the early months, which is why the wrong choice surfaces later as a surprise full-price invoice. Pick durationinmonths for promotions with an end date and forever only for negotiated permanent pricing. Record the choice on the customer record so support can answer 'why did my bill go up' in one look.

Not specified by the original author.

TL;DR

redeemby is a hard expiry on the coupon: any invoice created after that timestamp gets no discount. Extend redeemby, create the invoice before the deadline, or replace the coupon. Check the invoice created date against the coupon redeem_by timestamp to confirm.

coupon redeem_by invoice no discount

Use this when

• A coupon attached to a customer or subscription shows no discount on the invoice.
• redeem_by is set and the invoice was created late.
• You need to decide whether to extend the coupon or issue a credit.

Not for this skill when

• The coupon was rejected when you tried to attach it. That is an invalid-coupon error, not an expiry.
• The discount shows on some invoices but not others. That is a duration (once/repeating) setting.

Steps

1. ('Compare the invoice created timestamp with the coupon redeemby timestamp. Verify: created is after redeemby.', 'Check the coupon duration setting too: a once coupon is consumed by the first invoice. Verify: no earlier invoice already consumed it.', 'If the promotion is still valid, update the coupon with a new redeem_by or create a replacement coupon. Verify: the new coupon is attachable.', 'For the already-created invoice, void it and re-invoice, or apply a discount credit. Verify: the new invoice shows the discount line.', 'Tell finance the coupon expired mid-cycle so the write-off is recorded correctly.')

Variant phrasings

stripe coupon expired no discount invoice

Symptom search.

redeem_by passed coupon still attached

State-observation search.

stripe coupon not applied to invoice

Broader phrasing.

Compatibility: Stripe Billing coupons and invoices APIs, all client versions.

Why it happens

redeem_by makes the coupon unusable for any invoice created after the timestamp, but Stripe does not detach the coupon or warn you. The coupon sits on the customer looking valid while silently skipping every invoice past the deadline. Teams hit this when finance sets a promo end date and billing runs on a later cadence.

Edge cases / pitfalls

• Extending redeem_by does not retroactively fix invoices already created. Re-invoice or credit.
• A coupon with duration once applies to the first invoice only; redeem_by is a separate axis. Check both.
• Test clocks often sit before redeem_by, so this passes in tests and fails in production.
• Coupon IDs are immutable on some fields; sometimes replacing is cleaner than updating.

Provenance

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

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

Thread query: stripe coupon passed "redeem_by": invoice shows no discount applied

TL;DR: redeemby is a hard expiry on the coupon: any invoice created after that timestamp gets no discount. Extend redeemby, create the invoice before the deadline, or replace the coupon. Check the invoice created date against the coupon redeem_by timestamp to confirm.

Not specified by the original author.

TL;DR

On a Stripe invoice, coupons reduce the subtotal first and customer balance (credit) applies against what remains. So a 20 percent coupon plus a 50 credit on a 200 invoice yields 160 after the coupon, then 110 after the credit, not some other combination. When the numbers look off, check this order before assuming a bug. If you need a different effective order, convert one of the two into the other form: turn the coupon into a fixed credit or the credit into a coupon.

The query

Stripe discount stacking on invoices: coupon plus customer balance order

Use this when

• Invoice total wrong when a coupon and credit both apply
• Understanding Stripe discount application order
• Customer balance not reducing the invoice as expected

Not for

• Tax computation order (separate rules)
• Multiple coupons on one invoice (Stripe allows one coupon per customer/subscription by default)

Steps

1. Pull the finalized invoice and read the discount lines and the startingbalance / endingbalance fields. Expected output: You see the actual application order on the record.

2. Verify the coupon applied to the subtotal before the balance. Expected output: The math matches: coupon first, credit second.

3. If the coupon is percentage-based, confirm it computed on the pre-credit subtotal. Expected output: No double-dipping surprises.

4. If the business wants credit applied first, restructure: use a fixed-amount coupon instead of balance. Expected output: The effective order matches the commercial intent.

5. Document the order in your billing runbook for support. Expected output: Discount-stacking questions get a canonical answer.

Variant phrasings

Stripe coupon and customer balance order

discount stacking Stripe invoice

customer balance applied before or after coupon Stripe

Root cause

Coupons apply first because they are discounts on the sale itself, while customer balance is a payment-like credit against the amount owed. The invoice object models them in separate fields (discounts vs starting_balance), which is why the order is fixed rather than configurable.

Edge cases

• Negative invoice totals from over-stacking become customer balance credit automatically
• Proration invoices follow the same order; verify with the upcoming-invoice preview

Provenance

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

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

Thread query: Stripe discount stacking on invoices: coupon plus customer balance order

TL;DR: On a Stripe invoice, coupons reduce the subtotal first and customer balance (credit) applies against what remains. So a 20 percent coupon plus a 50 credit on a 200 invoice yields 160 after the coupon, then 110 after the credit, not some other combination. When the numbers look off, check this order before assuming a bug. If you need a different effective order, convert one of the two into the other form: turn the coupon into a fixed credit or the credit into a coupon.