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.

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.

1. Verify the coupon applied to the subtotal before the balance.

Expected output: The math matches: coupon first, credit second.

1. If the coupon is percentage-based, confirm it computed on the pre-credit subtotal.

Expected output: No double-dipping surprises.

1. 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.

1. 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