Plany & Billing

Per-app, per-bundle, per-seat, tiered, multi-currency. Stripe Connect pod spodem.

Plany & Billing

Każda apka którą rejestrujesz może sprzedawać subskrypcje. WolfieAuth obsługuje cały pricing → checkout → recurring → invoicing pipeline. Pieniądze płyną na konto Connect Twojego klienta; platforma bierze 5% fee śledzony lokalnie i fakturowany przez KSeF miesięcznie.

Plan scopes

Plan może być scoped na dwa sposoby:

• Per-App (default) — każdy plan żyje na jednym OidcClient. Większość apek tak robi.
• Per-Bundle (opt-in) — pojedyncza subskrypcja daje dostęp do każdej apki w AppBundle. Używaj dla “Premium tier odblokowuje CRM + Mail + Storage”.

Oba ciągną pieniądze na to samo connected Stripe account (org-a właściciela). Wybór jest tylko o organizacji katalogu.

Modele cenowe

Tworzenie planu

/admin/clients/<your-app-id>#plans → + Nowy plan:

1. Nazwa (np. “Pro”) — slug auto-derive z nazwy z diacritic folding (“Plan Złoty” → plan-zloty)
2. Opis, color, feature flagi (free-form stringi które Twoja apka interpretuje, np. ksef_enabled, unlimited_storage)
3. Klik “Add price” → otwiera modal z pełnymi opcjami
4. Save → plan istnieje w DB. “Sync to Stripe” button → provisionuje Stripe Product + Price na Twoim Connect account.

Per-seat z auto-bump

Per-seat plany mają quirk: gdy admin org zaprasza nowego członka, seat count musi bumpnąć w górę. Inaczej masz 5 płatnych seatów i 7 active członków, gdzie #6 i #7 są effectively darmowe.

WolfieAuth obsługuje to automatycznie. Na każde successful invite:

1. Nowy OrgMembership rząd wstawiony
2. checkSeatCapBeforeAdd() biegnie przeciwko aktywnej subskrypcji
3. Jeśli new member count > current quantity:
     stripe.subscriptions.update(sub.id, {
       quantity: newCount,
       proration_behavior: "create_prorations",
     })
4. Stripe charge-uje prorated różnicę na następnej fakturze

Reverse na revoke — auto-decrement, credit na następnej fakturze. Floor na quantity=1.

Comp overrides (“free pass per user”)

Czasami chcesz comp-ować konkretne konta — founding customers, beta testerzy, employee z personal accountami, partner orgi. WolfieAuth ma per-(user, app) override:

/admin/clients/<app-id>#users → ∞ toggle obok user-a

OIDC claim emitter syntetycznie wstrzykuje ACTIVE plan entry do wolfieauth_plans[]:

{
  "planSlug": "comp",
  "planName": "Complimentary",
  "status": "ACTIVE",
  "appClientId": "wolfie-wolfiecrm",
  "features": [],
  "currentPeriodEnd": null
}

Helpery SDK (hasActiveFeature, etc.) traktują to dokładnie jak płatną sub. User nie wie że jest comp-ed — dostaje experience, Ty nie dostajesz billingu.

Money flow + platform fee

Klient płaci $99/miesiąc za "Pro" plan na Twoim CRM
  ↓
Stripe Connect routuje $99 na connected acct Twojego klienta (jego org)
  ↓
WolfieAuth śledzi $4.95 (5%) jako platform fee row
  ↓
Monthly aggregator job biegnie 1-go każdego miesiąca
  ↓
Generuje fakturę KSeF wolfiecrm dla aggregate fee tego miesiąca
  ↓
Klient org płaci platform invoice przez Stripe / przelew

5% rate jest configurable per-org (override w admin); default 5%.

wolfieauth-platform sam

WolfieAuth chargeuje customer orgi za używanie WolfieAuth. Plan “Pro” na self-clientcie wolfieauth-platform ma defaultowy kształt:

• 3 seaty darmowe, $5/seat dalej
• billing_scheme: tiered, tiers_mode: graduated, usage_type: licensed
• Pieniądze idą bezpośrednio na platform Stripe account (nie Connect — inna ścieżka kodu)

Członkowie platform-owner org-u (wolfie org) automatycznie dostają syntetyczny plan platform-owner-grant przez OIDC claim emitter — nie muszą subskrybować się sami siebie.

Czytaj dalej

• Stripe i tryb testowy — jak przetestować billing end-to-end z fake-cardami zanim wejdziesz na żywe pieniądze
• Admin — Plans panel, Comp toggle, Sync to Stripe button
• SDKs — @wolfieauth/sdk-paywall dla embedded checkout

Ostatnia aktualizacja: 2026-05-03