Guide 57 · Technology
Real-time or batch points posting?
Post points in real time for any purchase where members can see, redeem or transfer their balance right away, because a missing balance after a purchase looks like a broken promise. Keep batch processing for partner settlement, internal adjustments and period-end calculations. Real-time posting only works if the ledger can accept each event safely once, so check that before you promise instant points.
Real-time loyalty starts with a simple question: when a member buys something, how soon should the points appear? For years the answer was the next day, after an overnight file. Today many members check the app at the counter. This guide explains real-time and batch processing for points, what each asks of your systems and how to decide which events need which.
Two methods
What is the difference between real-time and batch posting?
With real-time accrual, the point of sale, checkout or app sends each qualifying transaction to the loyalty platform as it happens. The platform applies the earning rule and the balance updates within seconds. With batch accrual, transactions are collected and sent in a file, often nightly or hourly, and the platform applies them all in one run.
“Real-time loyalty” is also used for two other things: instant redemption at checkout, and offers triggered by what a member is doing right now, covered in how far loyalty personalization should go. This guide is about earning, the posting of points, because the other two depend on it: an instant offer is of little use if the balance behind it is a day old.
Both methods write to the same place in the end: the points ledger, the record of every point earned, spent, reversed and expired. The difference is when the write happens and what the member sees in between.
What members notice
Why does posting speed matter to members?
Because points are a promise made at the moment of purchase. If a member pays, opens the app and sees no points, many will assume something went wrong. Some will call or write to customer service, and some will stop trusting the balance.
Speed matters most when members can act on the balance immediately: redeem a reward on the next visit, use points toward the same day’s purchase, transfer points or watch progress toward a tier. If the program offers any of these, a delay is visible. If members only see a monthly statement and cannot redeem until then, a delay is mostly invisible.
There is a cost on the other side, too. In a hypothetical program with 2 million qualifying transactions a month, if delayed posting triggers one “where are my points” contact for every 250 transactions, that is 8,000 contacts a month. At a few dollars each in agent time, the support bill alone can exceed what the extra infrastructure for real-time posting costs. Measure your own missing-points contacts before and after any change.
What the ledger needs
What does real-time posting require from the ledger?
Three properties, and the first is the most important.
- Each event is applied once. Networks retry messages, and terminals resend them after timeouts. The ledger should use the source transaction ID as a key, so a duplicate cannot post points twice. This property is called idempotency.
- Balances are consistent right after a write. If the app reads the balance a second after the purchase, it should see the new points. Otherwise the program is real time in name only.
- Order does not break the result. A refund can arrive before the purchase it reverses, or two events can arrive out of sequence. The ledger needs rules for both, such as holding a reversal until its original earn is found.
If your current ledger cannot do these things, the decision is not real time against batch; it is whether to replace or upgrade the ledger first. An event-driven architecture, where systems publish each transaction as an event that the loyalty platform subscribes to, is the common way to meet these needs.
Where batch fits
Where does batch processing still make sense?
Batch remains the right tool for work that is naturally periodic or that comes from outside your systems:
| Activity | Usual method | Why |
|---|---|---|
| Base points on your own purchases | Real time | Members expect to see them at once |
| Redemptions | Real time | Points must be reserved before the reward is given |
| Partner earn (cards, travel, retail partners) | Batch, shown as pending | Partners send settlement files on their own schedule |
| Period-end bonuses (“spend $200 this month”) | Batch | The result is only known when the period ends |
| Points expiry | Batch | Runs on a schedule against inactive balances |
| Manual adjustments and corrections | Either, logged with a reason | Volume is low; traceability matters more than speed |
| Reconciliation with sales and finance | Batch | Compares full days or periods |
A program can therefore post base points instantly and still run nightly jobs. The important part is that every path writes through the same ledger with the same rules.
Partner activity
How should you handle partner activity that cannot post instantly?
Show it as pending. When a member books a partner hotel or uses a co-brand card, you may know about the activity long before the partner settles it. Display a pending entry with the expected posting date, then confirm it when the file arrives. This keeps the member informed without pretending the points are spendable.
Agree posting timelines in each partner contract, and track late or missing files. Members will blame your program for a partner’s delay, so the pending view and a clear explanation in the program terms protect you both.
Make the call
How do you choose for your program?
Apply three tests:
- The counter test. Can a member open the app right after paying and see the points? If they cannot, and your program lets members redeem or track progress at any time, move base earn to real time.
- The ledger test. Can your ledger apply each event exactly once and show a consistent balance within a second? If not, fix that first. Promising instant points on a ledger that double posts is worse than an honest overnight wait.
- The cost test. Compare the infrastructure cost of real-time posting with the support contacts, complaints and goodwill lost to delays. If real time would cost a significant share of program margin and you have measured no drop in missing-points contacts where you have tried it, batch may be the cheaper honest choice.
If you are moving from batch to real time, do it in stages. Start with one channel, such as the app or online checkout, and run the real-time feed alongside the existing nightly file for a few weeks. Compare the two every day: the same transactions should produce the same points. Once they match, switch that channel off the file and move to the next one. Keep the nightly reconciliation even after every channel is live, because it is how you catch events that never arrived. Tell members what is changing only when it works in every channel, so the promise of instant points is one you can keep.
Also plan for fraud. Points that post instantly can be spent instantly, so consider a short hold before points from returnable purchases can be redeemed. See loyalty fraud for the common patterns.
More answers
Frequently asked questions
What is real-time points posting?
The member's balance updates within seconds of the qualifying purchase, because the point of sale or checkout sends each transaction to the loyalty platform as it happens. Batch posting instead collects transactions and applies them in a scheduled run, often overnight.
Is batch processing outdated?
No. Batch is still the right tool for partner settlement files, bonuses calculated at the end of a period, expiry runs and reconciliation. The question is which events members expect to see immediately, not which method is newer.
How should a program show points from partners that arrive later?
Show a pending entry as soon as you know about the activity, with an expected posting date, and confirm it when the partner file arrives. Members accept a short wait when they can see the points are on the way.
Does real-time posting increase fraud risk?
It can, because points that post instantly can also be spent instantly. Reserve points earned on returnable purchases, or hold them for a short period before they can be redeemed, and monitor unusual earn and burn patterns.
How long do loyalty points take to post?
With real-time posting, seconds after the purchase. With batch posting, usually after the next scheduled run, often overnight. Points from partners such as card issuers or hotels can take days or weeks, because they post only when the partner sends its settlement file, which is why programs should show them as pending.
Can a program mix real-time and batch posting?
Yes, and most do. Base points on your own transactions post in real time, while partner earn, some promotions and adjustments run in scheduled batches. The member view should make clear which entries are confirmed and which are pending.