The intent
Most small-business loyalty programs die at the install step. A customer at the counter will not download an app for a coffee shop or a barber, so the punch card stays on paper and the data never exists.
Fideloop removes the app. The loyalty card lives in the wallet the customer already opens every day. Keep the mechanics merchants understand (stamps, points, a reward at the end) and move them onto the one surface a phone already trusts.
What we built
A merchant dashboard to design a card (brand, reward rule, fields) and issue it as an Apple Wallet pass and a Google Wallet object from the same definition. Customers add the card from a link or a QR code, nothing to install.
Each time the merchant scans the customer's card at the counter, the pass updates in place. Balances and rewards push to the device through the wallet platforms, so the card the customer already holds reflects the new state without a re-issue or a separate notification app.
The approach
The hard part of wallet loyalty is the two platforms underneath. Apple Wallet (PassKit, signed .pkpass bundles) and Google Wallet (a REST objects API with JWT save links) model passes differently and update them differently. Fideloop holds one internal card model and projects it to both, so a merchant edits once.
Updates are the second hard part. Apple passes refresh through a web service the device polls after a push; Google objects update by API call. We treat issuance and update as a server responsibility, signed and idempotent, so a counter scan is a single reliable action rather than a fragile client-side workaround.
Where it stands
Fideloop is in active development at fideloop.app. The card model, dual-platform issuance and counter-side updates are the core we are building and hardening.
As a first-party product it sets our own bar for the wallet and loyalty work we take into client projects: not a demo of a pass, but the full path from a merchant defining a program to a customer's card updating after a scan.
Stack
Next.js gives one TypeScript codebase for the merchant dashboard, the customer-facing add-to-wallet pages and the server routes that sign and issue passes, which matters because pass generation and updates have to run server-side with credentials. Supabase covers Postgres, auth and storage in one place: card definitions, customer balances and scan events live in relational tables with row-level security, and the same project handles merchant accounts. The pairing keeps a small team shipping end to end without stitching a separate backend onto the wallet integrations.
- Do customers need to download an app to use Fideloop?
- No. The loyalty card is added straight to Apple Wallet or Google Wallet from a link or QR code. The customer uses the wallet app already on their phone; there is nothing else to install.
- How do customers earn stamps or points?
- The merchant scans the customer's card at the counter. Each scan updates the pass in place, so the balance and any reward push to the card the customer already holds, with no re-issue and no separate notification app.
- What stage is Fideloop at, and is pricing announced?
- Fideloop is in active development at fideloop.app, built in-house by Kōten. It is not yet launched and pricing is not yet announced. The dual-platform card model, issuance and counter-side updates are the core under construction.
Building something like this?
We build first-party products and client projects with the same engineering practice. Tell us what you have in mind.