Documentation
Frameworks, inventories, banking scripts, phones and target systems — what is supported, how each layer is detected, how to override it, and how to add a backend of your own.
Nothing inside Quasar Billing knows which framework, inventory or banking script you run. Every third-party resource is reached through a contract, and one small adapter per backend fills that contract in. Detection happens at boot, and the console prints what it picked.
Layer | Supported | Without it |
|---|---|---|
Framework |
|
Runs standalone, with no jobs or society accounts. |
Inventory |
| No physical invoice or receipt. Everything else works. |
Banking |
| Payments still happen; no statement line is mirrored. |
Phone |
| On-screen notifications only, no phone push. |
Target |
| Terminals fall back to a proximity radius. |
Properties | Your framework's own vehicle and property tables. | The city property tax has nothing to tax. |
Database |
| Required. The only one. |
Every optional integration degrades silently. A missing resource makes its feature disappear, not throw. That is why the boot summary matters — it is the only place that tells you an integration is absent before a player does.
The phone row above is about notifications — an invoice arriving as a push rather than only as a toast on screen. Two of those phones get more than that: the download carries a companion app for each of them — qs-billing-app for qs-smartphone and lb-billing-app for lb-phone — with its own screens for what a player owes and how they settle it. The two are built from one source and behave identically; they are optional and install separately. Installation has the steps, Usage has what is on them.
Each layer is detected by looking for started resources in priority order — the first one found wins. An explicit value in config/shared/config.lua always beats detection, and the boot summary reports it as (manual) so you can see it was deliberate.
-- Auto, the default: the first started resource in the list wins.
Config.Inventory = ConfigAutoDetect('Inventory', {
'ox_inventory',
'qs-inventory',
{ resource = 'qb-inventory', value = 'qb' },
}, 'vanilla')
-- Manual: skip detection entirely.
Config.Inventory = 'ox_inventory'This is worth doing when two candidates are running at once, or when a resource has been renamed on your server and detection cannot see it under its usual name.
Billing does not know what an MDT is. What it offers is a place to put yours: pass a metadata table when you create the invoice, and it is handed back when that invoice is settled. Your fine closes itself, carrying whatever id you gave it.
exports['qs-billing']:CreateInvoice({
target = source,
society = 'police',
category = 'fine',
lines = { { label = 'Speeding', price = 500 } },
metadata = { mdtFineId = 812 }, -- comes back on payment
})The same trick works for any resource that needs to know its own record was paid — a garage, a housing script, a court system. See Commands and Exports.
Supporting something that is not on the list is deliberately small: one file plus one line. Nothing else in the resource changes, because nothing else in the resource ever refers to your framework by name.
A file under server/custom/framework/, guarded so it only runs when it is the chosen backend, filling the contract declared in server/globals.lua:
if Config.Framework ~= 'mycore' then return end
function Framework.GetMoney(source, account) ... end
function Framework.RemoveMoney(source, account, amount, reason) ... endUnder client/custom/framework/, normalising your player data into the shape the interface expects. It looks the same on every framework, which is why no view has a special case in it.
One entry in the ConfigAutoDetect list in config/shared/config.lua, so it is found automatically and reported in the boot summary.
Inventories, banking scripts, phones and MDTs extend exactly the same way, against their own contracts.