How a FiveM server store works on Skalp: payment, in-game delivery and refunds
A server store on Skalp sells VIP, ranks, items and vehicles to the players on your FiveM server. The player pays on your store page, the skalp resource on your server picks the purchase up within about ten seconds and hands it over in game, or straight into their character if they are offline. Skalp is the seller, so VAT, invoices, refunds and chargebacks are handled on our side.
What players can buy
Anything your server can give a player with a command or a script. Items and vehicles work out of the box on the common frameworks. A job, a rank, a whitelist spot or queue priority go through your own server commands. A monthly VIP can be a subscription that is delivered again every paid month, and players can buy any product as a gift for a friend.
The store gets its own address at yourname.skalp.gg, or your own domain. It is listed on the Skalp marketplace under Server stores, with the number of players online if you add your server address. Single products such as a VIP rank stay out of the marketplace product list, because they only mean something to players of your server.
How a purchase reaches the player
- Before buying, the player links their Steam account. That is how your server knows who bought what. They pay by card, Apple Pay, Google Pay or a local payment method.
- The skalp resource asks Skalp for new purchases about every ten seconds. It saves each one in the
skalp_deliveries table before confirming it, so a crash in between fetches it again and nothing is lost.
- A player who is in game gets the purchase at once. If they are offline, the built-in rewards go straight into their character in your database, so everything is there at their next login. Skalp picks the character they played last: ox_core and vRP link it to Steam themselves, and on ESX, QBCore and Qbox the resource learns it the first time the player loads a character with resource 3.2 or newer. Until then, and for anything that cannot be written safely while the player is away, the delivery waits for them to join.
- The order in your dashboard shows whether it was delivered, is waiting or failed, and why.
Connecting your server
In your store dashboard, open Game server and click Connect server. Download the resource, drop the skalp folder into resources and paste the three lines from the dashboard into server.cfg:
ensure skalp
set skalp_key "the key from the dashboard"
add_ace resource.skalp command allow
After a restart the console prints Connected to Skalp and the dashboard shows the server as connected. You see the key only once. If you lose it, make a new one, and the old one stops working straight away.
Players are matched by Steam, so the server needs a Steam Web API key (steam_webApiKey in server.cfg). The resource works on ESX and its forks, QBCore, Qbox, ox_core and vRP, with ox_inventory or the framework's own inventory. A server without a framework can still deliver with commands and its own scripts. oxmysql is optional: with it, deliveries are kept in your database, and without it in the resource's own storage.
Nothing connects to your server, so there are no ports to open and no URL to set. Your server asks Skalp for purchases, and everything sent either way is encrypted and signed with your key. The key itself never leaves the server, so a fake API or an intercepted connection cannot make it hand anything out.
What a product gives
On each product you write what it gives as a command. The resource comes with commands that work the same way on every framework, for example:
| Command | What it does |
|---|
skalp_item {playerId} bread 5 | Adds an item through ox_inventory, qb-inventory or the framework. |
skalp_vehicle {playerId} sultanrs | Saves the vehicle with a free plate in the player's garage. |
Any other command that a resource on your server registered works too, for example setjob {playerId} police 0. Separate several steps with ;. Skalp fills in {playerId}, {steamhex}, {steamid}, {quantity}, {orderId}, {productSlug} and {buyerName}. A command that uses {citizenid}, {charId} or {license} instead of {playerId} also runs while the player is offline. You can also ask the buyer up to ten questions at checkout, such as the text for a custom plate, and use the answer as {field_plate}. Answers typed by the buyer are cut down to letters, digits and _.:-[], so nobody can slip a second command in.
Commands run as the server console, and only commands that a game resource registered will run. The server's own console commands such as quit, exec or add_ace and txAdmin's commands never run, whatever a product says, and you can block more in Config.BlockedCommands. A command that does not exist on your server fails the delivery with its name, so a typo shows up on the order.
Custom systems: your own garage, VIP or shop script
If your server gives things through its own script, for example a custom garage or VIP system with no console command, register a handler in your own resource. A handler takes over from the product's command:
local function register()
exports.skalp:RegisterHandler('sultan-rs', function(ctx)
local ok, err = exports.my_garage:GiveCar(ctx.playerId, 'sultanrs')
if not ok then return false, err end
return true
end)
end
AddEventHandler('onResourceStart', function(name)
if name == 'skalp' then register() end
end)
if GetResourceState('skalp') == 'started' then register() end
The key is the product's slug or id. Return true when the purchase is delivered, false, 'reason' when it failed (the reason shows on the order), or nil, 'reason' to keep it waiting and try again later. ctx carries the player id, their identifier, the quantity, the order number, the product and the buyer's answers to your questions.
The resource also exports GiveItem and GiveVehicle for your own scripts, and its examples folder has ready files for ESX, QBCore and servers without a framework. Handlers live in your resource, so updating skalp never overwrites them.
Handlers run when the player is in game. If your server keeps characters, inventories or garages in its own tables, register offline handlers with exports.skalp:RegisterOfflineHandler and offline delivery works with your setup too.
Subscriptions, refunds and chargebacks
- A subscription is delivered again for every paid period. Once it has really ended, the product's revoke command runs. A handler registered with
RegisterSubscriptionHandler gets ctx.active and can grant or remove the perk itself.
- A full refund cancels whatever is still waiting and runs the revoke command for what the server already delivered. A player who is offline loses it the next time they join.
- Skalp fights chargebacks with the bank. A lost one works like a refund and also bans the buyer from joining your server, and winning it back later lifts the ban. A player who got the purchase as a gift is not banned for the giver's chargeback.
What your server sends to Skalp
The connection id, the resource version, the framework name, whether commands and Steam sign-in are enabled, and the result of each delivery. It sends no player list, no identifiers of players who bought nothing and nothing from your database. Skalp in turn sends the server only what a delivery needs, without the buyer's e-mail, the amount paid or other order details.
Payments, tax and payouts
Skalp sells to the player as merchant of record. The VAT of the buyer's country is added at checkout and Skalp issues the invoice. The fee is 10% of the net sale price, or 7% once your sales over the last 30 days reach $20,000. Payment processing is included and there is no monthly fee. Orders clear 7 days after completion, and from USD 20 you can request a payout from the dashboard to a bank account in your or your company's name.
What you list is up to you
You decide which products your store sells. Make sure each one follows the rules of the game and the platform your server runs on.
Frequently asked questions
Do I need to open a port or set up a webhook?
No. Your server asks Skalp for new purchases, so nothing has to connect to it from outside.
Which frameworks does it work with?
ESX and its forks, QBCore, Qbox, ox_core and vRP. A server without a framework can deliver with commands and its own handlers.
What happens when the player is offline or their inventory is full?
The built-in rewards go into the character right away, as long as Skalp knows which character it is and the player is not on the server and did not leave it in the last two minutes. Items that get their own data when created, such as weapons, wait for the player to join, and so does everything when the inventory is full. Waiting deliveries stay in the skalp_deliveries table, run when the player joins and are retried every 30 seconds while they play. If the player does not join within 30 days, they expire. Set Config.OfflineDelivery = false to always wait for the player.
Can a purchase be delivered twice?
No. Every product in an order has its own row, and a delivery with several steps remembers which steps already ran.
How do I test it before selling?
Click Send a test in the dashboard, and the server prints it in its console the next time it checks in. The reward commands also work in the server console, for example skalp_item 1 bread 5, and skalp status shows the connection, the framework and how many deliveries are waiting or failed.
Can I also sell my scripts to other servers?
Yes, from a script store, which is a different store type. Skalp protects the files and binds them to a licence. How selling FiveM scripts works.
Is Skalp affiliated with Rockstar Games or any game platform?
No. Skalp is an independent store for digital products.