An add-on whose payment is due shows no state and is offered again #258

New Issue

2026-10-24T06:24:50Z

cgalo5758 commented

2026-10-24 06:24:50 +00:00

What happens

When an add-on's renewal payment fails, its subscription turns past_due and the console suspends what it delivers. The add-ons section of the Products page does not show this. buildAddonsData in internal/server/member_addons.go lists every published, public product that is not a plan tier and reads nothing the organization holds, so the add-on reads exactly as it did before the member bought it: no "payment due", no way to pay, and Add, which starts Checkout for a new subscription.

A member who sees the add-on stop working and buys it again gets a second subscription. When the first recovers, both bill.

What should happen

A held add-on whose payment is due reads as payment due on the add-ons section, with a way to pay the open invoice, as a plan does (#148), and the member is not led into a second subscription to get back what the first one already pays for.

Where

internal/server/member_addons.go (buildAddonsData), internal/embeds/templates/partials/member_addons.html. Products on no ladder can be bought more than once by design, so whether Add stays offered beside a held add-on follows that rule (#3 is about holding one several times).

Steps

A member's organization buys an add-on.
The add-on's renewal payment fails; Stripe marks the subscription past_due.
The Products page lists the add-on with Add and no state.
Buying it again creates a second subscription for the same product.

Why it matters

The member is not told that a payment is due, and the page's only control leads to paying twice.

### What happens When an add-on's renewal payment fails, its subscription turns `past_due` and the console suspends what it delivers. The add-ons section of the Products page does not show this. `buildAddonsData` in `internal/server/member_addons.go` lists every published, public product that is not a plan tier and reads nothing the organization holds, so the add-on reads exactly as it did before the member bought it: no "payment due", no way to pay, and Add, which starts Checkout for a new subscription. A member who sees the add-on stop working and buys it again gets a second subscription. When the first recovers, both bill. ### What should happen A held add-on whose payment is due reads as payment due on the add-ons section, with a way to pay the open invoice, as a plan does (#148), and the member is not led into a second subscription to get back what the first one already pays for. ### Where `internal/server/member_addons.go` (`buildAddonsData`), `internal/embeds/templates/partials/member_addons.html`. Products on no ladder can be bought more than once by design, so whether Add stays offered beside a held add-on follows that rule (#3 is about holding one several times). ### Steps 1. A member's organization buys an add-on. 2. The add-on's renewal payment fails; Stripe marks the subscription `past_due`. 3. The Products page lists the add-on with Add and no state. 4. Buying it again creates a second subscription for the same product. ### Why it matters The member is not told that a payment is due, and the page's only control leads to paying twice.

cgalo5758 added the

kind

bug

area/billing area/member-ui labels 2026-10-24 06:24:50 +00:00

cgalo5758 referenced this issue from a commit

2026-10-26 20:16:32 +00:00

Let a member pay a plan's unpaid invoice on Stripe's page

Sign in to join this conversation.