Ti Ext Coupons Laravel Package

Technical Evaluation

Architecture fit

• This is a TastyIgniter extension, not a general-purpose Laravel package. It registers coupon models, an admin CRUD surface, cart/checkout discount application, an order-level redemption ledger (history), and JSON:API endpoints (/api/coupons scoped by coupons:read / coupons:write). Architectural fit is excellent inside TastyIgniter and effectively zero outside it.
• The coupling is deliberate and deep: recent releases bind the coupon model directly to the platform's Location class (v4.1.3) and to the tastyigniter/core version constraint (v4.2.0 requires ^v4.4). Treat this as a platform module we consume, not a library we integrate around.
• The discount surface is one-coupon-per-order-shaped, with validity modes (forever, fixed, period, recurring), day/time windows, min-basket, min-item-quantity, location scope, and order_restriction (delivery vs. collection). That covers standard promo ops; it does not model stacking, bundles, loyalty redemption, or gift cards.

Integration feasibility

• Low engineering effort if we are already on TastyIgniter v4.4+. Install via Composer, register the extension, run migrations, configure coupon rules in admin. No external services, no paid tier, MIT license — the cost is integration QA, not procurement.
• The real effort is verification, not wiring: discount × tax × delivery-fee composition (delivery-fee discounting landed in v1.11.0), refund/partial-refund proration, and the payment-vs-redemption sequence (v1.10.3/v1.10.4 moved to "log before payment, redeem after payment").

Technical risk

• Maturity signals are weak. 4 stars, 0 dependents, community-maintained, no vendor SLA. Issue reporting is routed to the core TastyIgniter tracker rather than this repo, so triage latency is outside our control and we cannot read a clean backlog for this component.
• Release-date anomaly to resolve before planning. The provided latest-release date (2026-08-15) is ahead of any current planning horizon. Do not plan against it until confirmed on Packagist; a stale or misreported release cadence materially changes the fork decision.
• Churn is visible and behavioral. Recent patch releases fixed delivery-only validity logic (v4.1.4), customer-restricted redemption (v4.1.1), a foreign-key break in checkout when writing coupon history (v1.8.2), and long-index migration failures (v4.0.4). Each is a plausible production incident class for us — informative about the failure surface, not disqualifying.
• Documented data hazards. Examples show created_at/updated_at as -0001-11-30 00:00:00 and redemptions: 0 without stating whether zero means unlimited. Both must be resolved before anything downstream (reporting, finance, throttling) depends on them.
• Out of scope by design: stacking/priority rules, tax treatment of discounts, refund proration, and abuse/rate-limiting on code guessing. Those become our product decisions and our build effort.

Key questions

1. Which TastyIgniter core version are we on, and does it satisfy ^v4.4? What is our core upgrade cadence versus this extension's?
2. Does the platform allow only one coupon per order, and is discount applied pre- or post-tax? Is the delivery fee discountable in our configuration?
3. What are the exact semantics of redemptions: 0 (unlimited vs. none) and of null/-0001 timestamps — and are they surfaced anywhere in admin or API responses?
4. On payment failure after "log before payment," are history rows orphaned, and does that corrupt usage-cap enforcement?
5. Who owns the fork, and what is the trigger (upstream silence for N months, a security finding, a core-version break)?
6. Do we need stacking, loyalty redemption, or per-customer personalized offers on the roadmap within 12 months? If yes, scope that as our own build, not a fork of this.

Integration Approach

Stack fit

• Requires PHP/Laravel/TastyIgniter; team must be Laravel-fluent. Fits cleanly if TastyIgniter is already our storefront and back-office platform — the extension plugs into the existing admin, cart, checkout, and API without a translation layer.
• The JSON:API surface is the important architectural property for us: coupons:read / coupons:write abilities let a marketing dashboard or partner tool manage promotions without touching the admin UI, which is what makes self-serve campaign ops viable.

Migration path

• Greenfield TastyIgniter: install as part of the initial extension set; no migration.
• Existing TastyIgniter storefront with manual/hardcoded discounts: enumerate current promotions, map each to a coupon record (type, amount, validity mode, scope, caps), and run both in parallel in staging until discount math matches exactly.
• Non-TastyIgniter stack: do not port. Evaluate standalone Laravel promo libraries or build in-house; the value here is the native integration, which does not survive porting.

Compatibility

• Pin explicitly: extension 4.2.x against tastyigniter/core ^v4.4. The v1.11.x line is the older branch — do not mix.
• Watch two known migration sensitivities: index-name length on MySQL (fixed in v4.0.4) and the Location class binding change (v4.1.3) if we have any local overrides on the coupon model.
• Currency-aware decimal validation (v4.2.0) means discount and minimum-total fields validate against the configured currency's decimal precision — verify on any non-2-decimal or high-precision currency before go-live.

Sequencing

1. Confirm baseline — core version, PHP version, currency config, single- vs. multi-location, delivery/collection mix.
2. Pin and install in staging with a locked Composer constraint; capture the resolved version in our dependency inventory.
3. Write contract tests around Coupon::isValid() — the recurring bug locus (delivery-only, customer-restricted, min-quantity). This is the highest-ROI test investment.
4. End-to-end checkout validation — apply, remove, re-apply, fail payment, refund fully, refund partially; verify the redemption ledger and usage counters in every branch.
5. Define and implement the gaps we own — tax treatment sign-off with finance, refund proration rule, and a code-guessing/abuse control (rate limiting at the API or checkout layer).
6. Expose to marketing — wire the API into internal tooling only after the history/reporting semantics (redemptions: 0, null dates) are confirmed and normalized.
7. Publish an upgrade runbook — core upgrade → extension upgrade → contract tests → staging smoke → production.

Operational Impact

Maintenance

• We are the de facto maintainers. Low stars, zero dependents, and issue routing to the core repo mean no external safety net. Budget a standing owner (fractional FTE) and a documented fork-and-patch procedure, including how we would carry a local patch across a core upgrade.
• Dependency chain is short but version-locked: extension ↔ core. Every core upgrade is a potential extension break; every extension upgrade is a potential schema migration.

Support

• Tier-1 support needs the admin coupon-history page (added v4.0.5) as the primary diagnostic surface: coupon code, order, customer, amount, timestamp. Confirm it renders correctly and that the data is complete for failed-payment cases.
• Expect customer-facing support themes: "my code didn't apply" (validity window, min basket, min item quantity, location, delivery/collection restriction) and "I was charged wrong after refund." Both argue for surfacing the reason a coupon failed to the customer and for a clear refund policy statement.
• Bug triage latency is not contractually ours to control. Escalation path must be internal: patch locally, or disable the feature flag.

Scaling

• Coupon validation executes in the cart/checkout path — a latency- and correctness-sensitive hot path. Load-test with realistic concurrent checkout volume, particularly with auto_apply enabled, which evaluates coupons without user action and can multiply validation calls per session.
• Two data-growth concerns: the coupon table (bounded, admin-managed) and the redemption history table (unbounded, grows with order volume). Confirm indexes on order/customer/coupon foreign keys and plan retention or archival before the ledger reaches reporting-scale.
• API-based promo management scales the authoring side cheaply; it does not change checkout-path cost.

Failure modes

• Orphaned redemption rows — "log before payment, redeem after payment" means a failed or abandoned payment can leave a logged-but-unredeemed history row; risk of usage-cap drift and dirty reporting.
• Checkout hard-fail on ledger write — historical precedent: a foreign-key constraint broke the entire checkout flow when adding coupon history (v1.8.2). This is the highest-severity class: a promo subsystem taking down checkout. Mitigate with a kill switch and a checkout-level try/catch policy decision.
• Validity logic false negatives — delivery-only (v4.1.4) and customer-restricted (v4.1.1) bugs both manifested as "valid coupon rejected" or "invalid coupon accepted." Accepted-invalid is the margin-bleed case; rejected-valid is the CX case. Test both directions.
• Rounding/precision drift — currency decimal validation changes can shift discount amounts by minor units; reconcile against finance expectations after any upgrade.
• Abuse — no documented rate limiting or code-guessing protection. Treat as an accepted risk only if we add controls ourselves.

Ramp-up

• Engineering: half-day to install and configure; 3–5 days to write contract tests and validate checkout/tax/refund behavior end to end. The learning is in the checkout integration, not the package.
• Marketing/ops: low — the admin UI is the product surface, and the API supports a self-serve dashboard. Requires a short enablement session on validity modes and restrictions, plus a promo-approval guardrail so is_limited_to_cart_item / menu-category scoping is used rather than sitewide percentage codes.
• Support: 1–2 hours on the history page and the top five "why didn't my code work" causes.
• Finance: explicit sign-off on discount tax treatment and refund proration before launch — this is a policy decision the package does not make for us.