What Happens to Your Tebex Store When the Server Goes Offline?
What Happens to Your Tebex Store When the Server Goes Offline?
Host has a bad night. Your city is down from eleven in the evening until lunchtime the next day. You wake up to forty Discord pings, a very calm message from your host, and a sales notification for a package that was bought at 3am by someone who could not connect to anything.
The part that surprises owners every time is that a Tebex store keeps trading whether or not the game server exists. The shop and the payment flow live somewhere else entirely, and your server only enters the picture at delivery. Which means an outage is not a pause in sales. It is a pause in fulfilment, with sales continuing on top, and the gap between those two is where refunds and chargebacks come from.
Two systems, one of which does not care about your outage
The store front, the basket, the payment and the receipt all happen on infrastructure that has nothing to do with your machine. Card processing does not check whether your server is up. A player who bookmarked your store, or clicked a link in Discord, can buy at any hour of any night in the middle of the worst outage of your life.
Delivery is the only half that touches your box. The integration on your server asks for pending commands and runs them. No server, no asking, no running. Purchases sit in the queue, patiently, being undelivered.
Packages that need the buyer online are a second layer of waiting: they hold until that specific player is connected. So a long outage produces two piles, one waiting on the server and one waiting on a player who has given up and gone to bed.
The clock that matters is the buyer’s patience
Nobody reads your status channel before buying. From the buyer’s side, the sequence is: pay money, wait, nothing happens, check the server, cannot connect, assume they have been robbed.
How that ends depends on how long they wait and how visible you are. Twenty minutes and a pinned message, and most people shrug. Twelve hours and silence, and you get a payment dispute, which costs you the sale, the fee, and a mark on your account that no amount of “it was the host” will remove. Disputes are decided on documentation, and “the game was down” is not documentation.
That is the actual risk of an outage on the commercial side. Not lost sales. Delivered nothing, charged anyway.
What to switch off, and in what order
Fifteen minutes of downtime needs nothing. Once you are past an hour with no fix in sight, work down this list.
- Put a notice at the top of the store. Whatever your store settings allow, the shortest useful sentence is the outage, the expectation, and that purchases will be delivered. Buyers who see it before paying are buyers who do not open a dispute.
- Close the store if the outage is going to outlast the day. A closed store makes nothing. An open store that takes money it cannot honour costs more than nothing.
- Say it in Discord where people already are. One message, in the channel they actually read, with a time estimate you can keep.
- Leave subscriptions alone but know they are still running. Recurring payments do not know about your outage either. If it runs long, plan for the renewals that landed during it.
- Write down when it started. You will need the window when you reconcile, and nobody remembers accurately the next day.
Coming back up without losing the queue
When the server returns, the integration starts asking for pending commands again and works through the backlog. That mostly just happens, and the mostly is where you come in.
Check the order list against the outage window and confirm each one actually landed. The failures cluster in predictable places: packages that grant an item to a player who has not come back, commands referencing a resource that failed to start after the reboot, and anything that depends on a character existing when the buyer made a new one out of frustration.
For anything that did not deliver, granting it by hand is faster than explaining why it did not. Keep the admin command for your own packages ready to paste, and log every manual grant with the order id, because otherwise you are one screenshot away from giving the same thing out twice.
If a purchase cannot be delivered at all, refund it yourself before they ask. A refund you issue is an administrative line. A refund they force through their bank is a fee and a dent in your processing reputation.
Build packages that survive being late
The difference between an outage that costs you twenty minutes of admin and one that costs you a weekend is mostly decided months earlier, when the packages were written.
- Make delivery idempotent. A command that can run twice without giving out two cars means you can retry freely instead of investigating first.
- Grant to the account, not the session. Anything tied to a player being in a particular place at a particular moment is a package that fails whenever timing goes wrong. Anything tied to their identifier or licence catches up on its own.
- Know how your framework stores what you are selling. A package that hands over an in game item has to write it in the exact shape the inventory expects, which is a good reason to understand how items are defined and stored before you sell one rather than after a hundred people bought it.
- Log every delivery on your side. The store knows what it charged for. Only your server knows what actually arrived.
- Test against a clean install. Deliveries that only work on your live box have a habit of failing right after a rebuild, which is exactly when you are already having a bad day.
The backlog you cannot see
Undelivered one off purchases are visible: there is an order, and there is no matching delivery. The expensive part of an outage is the traffic that leaves no obvious gap.
Renewals that charged during the downtime. The payment went through on schedule for a perk nobody could use that day. Nothing failed, so nothing appears in any error list, and the only person who notices is the subscriber. A week of goodwill costs you a message saying you have extended everyone by the length of the outage. Not sending it costs you the renewal after next.
Perks that expired while the lights were off. Time based benefits keep counting down whether or not the city exists. Someone who paid for thirty days got twenty eight, and they know exactly which two.
Abandoned baskets. People who reached the checkout during the outage, saw something odd, and left. There is no record of them anywhere on your side, and they do not come back on their own.
Deliveries that half worked. The command ran, one part of it failed, and the order shows as completed. These are the worst of the set, because the player is certain they are missing something and your records say they got everything. Per item logging on your own side is the only thing that resolves it.
The fix for all four is the same and takes fifteen minutes: after any outage longer than an hour, list every order and every renewal in the window, extend time based benefits by the length of the downtime, and say so publicly. Players forgive downtime easily. What they remember is being charged for it.
The long outage nobody plans for
Short outages are an operations problem. The awkward one is the outage that turns out to be permanent, because the host vanished, the owner walked away, or the money ran out.
If you are heading there, the order is: close the store first, cancel recurring payments second, refund anything undelivered third, and say so publicly fourth. Doing it in that order costs you a weekend of admin. Doing it in the reverse order, or not at all, is how a server owner ends up with a payment processor that will not work with them again, long after the community has moved on and forgotten why they were angry.
Practical takeaway
Treat your store and your server as two businesses that happen to share a logo. When one stops, the other keeps trading, so the outage runbook needs a commercial half: notice up, store closed if it is a long one, backlog checked on the way back, manual grants logged, proactive refunds for anything you cannot honour.
Write that down now, while the server is up and nobody is shouting. Three in the morning is a bad time to be deciding your refund policy, particularly when you are also trying to remember how a framework install is supposed to go on the rebuild you are halfway through.
Free Scripts on Tebex
