Real-time loyalty: what it really means and how to verify it
Resources · Concept
Real-time loyalty is a loyalty program in which earning, balance, rewards and events happen while the customer is buying: points are recorded in seconds, the balance is the same on every channel, the discount or cashback is applied inside the payment and every event goes out by webhook immediately, not in an overnight batch.
- RegisterIn-store purchase
- IdentificationDynamic QR
- RewardInside the payment
CamilaGold member · 2,480 ptsThe channels- AppBalance updated
- ConsoleSame balance
- WebhookEvent sent
- < 50 msMember recognized
- ~150 msReward decided
- < 1 sPurchase recorded
Banks and fintechs, in production
Our banking and fintech clients already deliver cashback at payment with Qurable.
Pomelo, Santander Peru, Banisi and Konfío, among others. With Pomelo, banks, fintechs and companies that issue cards turn on loyalty and cashback without a separate technical project.
- ~150 msReward decisionInside the authorization
- < 50 msMember identificationp95, server-side
- 99.5%SLACommitted availability
- 18MMembersIn programs running on Qurable
Key takeaways
- Real time means earning, balance, rewards and events happen while the customer is buying, not in an overnight batch.
- Ask for latency per operation, in p95 or p99 percentiles, stating where it is measured.
- A balance that differs between the app and the register gives away batch in disguise.
The difference
Real time or batch in disguise.
Many loyalty platforms show a fast screen, but behind it they calculate points in an overnight batch. Members notice when their balance differs between the app and the register, or when the reward arrives days later.
| Batch in disguise | Real time | |
|---|---|---|
| Earning | Points appear the next day, after the close | Points are recorded in the same operation or in under a second |
| Balance | Each channel shows a different snapshot of the balance | One balance, the same in the app, the register, ecommerce and customer service |
| Reward | Calculated later and delivered on the statement or the next purchase | Decided and applied inside the payment, on the same receipt |
| Redemption | Validated against a balance that may be out of date | Points are held on the spot and confirmed or released with the payment |
| Events | A daily file for the CRM and other systems | Every program event goes out by webhook as it happens |
| Liability | Known at month-end close | Visible at any moment, with every movement |
The four layers
Where it has to be real time.
«Real time» is not one thing. It is four moments of a points program, and each one has its own latency and its own way of failing.
The purchase reaches the profile
In the same operation (synchronous) or in the background (asynchronous), depending on the integration.
With a measured confirmation
How long it takes to be committed, measured in percentiles, not as an average.
No duplicates
A retry from the register never adds the points twice.
One balance
Every channel reads the same record, not a copy that syncs every so often.
Hold on redemption
Points are held on authorization and deducted on capture, or released if the payment does not go through.
Instant reversals
A return deducts or restores points on the spot, not at the next close.
Identify
Recognize the member by card, QR code or account before the receipt closes.
Decide
Choose the reward with the current profile, balance and rules.
Apply
Discount, cashback or points on the same receipt, without slowing the sale.
A webhook for every event
Points earned and redeemed, tier changes and coupons used, as they happen.
Journeys that react
A message or campaign triggered by the purchase, not the next day.
Signed
Every event carries a signature so the receiving system can verify where it came from.
The latencies that matter
What to measure and how to ask for it.
A latency without context says nothing. Ask for it per operation, in percentiles (p95 or p99), stating where it is measured and what happens when it is exceeded.
| What to measure | How to ask for it |
|---|---|
| How long it takes to recognize the member | At p95, server-side. If the reward goes on the receipt, it has to be a fraction of the total payment time. |
| With which identifiers | Card, QR code, phone or account, and whether the QR code changes so it cannot be copied. |
| How long the full decision takes | From the moment the transaction arrives until the reward comes back, including reading the profile and the rules. |
| Which data it uses | Whether it decides with the current balance and profile or with yesterday's copy. |
| Synchronous or asynchronous | Whether the purchase is recorded in the same operation or in the background, and how quickly it is confirmed. |
| Idempotency | A retry with the same key must not create a second movement. |
| When each event goes out | As it happens or in a batch. Ask for the event list and whether events are retried when the destination fails. |
| What happens to the sale | The sale should never be blocked: earning is queued and recorded when the service is back. |
| Which operations do need a connection | Redemption has to confirm the balance; ask how it behaves when there is no response. |
How to evaluate
Five tests to catch batch in disguise.
Run them in a demo or a pilot, with a real or simulated purchase. If any of them fails, real time is only on the screen.
Buy and check the balance
Make a purchase at the register and open the app: the points must be there within seconds.
Compare two channels
Balance and tier must be the same in the app, ecommerce and customer service.
Make a return
The reversal must show in the balance right away, not the next day.
Listen to the webhooks
Connect a test receiver and check when each event arrives after the purchase.
Ask for percentiles, not averages
Latencies at p95 or p99, measured in production, with the exact measuring point.
With Qurable
Qurable's latencies, measured in production.
Qurable recognizes the member, decides the reward and records the purchase while the payment is being authorized, with one profile, one rule set and one ledger.
Identification in under 50 ms
p95 server-side, by card, a QR code that changes every 30 seconds, a wallet pass or an account.
See the Customer Data PlatformDecision in ~150 ms
The reward is chosen and applied inside the authorization, at the POS, the processor or checkout.
See Transaction IntelligenceRecorded in under 1 s
In the same operation or in the background, on a double-entry ledger with idempotency; every event goes out by signed webhook.
See the Loyalty LedgerThe sale is never blocked
If the service does not respond, the register keeps selling and earning is recorded when it is back; redemption does require a connection.
Loyalty at the POS and checkout
FAQ
What teams ask about real-time loyalty.
Short answers for loyalty, technology and payments teams.
It is a loyalty program in which earning, balance, rewards and events happen while the customer is buying. Points are recorded in seconds, the balance is the same on every channel and the reward is applied inside the payment, instead of being calculated in an overnight batch.
It means processing transactions in batches, usually once a day: the system receives purchases, calculates points overnight and updates balances the next day. It works for statements and reports, but it cannot give the reward on the same receipt or show an up-to-date balance.
One that lets the platform decide without noticeably lengthening the payment: a fraction of the total authorization time. Ask for it per operation (identification, decision, recording), at p95 or p99, measured in production. On Qurable, identification is under 50 ms at p95 server-side and the full decision takes ~150 ms.
With synchronous recording, the purchase is recorded in the same operation as the payment. With asynchronous recording, it is recorded in the background right after. Both are real time if confirmation arrives in seconds; neither is if it waits for an overnight batch. On Qurable, asynchronous recording confirms in under 1 s.
In a sound design, the sale is never blocked: earning is queued and recorded when the service comes back. Redemption is different, because it has to confirm the balance before deducting points, so it requires a connection.
It matters most when the reward is given at the register or at checkout, and when members use several channels: in-store, app and ecommerce. A program that only sends monthly statements can live with batch; one that rewards inside the purchase cannot.
Yes. Qurable recognizes the member in under 50 ms (p95, server-side), decides the reward in ~150 ms inside the payment, records the purchase in the same operation or in under 1 s, and publishes every program event by signed webhook as it happens.
Last reviewed
Further reading
Keep reading about loyalty at payment.
The pages where real time shows up in the product.
- ConceptTransaction Intelligence
What it means for loyalty to decide inside the payment.
- ModuleLoyalty at the POS and checkout
Discounts, cashback and pay with points inside the authorization.
- ModuleLoyalty Ledger
Every movement recorded, with lots, expirations and liability.
- ResourceCard-linked offers vs loyalty at payment
After the payment or inside it: what changes for the customer and the program.
- ResourceLoyalty RFI, RFP and RFQ checklist
The questions to evaluate platforms, area by area.
Measure real time with your own program.
In a 45-minute technical session we walk through a purchase end to end, with measured latencies and a case like yours.