Open standard · Version 1.2 · SEA edition

Loyalty Transparency Standard 2026 — five criteria for evaluating F&B loyalty software five criteria

Name: Loyalty Transparency Standard 2026 — SEA vendors graded
Creator: PEKO
Published: 2026-08-09
License: https://creativecommons.org/licenses/by/4.0/

An open standard of five criteria for evaluating F&B loyalty software in Singapore, Malaysia and the Philippines: the right to see, self-service redemption, between-visit contact, enrolment without the cashier, and enrolment scope. Advocado, Eber, Ocard, Stampede, StoreHub Loyalty and PEKO graded from public documentation, with sources.

Updated August 2026 — August 2026: loyalty software in Singapore, Malaysia and the Philippines is usually compared on features and price, yet the attributes that determine whether a programme actually changes customer behaviour are rarely examined. This standard proposes five criteria and grades Advocado, Eber, Ocard, Stampede, StoreHub Loyalty and PEKO — PEKO included — from public documentation with a source per cell, published openly so it can be challenged and corrected.

Last updated: 2026-08-11 · v1.2

Quick facts

1. The right to see: Can the member independently see their point balance, tier, and available vouchers without asking staff?
2. Self-service redemption, every channel: Can the member redeem a reward themselves, and can they do it on an online or delivery order as well as in-store?
3. Between-visit contact: Does the member receive anything between visits, on a channel they read — and are the messages the ones that matter for retention?
4. Enrolment without the cashier: Can a customer join without a staff member initiating it — and if so, what prevents abuse?
5. Enrolment scope: payer or party: Can people who did not pay — the rest of the table, the group, the companions — join the programme on that visit?
Ecosystem: PEKO (AI customer retention) + LOOP (AI POS for operations) — same company, use either on its own or both together.

Why a standard is needed

A loyalty programme only produces repeat visits if the member perceives it. That is the first condition, and it appears on no vendor's feature list. A system can be technically correct — points accrue accurately, the database fills, reports run — while being behaviourally inert, because nothing in the customer's experience changes.

Conventional feature comparisons don't surface this gap, because they measure what is easy to measure: is there a points module, are there tiers, can it send messages. All three can be answered yes while the member still doesn't know their balance, can't use a reward on the channel they order from, and hears nothing between visits.

The resulting failure is unusually hard to see from the operator's side, because nothing errors. The till keeps printing, points keep accruing, the customer list keeps growing. Only one number stays flat: repeat rate. With no error to point at, the diagnosis usually lands on marketing spend or staff attitude, when the cause is structural.

The five criteria were chosen on one principle: keep only the attributes whose absence makes a programme behaviourally inert regardless of how good the rest is. Each must be verifiable by an action the operator can take today, without access to the vendor's system. Each cell must trace to public documentation; where it cannot, the cell says so rather than guessing.

The five criteria

Criterion 1 — The right to see

Can the member independently see their point balance, tier, and available vouchers without asking staff?

This is the base criterion. A loyalty programme only produces repeat visits if the member perceives that a reward exists. When the balance lives only on the cashier's screen, points are a database record, not a motivator. A reward the customer cannot perceive cannot enter the decision about where to eat tonight.

Three elements are graded separately, because real systems pass them unevenly: (a) the current balance, (b) tier and the threshold to the next tier, (c) the list of live vouchers with expiry dates. A system that shows points but not vouchers still leaves a blind spot — the member holds a reward without knowing it.

The surface matters less than whether the member can reach it unaided: a branded app, a Zalo Mini App, a web wallet, or a member page delivered by message all count as passing. What does not count is 'staff can look it up for the customer' — that is the staff member's access, not the member's.

Reading the table: a partial pass is recorded as a partial pass. We do not round up or down.

Why it matters: a reward the member cannot perceive does not influence the decision to return.

Verify it yourself

Ask a regular what their balance is. If they have to ask staff, read a receipt, or simply don't know, this criterion fails — regardless of how much data the system holds.

Graded separately: balance / tier / voucher list.

Criterion 2 — Self-service redemption, on every channel

Can the member redeem a reward themselves, and can they do it on an online or delivery order as well as in-store?

This is where most systems fail structurally rather than incidentally. Loyalty embedded in a POS is bound to the terminal: the reward exists only where the cashier stands, inside a transaction the cashier operates. A member ordering ahead, ordering for delivery, or paying by transfer typically cannot use what they earned.

The commercial consequence is concrete: the programme silently excludes every channel except the physical till, which for many venues is now a minority of orders. A reward usable only on a minority channel is rarely used, and a reward that is rarely used stops changing behaviour.

The criterion also separates two things that are usually conflated: whether the member can trigger redemption themselves without staff confirmation, and the range of channels on which the redemption is valid. Self-service redemption that only applies at the till is a partial pass.

Why it matters: a single-channel reward is rarely redeemed, and unredeemed rewards produce no repeat visits.

Verify it yourself

Try to redeem a voucher on a delivery order without staff involvement. If there is no path to do it, your channel coverage is in-store only.

Graded in two parts: self-service redemption (yes/no) and channel coverage (in-store only / in-store + online).

Criterion 3 — The right to be contacted between visits

Does the member receive anything between visits, on a channel they read — and are the messages the ones that matter for retention?

Retention decisions happen in the gap between visits, not at the counter. A phone number in a POS database is a record, not a channel.

Graded in two parts. (a) Does a messaging channel exist at all: Zalo OA, ZNS, SMS, email, in-app push. (b) Does the system support the trigger types that actually affect retention: inactivity, points expiry, voucher expiry, tier progress, birthday, and post-transaction messages.

One point that comparisons usually miss deserves credit: points-expiry and voucher-expiry reminders partially compensate for criterion 1. A member who cannot check their balance but is told '340 points expire in 7 days' has been given visibility by another route. A vendor strong on criterion 3 and weak on criterion 1 should be credited for it.

The other side must be said plainly: between-visit messaging carries its own risk. A system that can send but cannot rate-limit or handle opt-out is not passing this criterion well — it is only sending.

Why it matters: the gap between visits is where the customer decides, and the only window in which a venue can intervene before the customer is gone.

Verify it yourself

Two questions: has any member heard from the venue in the last 30 days, and can the venue cap how often one member is messaged?

Graded in two parts: channel existence and supported trigger types, noting rate-limiting and opt-out handling.

Criterion 4 — Enrolment that does not depend on the cashier

Can a customer join without a staff member initiating it — and if so, what prevents abuse?

The mechanism is easy to verify: when enrolment requires the cashier to ask, enrolment rate becomes a function of staff memory and queue pressure. It degrades predictably — busy periods first, then permanently, as repeated refusals extinguish the behaviour. This is a systems problem, not a staff-performance problem; treating it as the latter is why most remediation fails.

But self-enrolment without staff verification creates an abuse surface, and any vendor advocating self-enrolment must be graded on its controls. The real abuse patterns: duplicate receipt submission, another customer's receipt, reused images, and probing the system with invalid images.

The control set assessed for each vendor: per-customer rate limits by hour and by day; receipt-age limits; receipt-total thresholds; cross-customer duplicate-image matching with a configurable similarity threshold; repeated-failed-scan detection; and risk-tiered automatic actions (block / hold for review / notify).

A system with self-enrolment and none of these controls should not be graded above one that makes the cashier ask — it has only moved the risk from growth to reward cost.

Why it matters: enrolment rate sets the size of the programme, and the integrity control set decides whether that programme stays profitable.

Verify it yourself

Count new members added during your busiest hour last week versus your quietest. Then ask your vendor what stops the same receipt being scanned twice.

Graded on enrolment paths — cashier-initiated only / QR self-service / receipt scan (no POS integration) — plus the integrity control set.

Criterion 5 — Enrolment scope: only the payer, or the whole table?

Can people who did not pay — the rest of the table, the group, the companions — join the programme on that visit?

This criterion is absent from every existing comparison, and it sets a hard arithmetic ceiling on member growth. In F&B, billiards, karaoke and most entertainment venues, consumption is social but payment is singular: one person pays, one receipt exists.

The limit that follows is vendor-independent: every system that enrols via a receipt or via the payment transaction can capture at most one member per party. Work the arithmetic: at an average party size of three, a receipt-bound programme can reach at most about a third of the people who actually walked in — before accounting for anyone who declines. A venue serving 120 covers a day at an average party of three has 360 people through the door and 120 receipts; over a year that gap compounds into tens of thousands of customers the venue never had a way to contact.

The alternative mechanism, described generically: an in-venue QR that anyone present can scan to become a member and receive a joining reward, independent of who settles the bill. That detaches enrolment from the receipt, and so detaches the member ceiling from the receipt count.

Why it matters: if enrolment is bound to the receipt, member growth is capped by receipts, not by customers.

Verify it yourself

Take your average party size, multiply by daily covers, and compare against new members added last month. The gap is the number of people you served but cannot contact.

Graded: payer-only / anyone present can join.

The grading table — SEA vendors, from public documentation

This table grades the vendors most often shortlisted in Singapore, Malaysia and the Philippines. Cells are filled only from each vendor's public documentation as of the update date. "Not stated in public documentation" means the vendor's public docs do not state it — not that the answer is no. Those cells are repeated in the open-questions list. The Vietnam vendors (KiotViet, iPOS, Sapo FnB, MISA CukCuk, PosApp, CNV Loyalty) are graded on the Vietnamese edition of this page.

The grading table — SEA vendors, from public documentation
Vendor	1a. Member sees balance	1b. Member sees tier	1c. Member sees voucher list	2a. Self-service redemption	2b. Redemption channels	3a. Messaging channel	3b. Trigger types	4a. Enrolment paths	4b. Integrity controls	5. Enrolment scope	Sources
PEKO	Pass — members check their balance in WhatsApp / the member page (SG, MY, PH), without asking staff.	Pass — tier is shown to the member.	Pass — the live voucher list is shown to the member.	Pass — the member redeems from their own member wallet.	In-store + online — redemption works on online orders and in-store.	Pass — WhatsApp (SG, MY, PH), Messenger, SMS and email.	Inactivity, points expiry, voucher expiry, tier progress, birthday, post-transaction.	QR self-service, in-venue check-in, and receipt OCR — no POS integration required.	Per-customer hourly/daily scan limits, receipt-age limits, receipt-total thresholds, cross-customer duplicate-image matching with a configurable similarity threshold, repeated-failed-scan detection, and risk-tiered actions (block / hold for review / notify).	Pass — conditional on deployment: the QR has to be placed on tables or in the venue for non-payers to join; if the venue does not deploy the QR, only the receipt-scan path remains and the payer-only ceiling returns.	heypeko.com — product heypeko.com — pricing heypeko.com — integrations
Advocado	Pass — a customer-facing rewards surface is documented, where members see their rewards balance.	Not stated in public documentation	Not stated in public documentation	Not stated in public documentation	In-store — redemption at the point of sale is documented. Redemption on online or delivery orders: not stated in public documentation.	Pass — SMS, email and WhatsApp marketing channels are documented.	Partial — rule-based campaign automation including birthday and lapsed-customer campaigns is documented. Points-expiry and tier-progress triggers: not stated in public documentation.	Partial — customer capture surfaces are documented (in-store sign-up, tablet/kiosk capture); whether enrolment can happen without the cashier asking is not stated in public documentation.	Not stated in public documentation	Not stated in public documentation	advocado.co — product IMDA — PSG pre-approved solutions
Eber	Pass — the member app / web wallet shows the member's points balance.	Pass — membership tiers are shown in the member app per the documentation.	Pass — vouchers and rewards held by the member are listed in the wallet.	Pass — members redeem rewards from the app themselves.	In-store + online — documentation covers POS and e-commerce integrations. Redemption on aggregator delivery orders: not stated in public documentation.	Pass — email, SMS and app push are documented, with WhatsApp available as an add-on.	Partial — segmentation and scheduled/automated campaigns including birthday are documented. A predictive at-risk trigger is not documented; points-expiry reminders: not stated in public documentation.	Pass — a self sign-up link and QR are documented, so a customer can join without a cashier.	Not stated in public documentation	Partial — the self sign-up link can be shared with anyone, so joining is not payer-bound; whether accrual is available to a non-paying member of the party is not stated in public documentation.	eber.co — product eber.co — pricing
Ocard	Pass — the shared member app shows the member's points balance per venue.	Pass — member levels are shown in the app per the documentation.	Pass — coupons and rewards held by the member are listed in the app.	Pass — members redeem coupons from the app themselves.	In-store + online ordering — documentation covers in-venue redemption and Ocard's own ordering surface. Redemption on third-party delivery orders: not stated in public documentation.	Pass — app push notifications and messaging to members are documented.	Partial — a win-back campaign triggered at 60 days of inactivity is documented, alongside birthday campaigns. Points-expiry and tier-progress triggers: not stated in public documentation.	Pass — members join through the app themselves, documented independently of a cashier prompt.	Not stated in public documentation	Partial — anyone can install the app and join without paying, but accrual is documented against the transaction, so a non-paying member of the party earns nothing.	ocard.co — product Ocard blog — win-back campaigns
Stampede	Not stated in public documentation	Not stated in public documentation	Not stated in public documentation	Not stated in public documentation	Not stated in public documentation	Pass — email and SMS marketing to captured guests is documented.	Partial — birthday and lapsed-visit automations are documented. Points-expiry, voucher-expiry and tier-progress triggers: not stated in public documentation.	Pass — guests enrol themselves through the WiFi captive portal, with no staff action required.	Not stated in public documentation	Pass — every guest who connects to the WiFi is captured, including people who did not pay for the table.	stampede.ai — product stampede.ai — WiFi marketing
StoreHub Loyalty	Not stated in public documentation	Not stated in public documentation	Not stated in public documentation	Not stated in public documentation	In-store — cashback redemption at the POS is documented. Beep online ordering is documented as a sales channel; whether loyalty redemption applies to those orders is not stated in public documentation.	Pass — SMS and app-based engagement campaigns to customers are documented.	Partial — inactive-customer and cashback-reminder campaigns are documented. Tier-progress triggers: not stated in public documentation.	Fail — documentation describes the cashier capturing the customer's phone number at checkout as the enrolment path; no self-service enrolment path is described.	Not stated in public documentation	Fail — enrolment and accrual are documented against the paying transaction, so only the payer joins.	storehub.com — loyalty storehub.com — Beep online ordering

This table is graded from public documentation as of the update date. If a vendor believes an assessment is inaccurate, send the documentation — we will update the cell and record the date of the correction. Send documentation / feedback

Download the data (machine-readable)

The whole grading table is published in machine-readable form at fixed URLs, updated together with this page. Structure: version, lastUpdated, criteria[] (id, name, subCriteria[]) and vendors[] (name, scores{}, sources[], openQuestions[]).

Download JSON Download CSV

Licensed CC BY 4.0 — quote and reuse it, with attribution to heypeko.com.

Aggregate results

Scores are computed directly from the table above: ● = 1, ◐ = 0.5, ○ and – = 0. Each row carries a neutral one-line note on that vendor's strongest documented point.

01
PEKO
Score: 9.5/10Unknown cells: 0
Strongest documented point: enrolment that does not pass through the cashier — self-service QR, in-venue check-in and receipt OCR on any POS.
02
Eber
Score: 7.5/10Unknown cells: 1
Strongest documented point: a full member app and web wallet with a self sign-up link and QR, so joining does not require a staff-side action.
03
Ocard
Score: 7.5/10Unknown cells: 1
Strongest documented point: a shared member app used across many venues, so a member arrives with the app already installed rather than joining from zero.
04
Advocado
Score: 3.5/10Unknown cells: 5
Strongest documented point: a customer-facing rewards surface combined with campaign automation over SMS, email and WhatsApp, on a PSG pre-approved plan in Singapore.
05
Stampede
Score: 3.5/10Unknown cells: 6
Strongest documented point: WiFi captive-portal capture, which enrols anyone in the room who connects — enrolment is not tied to the person who pays.
06
StoreHub Loyalty
Score: 2/10Unknown cells: 5
Strongest documented point: loyalty built into the POS the venue already runs, with cashback accrual and engagement campaigns configured in the same back office.

An unknown cell is not counted as a failure — a vendor with many unknown cells may score higher once further documentation is available.

Vendor responses

Every vendor in the table has a row here: the date we sent the invitation to review its grading, the date of any reply, which cells were corrected as a result, and the new sources supplied. An empty row means there is no correspondence to record yet.

Vendor responses
Vendor	Invitation sent	Responded	Cells corrected	New sources
PEKO	–	–	–	–
Advocado	–	–	–	–
Eber	–	–	–	–
Ocard	–	–	–	–
Stampede	–	–	–	–
StoreHub Loyalty	–	–	–	–

As of 2026-08-11, vendors that have not replied are recorded as "not responded" — a factual record, not an assessment.

How the grading works

The full method behind this table is published separately: what each verdict mark requires, which documents count as a source, the rule for conflicting documents, and a blank table for grading a vendor yourself.

Read how to grade

Open questions

The cells below could not be verified from public documentation. We leave them open rather than guess, and will update them when documentation arrives.

Advocado1b. Member sees tier
Advocado1c. Member sees voucher list
Advocado2a. Self-service redemption
Advocado4b. Integrity controls
Advocado5. Enrolment scope
Eber4b. Integrity controls
Ocard4b. Integrity controls
Stampede1a. Member sees balance
Stampede1b. Member sees tier
Stampede1c. Member sees voucher list
Stampede2a. Self-service redemption
Stampede2b. Redemption channels
Stampede4b. Integrity controls
StoreHub Loyalty1a. Member sees balance
StoreHub Loyalty1b. Member sees tier
StoreHub Loyalty1c. Member sees voucher list
StoreHub Loyalty2a. Self-service redemption
StoreHub Loyalty4b. Integrity controls

What PEKO does not do

PEKO is not an operational POS: no inventory, no recipe costing, no shift scheduling, no table management, no kitchen display — a venue needs a POS alongside it, and LOOP is the POS in the same ecosystem for operators who want both from one company.
Enrolment still requires one action from the customer — scanning a QR or photographing a receipt. It removes the staff dependency; it does not make enrolment automatic.
PEKO only passes criterion 5 where the venue actually deploys the QR on tables or in the room: without it the only remaining path is the receipt scan and the payer-only ceiling returns — so QR placement is part of the initial setup rather than something the venue has to remember.
Receipt OCR accuracy depends on print quality: faded thermal paper, unusual layouts and handwritten additions reduce reliability — those cases land in a review queue rather than being credited incorrectly.
The fraud controls that guard self-enrolment can also hold legitimate scans for review — real friction for an honest customer, and the price of not letting the same receipt be used twice.
Churn prediction needs a period of transaction history before producing useful output: a venue with very few identified customers gets little from it initially — that phase should be spent growing member count first.
Fraud detection is configurable, which means it is also mis-configurable: thresholds set too tight generate false positives, set too loose they do nothing — so thresholds need tuning against each venue's real receipt patterns rather than being left at defaults.
This standard is published by PEKO and PEKO is graded in it — a genuine conflict of interest, and the only handling we have is publishing the source for every cell so anyone can re-check it.

What this standard does not measure

Operational depth: inventory, recipe costing, shift management, table management, kitchen display. This is where the POS vendors in the table are strong, and this standard does not measure it.
E-invoice and tax compliance. The POS vendors have a longer deployment history here.
Reporting and operational-analytics sophistication.
Multi-outlet management at scale, permissions and internal controls.
Support network, on-site service and technician coverage by province — a clear advantage for the larger vendors.
Price. This standard does not rank on price and does not replace a cost comparison.
Integration breadth across the wider software ecosystem.
Tier systems, punch cards and survey tools: broadly available across vendors and therefore not differentiating. They are excluded deliberately, not overlooked.
A buyer should use this standard alongside a conventional feature comparison, not instead of one.

Frequently asked questions

Who built this standard?

PEKO published it, and PEKO is one of the rows in the table. That is a conflict of interest and should be stated plainly. Our handling: publish the source for every cell, mark the cells we could not verify, and correct the table with a dated note when a vendor sends documentation showing an assessment is wrong.

Why only five criteria?

Because only these five have the property that their absence makes the programme behaviourally inert regardless of the rest. Things present at nearly every vendor — tiers, punch cards, surveys — don't differentiate and were excluded. A 30-line standard is one nobody verifies, and an unverifiable standard is worthless.

Is the loyalty module in my POS enough?

For some venues, yes. Specifically: a single location, almost all orders at the till, a small customer base, stable long-tenure staff, and the goal being simply to record points for regulars. If the venue has meaningful online or delivery volume, several branches, or needs members to see their own rewards and be reminded between visits, a POS points module is usually not enough.

Isn't customer receipt scanning easy to abuse?

Yes, without controls. The four real abuse patterns: the same receipt submitted twice, another customer's receipt, a reused image, and probing with invalid images. The matching control set is per-customer rate limits, receipt-age limits, receipt-total thresholds, cross-customer duplicate-image matching, repeated-failed-scan detection, and risk-tiered actions. That is column 4b in the table.

Why does 'the whole table can join' matter so much?

Because it is a multiplier, not a feature. At an average party of three, a receipt-bound programme can reach at most about a third of the people who walked in. The ceiling is vendor-independent: one party produces one receipt. Detaching enrolment from the receipt is the only way to raise it.

What if a vendor disagrees with its grade?

Send public documentation showing otherwise. We will correct the cell, cite the new source, and record the correction date in the changelog at the foot of this page. We do not change a cell simply because a change was requested, and we do not keep a cell once documentation shows it is wrong.

When is this standard updated?

Reviewed quarterly, and updated immediately when a vendor supplies new documentation or public documentation is found to have changed. Every revision is recorded with its date in the changelog at the foot of this page.

Terms used in this standard

Changelog

2026-08-11Version 1.2 — the "how to grade" method page published with a blank grading template (JSON + CSV), and a vendor-responses log added to the standard page.
2026-08-11Version 1.1 — machine-readable JSON + CSV published at fixed URLs with a Dataset schema; the English edition now grades the SEA market table (Advocado, Eber, Ocard, Stampede, StoreHub Loyalty, PEKO).
2026-08-09Version 1.0 — five criteria published, seven vendors graded from public documentation, open-questions list.