Donations and revenue on a FiveM server

Taking money is the part of running a server that can end it. The platform rule that closes servers is about selling things that change what happens in the game, and the operational mistake that hurts most is running the payment side on the same machine as the game. Both are avoidable.

The rule that ends servers

Cfx.re publishes platform rules covering how a server may take money, and enforcement is real: a server key can be revoked and a server can be removed from the list. That ends the server regardless of how long you have run it or how much you have put into it, and there is no hosting decision that protects you from it.

The line those rules turn on is whether the payment changes what happens in the game. In-game money, items, vehicles, faster progression, or better outcomes are selling an advantage, and that is the category that gets acted on.

A useful test before you list anything: put a paying and a non-paying player in the same situation. If the paying one wins more often, gets there faster, or ends up with more, do not sell it.

Do not reason from what other servers appear to be doing. Perks that people assume are settled, including priority in a queue, paid access or whitelisting, extra character slots, paid access to a job or role, and anything shaped like gambling, are exactly the ones where servers get it wrong.

The safer shape

The perks that stay furthest from the line are the ones that do not touch gameplay at all:

• Cosmetic. Appearance items, liveries, plates: things other players can see and that do nothing else.
• Outside the game entirely. A Discord role or colour, access to a supporter channel, a name in the credits, merchandise.

Even these should be checked against the current rules rather than assumed, and there is a second test worth applying: could a player reasonably describe your server as pay-to-win? Perception costs you separately from the rules, because the players who will not pay are most of your server, and they leave quietly.

Never sell a staff position, and never let a purchase grant permissions. That is a platform problem and a security problem at once. See Managing staff on a FiveM server.

Be clear about what the money is for

If you tell players donations cover hosting, make that true and specific. Publish the actual costs: the server, the database, the domain, asset licences, and any paid development. Concrete numbers earn more trust than a vague appeal, and they are easier to keep honest.

Two wording points that prevent disputes later:

• If the payment gets the player something, it is a sale, not a donation. Call it that on your store page, in your Discord, and in your own records. Describing a sale as a donation causes problems with players and with payment providers.
• Do not promise features in exchange for funding unless you are certain you will build them. Unbuilt promises are the most common reason a chargeback is filed months later.

Publish a refund policy before you need one, and deliver perks automatically so that every purchase has a delivery record attached to it.

Keep payment handling off the game server

Do not run the store, the payment webhooks, or anything that touches card details on the machine running FXServer. Three reasons, all of which have bitten servers:

• The game server is the machine that gets attacked. An attack on your game port should not also take down the place people pay you. See How protection works.
• A compromised resource on the game server reaches whatever else is on that machine.
• Game servers get restarted, rebuilt, and handed to developers. That is not the lifecycle you want for payment records.

Use a hosted store platform, of the kind commonly used for game servers, or a hosted payment provider, and never handle card details yourself. Check whether the platform rules require or restrict particular providers before you choose one.

The only thing that should cross from the store into the game is a delivery instruction: an authenticated webhook or API call from the store host, verified on arrival. That means checking the signature or token on every call, restricting which addresses may make it, and never exposing an endpoint that grants items without authentication. Give the store its own database credentials, separate from the game server's, so that a compromise on one side is not automatically a compromise on the other.

The bookkeeping side

Running this as a business is mostly record-keeping, and the records are easiest to keep from day one rather than reconstructed later.

• Separate the money. A dedicated payment account for the server, not your personal one. It makes reconciliation possible and a handover survivable.
• Record every payment: date, amount, currency, the provider's fee, what was delivered, and the player identifier it was delivered to. That record is what answers a chargeback, a player dispute, and a question from an accountant.
• Reconcile monthly against your hosting invoices, so you know whether the server pays for itself rather than assuming it does.
• Expect chargebacks. A reversed payment usually costs a fee on top of the amount, so treat it as a running cost rather than a surprise.
• Register accounts in the name of whoever owns the server, not a staff member's personal account. The store, the payment provider, the domain, the hosting, and the Cfx.re account all become unrecoverable when the person whose name they are in leaves. See the handover problem.
• Be careful about committing the income. Paying developers or staff is an ongoing obligation funded by voluntary payments. Do not commit to it on the strength of one good month.

Related