Developer guide · Points
Points and rewards inside a maintained Laravel application.
The application already connects earning rules to staff actions, member balances, rewards, tiers, and transaction history.
- Core record
- Points transaction ledger
- Derived state
- Balance, rewards, tiers
- Entry
- Staff, API, or commerce event
Short answer
Start with the operating model.
Reward Loyalty’s points module connects earning rules, purchases, balances, rewards, tiers, bonus hours, staff actions, member requests, redemptions, expiry, reversals, and analytics inside the Laravel application. Extending it means preserving ledger integrity and every derived state that depends on the transaction.
Before extending the ledger, review the application-wide Laravel extension boundary.
Decision criteria
What the decision changes.
These choices affect configuration, staff work, economics, support, and the customer promise.
Earning source
State whether staff, a POS integration, commerce order, code, transfer, bonus window, or another supported event creates points.
Reward liability
Model points issued, expiry, reward cost, minimums, caps, multipliers, and reversals.
Ledger effect
Every custom action should create an explainable record and update balances and tier state through the product domain.
Module map
Trace the points event through every dependent feature.
A purchase can affect more than the displayed balance.
Card rules
The partner configures earn ratios, minimum and maximum purchase values, expiry, content, design, and availability.
Transaction ledger
The event records points, purchase amount, currency, staff or integration attribution, notes, expiry, and related reward data.
Rewards and tiers
Redemption uses the balance. Tier qualification and multipliers follow their own configured rules and histories.
Reporting and correction
Staff and partners use supported histories, reversals, filters, exports, and analytics rather than editing totals.
Extension work
Keep calculation and presentation separate.
A source change should reuse the domain operation instead of writing a balance in one screen.
New event source
Integrate through the existing transaction action so ledgers, balances, tiers, live updates, and audit behavior stay aligned.
New reward presentation
Change the customer surface without changing the points economics unless the requirement needs a domain change.
New qualification rule
Add validation, configuration, migration, reporting, and tests for staff, partner, member, API, and reversal behavior.
Product and operating limits
Keep the recommendation inside the product boundary.
- This is a complete application module rather than a standalone Laravel package.
- Points from different businesses or programs should not be added together unless the implemented program model supports that relationship.
- Tier multipliers, bonus hours, online orders, achievements, transfers, expiry, and corrections have distinct rules. Do not describe one as applying everywhere.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.