- Documentation
- 06Game
Salary transfersGame
Pay an approved pay period’s payslips in game: supported banks, bank history, company account debit, never twice.
Salary transfers pay the payslips of a period approved in the Payroll module into the bank account of each officer’s character, in game. Nothing leaves on its own: an authorized person prepares the transfers, checks them, then sends them.
Turn it on
Section titled “Turn it on”- In Settings › Game › Integrations, turn on Salary transfers.
- Optional: Debit the company account. Each transfer is then taken from the service’s
company account (the one of its first linked job, for example
police). You need a bank that handles these accounts (see the table). - Turn off the framework’s automatic paycheck for the jobs paid by SuperMDT (grade
salary set to 0 in
qbx_core/shared/jobs.lua,qb-core/shared/jobs.luaor ESX’sjob_gradestable). Otherwise, your officers get paid twice.
Under the switch, SuperMDT shows the detected bank, whether the transfer will show in the player’s bank history, and whether the bank can debit a company account.
Pay a period
Section titled “Pay a period”- In Payroll, open an approved and frozen period.
- In In-game transfers, click Create the transfers: one transfer per payslip, to the character of the officer whose job is linked to this service.
- Check the list and the Prepared amount. Cancel the preparation (hold) removes everything without sending anything.
- Hold Send N transfers to confirm.
Each line follows its status:
| Status | What it means |
|---|---|
| Prepared | Not sent yet. |
| Waiting for login | The character isn’t in game: the transfer leaves at their next login. |
| In progress | Sent to the game. |
| Paid | Paid; the line says whether it’s In bank history. |
| Failed | With the reason: insufficient funds on the company account, bank refusal, no character linked to the service… |
Retry failures retries failed transfers, except an uncertain result.
Never twice
Section titled “Never twice”Each transfer has a unique ID, kept by the bridge even after a server restart: it’s never paid twice. A payment interrupted by a hard stop is marked Uncertain result: check the balance in game; it’s never retried on its own.
Who can do it
Section titled “Who can do it”Prepare, send, cancel and retry: the Payroll › Send transfers permission, in the period’s service; without it, the transfers’ status stays readable but with no action buttons. Settings › Game: organization administrators, or Delegated administration › Set up the game (see Permissions). Everything is written to the audit log.
Compatibility
Section titled “Compatibility”Tested in game tried in game on a real server. Verified in code written from the script’s source code or native API, covered by the bridge’s tests, not tried in game yet. Experimental from the publisher’s public documentation, never tried: check it on your server before relying on it.
In every case, the money is paid into the framework’s “bank” account. The bank changes two things: the line in the history of the banking app, and the company account debit.
| Framework | Bank | Status | Player’s history | Company account debit |
|---|---|---|---|---|
| ESX, QBCore, Qbox | Renewed-Banking | Verified in code | Yes | Yes (job account) |
| QBCore | qb-banking | Verified in code | Yes | Yes (job account) |
| ESX | esx_banking + esx_addonaccount | Verified in code | Yes (esx_banking app; sd-phone Wallet if started) | Yes (society_ + job) |
| ESX | esx_addonaccount alone | Verified in code | Only in sd-phone if started | Yes |
| ESX, QBCore | okokBanking (V2) | Experimental | Yes | Yes |
| ESX, QBCore, Qbox | qs-banking (Quasar) | Experimental | An activity line (amount in the text) | Yes |
| ESX, QBCore, Qbox | fd_banking | Experimental | No | Yes |
| ESX, QBCore | snipe-banking | Experimental | Yes | Yes |
| ESX, QBCore, Qbox | tgg-banking | Experimental | Yes (if the character has a tgg-banking account) | Yes |
| ESX, QBCore, Qbox | No recognized bank (framework fallback) | Verified in code | No | No: with the debit on, transfers fail |
With the supported banks, the character must be in game when the payment happens; otherwise the transfer waits for their login.
Is your script custom?
Section titled “Is your script custom?”| Your bank… | Result |
|---|---|
| keeps the framework’s “bank” balance (the case of every bank above) | The transfer is paid, with or without a history line depending on the table. |
| isn’t in the table | Framework fallback: paid, but with no history and no company account debit. |
| keeps its own balance, without the framework | The payment goes to the framework’s “bank” account, which your bank may not display. |
Troubleshooting
Section titled “Troubleshooting”| What you see | Cause | What to do |
|---|---|---|
| Waiting for login | The paid character isn’t in game (or another character is loaded) | It leaves at this character’s next login. |
| Uncertain result | The server stopped during the payment | Check the balance in game; never retried on its own. |
| Paid but missing from the history | Framework fallback | Install a supported bank, or accept it. |
| “The bank can’t debit the company account” | Debit on with a bank that doesn’t handle it | Turn off the debit, or change bank. |
| “Not enough funds on the company account” | The service account is too low | Top up the account, then Retry failures. |
| Officers paid twice | Framework automatic paycheck still on | Grade salary set to 0 for these jobs. |