Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#908 0 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@Priyanshubhartistm já está trabalhando nisso.

Desde 19/10/2026.

  • #909 de @Priyanshubhartistm — aberto

Avaliação

Esta issue ainda não foi avaliada.

Descrição

enhancement

Is your feature request related to a problem? Please describe.
With the subscription data model in place, nothing creates or extends a subscription, issues renewal invoices, or ends access when a period lapses. Write access still depends only on the permanent is_admitted flag.

Describe the solution you'd like

  • A SubscriptionService for subscribe, renew and status transitions (active → renewal_pending → past_due → expired).
  • PaymentsService.confirmInvoice extends the subscription period (same transaction as the invoice confirmation). All five confirmation paths (maintenance poll and the Zebedee/LNbits/OpenNode/Nodeless callbacks) already go through it, so the invoice carries its plan_id instead of each callback learning about plans.
  • POST /invoices accepts a plan id; existing admission behaviour is unchanged when no plans are configured.
  • A periodic sweep (maintenance worker) that issues renewal invoices before period end and moves overdue subscriptions through grace to expired.
  • isUserAdmitted checks for an active subscription, reusing the existing admission cache so there is no extra database read per event.
  • Tests for each transition, the confirm path, and the cache behaviour.

Additional context

  • Design: #673. Renewal is invoice-based: Lightning cannot pull funds, so the relay issues a renewal invoice and the user pays it.
Linguagem predominante
TypeScript
Estrelas
829
Forks
234
Merge médio
17h 46min
PRs com merge (30d)
73

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cameri/nostream

Todas as issues de cameri/nostream

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.