This asks for customer and subscription tables in bitborg-web's schema. The approved design puts all
billing state in a separate gitborg_payment database owned by a separate private service — the
portal keeps sign-up and the account panel, and Kanidm group membership is the integration seam. Adding
these tables here would duplicate the owning service's schema in a repo that has no business writing it,
which is the specific outcome the design's state-ownership section rules out.

The tables exist, correctly, in the payment service — including the customer, subscription,
seat_assignment, charge, invoice, provider_event and refund tables, with migrations and
constraints reviewed.

The issue was never triaged (needs-triage) and predates that decision, so there is nothing here to
rescope — the work it describes should not happen in this repository at all.

What genuinely remains for the portal is the upgrade UI and the typed client calls into that service,
behind the existing PAYMENTS_ENABLED flag (src/lib/payments-access.ts). Filed separately as #145 so
the remaining scope is stated accurately rather than inherited from a superseded plan.

Closing as **superseded by the approved architecture**, not as done. This asks for `customer` and `subscription` tables in bitborg-web's schema. The approved design puts all billing state in a **separate `gitborg_payment` database owned by a separate private service** — the portal keeps sign-up and the account panel, and Kanidm group membership is the integration seam. Adding these tables here would duplicate the owning service's schema in a repo that has no business writing it, which is the specific outcome the design's state-ownership section rules out. The tables exist, correctly, in the payment service — including the `customer`, `subscription`, `seat_assignment`, `charge`, `invoice`, `provider_event` and `refund` tables, with migrations and constraints reviewed. The issue was never triaged (`needs-triage`) and predates that decision, so there is nothing here to rescope — the work it describes should not happen in this repository at all. What genuinely remains for the portal is the **upgrade UI and the typed client calls** into that service, behind the existing `PAYMENTS_ENABLED` flag (`src/lib/payments-access.ts`). Filed separately as #145 so the remaining scope is stated accurately rather than inherited from a superseded plan.

supernaut refererade till detta ärende

2026-08-01 14:49:39 +00:00

payments: the portal's upgrade surface and typed calls into the payment service #145

supernaut stängde ärendet

2026-08-01 14:49:48 +00:00

Logga in för att delta i denna konversation.

Ingen milstolpe

Inget projekt

Inga tilldelade

1 deltagare

Notiser

Förfallodatum

Förfallodatumet är ogiltigt eller utanför gränserna. Använd formatet "åååå-mm-dd".

Inget förfallodatum satt.

Beroenden

Inga beroenden satta

Referens

bitborg/bitborg-web#34

Ingen beskrivning angiven.

Rader
Kolumner