Dungeon Books Ecosystem
How the pieces fit together across dungeonbooks.com and dungeon.club.
The Vision
Square gives customers a receipt history and calls it a “profile.” There’s no loyalty, no community, no events, no personality. It’s transactional. Every fragmented service — Square, Stripe, Hi.Events, Discord — holds a sliver of who the customer is.
The Guild member portal is the unified customer profile — one place where all the fragmented data comes together into something the member actually cares about:
- Purchases — in-store (Square) + online (Medusa, eventually), all in one timeline
- Membership — tier, subscription, billing, benefits
- Points — balance, earn history, redemptions, dollar equivalent
- Events — RSVPs, attendance history, upcoming events
- Check-ins — visit streak, last visit, kiosk taps
- Community — Discord link, role, community milestones
- Identity — NFC card status, linked accounts
Square, Stripe, Hi.Events, Discord — they’re all just data sources feeding into one unified profile. The portal is the face of it.
This is also the multi-tenant value prop. If another indie shop adopts Guild, their customers get this same unified profile. That’s something Square will never build — they’re a payments company, not a community platform. The opportunity is filling the gap between “payment processor customer record” and “actual relationship with a person who walks into your shop.”
The Two Domains
dungeonbooks.com dungeon.club
───────────────── ────────────
THE STORE THE GUILD
Browse & buy books Join / manage membership
Product catalog Member portal (points, tier, benefits)
Cart & checkout Events (RSVP, tickets, attendance)
Blog / editorial Kiosk check-in (NFC / phone)
Signup & billing
Medusa v2 + Solace (planned) Payload CMS + Next.js
Stripe + PayPal Stripe subscriptions
Square POS sync (inventory) Square POS sync (member data)
MeiliSearch Hi.Events (currently SaaS)
Tailwind — "Indie Publisher" Tailwind + shadcn — "Cassette Futurism"
Identity: One Account, Everywhere
The goal is a single Dungeon Books identity that works across:
- dungeon.club — membership, points, events, portal
- dungeonbooks.com — store, purchases, wishlists
- Square POS — in-store purchases, discounts at register
- Hi.Events — event RSVPs and attendance
- Discord — community roles tied to membership tier
Current State of Customer Identity
| System | Identifier | Status |
|---|---|---|
| Guild (Payload) | Member record (email, stripeCustomerId, squareCustomerId) | Built |
| Square POS | Square customer ID + custom attributes | Built, synced |
| Stripe | Stripe customer ID | Built |
| Medusa | Medusa customer account | Not built yet |
| Hi.Events | Attendee ID (hiEventsAttendeeId field exists) | Planned |
| Discord | Discord user ID (no field yet) | Future |
Reconciliation Strategy (Long-Term)
Guild membership is the source of truth for identity. All other systems link back to it.
┌─────────────┐
│ Guild │
│ Member │
│ (Payload) │
└──────┬──────┘
│
┌────────┬───────┼────────┬──────────┐
│ │ │ │ │
Stripe Square Medusa Hi.Events Discord
customer customer customer attendee user
- Email is the shared key across all systems
- Stripe customer ID links billing (Guild subscriptions + store payments)
- Square customer ID links POS (in-store purchases + member data at register)
- Medusa customer links store account (when built)
- Hi.Events attendee links events
- Discord user links community
When Medusa is built, the store’s “create account” flow should either:
- (a) Create a Guild member simultaneously (preferred — one signup, full access)
- (b) Link to an existing Guild member by email
SSO across domains (dungeonbooks.com ↔ dungeon.club) is an open design question. Options include shared auth tokens, OAuth between the two apps, or a shared auth service. The important thing is that the user experience is seamless — one login, one identity.
Data Flow Between Systems
Customer buys book in-store
→ Square POS records sale
→ Square webhook → Guild awards loyalty points
→ Points synced back to Square custom attributes
Customer buys book online
→ Medusa processes order (Stripe payment)
→ [Future] Medusa webhook → Guild awards loyalty points
→ Points synced to Square
Member subscribes to Gold tier
→ Stripe processes subscription
→ Stripe webhook → Guild updates tier + status
→ Square custom attributes updated (guild_tier, guild_points, guild_status)
→ [Future] Discord role updated
Member checks in at kiosk
→ NFC tap or phone number
→ Guild logs check-in, returns member info + points
→ [Future] Check-in awards bonus points or streaks
Member RSVPs to event
→ Hi.Events records attendance
→ [Future] Hi.Events webhook → Guild awards attendance points
Events
Currently using Hi.Events SaaS (hosted at app.hi.events). dungeonbooks.com links to the event page. Event page: https://app.hi.events/events/5838/dungeon-books
Future options:
- Continue SaaS — simplest, works now
- Self-host Hi.Events — more control, can integrate attendance webhooks directly
- Multi-tenant SaaS license — if scaling to multiple shops/orgs
Regardless of hosting model, events live under dungeon.club (the Guild), not the store. The store links to events but doesn’t own them.
Open Questions
- SSO implementation — shared auth tokens, OAuth, or shared auth service between dungeonbooks.com and dungeon.club?
- Medusa ↔ Guild account linking — create Guild member on store signup, or link after the fact?
- Discord integration — OAuth flow to link Discord, then bot to manage roles based on tier?
- Hi.Events webhooks — does Hi.Events SaaS support outbound webhooks for attendance? Or do we need self-hosted?
- Unified notifications — email, push, Discord DM? Where does a member get notified about points earned, events, tier benefits?