🎥 Video: How Retailers Use Gamified Loyalty to Outperform Competitors.
Save your seat.
You have the app. You have the users. Multiple services, daily touchpoints, a growing dataset of behavioral signals across payments, bookings, insurance, or whatever verticals your platform covers. And yet the loyalty program is not doing what it should. Enrollment is fine. Engagement drops off. The points balance sits there. Members do not go deeper into the platform the way the product team hoped.
This is a common pattern in multi-service apps, also called super apps, and it is almost never a mechanics problem. The issue is usually that loyalty was added after the platform was built, slotted in on top of an architecture that was never designed to support it. The result is a rewards layer that works in isolation but does not connect to the product behavior it is supposed to reinforce.
This article is about how to fix that. Or, if you are earlier in the process, how to avoid building it that way in the first place.
Loyalty is the connective tissue that makes a multi-service app worth more than the sum of its parts. Or it should be.
It is also a problem that is becoming more common. Business of Apps reported at the start of 2026 that industry analysts see this year as an inflection point for Western connected ecosystems, where loyalty, payments, commerce, and media are converging the way they already have in Asia.
Mordor Intelligence's January 2026 analysis puts North America and Europe together at roughly a third of global super app market volume.
A 2024 peer-reviewed study in Heliyon tracking 380 platforms found firms across mobility, finance, and retail actively restructuring around the multi-service model. More platforms means more loyalty programs being added after the architecture is already in place.
Typically, the sequence goes: launch core services, grow the user base, then ask what to do about retention. A points program gets added. A rewards hub gets built. A tier structure gets designed.
The result is almost always a loyalty layer that sits beside the product rather than inside it. Members accumulate points somewhere, check their balance somewhere else, and redeem through a process that feels disconnected from the rest of the app. Engagement is low not because the incentives are wrong but because using the program takes effort the rest of the app does not.
This is not a design problem. It is an architecture problem.
Multi-service apps arrive at the loyalty question from two very different places, and the solution is different for each.
Grab, Gojek, and WeChat had daily active users before they ever thought seriously about a loyalty program. The challenge for these apps is not frequency; users open them anyway. The challenge is rewarding cross-service depth. A Grab user who only takes rides is worth less than one who also orders food, transfers money, and buys travel insurance. Loyalty should reflect and reinforce that difference, not just count transactions.
GrabRewards was built on a vertical and tier multiplier architecture that varied earn rates by both service type and membership level, a design documented in Grab's own engineering blog. The program rewards usage across transport, food, grocery, and payments rather than optimising for a single service.
Insurance renews once a year. A monthly bank statement is barely a touchpoint. A telco bill is usually ignored. For companies in these categories, building a multi-service platform is an explicit attempt to change the engagement model: give customers a reason to open the app in March, not just when their policy is up.
This is where the loyalty design challenge is most acute. The mechanics cannot just reward the core product (that would be one reward event per year for an insurer). They have to reward engagement with the adjacent services the company added specifically to increase frequency: parking payments, assistance bookings, health checks, partner offers.
Orange Money and MTN's MoMo service show what this looks like in practice: the mobile money account creates daily touchpoints that did not exist when the relationship was purely about airtime, giving the loyalty program a much broader behavioral surface to work with.
The design principle that follows: in a low-frequency category, the loyalty program is not a retention tool. It is a frequency-building tool. That distinction changes what mechanics you choose, what the reward currency does, and what success looks like.
In a single-product loyalty program, a points currency is a retention lever. In a multi-service platform, it has to be something more.
A virtual currency that can only be spent within one service vertical functions, from the customer's point of view, as a discount mechanism rather than a reward. The economics of loyalty points work very differently when the currency is fungible across the whole platform.
A currency that earns and burns across every service (rides, food, insurance, finance, parking, partner discounts) gives customers a reason to consolidate behavior on one platform rather than across five. Every interaction builds toward something useful everywhere. That is the behavioral loop that makes multi-service loyalty work.
Kakao Pay's rewards architecture lets users earn points through financial transactions and spend them across Kakao's entertainment, retail, and commerce services. Mercado Libre relaunched its loyalty program as Meli+ in 2023, covering marketplace purchases, Mercado Pago fintech transactions, and logistics services across Latin America. In both cases, the currency has value because it works across the platform rather than inside a single vertical.
Designing a fungible currency requires a decision made before the first vertical goes live. After members have accumulated balances, changing the redemption model is operationally painful and commercially risky.
In a multi-service app, loyalty-relevant events are continuous: a payment completes, a parking session ends, a service appointment gets booked. The loyalty engine needs to handle these in real time. Batch processing (overnight jobs that update balances the next morning) breaks the feedback loop. When someone parks their car and opens the app five minutes later to see their balance unchanged, the program has already failed that interaction.
For apps targeting frequent engagement, the latency between action and reward is not a technical detail. It is the product experience. Asia Commercial Bank's loyalty program, built on Open Loyalty, handles over 800,000 daily active users and 60,000 transactions a day — a practical benchmark for what real-time processing at scale looks like.
The payments team has one view of the customer. The insurance team has another. The mobility team has a third. The loyalty engine needs a single member profile that aggregates behavioral signals from every vertical to drive tier logic, reward triggers, and personalized mechanics, without requiring each product team to rebuild their data model around it.
This is harder than it sounds. Each vertical usually has its own team, its own roadmap, and its own priorities. Getting them to feed a shared loyalty data layer requires organizational commitment, not just a clean API spec.
One pattern that consistently derails multi-service loyalty programs: the marketing or loyalty team has to open a development ticket every time they want to change a reward rate, add a new partner, or launch a seasonal mechanic.
In a platform that is constantly adding services, the loyalty program will always lag the business if configuration requires engineering time. The teams running loyalty day-to-day need to be able to create triggers, adjust rules, and add integrations without a code deployment. This is a product requirement for the loyalty tooling.
If the payments team owns the loyalty program, the insurance team will integrate reluctantly. If the insurance team owns it, the food delivery team will build a workaround. The loyalty layer needs to sit outside the verticals, connected via a standard event API that each service feeds into. This is what headless loyalty architecture makes possible: a single engine that any surface can connect to without owning the program logic. The program processes the event, applies the rules, updates the member state. What vertical produced the event is irrelevant.
This is as much an organizational question as a technical one. Someone senior has to own loyalty across all services as a function, not as a feature inside one team's product.
The mechanics are rarely where multi-service loyalty programs break down.
The integration model is a more common point of failure. When each vertical builds its own custom connection to the loyalty engine, some do it well and others deprioritize it. The loyalty tech stack integration guide covers in detail how this breaks down and what to do about it. The program ends up reflecting the parts of the business with the strongest engineering teams, not the parts that matter most to the customer.
The second most common failure is the redemption experience. A program where points earn easily but redeem awkwardly (buried menus, limited catalog, separate balances per service) trains users to ignore it. The earn-to-redeem loop needs to be as frictionless as any other transaction in the app.
A subtler failure mode: programs that are generous at launch to drive enrollment, then reduce reward rates once the base is established.
Some decisions in multi-service loyalty are very difficult to reverse after the program is live.
The currency model (what earns, what redeems, and whether the currency is genuinely fungible across all services) should be defined before the first vertical integrates. If the program is running a soft launch or pilot phase first, this is the decision that needs to be locked before that cohort goes live. Members form expectations quickly. Changing those expectations once they have accumulated balances is costly.
The ownership model (where the loyalty engine sits, which team owns it, and what the API contract looks like for each vertical) should be treated as platform infrastructure from the start. The cost of rebuilding loyalty infrastructure around live members is significantly higher than the cost of designing it well in the first place.
And the success metric should be set before the program runs. For a native super app, success is probably cross-service usage depth. For a company moving out of a low-frequency category, it is probably engagement frequency. These are not the same measurement, and a program optimized for one will perform badly on the other.
The companies with loyalty programs that have compounded over time treated the loyalty layer as infrastructure. The connective layer that every service feeds into, and that gets more valuable the more of the platform a customer uses.
The checklist below is not about building the super app itself – the platform, the services, the product stack. It is about the loyalty layer that sits inside it.
These are the decisions that are expensive to revisit once members are live, balances have accumulated, and each vertical has already integrated in its own way.
Getting them right before the first integration is significantly cheaper than correcting them after.
API-first loyalty and gamification engine
Get a weekly dose of actionable tips on how to build and grow gamified successful loyalty programs!
