Product
jr_banking · on sale
Guides
Live · official sources only
Trackers
Not ready

A bank that cannot print money.

Banking for FiveM RP servers. A double-click does not print money. The author answers in 72 hours. Install is two SQL files and a config — not a three-day rewrite.

Store open. Economy bundle on Tebex, $69. Interactive player tools are still in the oven.

sql · jr_accounts · the lock is the WHERE clause

-- Subtract only if the money is actually there.
-- 0 rows = denied. There is no second chance.

UPDATE jr_accounts
   SET balance = balance - :amt
 WHERE id = :from
   AND balance >= :amt
   AND is_frozen = 0;

-- Then the journal, always:
INSERT INTO jr_transactions
  (from_id, amount, actor, reason, denied_code)
VALUES
  (:from, :amt, :citizenid, 'withdraw',
   NULL -- or 'insufficient_funds' / 'frozen' / 'no_access');

-- Lua never decides the balance.

Illustrative of the invariant — not a paste of the shipping source. Amounts are integers. No float cents.

On sale · Tebex

jr_bankingMoney does not duplicate. That is the product.

Most RP banks read a balance in script, then write it. Two clicks can debit twice. Owners pay for that in donated cash and in player trust. Here the debit is one SQL CALL. If the row does not update, the money does not move.

Money does not duplicate

A double-click withdraw does not print cash on the account. The lock is WHERE balance >= ? AND is_frozen = 0 inside the same CALL that writes the journal. Proof: 48 Lua unit tests and a 12-process race on live MariaDB against a $100 account — one debit, balance zero.

The money path stays readable

Escrow encrypts Lua. It does not encrypt config.lua, SQL, locales, NUI, or the tests. A source-available SKU exists if you need to patch server/*.lua on licensed servers. Neither SKU is “open source”. We answer complete tickets within 72 hours.

An evening, not three days

Two SQL files on the oxmysql database, an open config, a Qbox or QBCore bridge. Not a framework rewrite. v1 has no ESX — that is a limit, not a footnote. We have not timed a production install; the steps are the claim, not a stopwatch.

In v1

  • Personal accounts
  • Organization accounts with owner / manager / member
  • Qbox and QBCore via a bridge layer
  • Open config.lua for limits, currency, ATM points
  • Tests in the zip: 48 unit, 4 live MariaDB

Not in v1

  • Invoices, loans, savings interest, crypto
  • ESX
  • Phone apps, cards, PIN
  • FiveM for GTAV Enhanced — Legacy only until we run it

What hurts. What we do.

Five owner problems, in their language. What we can stand behind, and what we will not pretend.

Duped money

A doubled withdraw burns donated cash. The account debit is one SQL CALL — 48 unit tests, a 12-process MariaDB race, 43 FXServer checks. Audit findings around the cash bridge are being patched. We do not claim every dupe class is closed.

Encrypted files, then silence

Paid, then weeks of nothing, and a zip you cannot fix. We answer complete tickets within 72 hours. SQL stays readable on the escrow SKU; a source-available SKU exists. No public support history — we will not write “we never leave”.

Install that eats days

Wrong framework and a host-key entitlement can eat three days. Two SQL files, open config.lua, Qbox or QBCore auto-detected. No ESX. No measured install time.

The new client is not production

Production is waiting on escrow and working NUI. We ship Legacy. No Enhanced mark until we have run it there.

The 0.00 ms stamp

Storefronts print idle times. We will not invent a number. When a live capture exists, it goes on the forum post. We do not sell an optimizer.

The line.

One resource is ready. Three more sit on the same money pipe. No ship dates — we do not have them.

jr_banking on sale

Personal and organization accounts. A double-click withdraw does not duplicate on the ledger.

jr_society planned

Boss / society / payroll. Closes a doubled withdraw from a job account.

jr_billing planned

Invoices on the same ledger. Companion to the bank, not a third storefront.

jr_shops planned

Ownable shops. The item leaves only if the money arrives.

Support

Complete tickets get a reply within 72 hours. Covered: install, config, and Qbox/QBCore ledger bugs on the purchased 1.x line for 12 months. Licence in EULA.md. Refunds follow Tebex digital-goods rules.

We do not have a public ticket history. 72 hours is the obligation we will keep, not a rating we can flash.

Channel

Email: hello@joyride.games.

Discord support is not live yet. No invite until the server exists.

Two audiences. No shared checkout.

Players have pages. Server owners have a product in progress.

Guides live · trackers coming soon

For players

Written guides for the next big open-world release are live. Interactive companions — maps of collectibles, progress trackers, checklists — are not. No paywall, no account.

  • Built around the next major open-world release, out November 19, 2026
  • Coverage uses official trailers and rockstargames.com only
  • Interactive maps and trackers land ahead of launch — the list below is the signal
Paid scripts · on sale

For server owners

Scripts for FiveM roleplay servers. First up: jr_banking, sold in the Economy bundle on Tebex. Three more scripts are planned; no dates.

  • Fits existing Qbox / QBCore setups via a bridge, not a rewrite. No ESX in v1
  • Support target: 72 hours. Discord is not live yet
  • Free reference in the meantime: what FiveM needs, which GTA V build, how a server is set up, and what the platform agreement says about charging players

A note when it ships.

No newsletter. One message when a new script or a player tool goes live.

Opens your email client, addressed to hello@joyride.games. A real signup form comes once the store is closer to launch.

Independent. In Georgia. Still building.

joyride.games publishes scripts for FiveM RP servers and free pre-release notes for the next open-world release. The first product is on sale on Tebex. There is no client list to flash.

Contact: hello@joyride.games.