Features
A closer look at what runs behind the admin console, the fleet portal, and the forecourt POS app.
Multi-tenant isolation
Every retailer brand you onboard gets its own stations, cards, accounts, and transaction history. Isolation is enforced with PostgreSQL row-level security scoped to each request's tenant claim, not just filtered in application code — so a bug in one tenant's query can't leak another tenant's data.
Forecourt POS
A cashier authorizes a sale against the card's live policy, the station's current pricing, and the account's balance or credit limit — approving or declining in real time with a specific reason code. Committing the sale posts a real ledger debit and is safe to retry: a repeated commit for the same authorization never double-charges the account.
Card policy engine
Attach rules to a card or account: which fuel grades are allowed, per-transaction or daily volume caps, spend limits, which stations the card can be used at, and time-of-day restrictions. Every authorization is evaluated against the active rules, with no code changes required to adjust a customer's policy.
Billing & settlement
Invoices are generated from real settled transactions for a billing period, not estimated. Re-running generation for a period that's already invoiced returns the existing invoice instead of duplicating it. Track status from issued through paid, cancelled, or automatically overdue, and download a real PDF for any invoice on demand.
Fleet self-service portal
Fleet managers log in to see only their own account: vehicles, issued cards, recent transactions, and invoices. Account-ownership checks mean a fleet manager can't reach another account's data even within the same tenant, not just across tenants.
Enterprise identity & access
Login runs through Keycloak (OIDC/OAuth2), with tenant, station, and account claims embedded in every token. Those claims drive both what a user can do and what data they can see, from the forecourt POS app up through the admin console.