Skip to content
FuelOne
Menu

Platform

Everything an OMC needs to run its own fuel card programme.

Cards issued from your IIN, a swipe decided in one request, monthly invoices with every payment recorded against proof, station stock, loyalty, and a depot-to-pump supply chain. The core runs for every OMC. The modules are switched on as you sell them.

Core, plus the prepaid cards, supplementary cards modules

Cards and issuance

You define card types: postpaid, invoiced monthly, or prepaid, with stored value on the card; for business holders, who are employees of a fleet customer, or for cash holders; each with its terms and, where loyalty is on, its own points rate.

A card is issued to an individual or to a vehicle. A fleet card is bound to the vehicle and has no named holder. A new holder is created inline with the full KYC profile: CNIC, encrypted at rest and checked for uniqueness by a one-way hash, date of birth, gender, and marital status. The card number is generated from your own IIN and is Luhn-valid. New cards start in processing and route through approval. Fleet customers raise card requests with the holder and limits they want, and your staff approve or reject.

Your staff set or change a card’s PIN, which locks the card for fifteen minutes as a safety measure, and block, unblock, or change its status; the holder is emailed on each change. With the prepaid module, recharge requests are paid to your published bank or wallet accounts and approved by your staff. With supplementary cards, additional physical cards share a primary card’s limits and billing.

  • Limits per card, as an amount or a volume per period
  • Physical cards are MifareClassic NFC; per-card sector keys are derived server-side by HMAC from the card number and a master key that never leaves the server
  • Card page with every transaction, a PDF receipt per row, and a monthly PDF statement

Core, on for every OMC

The swipe and its gates

A terminal is enrolled by its serial number and assigned to a station. Each terminal holds one active token; re-registering revokes the old one. At the pump the terminal picks a fuel type at the station’s locked price, takes the litres, and sends one request to the transaction API. The request passes seven gates, in this order: company status, card status and expiry, spending and volume limits, rate of use, prepaid balance, discount code, pin.

The outcome is complete, decline, or hold for a person to decide. A decline is stored with its reason, the cardholder is emailed, and a webhook fires. A held transaction is approved from the web. A completed transaction posts to the ledger at once, earns loyalty points in the background, and fires its webhooks and emails. Two worked examples, a decline and a hold, are on the home page.

Velocity rules are the rate-of-use gate: transaction count, total amount, total volume, maximum amount per transaction, minimum minutes between swipes, or distinct stations, each over a window. Every breach is written to an immutable log. The transactions list filters server-side by date and time in Asia/Karachi, card number, station, and status.

  • Every declined swipe is a stored transaction with its reason. None is discarded.
  • A velocity rule watches one metric over a window and flags, holds, or declines
  • The PIN is an optional second factor: two minutes, three attempts, then a 24-hour lock

Core, plus the referrals module

Business customers, fleets, and cardholders

Your staff add a business customer with its logo, create its first admin, and add further admins and cardholders. Or the customer applies through your sign-up form or an invite link, and your staff approve, reject, or approve and provision, which creates the customer and its admin and emails the credentials. A customer whose invoices stay overdue past a grace period you set is suspended automatically.

The customer gets its own portal on your tenant: a dashboard with thirty-day figures, daily spend, fuel mix, and top cards; employees and vehicles; card requests with KYC and requested limits, with the customer’s own internal approval before the request reaches you; card pages with receipts and statements; block and unblock; transactions with filters; and an employee spend statement. With billing on, invoices and payments with proof. With ledger on, a statement with running balance.

In the Android app: sign in with email and password or by scanning a QR from the portal; cards with balance and limits; block and unblock; the full card number behind biometrics; transactions with receipts saved as images; set or change the PIN; app lock; nearby stations on a map with favourites; notifications with push; and, with prepaid on, a top-up request. With the referrals module, cardholders share a link with a QR and each sign-up lands as a request with KYC for your staff to provision or reject.

  • A public sign-up form takes legal name, NTN, GST number, entity type, and billing address, and lands as a request your staff approve
  • Suspending a customer declines every card it holds at the next swipe
  • Cardholders get a web portal and an Android app built per OMC with your name and logo

Billing, ledger modules, switched on per OMC

Billing, payments, receivables, ledger

Billing generates a monthly invoice per business customer from its completed transactions: line items per fuel type at a weighted unit price, a statement per card, a summary per station, your service charge with per-customer overrides, sales tax, the amount in words, your NTN and STRN, your logo, in one of three templates. Invoice numbers are sequential per OMC. Generation runs on the first of the month, the PDF is emailed, and a daily run marks invoices overdue.

Payments are recorded against invoices by the customer, as pending, or by your staff, as verified. Your staff verify, reject with a reason, or reverse with a reason; the customer edits and resubmits a rejected payment. Overpayment flows into a per-customer credit wallet and can be applied to a later invoice. Receipts are numbered PDFs, a settled invoice carries a paid watermark, and a duplicate bank reference warns before it is accepted. Receivables are aged into buckets you configure. The Finance role lands on the payments queue and can touch nothing but money.

The ledger module gives each cardholder an append-only ledger with one account per balance: the postpaid amount due, and each prepaid card’s available balance. It filters, sorts, pages, and exports to CSV and PDF. A manual adjustment needs a reason and a permission that is mapped to no role, so it is granted to a named person or to nobody.

  • There is no payment gateway. The platform records and verifies payments and never holds funds.
  • Up to five proof files per payment, kept as evidence even after a reversal
  • Every ledger has a gapless sequence; a daily check reports drift and never repairs

Core, on for every OMC

Stations, tanks, and daily stock

Stations are created with address autocomplete and a map pin, licence fields, and fee settings recorded per station. Each station has tanks with capacity and fuel type, dispensers, and nozzles linked to their tank. Station analytics show figures, spend trend, fuel mix, a usage heatmap, and top cards, filtered by station and date. Your dashboard maps your stations and lists the top five by spend.

Pump managers are assigned to stations and get their own portal: their stations with tank, dispenser, and nozzle counts, price setting, dip recording, and daily stock entry per tank. Opening stock is pre-filled from yesterday’s closing and dispensed litres from completed transactions; the manager enters received litres and the physical closing; the platform computes expected closing and variance against your threshold.

  • Prices set and locked per station and fuel type against your own fuel type list
  • Dip readings recorded by staff; the level is estimated from sales since the last dip
  • Daily stock per tank with variance against your threshold, exported to CSV

Loyalty, campaigns, discount codes, referrals modules, switched on per OMC

Loyalty, campaigns, discount codes, referrals

Loyalty awards points on every completed transaction, from the terminal, the PIN path, or web approval. A points ledger and balances per cardholder are on the platform and read-only in the customer portal. Fleet cards, which have no named holder, earn nothing.

Campaigns award bonus points for a period and email you when their budget is spent. Discount codes are targeted to cardholders, customers, or stations, with use caps per code and per card, dates, and a budget. Referrals give cardholders a link to share, with the reward paid on sign-up or once the referred user has made a set number of transactions, litres, or rupees. Each of the four is its own module and can be on without the others.

  • Points per transaction, per rupee, per litre, or per block of rupees, under a label you choose
  • Campaigns targeted by station, customer, cardholder, or geographic radius, with an optional budget
  • A discount code entered with the swipe that is invalid declines the swipe

Supply chain module, switched on per OMC

Supply chain

For an OMC that runs its own depots. Depots have tanks and licence details. Trucking companies have trucks with compartments, a dip chart, and a calibration expiry, and drivers with a licence expiry. A truck or driver on an active trip cannot be deactivated.

A pump manager raises a requisition. Your staff approve it, possibly for a smaller quantity, or reject it with a reason. The Logistics role builds a trip: a depot, a truck, a driver, and requisitions allocated to compartments in full with the product matched; confirming locks the truck and driver. The Depot role dispatches it with a delivery note, seal range and count, and per-compartment dips with density and temperature, or returns it to Logistics with a reason. At the station the pump manager records arrival, checks the seals, records compartment dips, chooses the receiving tank, and completes the decant, which updates the tank level and computes the variance.

The deliveries overview lists every completed delivery with dispatched and received litres and the variance, threshold and broken-seal cases first.

  • Logistics and Depot are roles with their own portals; a Depot user sees only trips from their one depot
  • Each variance stores the threshold and reference temperature that applied
  • A broken seal needs a note and alerts you; it never blocks the delivery

Core, plus the support chat, onboarding modules

Access, audit, webhooks, SSO

Every user can enable two-factor authentication, register passkeys, trust a device for thirty days, and sign in by emailed link. Each OMC, and each business customer, can configure OpenID Connect single sign-on from the identity provider’s discovery document, for existing users only.

The platform operator works on a separate admin host: creates OMCs, switches modules, defines velocity rules, approves platform-level requests, enrols terminals, and manages card types. Everything the operator reads across OMCs about money is read-only by policy.

The support chat module lets you upload documents to a knowledge base and puts a chat widget on your tenant that answers from those documents and can look up your stations. The onboarding module gives your staff a setup checklist, a command palette that reaches every page and action they may use, and a guided tour.

  • Eight roles, with per-user permission overrides limited to what the granting admin holds
  • The audit log records every change on 28 kinds of record with the actor and the values before and after
  • Outbound webhooks on 25 event types, signed with HMAC-SHA256, retried, with a delivery log