Custom Integrations
Connect server rewards and purchases to FS-Money
Checked against local source and release-version 1.4.3. Integrate from your own server resource; start FS-Money and its database/dependencies before that resource. Add dependency 'FS-Money' to the integration manifest. No edits to protected FS-Money scripts are needed.
Server transaction contract
| Export | Result |
|---|---|
getMoney(moneyType, source) | Numeric balance; may return zero for missing player/account data. |
setMoney(moneyType, source, amount, sourceTag, reason) | Boolean from the write path. |
addMoney(moneyType, source, amount, sourceTag, reason, sendNotify) | Boolean from the write path. |
removeMoney(moneyType, source, amount, sourceTag, reason, sendNotify) | false for insufficient funds, otherwise the write result. |
transferMoney(moneyType, fromSrc, toSrc, amount, sourceTag, reason) | Removes first, then adds; returns the operation result. |
Use only configured currency IDs and finite positive transaction amounts determined by your server. sourceTag is the ledger/source label; reason is the human-readable explanation. sendNotify defaults to enabled unless explicitly false. Client getMoney is cached display data, not an authoritative balance for approving purchases.
local function payEarnedReward(playerId, earnedAmount)
if not GetPlayerName(playerId) then return false end
if type(earnedAmount) ~= 'number' or earnedAmount ~= earnedAmount
or earnedAmount <= 0 or earnedAmount == math.huge then return false end
return exports['FS-Money']:addMoney(
'cash', playerId, earnedAmount, 'my-job', 'Completed delivery', true
) == true
endThis function does not decide whether a reward was earned; call it only after your own authoritative validation. Do not expose it through a network event accepting arbitrary amounts. Initialize the player's account before transactions. The inspected write path can return success without establishing that a missing account row was created, and notifications occur before the final write result. Verify the balance and ledger, not just a notification.
Purchases, retries, and transfers
For purchases, use the boolean returned by removeMoney before granting the item/service. A prior balance read alone is not payment. The inspected implementation reads and writes balances separately; it does not supply an atomic transaction or idempotency key for your custom workflow. Serialize conflicting transactions in your integration and reconcile ambiguous failures before retrying. transferMoney is not a guaranteed all-or-nothing transfer: a failed destination credit has no automatic rollback in the inspected export.
Test successful/insufficient-funds purchases, a missing account, stopped resource, duplicate reward requests, and simultaneous transactions. Confirm correct currency, one ledger entry, and exactly one item/reward. Preserve your integration separately and recheck export signatures after updates. See Exports for the side-specific API reference.