Purchases, Delivery and Refunds

What a purchase does

A player runs /buy <item> [quantity]. The platform checks the item is on sale in that server's shop, checks the balance covers it, takes the coins, writes a transaction, and only then tries to deliver.

The coins come out first and the delivery happens afterwards, in the background. That is why the reply names a delivery state rather than promising the item is already there.

A quantity of 1 to 100 is accepted, and it means how many of the shop row the player is buying. The row's own quantity is how many units one of those hands over, so the two multiply: three of a 64-block row costs three times the price and delivers 192 blocks.

If the balance is short, or the item carries a per-purchase limit lower than the number asked for, the purchase is refused before anything is charged.

The name the player types is resolved against the shop by exact item id, then exact display name, then a unique partial match. A partial match that could mean several items is refused with the candidates listed rather than guessed at.

One purchase, delivered once

A delivery can be slow without having failed. When the platform asks a server for one and the answer takes too long, it has no way to tell a busy server from an unreachable one, so it asks again — which is right, and which is also how a player could end up with the item twice.

Every delivery request now carries the transaction it belongs to, and a server that is asked twice about the same transaction replays the answer it already gave instead of delivering again. Ask five times, get one item and the same reply five times. The one exception is an answer that means nothing was given and the platform will try again on its own, such as the player being offline or the server being stopped: that answer is not replayed, so the next try really asks the game again and a purchase made while the server was down arrives soon after it is back.

This applies to every game on the platform, not just to the one it was found on. There is nothing to switch on and nothing for you to check.

The delivery column

Every purchase in the Transactions tab carries a delivery state, drawn as a badge.

How much a tick is worth, per game

• Minecraft — checked. The platform reads the server's reply, and where the reply is not conclusive it counts the item in the buyer's inventory before and after.
• Valheim — checked. The bridge plugin reports back what it actually put down and for whom.
• Palworld — the tick means PalDefender accepted the request.
• 7 Days to Die — the command is sent down the console and not verified. If the console drops after the command was sent and its answer is lost, the purchase is neither retried nor refunded automatically, because the item may already be in the player's inventory — check with the player before you refund.
• Windrose — the tick means our mod put the item in the world at the player's feet and the game accepted it.
• DayZ — the tick means the GameGrid DayZ server mod reported that it handed the item to that player: into their inventory, or at their feet if it was full. If the mod handed over only part of an order, or took the request and never answered, the purchase is neither retried nor refunded automatically, because something may already be in the world — check with the player before you refund.

A game that is not in this list says what its tick means in its own section of the knowledge base.

Windrose: the item lands on the ground

Windrose delivers automatically like every other game, with one visible difference: the item appears on the ground at the player's feet, and they pick it up. It does not go into their backpack, because there is no backpack on the server to put it in — Windrose is bring-your-own-character, and each player's character is a file on their own computer.

So the player has to be on the server to receive a purchase. If they buy while offline, the transaction is queued and delivered on their next session; nothing is lost and nothing needs you.

The Economy tab says this above everything else, so an operator reads it before pricing a shop rather than after the first player asks where their cannon went.

One outcome is specific to this game and worth knowing. If a delivery reaches the server and the server does not answer, the platform stops: it does not retry and does not refund, and it flags the transaction for you. The item may already be lying at the player's feet, so retrying would give them two and refunding would give them the item and their coins.

A Windrose game update can pause deliveries for a short window while we adjust to the new build. Purchases are refused rather than misdelivered, our monitoring picks it up rather than one of your players, and the fix reaches every running server within about half an hour with nothing restarted. Purchases made during it show as Failed and can be retried once it is back.

The reasons are in Windrose Economy and Shop.

Buying before linking, and buying while offline

Buying before linking is not possible. /buy is refused with "No wallet found", because linking is what creates the wallet the purchase would be charged against. Tell your players to link first.

Buying while offline is ordinary and does not lose the purchase. It is delivered the next time the player is on the server.

The platform re-tries a waiting purchase about once a minute for 24 hours. After that it is marked Failed, so that a purchase which is never going to deliver becomes visible while the customer still remembers making it, rather than spinning quietly for weeks.

Retry

The Retry button appears on a Failed or a Queued transaction. It puts the delivery back in the queue and tries again immediately.

Retry is worth a click when you have just fixed the cause — started the server, installed the mod, corrected an item id, asked the player to log in.

It is not worth clicking repeatedly against an unchanged cause. A failure that is a standing condition (a wrong item id, a missing mod, RCON not configured) fails the same way every time.

Retry on a Failed purchase sends only what has not arrived yet. If a purchase of 10 items stopped after 3, Retry sends the other 7, not all 10 again. It is sent as a separate attempt, so a game server that has forgotten the first one cannot mistake it for a new order and hand the first 3 over a second time.

Before it sends, Retry asks you to confirm. When GameGrid knows how many arrived, it asks "3 of 10 arrived — send the remaining 7?". When the transaction does not say how many arrived, it asks whether to send the whole purchase again: look in the game first, and if some items did arrive, cancel and Refund instead. Cancelling sends nothing. If every item has already arrived, Retry tells you there is nothing left to send. A Queued purchase is simply tried again, with no question. Through the Customer API the same choice is the confirmFullResend: true field on the retry request.

If part of a purchase arrived and the Retry then fails or runs out of its 24 hours, GameGrid does not refund it by itself, because a refund would pay back the part that was delivered too. It stays Failed for you to settle: Retry again, or Refund.

A delivered purchase cannot be re-delivered by this button, deliberately — that is how a player would end up with two of something they paid for once.

Refund

Refund credits the coins back to the player's wallet and records a matching refund transaction, so both the original purchase and the refund stay in the history.

A refund does not take the item out of the player's inventory. The panel says so before you confirm. If the item was delivered and you want it back, you have to remove it in game yourself.

The reply names the amount credited and the wallet's new balance.

From Discord, /refund <transaction-id> [reason] does the same and needs the economy.admin.refund ability (in the moderator preset). Transaction ids come from /my-transactions or the panel.

Reading the Transactions tab

The three cards at the top total the purchases, everything paid out (hand awards and auto-earn together), and the number of rows currently shown — which is the most recent 200, not the whole history.

The Type filter narrows to purchases, awards, refunds or auto-earn. The search box matches the player, the item and the reason. Other rows appear under All Types: a starting_balance row for a new wallet that began with your starting balance, and a wallet_merge row when two of a player's wallets were combined (when servers join or leave an economy).

The Type, Amount, Delivery and Date headings sort. Sorting by Delivery is the fastest way to find everything that has not landed.

Delivery failures are also written to the platform's own logs with the reason. If a whole server's purchases are failing and the panel does not make the cause obvious, open a ticket and quote a transaction id — that is enough for support to find the exact reason it recorded.

The things that fail and cannot be retried

• An item id the server does not have. Usually an old catalog: re-scan the item list and re-price the item.
• A player the platform could not identify — the link holds neither a usable name nor a usable id. Remove the link and have them link again, or add one by hand.
• A quantity the game itself refuses. Minecraft, for example, has refused more than 100 stacks in one give command since 1.17, so a large quantity of a stacking item can exceed what one purchase can deliver.
• On Minecraft: an item with an enchantment or custom-name tail written in the wrong dialect for the server's version, and RCON not being configured yet (one restart fixes that one).
• On Palworld: PalDefender not installed, or the server never restarted since it was.
• On Valheim: the bridge not reachable — which fixes itself on the next restart.
• On DayZ: the GameGrid DayZ server mod not running, which means the server is stopped. A shop purchase made while the player is offline, dead or unconscious waits and is retried; a kit item that cannot be handed over at that moment is refunded instead.