In brief
A loyalty engine, a consumer loyalty app and a digital card product share a category name and almost nothing else. The costly mistake is not overpaying, it is buying the one that assumes a developer you do not have or a relationship you thought you owned.
The short answer
Three unrelated products are sold under the phrase “loyalty software”, and they are not tiers of one another. A loyalty engine is a rules backend with an API and no customer-facing screen. A consumer loyalty app is one app the customer downloads and uses at many shops, where your business is a tenant. A digital card product gives your business its own card and asks the customer to install nothing.
Buying the wrong one is expensive in a specific way. An engine costs you a developer you did not budget for. A multi-merchant app costs you the relationship you thought you were buying.
A loyalty engine is a backend with no front
It stores members, balances and rules, and exposes them over an API. It ships no screen for the customer and usually none for the counter.
What you pay for is the ledger and the rule evaluation. Earn one point per pound. Move up a tier at five hundred. Expire unused points after twelve months. Exclude gift cards from earning. An engine does all of that correctly, at volume, and it will keep doing it when you have four million members.
What it does not do is show anybody anything. The card, the balance, the “two visits to go” line, the join screen and the button on the till are all yours to build, and then yours to keep building. Every rule change is a ticket in somebody’s sprint.
The tell is the pricing page. If the price is “contact sales”, the API documentation is a top-level navigation item, and every screenshot is of a developer console rather than a counter, you are looking at an engine.
Who it is for. A business that already runs an app or a transactional website, with someone whose job is to change them. If nobody’s job description includes shipping code, an engine is a database you rent.
A consumer loyalty app makes you a tenant
One app, many merchants. The customer downloads it once and collects at every shop in the network, and your program is one entry inside it.
The customer joined the app, not you. The account, the password reset, the notification permission and the icon on the home screen all belong to the app. Your name appears inside a container somebody else controls, and the push notification that brings someone back was sent by a brand that is not yours.
The network is also a directory, and density is what makes it worth downloading. That gives the app a commercial reason to sign up the shop two streets away that sells what you sell. This is not bad faith on the vendor’s part. It is the product working exactly as designed, and it is the thing to price in before you sign.
Worth separating from a superficially similar thing. Several card products also keep one customer’s cards from different businesses in one place. The distinction is not whether cards share a container. It is who the customer signed up with, and who is allowed to message them afterwards. Ask those two questions rather than looking at the screen. There is more on the three meanings of this phrase in loyalty card apps.
Who it is for. Businesses whose customers already have the app, and locations where the network genuinely has density: a shopping center, a campus, a chain of forecourts. Where the network is thin, you are asking every customer to install an app in order to visit one shop, which is the worst of the three options on offer.
A digital card product gives you your own card
Each business gets its own card, its own rules and its own name on it. The customer joins by scanning a QR code or opening a link, and installs nothing. The mechanics are covered in digital loyalty cards.
The mechanic is nearly always a count. A visit, a stamp, a target, a reward, with someone on shift confirming each one. The owner sets the rules in a browser, and setup is measured in an afternoon rather than in sprints.
The limit sits on the rule side and it is real. A card product counts one thing and pays out at a number. Spend bands, tiers, transferable balances and points that expire on a schedule are usually outside it, because the product never sees the basket. If your program needs the transaction value, it needs the till, and that is a different purchase.
NeoLoyal is in this third category. That is worth stating early, because the rest of this post rules it out twice.
Who it is for. Businesses with a counter, transaction values that are broadly similar to each other, and no engineer.
The three, side by side
| Loyalty engine | Consumer loyalty app | Digital card product | |
|---|---|---|---|
| What you buy | Rules and an API | A place inside someone’s app | Your own card |
| Customer-facing screen | None. You build it | The app’s | A browser card or wallet pass |
| Who the customer joins | You, through your app | The app | You |
| Set up by | A developer, over weeks | A merchant agreement | The owner, in an afternoon |
| Rule complexity | Anything you can specify | Whatever the app supports | A count and a target |
| Changing a rule | A release | A support request | A form |
| Price shape | Annual contract, per member or per call, plus implementation | Monthly fee or commission | Flat monthly |
| Where it fails | Nobody has time to build the front end | Your regulars become loyal to the app | It will not do spend-based rules |
The row that decides most purchases is not the price. It is “set up by”, because that is the line where the cost stops being money and starts being your calendar.
Match the product to the shape of the business
One shop
A card product. An engine has nothing to sit in front of it, and a network app asks your regulars to install something in order to visit one counter. This is the cheapest correct answer, and the correctness matters more than the cheapness.
Several outlets, one owner
Still a card product, but the multi-outlet question becomes the buying question. Are balances shared across sites, or does each site keep a separate list? Customers assume shared, so a tool that duplicates the program per location will produce an argument at the second shop within a month. That, plus staff permissions that follow a person to whichever site they are working at today, is what running one program across several shops turns on.
Online only
Neither of the first two by default. There is no counter, so there is no QR poster and no member of staff to confirm anything. The store already records the order value and the email address, which means the qualifying event is captured before any loyalty tool is involved. The right answer is whatever attaches to the store: the platform’s own loyalty extension, or an engine if you have someone to wire it up.
Franchise
The software question comes second. First: does the customer belong to the brand or to the individual franchisee, and will a balance earned at one owner’s site be honored at another’s? That is a contract question, and it has been settled badly in enough networks to be worth settling on paper first. Once it is answered, an engine or a multi-site card product can implement either answer. Before it is answered, no product can.
The question that sorts it in a minute
Who does the customer think they joined?
- Your own app: you need an engine.
- The app’s brand: you are buying a consumer loyalty app.
- Your shop: you need a card product.
The three categories map onto three completely different budgets, and the category is a firmer decision than the vendor. There is a longer treatment of the evaluation in how to choose loyalty program software, and the vendor questions themselves are in ten things to check before buying.
Before any of that, do the thing you are about to ask every customer to do. Take out your own phone, go through the vendor’s join flow as a customer, and count the taps between the poster and the first stamp. Then read whose name is on the screen that comes back. The tap count and the name are the two facts that decide this, and neither of them appears on a pricing page.