Apache-2.0 · LIP 0.2.0 · Node 22
The open-source loyalty platform for restaurant technology teams.
Own the marketer workspace, customer data, campaigns, guest wallet, and checkout lifecycle. Self-host the Apache-2.0 stack or use the open protocol inside an existing ordering platform.
Marketer + guest experienceSegments, campaigns, holdouts, attribution, branded wallet
Restaurant transaction coreModifiers, split tender, offline replay, void, refund
Deployable evidenceDocker, Postgres, OpenAPI, SDK, fixture certification, conformance
Run checkout through refund.
This deterministic simulation runs entirely in your browser with synthetic data. It sends no order, identity, or credential anywhere. Select a step or run them in sequence.
600 points · 600 available
Ledger / account effect
Idempotency key:
A loyalty operating system you can inspect.
The platform layer handles day-to-day growth workflows. The separate LIP protocol keeps checkout behavior portable for POS, ordering, payment, and loyalty integrations.
Marketer workspace
Build consent-aware audiences, schedule campaigns, reserve deterministic holdouts, and measure conversion within an attribution window.
Explore the platform API →Reference guest wallet
Use a branded, responsive wallet with OIDC Authorization Code + PKCE and a BFF that keeps merchant credentials off the device.
Review the wallet boundary →Restaurant onboarding
Import consented members from bounded CSV files and map current Square Orders and refunds through typed, synthetic certification fixtures.
Review Square scope →Built for teams that own the integration.
LIP is strongest when restaurant loyalty has to connect cleanly to ordering, payments, refunds, locations, and existing customer identity.
POS and ordering products
Add a loyalty product without outsourcing the core ledger, campaign data, or checkout contract to a closed vendor.
Multi-unit technical teams
Run a portable stack across brands and locations when data ownership, migrations, and refund correctness matter.
Restaurant agencies and builders
Start from tested APIs and adapters instead of rebuilding balances, idempotency, wallets, and campaign plumbing for every client.
Not the best fit yet: a restaurant that wants a no-code, turnkey consumer marketing service with no technical owner. This repository is pre-1.0 infrastructure and a reference product, not a claim of feature parity with every mature commercial suite.
The durable moat is lifecycle correctness.
Campaign tooling is useful; trustworthy ordering behavior is foundational. LIP makes both inspectable while keeping the portable transaction contract explicit.
Retry without double posting
Stable business keys, exact replay, explicit payload conflict, immutable ledger linkage.
Read idempotency →Certify the source mapping
A typed adapter contract and fixture runner cover modifiers, combos, tenders, comps, offline delivery, void, and refund.
Read adapter guide →Leave with your state
Checksummed full-state archives plus member/opening-balance plans and reconciliation reports.
Read migration guide →Operate the open stack
SQLite or normalized tenant-scoped Postgres, Admin, webhooks, metrics, key rotation, and conformance.
Reference platform →Choose with evidence
Compare lifecycle, portability, recovery, integration effort, marketer workflow, and ownership.
Provider selection →Keep identity separate
Your BFF verifies the customer and retains the merchant key. LIP receives only an opaque member id.
Identity boundary →Choose the next proof.
The protocol, reference implementation, and managed path stay explicit so adoption never depends on lock-in.
Browser walkthrough
Finish the synthetic lifecycle above and inspect every request, result, key, and ledger effect.
Reset and run it →Self-host
Clone the Apache-2.0 stack, start Docker, inspect Admin, then run black-box conformance.
Open quickstart →Map a real source
Bring one ordering/refund edge. Produce a certified adapter, migration rehearsal, and cutover record.
Design partner details →Truthful boundary: LIP 0.2.0 is pre-1.0 software. The repository tests and reports prove behavior of the supplied implementation and fixtures; they do not prove independent adoption, vendor endorsement, production SLO attainment, or benchmark leadership.