Nine o'clock on a Friday, peak hours, and someone buys a fifteen pound pack. They alt tab back in, wait, check their inventory, wait some more, and then type the word that ruins an evening: scammed. Six people pile in behind them within a minute, because a public accusation with no reply looks like an admission. Your staff are asleep, at work, or in a pursuit.
The purchase was fine. It delivered eleven minutes later, exactly as designed, to a player who had already left. What went wrong was everything around the delivery, and that part is entirely yours to fix. Here is what should happen in the first minute after a purchase, what to do when it does not, and how to stop one slow delivery from turning into a public incident.
The delivery chain, in plain terms
Four links, and three of them are outside your game server.
The player checks out on the store. The payment clears. The store records what was bought and holds the commands attached to that package. Your server's integration asks for pending commands on its own schedule and runs them.
That schedule is the reason "instant" is not quite true. There is a gap, usually short, between the payment clearing and your server picking the job up. Packages configured to require the player to be online add a second wait, because they hold until that specific person is connected.
So the honest promise to a buyer is not instant. It is "within a couple of minutes while you are in the city, and next time you join if you are not". Put that sentence on the package description and you have prevented most of the drama in this article.
What the first minute should look like
Three audiences, three things to see.
The player should get something in game the moment it lands. A notification with the package name, not a silent inventory change. People check their bag, see something that might always have been there, and stay unsure. A message that says what arrived removes the doubt entirely.
Your staff should get a line in a channel they can read: who bought what, when, and whether the command succeeded. Not the payment details, just enough to answer a question without waking the owner up.
Your logs should get a row in your own table with the order id, the identifier, the package, the result and the timestamp. The store knows what it charged for. Only your server knows what actually arrived, and the gap between those two is where every awkward conversation happens.
Design packages that can catch up
Deliveries fail. The goal is to make failure boring.
Grant to the account, not the session. Anything that depends on the player standing in a particular place at a particular moment breaks whenever timing goes wrong. Anything keyed to their identifier catches up by itself.
Make delivery idempotent. A command that can run twice without handing out two cars means you can safely retry instead of investigating first.
Give the player a claim. A command or a menu that lets them collect an unclaimed purchase turns a support ticket into a self serve fix. It is the single highest value thing on this list, and nearly nobody builds it.
Know how the thing you sell is stored. A package that hands over an in game item has to write it in exactly the shape your inventory expects, which is a good argument for understanding how items are defined and stored before selling one rather than after a hundred people have bought it.
Test on a clean install. Deliveries that only work on your live box have a habit of failing right after a rebuild, when you are already busy.
The five reasons a delivery does not land
In the order you should check them:
- The player is not online and the package needs them to be. Nothing is wrong. Say so.
- The server is down or restarting. The queue holds and runs on the way back up.
- The command targets a resource that is not running. Common after an update, and invisible unless you log failures.
- The identifier does not match. Usually someone who linked the wrong account or bought for a friend, occasionally a mismatch between the identifier type your store sends and the one your script expects.
- A typo in the command. An item name that does not exist fails quietly on most setups. Your log is the only place that ever mentions it.
Four of those five are visible in your own logs within seconds, which is why the logging is worth more than any support policy.
The support script your staff can actually follow
Give your team four steps and they will handle nine out of ten of these without you.
Ask for the order number or the email used, never card details. Look the order up. Check the delivery log for that order id. If it delivered and the player cannot find it, walk them through where it went. If it did not, grant it by hand and record the manual grant against the order id so nobody does it twice.
Then the tone rule, which matters more than the steps: answer publicly, quickly, briefly. "On it, checking now" in the channel where the accusation landed does more for your reputation than a perfect resolution an hour later in a DM.
Refunds, before they become disputes
If you cannot deliver something, refund it yourself and tell them you have. A refund you issue is an administrative line item. A refund forced through a bank is a fee, a mark against your store, and a player who tells the story for months.
The window that matters is the first day. Most people who open a payment dispute do it after silence, not after a no. Even an answer they dislike, delivered the same day, usually keeps things civil.
Subscriptions, which fail differently
Recurring packages are the ones that generate support tickets months after the sale, and the failure modes are nothing like a one off purchase.
The renewal that lands while you are down. It charges regardless. The perk should already be active, so nothing visibly breaks, but your delivery log will show a renewal with no matching command, and a player whose perk expired the same night will reasonably assume the two are connected.
The expiry nobody communicated. A perk quietly stops working and the player thinks something broke. Anything that expires should tell the player before it does, and tell them again when it has. Silence here converts a lapsed subscriber into an angry one.
The cancellation that does not remove anything. Someone cancels, keeps the perk forever because nothing on your side listens for it, and your paying subscribers eventually notice. Handle the removal at the same time you build the grant, not later, because later means never.
The card that fails. Payments decline for ordinary reasons, and the player usually does not notice until the perk stops. A short, friendly message beats a silent downgrade, and it recovers a surprising share of them.
The rule underneath all four: build the grant and the removal in the same sitting, and make both of them tell the player what happened. A perk that arrives silently and leaves silently is a perk people stop paying for, because they were never quite sure it was doing anything.
Keep a monthly list of active subscribers somewhere your staff can check, too. When someone says they have been paying for three months and the perk stopped, the conversation is much shorter when you can see that they have.
The prevention list, in one place
- One line on every package description saying when delivery happens.
- A pinned message in your store channel saying what to do if something has not arrived.
- A dedicated channel for purchase problems, so they do not land in general chat.
- Delivery logging on your side with order ids.
- A claim command for anything that can be claimed.
- One person on call at weekends who can grant a package by hand.
None of that is technically hard. All of it is the difference between a quiet store and a public one.
Practical takeaway
The purchase is not finished when the payment clears. It is finished when the player can see what they bought. Build the confirmation, log the delivery, publish the timing, and give your staff a four step script, and the Friday night pile on stops happening.
The player from the opening got their pack, and an apology, and stayed. The six people who piled in behind them still tell the story occasionally. That is what an eleven minute silence buys you.
