Introduce a new Django app finance that integrates Stripe as the payment provider. Users complete payment on Stripe Checkout (hosted); we persist invoices and payments locally and drive subscription pricing from Django settings.
Related: #17 (token quotas / usage enforcement) — this ticket covers payment collection and ledger; #17 covers usage limits against paid plans.
Goals
New app: finance registered in INSTALLED_APPS
Stripe as the (initial) payment provider
Track invoices and payments in our DB
Subscription pricing values live in settings.py (env-backed)
Customer pays on Stripe’s hosted flow (Checkout / Customer Portal as appropriate) — we do not collect card details in our UI
Requirements
App & settings
Create finance Django app under the project
Add settings for Stripe + subscription pricing, e.g.:
Subscription price config (amount / currency / interval / Stripe Price ID mapping) in settings.py
Document required env vars in .env.example / .env.prod.example
Models
Invoice: link to user/company, Stripe invoice/session IDs, status, amounts, period, timestamps
Payment: link to invoice (and/or user), Stripe payment intent / charge IDs, amount, status, timestamps
Store provider name (e.g. stripe) so we can add other providers later without a rewrite
Stripe flow
API to create a Stripe Checkout Session (or equivalent) and return the redirect URL
User completes payment on Stripe
Webhook endpoint verifies signatures and upserts invoice/payment records on relevant events (checkout.session.completed, invoice.paid, invoice.payment_failed, etc.)
Idempotent webhook handling (safe retries)
Admin / API
Django admin for invoices and payments
Authenticated endpoints to start checkout and list own invoices/payments (as needed by FE)
Acceptance criteria
finance app installed and migrated
Subscription pricing configurable via settings / env
Checkout redirects user to Stripe to enter payment details
Webhooks create/update Invoice and Payment rows
Admin can inspect invoices and payments
Tests cover session creation (mocked Stripe), webhook verification, and model persistence
Secrets never committed; examples documented
Out of scope (unless needed for MVP)
Full Customer Portal UI for plan changes/cancellations (can follow-on)
Frontend self-serve registration (tracked in chat_web_app)
## Summary
Introduce a new Django app `finance` that integrates Stripe as the payment provider. Users complete payment on Stripe Checkout (hosted); we persist invoices and payments locally and drive subscription pricing from Django settings.
Related: #17 (token quotas / usage enforcement) — this ticket covers payment collection and ledger; #17 covers usage limits against paid plans.
## Goals
- New app: `finance` registered in `INSTALLED_APPS`
- Stripe as the (initial) payment provider
- Track **invoices** and **payments** in our DB
- Subscription pricing values live in `settings.py` (env-backed)
- Customer pays on Stripe’s hosted flow (Checkout / Customer Portal as appropriate) — we do **not** collect card details in our UI
## Requirements
### App & settings
- Create `finance` Django app under the project
- Add settings for Stripe + subscription pricing, e.g.:
- `STRIPE_SECRET_KEY`, `STRIPE_PUBLISHABLE_KEY`, `STRIPE_WEBHOOK_SECRET`
- Subscription price config (amount / currency / interval / Stripe Price ID mapping) in `settings.py`
- Document required env vars in `.env.example` / `.env.prod.example`
### Models
- **Invoice**: link to user/company, Stripe invoice/session IDs, status, amounts, period, timestamps
- **Payment**: link to invoice (and/or user), Stripe payment intent / charge IDs, amount, status, timestamps
- Store provider name (e.g. `stripe`) so we can add other providers later without a rewrite
### Stripe flow
- API to create a Stripe Checkout Session (or equivalent) and return the redirect URL
- User completes payment on Stripe
- Webhook endpoint verifies signatures and upserts invoice/payment records on relevant events (`checkout.session.completed`, `invoice.paid`, `invoice.payment_failed`, etc.)
- Idempotent webhook handling (safe retries)
### Admin / API
- Django admin for invoices and payments
- Authenticated endpoints to start checkout and list own invoices/payments (as needed by FE)
## Acceptance criteria
- [ ] `finance` app installed and migrated
- [ ] Subscription pricing configurable via settings / env
- [ ] Checkout redirects user to Stripe to enter payment details
- [ ] Webhooks create/update Invoice and Payment rows
- [ ] Admin can inspect invoices and payments
- [ ] Tests cover session creation (mocked Stripe), webhook verification, and model persistence
- [ ] Secrets never committed; examples documented
## Out of scope (unless needed for MVP)
- Full Customer Portal UI for plan changes/cancellations (can follow-on)
- Token quota enforcement (see #17)
- Frontend self-serve registration (tracked in `chat_web_app`)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Introduce a new Django app
financethat integrates Stripe as the payment provider. Users complete payment on Stripe Checkout (hosted); we persist invoices and payments locally and drive subscription pricing from Django settings.Related: #17 (token quotas / usage enforcement) — this ticket covers payment collection and ledger; #17 covers usage limits against paid plans.
Goals
financeregistered inINSTALLED_APPSsettings.py(env-backed)Requirements
App & settings
financeDjango app under the projectSTRIPE_SECRET_KEY,STRIPE_PUBLISHABLE_KEY,STRIPE_WEBHOOK_SECRETsettings.py.env.example/.env.prod.exampleModels
stripe) so we can add other providers later without a rewriteStripe flow
checkout.session.completed,invoice.paid,invoice.payment_failed, etc.)Admin / API
Acceptance criteria
financeapp installed and migratedOut of scope (unless needed for MVP)
chat_web_app)Frontend companion: ai_ml_operations/chat_web_app#31 (self-serve sign-up → Stripe Checkout).
Follow-on for Customer Portal / Account billing UI: ai_ml_operations/chat_web_app#33
ai_ml_operations/chat_web_app#33