Most loyalty stacks are built around transactions. That usually means POS integrations, receipt parsing, delayed confirmations, or card-network data—each of which adds time, complexity, and ambiguity.
Perqlo takes a different approach: it treats loyalty as a live, confirmed session at checkout. The goal is simple: create a moment that is fast for staff, simple for customers, and produces a clean event record for analytics and automation.
What Is a Live QR Session?
A live QR session is a short-lived, one-time token that represents a specific loyalty action (e.g., “coffee purchase”, “haircut service”, “$10–$20 bracket”). The session is created by staff with one tap, displayed as a QR, and confirmed by the customer with a single scan.
When the customer scans, the system can instantly update points, tiers, streaks, or vouchers—and record an auditable event.
The Pipeline: Tap → Session → Scan → Confirm → Log
- Tap — staff selects a preset that encodes what happened at checkout.
- Session — the system mints a one-time token with a short TTL (time-to-live).
- Scan — the customer scans the QR inside the consumer app.
- Confirm — rewards and status update immediately.
- Log — the event is stored with staff attribution and policy context (caps, tier rules, etc.).
Why One-Time Tokens Matter (TTL + Single Use)
“Static QR codes” are easy to copy, replay, and abuse. A live session flips that model:
- Short TTL reduces replay risk. If the scan doesn’t happen quickly, the session expires.
- Single-use prevents multiple redemptions of the same session.
- Explicit context (preset + staff + store) makes the event auditable.
Idempotency: Preventing Double-Scans and Double-Credits
In real life, customers double-tap buttons, networks retry requests, and apps recover from flaky connections. A session system needs idempotency: the same session confirmation should always produce the same final result.
Practically, that means:
- Confirm endpoints treat a session token as a unique key.
- Rewards are granted once, even if the client retries.
- The response can be safely returned multiple times.
Logging: Turning Checkout Into Structured Data
A confirmed session can store the data SMBs actually need—without asking staff to type anything:
- Merchant and location identifiers.
- Staff attribution (who initiated the session).
- Preset identifier (what was selected).
- Timestamp (for recency and visit patterns).
- Policy snapshot (caps, tier rules, voucher rules).
This is the foundation for RFM segmentation, streak mechanics, tier progression, and win-back triggers—without a data team.
Anti-Fraud Controls That Fit SMB Reality
Any loyalty program that produces value can be gamed. The goal is to add protection without adding friction. Live sessions make it easier to apply practical controls such as:
- Session caps per staff member per time window.
- Customer cooldowns (e.g., only one confirmation per preset per X minutes).
- Tier velocity limits to prevent unnatural acceleration.
- Audit trails so merchants can review anomalies.
Because sessions are explicit events (not inferred transactions), the enforcement logic is simpler and the audit story is cleaner.
Why This Avoids POS Integration (Without Losing Measurement)
Traditional systems rely on the POS to tell them what happened. Live sessions rely on the checkout moment to confirm what happened.
That sounds subtle, but it’s the difference between:
- Inferred events (delayed, inconsistent, often incomplete)
- Confirmed events (instant, explicit, designed for automation)
For SMBs, “confirmed now” beats “maybe later.”
Implementation Notes (Plain English)
If you’re building or evaluating a system like this, look for a few practical details:
- Token format that can’t be guessed and doesn’t leak sensitive context.
- Expiration handling that’s clear in the UI (so staff don’t keep showing a dead QR).
- Retries that don’t create duplicate credits (idempotency).
- Fast confirmation so the reward lands while the customer is still present.
Bottom Line
A live QR session pipeline is a compact loyalty primitive: it’s fast at checkout, produces clean data, and supports sophisticated mechanics without complex integrations.
Once you have a reliable “confirmed session” event, everything else (tiers, streaks, leaderboards, RFM, win-back) becomes a product decision—not an engineering dependency.