Capture & Engage · Stores & QR Sign-up
One branded QR code on the counter turns a walk-in into a first-party member — no app to install, no POS to replace. The sign-up runs on deterministic, security-hardened infrastructure that's built to be reliable and compliant, not clever.
Join & get 15% off
CCPA notice shown to California visitors automatically.
The problem
People buy, browse, and leave without ever entering your owned channel. The relationship ends at the door.
Asking a walk-in to download an app to join is friction most won't accept. The sign-up dies on the spot.
Swapping checkout hardware to capture members is expensive, slow, and risky for a marketing win.
How it works
Each store gets a branded QR that resolves to a public /f/{code} capture page — your logo, your incentive, your colors. Behind it runs a three-phase pipeline that validates, writes once, and fans the follow-up out asynchronously.
Two-layer rate limit
Fail-closed: a Redis outage can't open the gate.
DB-unique dedup
Unique (email, store) — never the same member twice.
Bot defense
Honeypot + timing check return a silent fake-success.
CCPA geo-detect
California visitors get a tailored consent notice.
Brand color is contrast-checked so a low-contrast palette can never produce an unscannable code; error-correction H plus a white quiet-zone keep a centered logo safe. Four dot styles, four frames.
8-character codes from an alphabet that drops look-alike 0/O and l/1/I — roughly 2.8 trillion combinations, backed by a DB unique constraint.
On success the page returns a coupon — pool-allocated with SELECT FOR UPDATE SKIP LOCKED, an HMAC-signed claim URL, or a universal code.
A note on scope. This is a scan-to-sign-up acquisition engine — it captures new members. In-store coupon redemption is a separate, deliberately decoupled flow. We say so plainly rather than imply a scan-to-redeem feature that lives elsewhere.
Why it's different
The point isn't a prettier QR. It's that the member, their consent state, and their reward all land in your first-party graph — no app gate, no checkout swap, and the same member object the rest of Flash builds on.
Typical approach
App-gated loyalty sign-up
Make the walk-in install an app before they can join.
Flash, by design
A public web capture page — one scan, one tap, no install, by design.
Typical approach
POS-tethered capture
Require new checkout hardware or a platform migration.
Flash, by design
Runs alongside whatever you already use — no POS swap, by design.
Typical approach
Form builders that just collect
Drop an email into a list and call it done.
Flash, by design
Validates, dedups, geo-tags for CCPA, and rewards instantly — then fans out the welcome.
Reliability, not AI
Acquisition is a place you want deterministic, auditable behavior — not a model's best guess. The value is engineered reliability, compliance, and security. The only "automation" is an event-driven async fan-out, every job gated on explicit marketing opt-in.
Production rate limiting fails closed — a Redis outage tightens the gate instead of opening it. A capped in-memory fallback still bounds abuse.
DB-unique (email, store) with conflict recovery; BullMQ jobs carry deterministic IDs so retries never double-fire; opt-in only ever upgrades.
RFC-5322 validation, a ~30-domain disposable-email blocklist, a hidden honeypot and a sub-2-second timing check that silently fakes success.
IP-to-region detection stamps CCPA status and tailored consent text per capture; geocoding is best-effort and never blocks a store change.
Every scan is a chance to convert a stranger into an owned, consented, rewarded member — reliably.
No app
a public web capture page, one tap to join
No POS swap
runs alongside the checkout you already have
Fail-closed
two-layer rate limiting that can't be bypassed
CCPA-aware
consent state stamped per capture, automatically
We'll generate a branded QR, walk the live capture page, and show the fail-closed, CCPA-aware pipeline behind it.
