Loyalora

Self-hosted points register with a ledger you can replay: no stored balance, no order ceiling, no monthly fee.

The problem it solves

A loyalty scheme is judged in one moment: a customer at the counter says the balance is wrong, and somebody has to work out which number is true while a queue watches.

Hosted loyalty tools meter by how many orders your business takes, so the bill is indexed to your own growth for as long as you run the scheme. And most of them store a balance as a number, which is exactly the design that eventually stops agreeing with the history behind it.

• Monthly plans priced by order volume, rising as the business does well
• A customer list and a points ledger living in somebody else's account
• A stored balance that drifts from its own transaction history, silently

Every feature

• The customer card. One screen: the balance, the immutable history with a running total behind it, what that balance can be turned into right now, and how many points the next reward still needs.
• A balance is a SUM, never a stored number. SUM(points) over the ledger. There is no balance column and a test asserts the schema has not grown one, so no screen, export, PDF or API response can disagree with the history behind it.
• Entries are immutable. Nothing updates or deletes an entry. A mistake is corrected by writing an opposite entry with a reason, so the register can always answer why a balance is what it is by replaying itself.
• A redemption cannot spend the same points twice. The write transaction re-reads the balance inside the lock before it commits. Proven by racing six real operating-system processes at three redemptions worth of points, on both database engines: exactly three win, the balance lands on zero, never below.
• Points are earned, never typed. You enter what happened — the amount spent, the visit — and the program rate decides, in integer arithmetic that always rounds down. The counter, the API and the assistant take what happened — the amount spent, the visit — and the program rate decides the points. The one exception is a manager's adjustment, which carries a written reason on the ledger.
• Two program kinds over one ledger. Points per amount spent, or stamps per visit, with rewards priced in the same unit.
• A role ladder with the right gap in it. A clerk redeems; only a manager can create or destroy points by adjustment, because an adjustment is points minted from a typed reason. A register where anyone at the till can mint points is not one anyone can defend.
• Works for your AI, not just for you. A REST API with an OpenAPI spec, signed webhooks, and an MCP endpoint, all under the same key, roles and floor-at-zero guards as the counter.
• Points from the till. Your till sends each sale with the card code and Loyalora's own rate decides the points. A retried sale is never counted twice.
• Customers join from their own phone. Put the poster by the till; customers scan it, type their name and show their new card.
• VIP tiers. Regulars earn more: tiers by what they earned in the last 12 months, applied everywhere points are recorded.
• Bonus points by item. A coffee can earn more than a pastry, at the counter and from the till.
• Several shops, one balance. Every entry records its shop; the ledger filters and exports by shop.
• Refunds take the points back. Once, and never below zero.
• Redeem at the till. Your till sends the card code and the reward; the reward is redeemed if the balance covers it, a retried request redeems once, and a short balance says how many points are missing.
• Updates from inside the app. The Updates page installs a new release with your license key: Ownware's signature is checked, a backup is taken first, and the app puts the previous version back by itself if the update is interrupted or the database step or start-up check of the new version fails. It never checks by itself.
• Backups by themselves. Automatic backups, an optional copy to S3-compatible storage you own, and a weekly check that the latest backup reads back. The Health page names anything that needs attention.
• Own It 4.0.1 — fixes and an up-to-date manual. For Loyalora, 4.0.1 fixes an installer that had lost its styling, a rollback that a page opened during an update could stop and a command-line update that ended in an error after putting the previous version back. Its manual, FAQ and QUICKSTART now cover everything 4.0 added, including two Nginx rules that keep the data folder private. Your license covers it: press Check for updates on the Updates page, or download it from your order page.
• Own It 4.0.2 — the installer opens on every host. For Loyalora, 4.0.2 fixes a fresh install on an Apache host: the one-page setup at /install/ looped back to itself and never opened, and now it opens. Your license covers it: press Check for updates on the Updates page, or download it from your order page.

Release notes in full

• Own It 4.1: client installations and your other tools. For Loyalora, 4.1 makes two changes that every app gets. An Extended license bought from October 4, 2026 covers up to ten client installations, one per client project: hand each one over to the client or host it for them, with the client's logo and colors from the app's branding settings. The API reference now shows how to connect Loyalora to Zapier, Make or n8n, using its own webhooks and API key. Your license covers the update: press Check for updates on the Updates page, or download it from your order page.
• Own It 4.0: it updates and backs itself up. For Loyalora, 4.0 means updates from inside the app: the Updates page checks for a new release with your license key, verifies Ownware's signature, takes a backup and puts the previous version back by itself if the update is interrupted or the database step or start-up check of the new version fails. A new install can start with a sample business and remove it in one click; backups run by themselves, with an optional offsite copy and a weekly check that the latest one reads back; and the Health page says whether the install is looking after itself.
• Own It 3.3: rewards redeemed at the till. For Loyalora, 3.3 meant redeeming at the till: your till sends the card code and the reward, a retried request redeems once, and a short balance says how many points are missing. It is the card above.
• Own It 3.2: points straight from the till. For Loyalora, 3.2 meant points sent straight from your till, customers joining from their own phone (off until you switch it on), VIP tiers, bonus points by item, several shops on one balance, and refunds that take the points back. Every REST write now checks the key holder's role. Each change is a card above.
• Own It 3.1: it writes to the people you serve. Loyalora was built after the 3.1 wave. Its one outbound path is a customer's own balance, emailed to that customer when you press Email balance on their card — through your own SMTP, off until you switch it on. It sends no campaigns and no marketing of any kind.