Skip to main content
FASTCREDITS · FOR FINANCE & PROCUREMENT

Org balance, shipped today. Finance UX, shipping 2026.

The schema and the /v1/accounts handler accept owner_type=organization — so org-owned credits are operational right now. Bulk top-up, department budgets, reconciliation, invoice export are on the 2026 roadmap. We will say so plainly.

FastCredits offers organisations a single org-owned credit account today — owner_type=organization is shipped, the unique index on (owner_id, owner_type) deduplicates, the same hold/capture/refund grammar applies. The bulk-buy, department-budget, reconciliation, and invoice surfaces are 2026 roadmap; we are explicit about which surfaces are operational and which are mocked, because Nigerian healthcare procurement deserves honesty about what ships.
01 / 05

1 · Org-owned account

Create an org account through POST /v1/accounts with owner_type=organization and owner_id pointing at your organisation identifier. The unique index on (owner_id, owner_type) prevents duplicates; a duplicate-create call returns the existing account, which is exactly the post-registration semantics FastLogin uses for user accounts. The org account carries the same fields, the same balance and held columns, the same SERIALIZABLE write paths as a user account.

Your Balanceowner_type=organization · 1 credit = ₦1
St. Anne's Hospital · group account
1,250,000CREDITS
48,200 on hold across 27 active sessions
One ledger across the orgService tokens scope spendAppend-only · audit-grade
Top up
ORGANIZATION
fastcredits.fastclinic.xyz/dashboard
02 / 05

2 · Bulk top-up — coming 2026

Bulk top-up is on the 2026 roadmap. The plan is volume-tier pricing — five percent off at one million credits, eight percent at five million, ten percent at ten million — settled through Paystack's bulk-payment rail. The mock surface here is the shape we are designing toward: a tier picker, an estimate of effective price per credit, a single Paystack handoff for the lump sum, and the resulting top-up reflected on the org balance card.

Bulk top-upOrg owner_type

Buy CREDITS in volume — discount tiers apply automatically.

Starter0%
10K CREDITS
₦1.00 per credit
Growth5%
50K CREDITS
₦0.95 per credit
Scale10%
250K CREDITS
₦0.90 per credit
Enterprise15%
1M CREDITS
₦0.85 per credit
You pay₦225,000 (10% off)
Issue tax receipt (TIN required)✓ ON
Pay with Paystack
Coming 2026
fastcredits.fastclinic.xyz/finance/bulk-buy
03 / 05

3 · Department budgets — coming 2026

Department budgets are forward-looking. The plan is sub-allocations against the org account — Cardiology gets one million credits, Paediatrics gets eight hundred thousand, the ICU sits on a top-up rule — without splitting the underlying ledger. The shape is one org account with a department dimension on each transaction; the ledger primitives already support attribution columns, so when budgets ship, the migration is configuration rather than re-architecture.

Department budgetsApril 2026
DepartmentBudgetSpentRemaining
Cardiology50,00032,15017,850
Paediatrics30,00021,4008,600
Radiology40,00038,9201,080
General medicine60,00044,25015,750
Maternal health25,0009,80015,200
Reset monthly on the 1st✓ ON
Per-department holdsRadiology near capSlack alert at 80%
Coming 2026
fastcredits.fastclinic.xyz/finance/budgets
04 / 05

4 · Reconciliation dashboard — coming 2026

The reconciliation dashboard is on the 2026 roadmap. The plan is FHIR-grade attribution: each transaction reconciled against the originating service, the source clinical event (where it exists), the responsible cost centre, and the period-over-period delta. Today the underlying data is in the ledger as transaction rows; the dashboard that aggregates them into a finance-team-ready report is what 2026 unlocks.

Reconciliation dashboardLast 14 days
Hold · daily6,815
Capture · daily6,346
Release · daily216
Refund · daily57
Net debited (capture − refund)6,289 CREDITS
Download CSV
Coming 2026
fastcredits.fastclinic.xyz/finance/reconciliation
05 / 05

5 · Invoice export — coming 2026

Full invoice export with TIN is on the 2026 roadmap. Today, Paystack issues a receipt for every top-up with the org email; the FastCredits transaction feed gives you the full history of consumption. The 2026 surface adds the TIN-bearing invoice that finance teams need for VAT-period reconciliation, the period-grouped consumption summary, and a downloadable PDF with the org letterhead and the controller's NDPC particulars.

Invoice exportTIN 12345678-0001 · VAT 7.5%
PeriodCreditsVATTIN
Apr 2026320,400₦320,400₦24,03012345678-0001Download PDF
Mar 2026298,150₦298,150₦22,36112345678-0001Download PDF
Feb 2026271,800₦271,800₦20,38512345678-0001Download PDF
Jan 2026245,500₦245,500₦18,41312345678-0001Download PDF
YTD total₦1,135,850 + VAT ₦85,189
Email all
Download PDF

FIRS-compliant invoice format · Nigerian VAT 7.5%

Coming 2026
fastcredits.fastclinic.xyz/finance/invoices
What you get

Org-owned account, today

Create an org account with owner_type=organization through POST /v1/accounts; consume credits via /v1/accounts/:id/* the same way a user account does. The schema, the handler, the unique-index dedupe, and the SERIALIZABLE write paths are all shipped. Spend across every Fastclinic product the same way a patient does, scoped to your org identifier.

One ledger across every department, when budgets ship

The forward-looking budget surface keeps the org's balance as one number and adds a department dimension on each transaction rather than fragmenting the ledger across sub-accounts. The architectural decision is to attribute, not split — so the audit trail stays single-rooted and the reconciliation surface aggregates without joining across separate ledgers.

Immutable audit trail, today

BEFORE-UPDATE and BEFORE-DELETE triggers on the transactions table are operational right now; balance_after and held_after snapshots are on every row; the seven-year retention applies when the org account sits behind the consolidated audit chain. Your finance team can read the full ledger history through the service-token API.

FHIR-grade reconciliation, when 2026 unlocks it

The reconciliation surface will reconcile each transaction against the originating service, the source clinical event where it exists, the responsible cost centre, and the period-over-period delta. The shape is finance-team-ready output bound to clinical reality through the source_service column we already write to every row.

Capabilities

Ledger
  • Immutable transactions · BEFORE UPDATE/DELETE triggers
  • 5 transaction types · purchase, debit, refund, hold, release
  • balance_after / held_after snapshot per row
  • Append-only history · never re-derived
  • related_tx_id chains refund→debit, capture→hold
  • Currency code CREDITS · single allowed value
Concurrency
  • SERIALIZABLE isolation on every write
  • 40001 auto-retry · max 5 attempts
  • Backoff 5–200ms exponential with jitter
  • Optimistic version on accounts · bumped per write
  • SELECT FOR UPDATE on account row
  • No advisory locks · row lock is enough
Idempotency
  • UNIQUE(account_id, reference) index on transactions
  • capture:{ref} · release:{ref} · refund:{txID} grammar
  • Single-writer 409-is-success invariant
  • Webhook idempotency on Paystack reference
  • errIdempotentHit re-reads existing row
  • Refunds idempotent on refund:{txID}
Holds
  • DefaultHoldTTL 10 minutes · max 24 hours
  • Partial index WHERE status = 'active'
  • ExpireHolds background worker
  • Two-step authorize-capture pattern
  • release:{ref} returns held to balance
  • capture:{ref} finalises the debit
Cache & performance
  • Redis balance cache · prefix credits:balance:
  • TTL 5 minutes · best-effort fill on miss
  • Balance-only · held_total never cached
  • Invalidate on every write
  • Falls back to Postgres on cache outage
  • JWKS cache 5 minutes · singleflight on unknown kid
Compliance & residency
  • NDPA 2023 compliant · controller Fastclinic Limited
  • African data residency · single Nigerian region
  • Paystack as PCI-DSS-Level-1 processor
  • No PCI scope on FastCredits
  • Documented data-processing record
  • Append-only ledger · 7-year retention

Integrations

Fastclinic
FastLogin

Every FastCredits API call carries a Hydra-issued OAuth2 access token from fastlogin.fastclinic.xyz. The dashboard UI uses the fastcredits-public authorization-code-with-PKCE client, scoped to openid credits:read credits:write. Service callers (Doorcta, OneHealth, the FastLogin webhook itself) use the fastcredits-server client_credentials grant, scoped to services:credits. The middleware classifies tokens by client_id rather than sub-non-empty because Hydra 2.x stamps sub equal to client_id on client_credentials tokens. Account auto-creation runs on FastLogin's post-registration webhook with both 201 and 409 treated as success.

Fastclinic
Doorcta

Doorcta calls FastCredits at consultation start to PlaceHold against the patient's account, scoped to services:credits, with a duration that bounds the consult. On consultation end, Doorcta calls CaptureHold with the actual amount; on patient cancel, Doorcta calls ReleaseHold and the held credits return to balance. The Doorcta integration shape is locked at the API contract — POST /v1/accounts/:id/hold, POST /v1/holds/:id/{capture,release} — even though the active Doorcta caller is on the 2026 roadmap. The reference grammar (capture:{ref}, release:{ref}) makes every retry idempotent.

Fastclinic
OneHealth

OneHealth places a hold at session start and captures on session end. The hold TTL is computed from the session lifetime plus a one-hundred-twenty-second buffer rather than the FastCredits ten-minute default — pre-OH-09 the default silently overrode the requested duration, which is now honoured. Suspend-all and revoke cascade to ReleaseHold; the OneHealth session reconciler ticks every five minutes and recovers any hold that landed in pending or failed state. Break-the-glass sessions ship with capture_state=captured so cost cannot become a deterrent against legitimate emergency access.

External
Paystack

Paystack is the cash on-ramp. The dashboard initialises a Paystack transaction with the user's email, the amount in kobo (one hundred times credits), the reference, the callback URL, and metadata that pins the account_id, the user_id, and the credits_amount. The browser is redirected to Paystack's authorisation_url. The webhook is double-verified — X-Paystack-Signature HMAC-SHA512 over the raw body, then a server-side verify call before crediting the account. The unique index on (account_id, reference) handles duplicate webhook deliveries.

Compliance & safety

NDPA 2023 — controller Fastclinic Limited (RC 1919428)

FastCredits processes the personal-data fields it needs to operate the ledger — the FastLogin user identifier, the Paystack receipt email, the transaction metadata — under NDPA 2023 §25 lawful bases. The data controller is Fastclinic Limited, RC 1919428, registered in Lagos. The data-processing record is updated alongside every release that touches a new dataset or a new processor. We do not claim NDPC processor registration; that filing is in progress.

NDPA 2023
PCI scope — Paystack as PCI-DSS-Level-1 processor

Card data never lands in FastCredits. Paystack holds PCI DSS Level 1 attestation and operates the card-present and card-not-present rails; the dashboard never sees a primary account number, a CVV, or a bank credential. FastCredits stores the Paystack reference, the credits amount, the user identifier, and the receipt email. The boundary between processor and ledger is the answer when a regulator asks about cardholder data scope.

Paystack PCI compliance
Append-only ledger — Postgres BEFORE-UPDATE/DELETE triggers

Every transaction row is immutable. A BEFORE-UPDATE trigger and a BEFORE-DELETE trigger on the transactions table raise the exception "transactions table is append-only" against any DML that tries to edit or remove a historical row. Balances never re-derive from history; balance_after and held_after are snapshotted on insert. The seven-year retention applies to the audit chain that wraps the ledger when FastCredits sits behind the consolidated audit posture.

Source — initial_schema migration
SERIALIZABLE isolation — Postgres-level integrity

Every write path runs at SERIALIZABLE isolation. On a 40001 serialization conflict, the repository retries the entire transaction up to five attempts with exponential backoff (five to two hundred milliseconds, jittered). The account row is pinned with SELECT FOR UPDATE inside every write transaction. The combination is the strongest concurrency guarantee Postgres ships and the right primitive for a financial ledger.

Postgres SERIALIZABLE docs
Idempotency by design — UNIQUE(account_id, reference)

A unique index on (account_id, reference) deduplicates every transaction. A duplicate insert returns errIdempotentHit and the repository re-reads the existing row. The reference grammar — capture:{originalRef}, release:{originalRef}, refund:{originalTxID} — is server-derived, never user-supplied, so the same logical operation produces the same reference and converges on the same row. The pattern follows Stripe's industry-standard idempotency-key design adapted to a server-derived reference.

Stripe — Idempotency keys

Plain answers

Org credits today. Finance UX shipping 2026.

owner_type=organization is operational right now — the schema accepts it, the handler accepts it, the ledger primitives are the same. Bulk-buy, department budgets, reconciliation dashboard, invoice export with TIN are forward-looking. If you want to be on the FastCredits org-finance design-partner shortlist, the contact link is below.