> For the complete documentation index, see [llms.txt](https://baobab-interactive.gitbook.io/baobab-interactive-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://baobab-interactive.gitbook.io/baobab-interactive-docs/junk-removal-simulator/frameworks-and-payments.md).

# Frameworks and payments

## Select one framework

Edit `Config.Framework` in `shared/config.lua`:

```lua
Config.Framework = {
    Mode = 'qbox',
    Resources = { esx = 'es_extended', qbcore = 'qb-core', qbox = 'qbx_core' },
    Accounts = { esx = 'bank', qbcore = 'bank', qbox = 'bank' },
}
```

| Mode       | Identity                 | Default payment      |
| ---------- | ------------------------ | -------------------- |
| standalone | FiveM license            | Business ledger only |
| esx        | ESX character identifier | bank                 |
| qbcore     | citizenid                | bank                 |
| qbox       | citizenid                | bank                 |

Use your actual core resource name and start it first. For standard cash accounts, use `money` in ESX or `cash` in QBCore/Qbox. Custom accounts must exist.

An unavailable core, unloaded character or invalid account blocks work instead of silently using standalone. Custom key, fuel, inventory and banking replacements may require an adapter.

## Revenue split

Standalone retains 100% as business cash. Framework mode defaults to 50% business cash and 50% owner payment, controlled by `Config.Business.FrameworkRetentionPercent`. The business share rounds down; the owner receives the remainder. A $285 receipt therefore retains $142 and pays $143.

Gross earnings, business cash and XP are recorded once. A pending owner payment does not mean the whole job should be awarded again.

## Retry a payment

Open **Earnings → Retry payment**, or use **/junk payment**. A confirmed decline can be retried. Pending payments block new work until resolved, and their original framework/account destination stays attached to the receipt.

If saving failed before the completed award was recorded, retain the original shift and use the prompted retry at the dump. The payment command cannot create an award that was never saved.

## Payment needs a log check

A crash or exception around a framework credit can leave its outcome uncertain. Automatic retry is blocked to avoid duplicate money.

An administrator must check the exact receipt in the framework logs using: `junk_removal:receipt:<receipt ID>:<framework>:<character ID>`.

From the **server console**, inspect the online player:

```
junk_payment 12
```

After verifying the result, use one appropriate outcome, substituting the actual player and receipt IDs:

```
junk_payment 12 7 paid confirmed receipt 7 in the framework money log
junk_payment 12 7 retry confirmed receipt 7 never credited
```

These are alternatives. `paid` finalizes without adding money; `retry` permits a new attempt. Do not grant money manually and then retry the same receipt. Current balance alone is not proof of a particular payment.

## Character separation

Profiles use resource KVP keyed by framework and identity. Switching frameworks does not migrate careers or deposit past standalone earnings. QBCore-to-Qbox migration is not automatic even with matching citizen IDs. Resolve pending payments and back up KVP before changing deployment.