Laravel Discount Laravel Package

Product Decisions This Supports

Scope decisions for a promotions/coupon capability

• Defines a concrete v1 feature envelope: percentage, fixed amount, capped percentage ("20% off, up to 100"), Buy X Get Y, tiered/spend-more-save-more, and free shipping. That is a credible launch set for most commerce products — it lets you defer "engine" work and ship promo mechanics in days rather than a sprint cycle.
• Forces explicit decisions on the mechanics customers actually negotiate over: stacking rules, expiry windows vs. start dates, per-code usage limits, guest redemption, and minimum order thresholds. Each of these is a config row rather than a product meeting.
• The DiscountResult object (originalAmount, discountAmount, payableAmount(), hasFreeShipping(), payableShipping(), payableTotal()) surfaces the money math as a first-class API. This is the artifact that supports pricing reviews, finance sign-off, and support tooling — not just checkout code.

Build vs. buy

• Strong "buy" candidate for the discount calculation layer. A discount engine looks trivial and is not: stacking precedence, cap interactions, item-quantity proration, tier boundaries, and free-shipping semantics are where in-house implementations rot. This package encodes those rules already, with events and typed exceptions attached.
• The data model (discounts, discount_usages, discountables, publishable migrations) lands in your database, not a vendor's. That materially lowers lock-in and makes "buy now, replace later" a viable sequencing decision rather than a trap.

Roadmap sequencing

• Unlocks a tiered roadmap: Phase 1 = coupon codes + percentage/fixed; Phase 2 = BXGY and tiered thresholds (merchandising-driven); Phase 3 = free-shipping promos as a margin lever; Phase 4 = campaign automation, promo analytics, and admin UI (none of which this package attempts).
• Because the package has no admin surface, the roadmap must include building one. That is the honest cost of adoption and should be scoped at the same time as the dependency.

Use cases it directly serves

• D2C/e-commerce storefronts on Laravel with a coupon field at checkout, seasonal sales, launch codes, and influencer/affiliate codes generated in bulk (generateCodes(100, 'VIP')).
• B2B or high-AOV catalogs where tiered volume discounts and minimum-order gating are the primary commercial lever.
• Marketplace/subscription products that only need "one promo code per order" — the stacking rules are configurable and restrictive by default is achievable.

Decisions it does not support (scope gaps to flag)

• Tax interaction is undefined: whether discounts apply pre- or post-tax, and how tax is recomputed, is left to the integrator. Finance will ask.
• No refund/reversal story for discount_usages — a refunded order likely consumes a redemption unless you build the release path. This is a support-ticket generator if ignored.
• No visible multi-currency, per-tenant, or rounding-policy controls. Rounding in particular is a reconciliation risk at scale.
• Usage-limit enforcement under concurrency (two carts redeeming the last redemption simultaneously) is unaddressed in the docs — needs verification before any high-traffic launch.

When to Consider This Package

Adopt when all or most of these hold:

• You are on PHP 8.1+ / Laravel 9+ and already storing orders and cart state in Eloquent. The package is happy to stand alone but is designed to pair with binafy/laravel-cart.
• Your promo requirements map to the six implemented types and you are not being asked for basket-scoped "cheapest item free," category-exclusion matrices, or multi-buy-mix-and-match rules.
• You can accept the operational burden of an admin CRUD layer, since none ships with the package.
• You are comfortable owning the risk of a small, single-maintainer dependency for money-adjacent logic. Mitigation: pin the version, vendor the calculation classes if licensing allows (MIT does), and write characterization tests around apply() output before you depend on it.
• Timing matters more than durability — you need codes live this quarter and can revisit the engine next year.

Look elsewhere (or build) when:

• Adoption signal matters. 58 stars and zero dependents means effectively no production battle-testing you can point at. For a payments-adjacent component, that is the single biggest caution flag. If your org requires a maintained-vendor review, this will not clear it unmodified.
• The rules get combinatorial. Stacking across categories, exclusions, "this code not valid with that sale," and priority ordering beyond "highest-value wins" will outgrow the model quickly.
• You need enterprise promotions primitives — campaign calendars, budget/burn caps, per-customer eligibility segments, A/B holdouts, fraud controls on code enumeration, or attribution reporting. Evaluate a commercial promotions platform instead.
• Multi-currency or multi-entity is on the near roadmap. Retrofitting currency-aware rounding and per-entity code scoping onto a single-currency schema is a migration you do not want to schedule twice.
• You need SOC2-style guarantees, SLAs, or a security disclosure channel with a response commitment. Check the repo's Security section and release cadence before signing up; treat a single-maintainer bus factor as a real risk to your promo calendar.

Verdict shape: reasonable for an MVP-to-Series-A Laravel commerce product where promotions are a supporting feature; a poor fit where promotions are the product or where a finance/compliance review will interrogate tax, rounding, and refund behavior.

How to Pitch It (Stakeholders)

For executives — one paragraph:

Promotions are a top-three lever on conversion and AOV, but discount logic is a classic hidden-cost build: the first coupon takes a day, the twentieth takes a quarter. This MIT-licensed Laravel package gives us percentage, fixed, capped, Buy-X-Get-Y, tiered, and free-shipping discounts, coupon code generation, expiry windows, usage limits, stacking rules, and typed validation exceptions out of the box — roughly a quarter of engineering effort we do not spend. It stores everything in our own database tables, so we are not locked in and can replace the calculation layer later without a data migration. The real cost is not the license (free) but the admin screens and the tax/refund edge cases, which we would have built either way. Primary risk: it is a small open-source project with minimal adoption, so we mitigate by pinning the version, testing the money math ourselves, and keeping the engine behind our own service boundary.

For engineering — the practical read:

• Install is a composer require plus migrations; service provider auto-registers; config and migrations are publishable for table-name and user-model customization. Integration surface is a facade (apply, applyCode, applyMany, isValid, generateCode(s), findByCode, matchingTier) returning a DiscountResult value object, plus an applyDiscounts() trait for model attachment. Low blast radius.
• Do wrap it. Put a thin PromotionService in front of the facade so the dependency never leaks into controllers, and so swapping the engine is a one-file change. Persist the resolved discount breakdown on the order — never recompute at display time.
• Known sharp edges to cover with our own tests: BXGY prices free items at basket average unit price, which will surprise merchandising on mixed baskets; quantity matters only for BXGY and is silently ignored elsewhere; free shipping sits outside stacking and always applies, which is a deliberate but non-obvious rule.
• Verify before launch: usage-limit behavior under concurrent redemption, behavior on partial/full refund (does a redemption get released?), rounding mode and where it is applied, and tax ordering. These are the four questions that will come back as bugs.
• Requires a migration widening the type enum and defaulting value if we have any pre-existing installs; on Laravel ≤10 that needs doctrine/dbal.
• Maintenance posture: MIT license means we can fork or vendor the calculation classes if upstream goes quiet. Budget a small ongoing owner — this is money logic, it needs a named maintainer on our side regardless of who wrote it.