Activa · working demo
You went to sleep asking for a working product: a full 24 BLVD org with tenants, the ticket system connected, membership and loyalty, a POS like Setpoint's, a staff QR check-in app, and a Thailand payments proposal. It's built and verified. Here's the state of it — and the one thing waiting on you (the remote apply).
Three loops, driven over the real HTTP API
Every step below was executed through the live GoTrue + PostgREST stack (the exact path the apps call), each returning 2xx with verified post-action state. Not screenshots, not psql shortcuts.
Anon sign-in → become a member → RSVP → QR code issued, +50 pts.
200 · code CU6TYFC6Staff scans the code → ticket flips to checked_in, +100 pts. Non-staff blocked.
200 · ok:trueStaff charges 2× off the LULU menu → atomic order, stock down, 7% VAT, one ledger.
200 · INV-…-0001Points move on every action; tiers recompute Guest→Insider→Icon.
balance verifiedWhat 24 BLVD holds now
The multi-vendor layer you asked about is real.
26 real events from our Instagram pipeline, all venue-linked, all published — RSVP issues a QR pass, staff scan it in.
3 plans (BLVD Social/Insider/Icon), 3 loyalty tiers, 8 demo members spread across all tiers with real balances and streaks. Loyalty coexists with membership exactly as designed.
Item/variation catalogue, open tabs, immutable orders, per-seller attribution, atomic server-side checkout with VAT + stock + one shared ledger. Seeded LULU F&B menu. Same members, same check-in architecture.
Each org sees only modules it bought; each role sees only modules its matrix grants — enforced at the data layer, not just hidden in the UI. Two cross-tenant breaches found by review and sealed.
Payments — researched, not built (as you said)
Full proposal in payments-thailand-proposal.html. The short version:
Opn Payments (Omise) as the primary gateway — Thai-native, cards ~3.65%, PromptPay ~1.65%, Schedules API for recurring memberships — with PromptPay dynamic QR as the default rail for tickets, top-ups and POS.
MVP = ledger-and-org-payout: everything settles to the 24 BLVD org account; Activa computes weekly per-operator statements and never holds funds. Phase 2 = native sub-merchant split via Opn Account Chaining.
Setpoint's stack, but no Terminal in Thailand, no daily payouts, 4.75% tourist cards. Activa diverges — a shared provider-adapter interface, a different first adapter.
A stored-credit wallet spendable across multiple tenant legal entities likely triggers Bank of Thailand e-money licensing. Needs Thai counsel before that feature ships — this is the one to discuss together.
Verification
Nothing here is claimed on a render alone.
Four suites — core RBAC, security hardening, POS, POS hardening — pass on every fresh supabase db reset. They prove entitlement walls, per-role reads, the sealed breaches, RSVP/check-in/signup, the full POS checkout lifecycle (VAT, atomic stock, one ledger, immutability), and that the negative-checkout exploit is rejected.
The member, door and POS loops were each driven through the running GoTrue + PostgREST stack with 2xx responses and verified post-action state (ticket checked_in, stock decremented, invoice issued, payment in the ledger).
Both apps (member + staff) pass flutter analyze with zero issues. The Flutter widget rendering itself is the one layer not yet exercised — that needs a simulator, which is your step.
A 22-agent fleet reviewed the RBAC layer (2 breaches sealed). A 20-agent fleet then reviewed POS and found a real one: negative-quantity checkout (inflate stock + forge a negative payment). Sealed, and the exploit is now verified dead over HTTP (400, stock unchanged, zero negative ledger rows). 13 of 15 findings fixed; 2 low-risk lows accepted.
1 · Remote apply. 12 migrations are proven on a fresh local reset but not on the remote Supabase. One supabase db push when you say so — your single deploy decision.
2 · Sim the apps. Both apps take a --dart-define local-URL flag now, so you can run them against the local stack (still up) or the remote once applied. You run the sim.
3 · Payments & the wallet. Let's pick the gateway together and get Thai counsel on the cross-tenant wallet before it ships.
4 · Next. A POS terminal in the admin, paid ticketing once a gateway lands, and per-operator payout statements.