Weave Code
Ti Ext Coupons Laravel Package
tastyigniter/ti-ext-coupons
TastyIgniter Coupons extension for adding fixed amount or percentage discounts, advanced usage restrictions, location-based and time-sensitive promotions to boost restaurant sales.
Extend the checkout experience with coupons and discount codes.
Frequently asked questions about Ti Ext Coupons
- How do I install the tastyigniter/ti-ext-coupons extension?
- Install it with Composer using composer require tastyigniter/ti-ext-coupons, then enable the extension from the TastyIgniter admin Extensions page and run the migrations it ships with. Once enabled, a Coupons admin surface appears where you create codes and configure their rules. No external services, API keys, or paid tier are required since the extension is MIT licensed.
- Which TastyIgniter versions does this coupons extension support?
- Support is pinned to the TastyIgniter core rather than to standalone Laravel versions. Recent releases tightened the constraint, with v4.2.0 requiring tastyigniter/core ^v4.4, so confirm your core version satisfies the Composer constraint before installing. If you are on an older core, either upgrade TastyIgniter first or pin an earlier extension release, and check Packagist for the real latest version since release dates in third-party metadata can be unreliable.
- What coupon types and discount modes are available?
- The extension supports fixed amount coupons and percentage-based coupons. Each coupon can be scoped with validity modes such as forever, a fixed date range, a recurring period, or a defined time window. This covers standard promotional operations but does not model stacking, bundles, loyalty point redemption, or gift cards.
- Can coupons be limited by location, day, time, minimum order, or delivery versus collection?
- Yes. Coupons can be targeted to specific locations, restricted to particular days and time windows, and gated on a minimum basket value or minimum item quantity. There is also an order_restriction setting for delivery versus collection orders. Note that location binding is deep: newer releases tie the coupon model directly to the platform Location class, so multi-location setups should be regression tested after upgrades.
- Can a customer apply more than one coupon to an order?
- No. The discount surface is designed around one coupon per order, and there are no stacking or priority rules in the extension. If you need combinable promotions or ranked discount application, that is custom development on your side rather than a configuration toggle. Plan your promotional logic around a single applicable code per basket.
- Does the extension expose API endpoints for coupons?
- Yes, it registers JSON:API endpoints under /api/coupons, scoped by the coupons:read and coupons:write permissions. Read access lets external systems list and inspect coupon definitions, while write access allows creating or updating them programmatically. Make sure the API tokens you issue carry only the scopes actually needed for your integration.
- How are taxes and delivery fees handled when a coupon discount is applied?
- Delivery-fee discounting was added in v1.11.0, so whether the fee is discountable depends on the version you run and your configuration. Tax treatment of discounts is explicitly out of scope in the extension, so pre-tax versus post-tax application is a decision and verification task for your team. Test discount, tax, and delivery-fee composition together in a staging order before going live.
- What does a redemptions value of 0 mean, and why do some timestamps show -0001-11-30?
- The documentation and examples do not clearly state whether 0 means unlimited redemptions or no redemptions allowed, and sample rows show created_at and updated_at as -0001-11-30 00:00:00. Both are documented data hazards that should be resolved before reporting, finance, or throttling logic depends on them. Inspect the underlying schema and admin and API responses in a test environment to confirm actual behavior on your version.
- Where do I report a bug in the Coupons extension?
- Issues are routed to the core TastyIgniter issue tracker on GitHub rather than to the extension repository itself. That means triage timing is controlled by the core maintainers, and you cannot read a clean per-component backlog. For anything business critical, keep a local patch or fork strategy ready instead of waiting on upstream fixes.
- Is this extension production ready and actively maintained, or should I use an alternative?
- It is community maintained with modest signals: around 4 stars, no dependents, and no vendor SLA. Recent patch releases fixed delivery-only validity logic, customer-restricted redemption, a checkout foreign-key break when writing coupon history, and long-index migration failures, which shows the failure surface more than it disqualifies the package. It is the natural choice if TastyIgniter is already your storefront, but it will not work in a plain Laravel app without TastyIgniter, so decide on fork ownership and an upstream-silence trigger before relying on it long term.
Weaver
How can I help you explore Laravel packages today?