Developer guide · Architecture
Multi-business loyalty inside one Laravel installation.
Partners share the application and infrastructure while the product scopes business data and operating interfaces.
- Deployment
- One Laravel application
- Business boundary
- Partner scope
- SaaS work left
- Billing, service, operations
Short answer
Start with the operating model.
Reward Loyalty provides a multi-business Laravel application with administrators, managers, partners, staff, and members. Partner data is scoped inside one installation, while the member identity can span businesses. The product does not automatically provide client billing, subscription checkout, provisioning policy, contracts, or the support operation around a public SaaS.
Decision criteria
What the decision changes.
These choices affect configuration, staff work, economics, support, and the customer promise.
Tenant model
Map a tenant to the product’s partner boundary and use clubs, networks, and roles for their documented purposes.
Provisioning model
Choose administrator-created, invited, or self-service partner registration and define the verification and plan path.
Commercial service
Design billing, tax, contracts, support, service levels, offboarding, and infrastructure outside the tenant data model.
Architecture
Use the product hierarchy as designed.
A source change that weakens scoping can affect every partner in the installation.
Administrator and manager
Operate shared settings, managers, plans, partners, health, and platform-level controls.
Partner and staff
Operate one business’s programs, customers, staff actions, reports, and business settings.
Member
Uses one account and wallet, while each business relationship and program stays scoped.
Network and club
Group partners or organize staff and programs without pretending they create a new tenant engine.
Service layer
Separate application capability from SaaS operation.
A public service needs more than a registration route.
Commercial systems
Choose payment collection, invoices, tax handling, plan policy, trials, cancellations, and failed-payment behavior.
Operations
Provide monitoring, backups, security, updates, incident response, abuse handling, and capacity planning.
Customer service
Define onboarding, documentation, support boundaries, data requests, export, offboarding, and escalation.
Product and operating limits
Keep the recommendation inside the product boundary.
- Do not claim built-in Stripe Cashier subscriptions, automated tenant billing, or a complete public SaaS business unless the current implementation and configuration provide them.
- The partner boundary and shared member identity have specific product semantics. They are not a generic tenancy package for another Laravel application.
- Source-level tenant changes require security review and tests across routes, queries, exports, jobs, APIs, webhooks, and files.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.