Backed by: @pithy-sh/payments. Scope: payments:subscriptions:read.
What it shows
The recurring subset of purchases. What each one grants is entitlements, what your Worker does with that is resolving them, and what ends one is refunds and lapses.
The purchases that renew — the product, the rail, the subject, the period, and the state.
Grace still grants
A subscription in its billing-retry period keeps its entitlements, because that is the point of grace: a failed card should not lock a paying subscriber out mid-period.
Once grace is exhausted the purchase moves to on-hold, which never grants.
That behavior is a config flag on your project, defaulted to true.
A lapse can arrive with no notification at all
Repairing a stale row is the reconciliation Workflow’s job. A read never writes.
Lapsed rows are shown, not hidden
With their dates intact.
A paywall wants to say your Pro ended on the 4th — and it can only do that if the row and its date survive the read. The same is true of this pane.
One renewal is one transaction
A subscription’s ledger grant fires once per billing period, because each renewal is a distinct provider transaction.
What a rail’s own console will not tell you
Which entitlement key a subscription grants, because that is your model rather than theirs.
This pane joins the two — the store’s renewal and your own catalog.
Every read is audited
Including the ones that found nothing.