Bagisto Reward Points Laravel Package

Product Decisions This Supports

• Whether loyalty belongs on the roadmap at all. This package is a working reference implementation of the loyalty MVP surface — admin-defined earning rules, checkout redemption, customer balance and history. It lets us price "v1 loyalty" in engineering weeks before we commit a sprint, rather than estimating from a blank page.
• Build vs. buy vs. fork. Concrete input to the classic three-way decision: native Bagisto extension (this), SaaS loyalty (Smile.io, LoyaltyLion, Yotpo), or in-house build. MIT licensing means forking and owning the code is legally clean; nine stars and zero dependents mean we must budget for hardening rather than assume it is turnkey. That trade-off is the decision.
• MVP scoping and gap analysis. The package anchors the first-release conversation around what it already ships, and simultaneously exposes what a real program needs: tiers/VIP levels, referral and birthday triggers, per-order redemption caps, expiry enforcement, refund clawback, statement and analytics views, fraud controls. Each gap becomes a scoped line item with a cost estimate instead of a vague "loyalty is big."
• Experimentation menu. Every mechanic becomes a testable hypothesis with a measurable outcome: repeat rate, AOV lift from threshold bonuses, redemption rate, LTV by cohort, win-back conversion. The package gives us enough surface to run a real pilot rather than a thought experiment.
• Data ownership and platform consolidation. If we run multiple Bagisto storefronts, keeping the points ledger inside our own data model beats exporting customer identity and full order history to a third party. That is a genuine lock-in and data-residency argument, not just a subscription-cost one.
• Liability and policy decision. Points are an unredeemed balance-sheet liability. Adopting or forking this forces the expiry, breakage, refund, and exclusion-policy conversation early — the right time to have it, not after launch when balances are live and support tickets are open.
• Support and operations sizing. A customer-facing balance means support will field "where are my points?" We should plan a read-only ledger view and an ACL permission for the support role as part of the launch scope, not as a later request.

When to Consider This Package

Consider it when:

• We are standardized on Bagisto/Laravel and want a native starting point instead of a SaaS subscription for a first-pass loyalty program.
• The program is deliberately phase 1 and modest: earn on paid orders, redeem at checkout, rules configurable by admin — and the business tolerates an evolving feature set.
• We have in-house PHP/Laravel engineers who will audit, fork, and maintain the extension, and who can own the edge cases it almost certainly does not cover (concurrency-safe redemption, refund clawback, expiry jobs).
• We want a cheap experiment to validate whether loyalty actually moves retention before funding a multi-sprint build or signing a vendor contract.
• Cost control, data residency, or SaaS fatigue make keeping loyalty logic inside our own stack strategically preferable.

Look elsewhere (or build in-house) when:

• We need enterprise-grade loyalty: tiers, liability accounting, breakage and expiry disclosure, partial-refund clawbacks, multi-currency conversion, fraud controls, full audit trails.
• We need proven maturity and vendor support. Nine stars, zero dependents, and a ~1.0 composite score signal a young, unproven codebase with effectively no community and no documentation beyond the README. There is no one to escalate to.
• The team is not prepared to own a fork. With no upstream momentum, every Bagisto core upgrade becomes our rebase-and-retest problem. That is a recurring schedule line, not a one-time install cost.
• We need redemption guarantees out of the box. The description emphasizes admin-side reward creation; the checkout redemption path, concurrency-safe balance handling, and refund clawback are integration work we will likely own. If we cannot staff that, a mature vendor product is the safer call.
• Regulatory or accounting scrutiny applies to customer balances. Then we need a build or vendor solution that treats the ledger as financial data, not a marketing feature flag.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed loyalty extension for our existing Bagisto storefront. It delivers the core of a points program — customers earn on purchases, admins configure the rules, customers see balances and history — without a SaaS subscription and without handing customer data or order history to a third party. It is a credible, low-capital way to test whether loyalty actually improves repeat purchase and AOV before we commit to a build or a vendor contract. The honest caveat: it is a young, essentially unsupported project, so treating it as production-ready off the shelf would be a mistake. The right framing is a funded pilot with engineering ownership attached, not a plugin install.

For engineering: Treat this as a Bagisto module to fork and own from day one, not a package to composer require into production. Budget 30–60 minutes of source reading plus a version-pin exercise before anything else, then validate a single end-to-end loop in staging: admin creates a rule → customer places a qualifying paid order → points land in the account → the same customer redeems at checkout. That one loop surfaces most of the gaps. The known work items: verify points accrue on payment-confirmed, not order-placed; make every credit and debit idempotent with a dedupe key so queue retries cannot double-mint; wrap redemption in a transaction with a row lock to prevent double-spend; own the checkout totals integration so points discount as a cart total and tax/shipping math stays correct; build the expiry scheduler and a nightly reconciliation between ledger sum and stored balance; and write the six money tests ourselves — credit on paid, no credit on failed, debit on refund, full and partial-cancel clawback, capped redemption, concurrent redemption. Design the seams now — earn calculator, redemption rule, ledger repository — because tiers, referrals, and bonuses will be requested within six months. Also flag the license nuance: MIT for the package, but Bagisto core is OSL-3.0, so confirm derivative-work obligations before shipping commercially.

For the business owner: The pilot question is narrow and answerable — does earning and redeeming points change repeat purchase behavior in a measurable way within one or two quarters? We should agree the success metrics, the expiry and refund policy, and the redemption caps before launch, because points become a liability the moment a customer earns them.