feat(payments): add subscription lifecycle, renewal invoices and plan-based write access

[Priyanshubhartistm]

Description

Builds on the subscription data model (#849). Nothing changes unless payments.enabled is true and payments.subscriptionPlans is non-empty.

• POST /invoices takes a planId (instead of a fee schedule) when plans are configured. The invoice is created for the plan price and stores the plan.
• PaymentsService.confirmInvoice starts or extends the subscription in the same transaction as the invoice confirmation, and admits the user. The plan comes from the stored invoice, so the five confirmation paths (maintenance poll and the Zebedee/LNbits/OpenNode/Nodeless callbacks) need no change. A payment below the plan price does not start or extend a period.
  • A payment while access is still running extends from the current period end (paying early loses nothing); after access lapsed, or off the grandfathered plan, the period starts now.
• New SubscriptionService.processLifecycle, run from the maintenance worker each minute: moves subscriptions whose period ended into grace (counted from the period end) or straight to expired (plan has no grace), expires subscriptions whose grace is over, and about three days before a period ends creates a renewal invoice and marks it renewal_pending. Each pass is bounded and a stuck row cannot loop it.
• isUserAdmitted checks the subscription behind the existing admission cache (no extra read per event). Access is judged from the dates, not only the stored status, so a lagging sweep neither locks anyone out nor keeps them in, and the admitted cache entry never outlives the end of access. Admitted users with no subscription row (admitted after the migration, or by invite code / NIP-43) keep access.
• With plans configured and no enabled admission fee, a plan is what admits a user. Pubkeys whitelisted on an admission fee schedule still bypass.
• CONFIGURATION.md describes the behaviour; the .knip.json ignore for the new repository is removed now that it is used.

Related Issue

Closes #908

Motivation and Context

With the data model in place nothing created or ended a subscription: write access still depended only on the permanent is_admitted flag. This adds the billing lifecycle (subscribe, renew, grace, expire) on the existing processors.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4667dc0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
nostream	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coveralls]

Coverage Report for CI Build 39453853954

Coverage increased (+0.4%) to 74.21%

Details

• Coverage increased (+0.4%) from the base build.
• Patch coverage: 1 uncovered change across 1 file (211 of 212 lines covered, 99.53%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
src/app/maintenance-worker.ts	7	6	85.71%
Total (12 files)	212	211	99.53%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	11255
Covered Lines:	8753
Line Coverage:	77.77%
Relevant Branches:	5903
Covered Branches:	3980
Branch Coverage:	67.42%
Branches in Coverage %:	Yes
Coverage Strength:	800.08 hits per line

---

💛 - Coveralls

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The PR changes recurring payment and write-access behavior for relays using subscription plans.

The PR still needs a paging fix so permanently failed rows cannot block later subscribers.

Findings

1.  Failed rows block other subscribers ▶

Summary

Adds subscription payments, renewal invoices, and date-based write access when plans are enabled.

• People can buy a subscription plan through the invoice page.
• Subscriptions get renewal invoices and move through grace to expired.
• Write access follows subscription dates when plans are enabled.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Choose a plan] --> B[Create invoice]
  B --> C[Payment confirmed]
  C --> D[Start or extend subscription]
  D --> E[Period nearing its end]
  E --> F[Create renewal invoice and send notice]
  F --> C
  D --> G[Period ends unpaid]
  G --> H[Grace or expiry]
  H --> I[Write access ends]

Loading

_{Reviews (2) · Last reviewed commit: "fix(payments): address subscription revi..." · Reviewed by Greptile}