Guides
Loyalty technology and architecture
Loyalty technology and architecture is the run-time system that records points, applies rules, updates tiers and settles redemptions. The core is a ledger with idempotent writes, a rules engine separated from the ledger, and a real time engagement API. Most cost and failure come from reversal handling, concurrent redemption and migration, so choose those mechanics before any vendor or interface.
What this covers
This guide covers the run-time architecture that keeps points, tiers and redemptions trustworthy across earn, redeem, reversal and expiry. The cluster contains 25 definitions, 8 decisions and 57 curriculum modules, supported by 305 glossary terms. It spans real time ledger mechanics, event integration, tier computation and the engagement surfaces that read balances. It excludes campaign strategy, member psychology, partner negotiation and legal terms. It also does not rank individual vendors beyond the architectural consequences of their integration model.
How the pieces fit together
A purchase at a point of sale, checkout, partner site or wallet sends an event identifying the member, spend and channel. The integration layer normalises that event into a common earn request before any loyalty logic runs. This normalisation is the first architectural choice, because inconsistent product or store identifiers make later reporting and reversals fragile.
The rules engine receives the earn request and calculates base, bonus and status points from the programme configuration. Configuration lives in the programme layer, not in code. Each result carries the source event identifier as an idempotency key, so a retry cannot create a second accrual.
The ledger then records the point movements as append-only entries. It is the only component allowed to change a balance. Every entry has a transaction identifier and a reason code. This ledger first design means duplicate events, chargebacks and manual corrections can always be traced.
Tier logic subscribes to ledger status point totals and updates the member profile when a threshold is crossed. Tier changes are events with old tier, new tier and effective date. The engagement API reads the profile and ledger projections and serves the same balance and next tier threshold to app, web, point of sale and call centre.
Redemption follows the reverse path. A redemption request first reserves the required points, then authorises fulfilment, then debits the reservation. Reversal is symmetrical: a refund event returns points only if the original earn was settled. This path prevents overspend and makes returns auditable.
Sector demand shapes which parts of this spine get exercised. Airlines run tiers in 61 of 61 profiled programmes and hotels in 18 of 18, so they need rich tier and partner earn logic. Grocery runs tiers in 0 of 18 and fuel in 0 of 12, so those programmes need high-volume accrual with simple redemption and almost no tier overhead. The same ledger can serve all sectors when tier logic is optional.
Where programmes get this wrong
The most damaging failure is treating the ledger as a reporting table. Teams copy points from nightly files and then allow marketing tools to add bonuses on top. A duplicate file load creates double points with no transaction history to find the doubled rows. The ledger must own every balance change and require a source identifier.
Hard-coding tier logic across channels produces inconsistent status. A member is Gold in the app but Silver at the service desk because one system recalculates status and another reads a stale field. The correction is one tier service that emits status changes, with every surface reading the same profile store.
Ignoring concurrency in redemption is another recurring mistake. If a system checks the balance and then writes fulfilment as two separate transactions, two simultaneous requests can both pass the balance check. The programme issues two rewards for one balance. Reservation or atomic conditional debit must happen before any partner instruction.
Vendor lock-in appears when a programme selects a platform without an export path for balances and history. Later migration means re-entering balances by hand. With 87 vendors profiled, most teams choose on feature demos rather than on data portability. Ask for the event schema and an exit file before signing.
Reversal handling is often an afterthought. A return arrives and the programme posts a manual negative adjustment that looks like a penalty rather than a reversal linked to the original earn. Members dispute it, support costs rise, and auditors cannot trace the chain. Design reversal as a first-class event with the original transaction identifier from the first week.
Programmes also assume one vendor must own every layer. They buy an enterprise suite for a simple single-brand programme or attach composable APIs to a legacy core with no event bus. Across 87 profiled vendors, the landscape includes 26 ecommerce-smb tools, 19 enterprise platforms, 18 composable-api specialists, 17 vertical specialists and 7 agency-services options. Each solves a different starting point, so match the layer rather than the largest vendor.
How to work through it
- Write the ledger contract before buying any platform. List event types: earn, manual adjustment, reversal, redemption reservation, redemption confirmation, expiry and tier change. Define required fields and idempotency keys. That contract becomes both the procurement specification and the migration map.
- Map the three touchpoints that must show a live balance first, usually mobile app, website account and point of sale. Do not require real time expiry from day one. Agree latency per channel and make the engagement API the only source of balances.
- Decide the integration model by how much of the stack you can own. Composable-api vendors number 18 and suit teams wanting their own ledger or interfaces. Enterprise platforms number 19 and suit teams wanting one supplier for ledger, rules and interfaces. Vertical specialists number 17 and suit sector-specific accounting or partner needs.
- Separate campaign logic from the core ledger. Bonuses, multipliers and challenges must be rules engine configuration, not statements inside checkout code. If changing a bonus needs a code release, the layers are coupled wrongly. Treat promotions as versioned configuration artefacts.
- Implement idempotent writes and replay before launch. Use the source event identifier as the ledger key. Test duplicate delivery, out-of-order events and retries from every integration. The ability to replay a day without doubling balances is a release gate.
- Model tiers as a subscriber to the ledger event stream. The tier service reads status point totals, applies thresholds and emits tier change events. No front end may compute tier. Call centre agents and apps read the same tier event.
- Test reversals, concurrent redemptions and expiry before adding partners. Simulate refunds arriving after expiry, two redemptions in the same instant, and a return of an item whose points already expired. These cases expose flaws in reservation and reversal design.
- Run a shadow tier on historical transactions before any member facing change. Feed a month of settled earns through the new tier service and compare with the legacy tier. Explain every difference before cutover, to avoid mass demotions or surprise upgrades.
- Choose vendors by published event model and exit path, then price. 48 of 87 profiled vendors publish full or partial pricing. A low price with a closed schema is a future migration cost. Require a documented API for balance export and an agreed data dictionary from the first proof of concept.
- Revisit architecture when adding coalition, transfer or gifting. Those features break the assumption that one member earns and redeems within one programme. Coalition programmes run tiers in only 2 of 15 profiled, but still need cross-brand earn reconciliation. Add a partner event adapter and an inter-ledger settlement record instead of bending the core ledger.