Rewards are worked out the moment the action happens.
A customer pays at 14:02. Their mission progress, streak and points balance are updated at 14:02, not by a job that runs at midnight. If the same purchase reaches us twice, they are still paid once.
The purchase and the work it triggers are saved in the same instant.
Most loyalty systems record the purchase now and work out the reward later, on a schedule. Anything that goes wrong in that gap loses the reward, and nobody notices until a customer complains. Here the purchase and the reward it owes are written in one operation: either both are saved or neither is.
By the time your server gets its reply, the work that action triggers is already saved and queued. Nothing else has to run for that to stay true.
- No nightly run, no batch window, no schedule to miss.
- The key decides test or live, so a rehearsal cannot pay a real customer.
- Sending the same thing twice is safe. Put your own reference on the request; if it arrives again we hand back the first result.
Send the same purchase twice by mistake and the reward is still paid once.
Repeats happen: a connection drops and your server retries, a queue redelivers, a customer double-clicks. Two things stop that becoming a double payout. Each request can carry a reference you choose, and a repeat returns the original answer instead of paying again. And each attempt is all or nothing, so one that fails halfway leaves nothing behind.
Why a retry cannot pay twice
An attempt either finishes completely or leaves no trace, so there is no half-done state for a second attempt to land on. And a request carrying a reference we have already seen is not run again: we hand back what happened the first time. A milestone pays once, however many times the message arrives.
What a technical review will ask
- A crash cannot strand a reward. Work that did not finish goes back into the queue on its own.
- Rewards are worked out off the request path. A spike in orders queues them, and the dashboard shows how far behind they are.
- The reason is kept. If a reward's delivery fails for good, what went wrong is stored on the player's reward, so you can look it up.
A purchase only wakes the campaigns that use purchases.
An action is not checked against everything you have ever built. When you save a mission we note which numbers it uses, so a purchase wakes only the missions and streaks that watch money spent. A challenge about visits is left alone.
You arrange none of this. When you save a mission, the engine notes which numbers and facts it depends on, and updates that note as you edit.
Run a seasonal campaign, a loyalty programme and a VIP track together. None of them slows the others.
See what happens when a reward fails halfway.
We build a mission in a test account, break it on purpose during the call, and show you what the customer is left with.