Wiki / Server

How delivery works

What happens between paying and holding the coins - and what to do when it does not.

This page is the "why is my order stuck" page. It is written for players, but the mechanics are the same ones staff use to fix a stuck order.

The four states an order can be in

State What it means
pending The bill exists and ToyyibPay has not confirmed it paid
paid The payment is confirmed. The coins are owed and waiting to be handed over
delivered The server has run the delivery and the coins are in your balance
failed The payment did not happen, or the gateway refused the bill

An order goes pending → paid → delivered, and can go pending → failed. A failed order cannot come back to life, so a payment that succeeds after a failure is handled separately rather than lost.

Why it is a queue and not a push

The Minecraft server is behind a home connection with no way in from outside, so nothing can call it. It cannot be told "someone paid". Instead the server asks the store every few seconds whether anything new has been paid for.

That is also why delivery is not instant. The store knows within a second or two of the payment; the server finds out on its next check.

Fast while you are paying, lazy the rest of the time

The store tells the server how soon to check again:

  • Every 3 seconds while an unpaid order is less than fifteen minutes old — that is somebody standing on a payment page.
  • Every 30 seconds otherwise.

So a purchase usually lands in a second or two, and the polling costs almost nothing the rest of the day. If the hint is missing or unreadable the server falls back to its configured interval rather than stalling, and it never goes faster than once every 2 seconds or slower than once every 5 minutes, whatever it is told.

The three things that can delay coins

1. You are not online. Coins are credited to a player who is on the server. If you are offline, the order sits in paid and the server holds it until you log in. Nothing is lost, and it does not expire.

2. The confirmation was lost. ToyyibPay confirms a payment by calling the store, and occasionally that call does not arrive. So the store also asks ToyyibPay about recent unpaid orders, on every check the server makes. An order whose confirmation went missing settles on the next check, usually within seconds.

This matters enough to be worth spelling out: it is not enough to trust the incoming call. A payment whose confirmation never arrived would otherwise sit at pending for ever, looking exactly like a payment that was never made.

3. You typed your username wrong. The delivery goes to the name on the order. A typo means the coins went to whoever owns that name. This is the one case nothing can undo.

If an order is stuck

The status is on the page you land on after paying, and it can be looked up by reference at any time. When you report one, quote the reference — it looks like ELD-1789660072112-7e2d74.

A lost confirmation on an order older than a day is the one case that needs a hand: the recovery sweep only looks back 24 hours, and it can only ask ToyyibPay about a bill whose bill code was recorded. If the code was never stored, the payment has to be found in ToyyibPay's own dashboard by hand. That is rare, and it is why an order that cannot be confirmed stays visible rather than being quietly deleted.

For staff

  • Every order is readable in one place, whatever its state, including the bill code and the reference the bank used.
  • An order that was created before bill codes were stored can have one attached by reference. The next check settles it, and the same code path pays the coins — so the purchase announcement fires exactly once however the payment was confirmed.
  • The thank-you page never settles anything. It is reachable by anyone with the URL, so it only reads. Settlement requires a confirmation whose signature is checked against the gateway's, and then a second check that asks ToyyibPay what the bill actually says.
  • Delivering twice is harmless and prevented twice over. The store hands an order over once; the server keeps its own record of what it has already given out, and refuses a repeat even if it is told about one.