Purchases, Delivery and Refunds
What happens between /buy and the item appearing in game, what each delivery state means, how long a stuck purchase is retried, and what a refund does and does not do.
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.
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.
| State | Badge | What it means |
|---|---|---|
| Delivered | ✓ | The item was handed to the player. |
| Pending | ⏳ | Written the instant the purchase is made, before the first delivery attempt. It should not stay there for more than a few seconds. |
| Queued | ↻ | Paid for and waiting for a reason time will fix — the player is offline, the server is stopped or restarting, or the host was briefly unreachable. Retried automatically, and it carries a Retry button if you want to try now. |
| Failed | ✗ | Either the platform gave up after retrying, or it hit something retrying cannot fix. This is the state that wants a person: Retry it after fixing the cause, or Refund it. |
| Refunded | ↩ | The coins were credited back. See below. |
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.
- Windrose — the tick means our mod put the item in the world at the player's feet and the game accepted it.
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.
/buyis 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.
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 Full Access. 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.
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.