Who Open Loyalty is
Open Loyalty is a loyalty engine: software that works out what each member of a loyalty programme has earned and keeps their balance. The company behind it, Open Loyalty sp. z o.o., gives its address in Wrocław, Poland, and is a member of the OEX capital group. It describes itself as a composable, API-first loyalty engine and says it is behind more than 100 enterprise brands. Despite the name, it is not open source: its own site says it is cloud-based software as a service, that the source code is not publicly available, and that the "open" refers to its API-first, composable architecture.
Its building blocks are members, transactions, custom events, campaigns, wallets, tiers, rewards and achievements. A campaign is a rule with a trigger, conditions and effects: a purchase transaction or a custom event sets it off, and it adds units, Open Loyalty's word for points, to a member's wallet. Tiers follow totals such as spending or units earned, achievements count progress towards a goal, and webhooks report each change. Each client runs on an independent instance on AWS with its own database, in Dublin, Frankfurt, Ohio, Singapore or Sydney, and Open Loyalty is certified to ISO 27001 and ISO 9001. It is made to sit behind another product's own server and apps, which is why it is one of the loyalty and promotions connectors of our Rewards & referrals module.
What it does in your platform
Rewards & referrals
Works out points, cashback and tiers from the settled card payments and other events the platform's server sends it, under the campaigns, limits and expiry rules your team builds in Open Loyalty's admin panel. Points live in its wallets, and cashback is paid as a credit in the Ledger. The platform still decides which payments count, who may join, and in which countries and products a programme runs.
How the connection works
Every call goes from the platform's server to Open Loyalty's REST API, with an API key in the X-AUTH-TOKEN header that never leaves the server. Open Loyalty's own guidance is the same: no app or browser calls it directly. What it decides comes back as webhooks signed with HMAC-SHA256.
A customer joins the programme
In the app, the customer joins your points programme. The platform's server adds them as a member with POST /api/{storeCode}/member, where the store code names your tenant, Open Loyalty's word for one programme. The platform's random ID goes in as the loyalty card number, the field Open Loyalty recommends for an ID of your own. Its API reference marks an email address as required on this call, so the customer's email goes with it, for this programme only. Names, birth dates and addresses are optional there and are not sent.
A card payment settles
The customer pays by card, and nothing is sent while the payment is only authorised. When it settles, the server sends POST /api/{storeCode}/transaction with the document type sell, the platform's own payment reference as the document number, the time, the amount and a spending category, matched to the member by their loyalty card number. Document numbers are unique per tenant, so a retry after a timeout cannot earn twice. Card numbers, account numbers and balances are never in the message.
A campaign awards the units
A campaign your team built in the admin panel, with the trigger Purchase transaction, works out the units from a formula on the transaction's gross value, inside the per-member limits and the unit budget set on the campaign. The units land in the member's wallet as pending for the number of days the wallet sets, which we match to your refund window, and Open Loyalty sends the CampaignEffectWasApplied webhook.
A tier is reached
A tier set holds the thresholds your team defines, on conditions such as total spending or total earned units. When the customer crosses one, Open Loyalty moves them up and sends the CustomerLevelChanged webhook, and the platform shows the new tier in the app. Your team also chooses whether a tier can be lost again: never, as soon as the conditions are no longer met, or at a yearly recalculation.
The platform books it
For points, the balance lives in Open Loyalty's wallet: the WalletBalanceUpdated webhook reports each change, and the app shows the active units, not the pending ones. For cashback, the wallet only does the sums. Once the units are no longer pending, the platform credits the customer's balance in the Ledger from your marketing budget account and spends the same units with POST /api/{storeCode}/points/spend, under an externalTransferId that Open Loyalty will not accept twice.
A refund takes it back
If the payment is refunded or charged back, the server sends a second transaction with the document type return and the first payment's number as its linkedDocumentNumber. Open Loyalty does not reverse the purchase campaign by itself: a campaign with the trigger Return transaction, which your team sets up to mirror the purchase one, deducts the units. By Open Loyalty's own description, a return does not undo a tier or a campaign limit the purchase counted towards. Cashback already credited is reversed in the Ledger.
Next to other providers
Open Loyalty hears only what the platform's records can prove. KYC / AML decides who may join, Card issuing and the Ledger say when a payment has settled or been refunded, and Fraud & risk looks for one person running several accounts before any event is sent, whatever limits a campaign also has. Notifications tells the customer about points earned or a new tier, from the webhooks. Open Loyalty has referral campaigns of its own, with rules for the referrer and for the friend, and the module's referral programme connectors, Referral Factory, GrowSurf and Friendbuy, are there when you want a tool made for refer-a-friend. Gift cards a customer picks for their points can be delivered through Runa.
Open Loyalty is one of the module's loyalty and promotions connectors, next to Talon.One, which puts loyalty, promotions and offers in one tool, and Voucherify, which adds coupons, gift cards and referrals to loyalty. The list of members and their platform IDs, the record of settled payments and refunds, every cashback entry in the Ledger and the country switches live in your platform, so moving between the three later swaps a connector and leaves your apps and your books as they are. Campaigns, wallets, tier sets and rewards are built in Open Loyalty's admin panel and would be built again in the new tool, and point balances and tiers would be exported and loaded into it.
When Open Loyalty fits best
A strong fit when
- You want points, cashback and tiers on card spend, with rules your team changes in an admin panel, without an app release.
- You want the programme's data on an instance of its own with a separate database, in an EU region: Dublin or Frankfurt.
- You plan more than points, such as achievements, challenges, badges or leaderboards, in the same engine and shown in your own apps' screens.
Also worth a look
- Talon.One or Voucherify, the module's other loyalty and promotions connectors, when promotions or coupons matter as much as points.
- A loyalty tool your team already runs: its account becomes a connector too.
How we get you live
The contract
We help you get your Open Loyalty contract in place, with the data processing agreement your compliance team needs. Open Loyalty gives each client a production environment and a staging environment, and we agree the production region with you before anything is built.
The data
We have your production instance placed in Dublin or Frankfurt. One tenant holds one programme, and its members are identified by loyalty card number, which carries the platform's random ID. With your team we set up the wallets, their unit names, expiry and pending period, the tier set and the first campaigns, each purchase campaign with a return campaign to match. Which payments count, who may join and where a programme is switched off stay in your backoffice.
The keys
The platform gets an API key of its own, generated in Open Loyalty's admin panel for a dedicated admin whose role is limited to your tenant and to what the platform does. The key goes into your platform's secrets, separate for staging and production, and is sent only from the server. Webhooks are signed: the platform checks the HMAC-SHA256 signature in the X-Webhook-Signature header and rejects any request whose timestamp is more than five minutes old.
A full test run
The whole case runs first on the staging environment, with test members and no real customer data, as Open Loyalty advises for staging: a member joins, a payment settles, units are awarded, a tier is reached and a refund takes the units back. The wallets, event schemas, rewards and campaigns are then exported and imported into production, where the keys and webhook subscriptions are created afresh, before your first real customer.
