Custom Loyalty Program Software: Why Does One Customer Have Three Different Point Balances?

Why loyalty stops being a marketing project at a certain size

A customer at a retail group checks the app and sees 4,180 points. At the till the same afternoon the POS shows 3,950, because the store terminal holds a cached balance that syncs overnight and her online purchase from Tuesday has not landed. Customer service sees a third number in the CRM (Customer Relationship Management). She was promised a reward at 4,000 and she is standing at a till being told she has not reached it. The associate does the only sensible thing and overrides, which creates a manual adjustment nobody will reconcile, and the group's points liability drifts a little further from anything finance can defend.

Multiply that by every channel and every store and you have the real reason loyalty ends up in custom build territory for large retailers. It is not the rewards catalogue or the tier badges. It is that points are money. Under IFRS 15 and ASC 606 points issued in a sale are treated as a separate performance obligation, so a portion of that revenue is deferred until the points are redeemed or expire. That makes your outstanding balance a liability on the balance sheet, estimated using a breakage assumption your auditors will question. A programme that cannot produce a defensible number is a finance problem wearing a marketing badge.

Meanwhile the programme touches every transaction in every channel, has to complete inside the till's timeout, must keep working when a store loses connectivity, and is a standing target for fraud because points are transferable value that nobody watches as closely as cash.

Problem 1: there must be one ledger, and it must actually be a ledger

Most loyalty stacks store a balance and update it. That single design decision causes every downstream problem. A stored balance cannot be audited, cannot be replayed, cannot survive a duplicate message and cannot explain itself to a customer on the phone.

Talon.One is a genuinely strong rules engine and we recommend looking at it, but it is a rules engine: it evaluates what should happen, and the orchestration, wallet, statements and reconciliation remain yours. Antavo brings good tier and reward modelling for a mid sized programme. Punchh is well suited to restaurant and convenience operators who want its app experience. Salesforce Loyalty Management fits naturally if the group is committed to Salesforce, and the constraints there are transaction cost and latency once every till in the estate is calling it. None of these will hold your programme's accounting to the standard your own auditors apply, because that is not what they are sold to do.

What a custom build does: an append only ledger of earn, burn, adjust, expire, transfer and reverse events, with the balance derived rather than stored. Every event carries an idempotency key from the source transaction, so a retried POS message cannot award twice, which is one of the most common silent sources of liability inflation we find. Every event carries an actor and a reason, so an associate override is a first class record instead of a mystery. When a customer disputes a balance, you replay their ledger and answer in a minute.

Problem 2: the till does not wait for you

Earn and burn have to complete inside the payment flow. If your loyalty call adds a noticeable pause to every transaction, store operations will disable it, and they will be right to. Worse, the store's link will drop at some point, and the till must keep taking money.

What a custom build does: split the paths. Burn, which spends value, needs a synchronous authoritative answer with a hard timeout and a defined failure behaviour, and the correct failure behaviour is almost always to decline the redemption and complete the sale rather than to hold the queue. Earn does not need to be synchronous at all: capture it locally, display an indicative balance, and post it asynchronously with the idempotency key doing the work. Offline mode then becomes a deliberate design rather than an outage: the till queues earn events, refuses new redemptions above a locally cached balance, and reconciles when the link returns. Decide the offline redemption policy with finance in advance, because the alternative is deciding it during an incident.

Problem 3: breakage is an assumption, and your auditors will ask how you got it

Breakage is the share of points that will never be redeemed. It drives how much deferred revenue you can recognise, so it directly affects reported results. Many programmes carry a number that was set years ago and has never been re-derived from behaviour.

What a custom build does: model breakage from your own cohort data rather than from a constant. Points issued in a period are tracked as a cohort and their redemption curve is measured over time, by tier, by channel and by earn reason, because points earned in a promotion behave very differently from points earned on a normal basket. That gives finance an estimate with a method behind it and a sensitivity analysis attached. Then produce the liability report as a first class output with a full audit trail: opening balance, issued, redeemed, expired, adjusted, closing balance, reconciled to the ledger, with every manual adjustment attributable to a named person. This is the feature that turns loyalty from a marketing cost line into something the CFO will sign, and it is almost always the reason a large group builds rather than buys.

Problem 4: points are transferable value and fraud follows value

Point transfers between members, gifting, family accounts and pooled corporate balances are all popular features and all attack surfaces. The common patterns are dull and effective: account takeover followed by an immediate transfer out, buy and return cycles that keep the points, employee accounts attached to walk in transactions, and reward stacking through a coupon interaction nobody modelled.

What a custom build does: velocity rules on transfer and redemption at member and device level, a hold period on points earned before they can be transferred, and mandatory reversal of points on refund with the reversal linked to the original earn event rather than deducted from the current balance. That last detail matters more than it sounds: deducting from the current balance is how a member ends up negative and how a fraud pattern hides. Anomaly detection has an honest role here, scoring member behaviour against their own history rather than a generic model, and flagging associate accounts whose attach rate diverges sharply from their store's norm.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A first release with the ledger, idempotent earn and burn, tier evaluation, POS integration within the latency budget and offline earn with reconciliation runs $120,000 to $250,000 and ships in 14 to 22 weeks. A full platform adding partner earn, offer and coupon interaction rules, breakage cohort modelling with auditable liability reporting, transfer and fraud controls, member self service and a migration from your existing programme runs $320,000 to $800,000 across 9 to 18 months.

What drives the number up in loyalty specifically: POS estate, because integrating one till software version is a project and integrating three is three projects. Migration, which is the item everyone underestimates, since importing historic balances is easy and importing the history that justifies them is not, and members will notice the difference immediately. Partner earn, where each partner is a settlement relationship as well as an integration. Multi country programmes, since points with monetary value attract different tax and consumer protection treatment by market and you need local advice, not a template. And finance sign off, which is a real workstream with real meetings.

What keeps it down: one channel first with the others reading from the same ledger, tiers before partners, and a deliberate decision to keep the reward catalogue simple in phase one.

Build versus buy, and when buying is the right call

Buy, and do not call us, if your programme is essentially single channel, your earn rule is a percentage of spend, your points outstanding are commercially small, and nobody in finance is currently arguing about the liability. Antavo or Talon.One will have you live in a fraction of the time and cost, and building a ledger to run a stamp card is a waste of your capital.

Build when two or more of these are true. Balances already differ by channel and customer service spends real time reconciling them. Your points liability is material enough that the audit conversation has become uncomfortable. Earn rules change faster than a vendor configuration cycle, which is typical for grocery and fuel where promotions are weekly. Your POS estate is old, mixed, or occasionally offline, meaning latency and queuing behaviour must be designed rather than assumed. You run partner earn or a coalition, where settlement and reconciliation become genuine accounting workflows. Or the programme is a strategic asset rather than a discount mechanism, in which case renting the ledger that holds your customer relationship is a decision you will regret at renewal.

How to choose a developer for loyalty software

Ask what happens when the same POS transaction message arrives twice. If idempotency keys do not appear in the first thirty seconds of the answer, expect double awarding and a liability figure nobody can defend.

Ask how the till behaves when the loyalty service is unreachable. You want a specific answer covering earn queuing, redemption decline and reconciliation on recovery, agreed with finance beforehand rather than improvised in an incident.

Ask how they would produce the liability report and what an auditor would ask for. A team that has done this talks about cohorts, redemption curves and adjustment attribution. A team that talks about a dashboard has built a marketing tool.

Ask who owns the code, the member data and the cloud accounts, and settle it in writing before kickoff. Your member ledger is the record of a promise you made to millions of customers, and it must be portable. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from any arrangement that leaves your points ledger inside someone else's platform.