Ti Ext Coupons Laravel Package

Product Decisions This Supports

Feature bets it de-risks

• Promotions as a first-class product surface. The extension ships the mechanics restaurant and marketplace roadmaps eventually need: fixed-amount and percentage coupons, minimum-order thresholds, menu-item and category scoping (is_limited_to_cart_item plus menu/category relations), and per-coupon and per-customer redemption caps. That's the "safe discount" primitive — a promo scoped to an item/category and a basket floor is the difference between a margin-safe offer and an accidental sitewide giveaway.
• Campaign scheduling as configuration, not engineering. The validity model (forever, fixed, period, recurring) combined with day-of-week and time windows turns happy-hour, weekday-lunch, and seasonal fill offers into admin settings. This is a direct lever on off-peak capacity — the kind of thing marketing should be able to launch on a Tuesday without a ticket.
• Multi-location and channel targeting. Location-scoped coupons plus order_restriction (delivery vs. collection) support franchise/multi-brand rollout plans and channel-mix experiments — e.g., a collection-only discount to protect delivery margin per order.
• Friction reduction via auto_apply. Unlocks the "discount already applied" checkout experience, a conversion/retention decision you can ship without building a bespoke promo engine.
• Auditability for finance and support. The history object records coupon, order, customer, amount, and timestamp at redemption. Note the redemption flow was deliberately reworked (v1.10.3–1.10.4) to log before payment capture and redeem after — worth understanding, because it defines what "redeemed" means in your reporting.

Roadmap and build-vs-buy

• Verdict: adopt, don't build. A promo engine looks trivial and isn't. Validity edge cases, redemption ledgers, stacking rules, and audit history are where quarters disappear. Recent releases are exactly these edge cases: delivery-only condition logic in Coupon::isValid() (v4.1.4), currency-decimal validation for discount and minimum totals (v4.2.0), customer-restricted coupons failing to redeem (v4.1.1). Each is a bug you'd otherwise write yourself.
• Enables API-first promotion management. Documented JSON:API CRUD scoped by coupons:read / coupons:write lets a marketing dashboard, back-office tool, or partner integration manage coupons without touching the admin UI — relevant if promo operations sit outside the core app.
• Sequencing input: treat standard coupons as table stakes for launch and spend internal effort on the differentiators (personalization, loyalty tiers, A/B-tested offer logic) rather than reimplementing code validation.

Use cases to validate against

• First-order acquisition discount; win-back coupon for lapsed customers.
• Off-peak or seasonal fill via recurring day-part offers.
• Location launch promos for new sites.
• Channel steering (collection-only discount to protect delivery economics).

Decisions this does not settle — flag explicitly. Coupon stacking and priority rules, tax treatment of discounts, refund/partial-refund proration, and fraud controls on code guessing are outside the documented surface. The model is one-coupon-per-order-shaped. Those remain product decisions requiring validation against the code and checkout flow before you promise them to anyone.

When to Consider This Package

Adopt when:

• You are building or operating on TastyIgniter. This is an extension, not a general-purpose Laravel package; its value outside that ecosystem is near zero. Do not attempt to port it.
• You need standard coupon mechanics — code, type, amount, minimum basket, validity window, usage caps — not a novel promotion model.
• You want config-driven campaign ops so marketing self-serves without engineering tickets.
• You need multi-location or delivery/collection targeting on day one.
• You want an API surface for coupon management to integrate with internal tooling or partners.
• Your team is PHP/Laravel-fluent and comfortable owning an MIT-licensed dependency, with fork-and-maintain as an accepted fallback.

Look elsewhere (or budget to build/fork) when:

• You are not on TastyIgniter. Evaluate standalone Laravel promo libraries or build in-house.
• You need advanced promotion logic: stacking priorities, BOGO or bundle rules, tiered/volume discounts, gift cards and store credit, loyalty point redemption, or per-customer dynamic offers.
• You require vendor SLAs, paid support, or a formal security review program. The signals here are weak: ~4 stars, 0 dependents, community maintenance, and issue reporting routed to the core TastyIgniter tracker rather than this repo — bug triage latency is outside your control.
• Data integrity matters and you can't test it. The documented payloads show created_at/updated_at as -0001-11-30 00:00:00 and redemptions: 0 with no statement of whether zero means unlimited. Verify both before building reporting or finance workflows on top.
• Your volume or compliance posture needs rate limiting, abuse detection, and immutable audit beyond a redemption count. Plan to add those yourself.
• You need only a single simple discount code — four validity modes, location arrays, and item restrictions may be more operational complexity than the payoff.

Adoption checklist before committing: confirm the TastyIgniter version constraint (v4.2.0 pins tastyigniter/core ^v4.4) and lockfile pinning; verify release cadence and maintainer responsiveness against Packagist rather than the listed date; test discount × tax × refund end to end; and name the owner of the fork if upstream goes quiet.

How to Pitch It (Stakeholders)

For executives — one paragraph. Coupons are a proven, low-cost demand lever, and we can have them in-market without a build cycle. This is an MIT-licensed module for our TastyIgniter platform: fixed and percentage discounts, minimum-order rules, scheduled and recurring campaigns, per-customer usage caps, location targeting, and delivery-versus-collection targeting — plus an API so marketing runs promotions without engineering support and an order-level redemption history for finance and support. There is no license fee and no per-redemption cost, so the investment is integration and QA time, not procurement. The trade-off is dependency risk: the project is community-maintained with a small footprint, so we should treat it as a supported-by-us component — pin the version, test it against our TastyIgniter upgrade path, and keep a fork option open. Recommendation: adopt for standard promotions, and keep differentiated offer logic (loyalty, personalization, stacking rules) as our own roadmap item.

For engineering — the short version. It's a TastyIgniter extension (a Laravel package) registering coupon models, an admin UI, cart/checkout discount application, and JSON:API endpoints at /api/coupons scoped by coupons:read / coupons:write. Integration cost is low if we're already on TastyIgniter, and the upstream maintainers are clearly fixing the hard parts — delivery-only condition evaluation in Coupon::isValid(), currency-decimal rounding on discount and minimum-total fields, and the log-before-payment / redeem-after-payment ordering introduced in 1.10.3–1.10.4. The real work is ours: (1) verify discount composition against tax and other order adjustments, (2) confirm null-date and redemptions: 0 semantics before they reach any reporting surface, (3) define refund and partial-refund behavior, and (4) own upgrades, since issue triage flows through the core TastyIgniter tracker. Pin the dependency, add contract tests around the coupon validation path (that's where the recent bugs clustered), and assume we may need to patch or fork.