A past-due subscription loses its plan at once, with no grace period #255

Open
opened 2026-10-24 06:21:34 +00:00 by cgalo5758 · 0 comments
Owner

The question

When a renewal payment fails, Stripe marks the subscription past_due and keeps retrying the card for days. The console suspends the plan at once: classifyStatus in internal/fulfillment/reconcile.go puts past_due with unpaid and paused as suspended, so the member loses every entitlement of the plan at the first failed attempt, often before a retry that would have succeeded. The data model describes past_due differently: its subscription status table in design/data-model.md reads "Payment failed, grace period", with the plan kept active for a configurable time.

Should a past-due plan keep delivering for a grace period, and if so, how long by default, and who sets it?

What depends on the answer

  • Whether the reconcile suspends on past_due at once or only when the grace period ends, and what ends it: a scheduled check in the console, or Stripe's own move to unpaid or canceled.
  • What the member sees during the grace period. The plan card and the entitlements panel show "payment due" while the plan is suspended (#148); a plan that still delivers needs its own line.
  • Whether the setting belongs to the deployment or to each product, and whether unpaid (Stripe's retries exhausted) is treated like past_due.

Options known so far

  • Keep suspending at once, as today, and correct the data model's table.
  • A deployment setting for the grace period, default zero, so nothing changes until a deployment sets it.
  • Deliver while past_due and suspend on unpaid. Stripe's retry settings, which the account holder sets in the Stripe dashboard, then decide how long the grace lasts, and the console adds no timer.

Decided when

The rule for a past-due plan, its default, and what the member sees during a grace period are written in the subscription management spec.

### The question When a renewal payment fails, Stripe marks the subscription `past_due` and keeps retrying the card for days. The console suspends the plan at once: `classifyStatus` in `internal/fulfillment/reconcile.go` puts `past_due` with `unpaid` and `paused` as suspended, so the member loses every entitlement of the plan at the first failed attempt, often before a retry that would have succeeded. The data model describes `past_due` differently: its subscription status table in `design/data-model.md` reads "Payment failed, grace period", with the plan kept `active` for a configurable time. Should a past-due plan keep delivering for a grace period, and if so, how long by default, and who sets it? ### What depends on the answer - Whether the reconcile suspends on `past_due` at once or only when the grace period ends, and what ends it: a scheduled check in the console, or Stripe's own move to `unpaid` or `canceled`. - What the member sees during the grace period. The plan card and the entitlements panel show "payment due" while the plan is suspended (#148); a plan that still delivers needs its own line. - Whether the setting belongs to the deployment or to each product, and whether `unpaid` (Stripe's retries exhausted) is treated like `past_due`. ### Options known so far - Keep suspending at once, as today, and correct the data model's table. - A deployment setting for the grace period, default zero, so nothing changes until a deployment sets it. - Deliver while `past_due` and suspend on `unpaid`. Stripe's retry settings, which the account holder sets in the Stripe dashboard, then decide how long the grace lasts, and the console adds no timer. ### Decided when The rule for a past-due plan, its default, and what the member sees during a grace period are written in the subscription management spec.
cgalo5758 added the
kind
design
area/entitlementsarea/billingarea/member-ui
labels 2026-10-24 06:21:34 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#255