ESX vs QB Core: Setting Up Refunds for Each Framework

ESX and QB Core dominate the FiveM ecosystem, but their inventory systems, database schemas, and event structures differ significantly. Getting refunds working smoothly requires understanding these nuances. This guide walks through setup for both frameworks so you can pick the path that fits your server.

Database schema differences

ESX traditionally stores player data across multiple tables (users, user_inventory, user_accounts), while QB Core consolidates most data into a single players table with JSON columns. LD Refund System adapts automatically, but custom queries need adjustment.

• ESX: Items stored in `user_inventory` with item name and count columns
• QB Core: Items stored as JSON in `players.inventory` column
• Both: Money typically split into cash, bank, and sometimes crypto accounts

Configuring item refunds on ESX

ESX uses xPlayer:addInventoryItem() and xPlayer:removeInventoryItem() for inventory operations. Ensure your items exist in the database items table and match the exact name string. Weight limits apply if you're using a weight-based inventory like ox_inventory.

-- ESX item refund example
local xPlayer = ESX.GetPlayerFromId(source)
xPlayer:addInventoryItem('bandage', 5)
xPlayer:addAccountMoney('bank', 50000)

Configuring item refunds on QB Core

QB Core relies on exports from qb-inventory or qb-core directly. Items must be registered in qb-core/shared/items.lua. The functions AddItem and RemoveItem handle quantity, but metadata support varies by inventory resource.

-- QB Core item refund example
local Player = QBCore.Functions.GetPlayer(source)
Player.Functions.AddItem('bandage', 5)
Player.Functions.AddMoney('bank', 50000, 'refund')

Weapon refunds: metadata matters

Weapons often carry metadata like serial numbers, attachments, and ammo counts. On ESX with ox_inventory, weapon metadata is stored as JSON. QB Core's qb-weapons similarly tracks serials. LD Refund System preserves this metadata when issuing weapon refunds, but custom scripts must handle serialization carefully.

Performance considerations

Both frameworks perform similarly for refund operations since the heavy lifting happens on the Discord bot side. However, QB Core's JSON columns can be slower to query at scale. For servers with 200+ concurrent players, consider indexing strategies or caching frequently accessed player data.

Whichever framework you run, the key is consistency. Pick one approach, document your item registry, and train staff on the exact refund flow.