TastyIgniter

Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.

order-capture-floor-plan-editor

Reservation module has Dining Areas and tables with per-table capacity, but configured as lists; no graphical editor, no saved layouts, no server sections. https://tastyigniter.com/docs/extensions/reservation · retrieved 2026-08-01

Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.

order-capture-seat-level

No seat, cover or position concept in the cart/order model. Orders are web or admin-entered carts with a single line-item list; the model set is Cart, Order, OrderMenu, OrderMenuOptionValue, OrderTotal with no seat column. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-03

Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.

order-capture-coursing-hold-fire

Resolved from `unknown`. The prior note's premise, that this rests on a one-line blurb, is half right: there is still no doc page (`/docs/extensions/waiter` returns the site's 404 body, byte-identical to a fabricated slug), but the vendor's own marketplace record does more than blurb. Waiter Management is described as 'Waiter service management with course ordering' and the publisher tags it `tables`, `dine-in`, `transfer` and `split-bill`, and the screenshots the same page links show an open check with a `Kitchen` action, so fire-to-kitchen from the terminal is visible rather than inferred. Shortfall: nothing published shows per-item course assignment, a held state, or a fire-next-course action that releases only one course — the check view has no course column. Graded C because the marketplace item page is a sell page. https://tastyigniter.com/marketplace/item/avisaas-waiter · retrieved 2026-09-10 adversarially verified

Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.

order-capture-split-merge

Resolved from `unknown`. Splitting is real and published: the vendor's own screenshot, linked from the Waiter Management marketplace page, shows a `Split Bill Mode` panel with per-line checkboxes, partial-quantity selection (a two-quantity line selected as '1 of 2'), a running 'Selected: 3 item(s)' count and a 'Pay Selected (£17.60)' action. Shortfall against the claim, which is wide: only by-item is shown. No by-seat split, no even N-way, no arbitrary dollar or percentage amount, no merge of checks or tables, and nothing on behaviour after a partial payment. Graded C — a screenshot on a sell page, not documentation. https://raw.githubusercontent.com/avisaas/extension-screenshots/main/waiter/screenshot-5.jpg · retrieved 2026-09-10 adversarially verified

Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator

order-capture-bar-tab-preauth

PayRegister ships a `WithAuthorizedPayment` pre-auth/capture trait that a gateway driver may opt into, but there is no tab object, no card-on-file-held-open flow, no incremental re-authorisation and no stale-tab close job. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03

An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.

order-capture-transfer-audit

The Cart model set is the complete order domain: Cart, Category, Ingredient, Mealtime, Menu, MenuCategory, MenuItemOption, MenuItemOptionValue, MenuOption, MenuOptionValue, MenuSpecial, Order, OrderMenu, OrderMenuOptionValue, OrderTotal, Stock, StockHistory. There is no check, tab or seat entity, so there is no open check to transfer between servers, tables or devices. The nearest thing is ti-ext-user's AssignableLog, which records assignment of an order to a staff member - not a transfer naming both employees. https://github.com/tastyigniter/ti-ext-cart/tree/master/src/Models · retrieved 2026-08-03 · not refetchable · site policy · graded A when read adversarially verified

Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.

order-capture-native-handheld

Vendor ships no handheld app. Product is a browser-based Laravel web application. https://github.com/tastyigniter/TastyIgniter · retrieved 2026-08-01

With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.

order-capture-offline-order-entry

Server-rendered web app with no local terminal runtime. Vendor publishes no offline behaviour of any kind. https://tastyigniter.com/docs · retrieved 2026-08-01

Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator

order-capture-qr-same-check

Resolved from `unknown`. The Table Ordering extension is documented at length on its marketplace page and describes the opposite of this claim: a QR scan 'stores the scanned table in the session, switches the location order type to table-order , and sends the customer to the menu with the table already selected' — the ordinary customer cart, producing its own order. What it preserves is the table number, to 'Keep the table number consistent through checkout and admin order views' , not the check. The avisaas POS confirms the shape from the other side: its Occupied Tables panel, published as https://raw.githubusercontent.com/avisaas/extension-screenshots/main/pos/screenshot-3.jpg , shows one table carrying '3 order(s)' rather than one accumulating check. https://tastyigniter.com/marketplace/item/avisaas-tableorder · retrieved 2026-09-10 adversarially verified

Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator

order-capture-kiosk-first-party

No kiosk product on the site or marketplace. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.

order-capture-drive-thru

Order types are an enumerated, extensible class set; the Cart docs name delivery and pickup as the only built-in types (subclasses of `AbstractOrderType`), each with configurable open/opening/closed/disabled descriptions. Anything else has to be written in PHP by the operator. There is no drive-thru order type, no lane or arrival state, no order-confirmation-board feed and no cars-in-lane concept. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-03

Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.

order-capture-drive-thru-timers

Order types are an enumerated, extensible class set; the Cart docs name delivery and pickup as the only built-in types (subclasses of `AbstractOrderType`), each with configurable open/opening/closed/disabled descriptions. Anything else has to be written in PHP by the operator. With no drive-thru flow there are no lane stage timestamps, no per-stage targets and no timer reporting. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-03

Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator

order-capture-voice-ai

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. There is no first-party voice agent, no voice-AI extension and no named voice partner. The open REST write API would permit a third party to build one, but none is published. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator

order-capture-throttling

Per-location 'Limit Orders' setting caps orders per timeslot, with configurable slot interval and lead time. No automatic quote-time extension on kitchen load. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.

order-capture-scheduled-orders

Scheduled orders with per-order-type lead time and min/max advance window are core. No make-queue fire-time injection — there is no make queue. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.

order-capture-catering

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No catering extension exists and core models no quote, deposit, balance or event object — the order model is a single cart with a fulfilment time. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator

order-capture-order-ready-signal

No third-party marketplace integrations exist to signal. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.

order-capture-void-comp-controls

The order status workflow supports a rejection status with configurable reasons and can be restricted to named staff, but there is no void/comp/discount reason-code model, no manager-approval gate and no exception report. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-03

Supports modifier groups nested at least three levels deep, each level with independent min/max selection counts and a forced-selection (required) flag.

menu-pricing-nested-modifiers

Single-level menu options (select/radio/checkbox/quantity) containing option values. No nesting; required flag and min/max exist at that one level only. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

A single modifier can carry different prices depending on the parent item and the selected size, configured as a matrix rather than by duplicating the modifier.

menu-pricing-modifier-price-by-parent-size

Option values carry one price. No parent-item or size matrix; you duplicate the option. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports fractional/sectioned modifier placement (at minimum halves, ideally quarters) with independent pricing per section. differentiator

menu-pricing-fractional-placement

No halves or quarters. Toppings are whole-pie option values only. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

The half-and-half pricing rule is operator-configurable among at least two of: charge the higher-priced half, average the halves, or charge each topping at a fraction of full price. differentiator

menu-pricing-half-and-half-rule

No half-and-half pricing rule of any kind, configurable or otherwise. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports modifier quantity tiers (light / regular / extra / double) with a configurable price multiplier per tier, distinct from adding the modifier twice.

menu-pricing-topping-quantity-tiers

'Quantity' option type lets a guest pick N of an option value, price multiplying linearly. No light/regular/extra tiers with independent multipliers. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Item base price can be defined as a grid across two variant axes (e.g. size x crust/preparation) with a per-cell price override. differentiator

menu-pricing-size-style-matrix

One base price per menu item. Size and crust would be modelled as option values with additive prices, not a two-axis grid with per-cell overrides. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Items can define an included-modifier allowance (e.g. three toppings included) that automatically charges only for overage and credits or forbids substitutions per configuration. differentiator

menu-pricing-included-allowance

Proven negative, still open today: issue #1178 '[Feature]: Add ‘Free Quantity Limit’ option for menu item options' (opened 2026-04-29) is one of only three open issues on the repository. The capability is an unimplemented request, not a shipped feature. https://github.com/tastyigniter/TastyIgniter/issues · retrieved 2026-08-03

Supports combo/meal construction where components can be swapped with a price delta, and the system can automatically detect and convert eligible a-la-carte items in the cart into the combo price.

menu-pricing-combos

Complete model set of the Cart extension, which owns the entire menu and order domain: Cart, CartSettings, Category, Ingredient, Mealtime, Menu, MenuCategory, MenuItemOption, MenuItemOptionValue, MenuOption, MenuOptionValue, MenuSpecial, Order, OrderMenu, OrderMenuOptionValue, OrderTotal, Stock, StockHistory. Stock/StockHistory is a plain count against a menu item or an option value with a low-stock alert; `Ingredient` is the renamed allergens table (migration 2022_02_03_000300_rename_allergens_to_ingredients_table), not a recipe component. There is no combo, meal or bundle model, no component-swap price delta and no cart-side combo detection. https://api.github.com/repos/tastyigniter/ti-ext-cart/contents/src/Models · retrieved 2026-08-03

Upsell/suggestive-sell prompts can be configured per item and per channel (POS, kiosk, online), and the vendor reports attach-rate on those prompts. differentiator

menu-pricing-upsell-prompts

Resolved from `unknown`. The Cart extension at /docs/extensions/cart documents the whole ordering and checkout contract and configures no suggestive-sell surface, per item or per channel, and no attach-rate metric. Controls run as stems, so an inflection cannot hide: `upsell` and `cross-sell` occur zero times anywhere. `recommend` does occur, and the one hit that could have falsified this is the help article 'Menu item recommendations' — it is copywriting advice ('Write clear names and descriptions' , 'Use high-quality photos') , not a prompt engine. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://tastyigniter.com/support/articles/menu-item-recommendations · retrieved 2026-09-10 adversarially verified

A single 86 action propagates automatically to POS, KDS, the vendor's own online ordering, kiosk, and connected third-party marketplaces, with a documented propagation latency.

menu-pricing-86-propagation

Stock quantity at zero makes the item unavailable across the site — but there is only one channel. Nothing to propagate to (no POS, no kiosk, no marketplaces). No latency published. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports per-item countdown/par counts that decrement on sale and automatically 86 the item at zero, with a scheduled auto-restore. differentiator

menu-pricing-countdown-auto-86

Per-item and per-option-value stock quantity decrements on sale and auto-hides the item at zero, with a minimum-quantity alert. No scheduled auto-restore. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Menus, individual items, and prices can be scheduled to activate and deactivate automatically by day and time in the location's own timezone.

menu-pricing-dayparting

Mealtimes (breakfast/lunch/dinner) gate item availability by time, and Special Pricing supports Daily / Period / Recurring-weekday validity with start-end times. Per-location timezone handling of these rules is not explicitly documented. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports distinct price books per channel (dine-in, pickup, delivery, kiosk, each third-party marketplace) including percentage-markup rules applied to a base price rather than manual per-item entry.

menu-pricing-channel-price-books

Items can be restricted to delivery, pickup, or both, but carry one price. No per-channel price book, no percentage-markup rule. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports dual pricing / cash-discount at the item level with the card price displayed as the base price, applied consistently across POS, kiosk, and online ordering, and printed on the receipt. differentiator

menu-pricing-dual-pricing

PayRegister documents five gateways — Authorize.Net AIM, Mollie, PayPal Express, Square, Stripe — all online/hosted-checkout drivers, plus opt-in traits for payment profiles, refunds and pre-authorised payments. Gateway configuration fields are enumerated as API credentials, order fee, minimum order total and order status mapping. A menu item carries one price; there is no cash-price/card-price pair on the item, no automatic differential applied at tender, and no receipt disclosure text. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03

Stores allergen flags and nutrition values per item and publishes them to online ordering and third-party menus, and can derive nutrition from linked recipe components rather than manual entry.

menu-pricing-allergen-nutrition

Ingredients/allergens can be tagged per item and shown to customers. No nutrition values and no derivation from recipe components. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Menu items and modifiers can be linked to recipes/bills of materials so that a sale depletes theoretical inventory and yields item-level theoretical food cost. differentiator

menu-pricing-recipe-linkage

Regraded D to A on better evidence, verdict unchanged. The linkage is real and now readable in source: `fc_recipes.menu_id` is a foreign key onto `menus` , and `fc_recipe_ingredients` joins a recipe to either a base ingredient or a `sub_recipe_id` with a quantity and a unit, so recipes nest recursively and cost resolves through them. Shortfall keeping this at partial: it is a third-party GPL extension with seven recorded installs, not core — core's own schema has no ingredient, recipe or cost entity of any kind — so the linkage is available to the platform rather than part of it. https://raw.githubusercontent.com/Paolorox/ti-ext-restapro/main/database/migrations/2024_01_01_000006_create_fc_recipe_ingredients_table.php · retrieved 2026-09-10 adversarially verified

Pushes menus to third-party marketplaces through a certified direct integration (not scraping or a menu-management middleman) and surfaces per-item sync status and rejection errors to the operator.

menu-pricing-3p-menu-push

No certified marketplace menu integrations. Only Uber Direct (courier-as-a-service, not the Uber Eats marketplace) and Shipday appear. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Supports rule-based dynamic pricing where item price varies automatically by time, demand, or channel, with configurable floor/ceiling guardrails.

menu-pricing-dynamic-pricing

Special Pricing (the MenuSpecial model) supports Daily / Period / Recurring-weekday validity windows with start and end dates — date- and time-driven only. There is no demand-, load- or inventory-driven pricing rule, no floor/ceiling guardrail and no experiment framework. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-03

The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator

payments-processor-choice

PayRegister documents five gateway classes - Igniter\PayRegister\Payments\Stripe, PayPalExpress, Square, Mollie and AuthorizeNetAim - plus opt-in traits (WithPaymentProfile, WithPaymentRefund, WithAuthorizedPayment) for building a sixth; the third-party SumUp gateway on the marketplace shows the extension point is used in practice. The vendor operates no processing business, so there is no in-house lock and no residual. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03 adversarially verified

Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator

payments-published-rates

Vendor publishes no card rate because it takes no processing margin — the merchant contracts directly with its own gateway. Structurally favourable, but the cell is literally unmet. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator

payments-dual-pricing

PayRegister documents five gateways — Authorize.Net AIM, Mollie, PayPal Express, Square, Stripe — all online/hosted-checkout drivers, plus opt-in traits for payment profiles, refunds and pre-authorised payments. Gateway configuration fields are enumerated as API credentials, order fee, minimum order total and order status mapping. No cash-discount or card-surcharge price pair exists in that configuration surface, and no dual-price line appears on the order-total model. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03

Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator

payments-surcharge-guardrails

PayRegister documents five gateways — Authorize.Net AIM, Mollie, PayPal Express, Square, Stripe — all online/hosted-checkout drivers, with configuration limited to API credentials, order fee, minimum order total and order status mapping. There is no surcharging engine at all, therefore no debit/prepaid BIN exclusion, no network cap enforcement and no per-state rule table. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03

All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.

payments-emv-nfc

PayRegister enumerates a closed set of five online gateways with no card-present flow, terminal pairing or reader SDK, and the vendor sells no hardware. The obvious counter-example was checked and fails: the SumUp extension ($50/yr, dineabyte, 11 installs) is 'an additional payment gateway for the Pay Register extension' for online card payments with Apple Pay and Google Pay embedded as web Alternative Payment Methods, not a terminal driver. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03 adversarially verified

Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator

payments-softpos-tap-to-pay

PayRegister documents five gateways — Authorize.Net AIM, Mollie, PayPal Express, Square, Stripe — all online/hosted-checkout drivers, plus opt-in traits for payment profiles, refunds and pre-authorised payments. Gateway configuration fields are enumerated as API credentials, order fee, minimum order total and order status mapping. There is no card-present, terminal, reader or Tap-to-Pay-on-phone path anywhere in the extension or its driver framework. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03

Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.

payments-pay-at-table

No handheld hardware of any kind. https://github.com/tastyigniter/TastyIgniter · retrieved 2026-08-01

Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator

payments-qr-guest-pay

Resolved from `unknown`. Two QR surfaces exist and neither pays a check. The avisaas POS receipt template, published as https://raw.githubusercontent.com/avisaas/extension-screenshots/main/pos/screenshot-6.jpg , renders a QR labelled 'Scan for Invoice PDF' over a sample path of `/storage/invoices/invoice-123.pdf` — a document link, not a payment link. The Table Ordering extension's table landing page offers exactly two service buttons, enumerated by the vendor as 'Call a Waiter' and 'Request the Check' ; requesting the check raises a staff notification, and the vendor describes staff completing, confirming or dismissing it. There is no scan-to-pay flow and therefore nothing that closes a check. https://tastyigniter.com/marketplace/item/avisaas-tableorder · retrieved 2026-09-10 adversarially verified

Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.

payments-tip-adjust

Guest tip is entered at online checkout (a custom tip input exists in the cart box). No pre-auth-then-adjust flow, no batch/adjust window, no unadjusted-tips manager screen. https://github.com/tastyigniter/TastyIgniter/issues · retrieved 2026-08-01

Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator

payments-tip-pooling

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. The tip is a line on order_totals with no employee link, so there is nothing to pool into or distribute from. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator

payments-offline-store-and-forward

Complete FIRST-PARTY gateway set is six classes — AuthorizeNetAim, Cod, Mollie, PaypalExpress, Square, Stripe — each authorising synchronously against the gateway's live API inside processPaymentForm. No store-and-forward queue, offline ceiling or deferred-capture path exists in any of them, and the only queued job in the extension is a Stripe webhook receiver. The gateway set is extensible (the docs describe authoring custom gateways, and the marketplace adds SumUp and a Stripe Connect split-payment gateway), so treat six as the first-party floor — but the constraint is architectural, not per-gateway: across the whole MIT source tree there is no service worker, web app manifest or IndexedDB store, so the browser holds no order or payment state that any gateway could forward later. https://api.github.com/repos/tastyigniter/ti-ext-payregister/contents/src/Payments · retrieved 2026-09-07

Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator

payments-offline-decline-liability

This is the vendor's complete published payment documentation — gateway configuration, per-location checkout settings, payment profiles, refunds and custom gateway authoring — and it carries no offline, store-and-forward or decline-liability section and no offline cap of any kind. There is no offline capture to allocate a loss for, and nothing published about one. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-09-07

First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.

payments-gift-cards

Regraded D to A on better evidence, verdict unchanged. Gift cards are entirely a Gift Up! integration: the free first-party extension registers a `giftup` cart condition that redeems a code against the cart total, and the vendor documents that an unspent remainder is retained for future use while a shortfall is settled by other payment methods. Shortfall keeping this at partial: TastyIgniter issues nothing, stores no card, holds no balance and reports no liability — the entire instrument lives in a third-party account reached by one API key, so the capability is resold rather than provided. https://raw.githubusercontent.com/igniter-labs/ti-ext-giftup/master/src/CartConditions/RedeemGiftCard.php · retrieved 2026-09-10 adversarially verified

House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.

payments-house-accounts

Resolved from `unknown` against the schema rather than the prose. The complete migration set of core plus every fetched extension creates 108 tables; none is an account, ledger, balance or statement table, and `customers` carries no credit or balance column. As stems over every corpus, `house account` , `on account` and `credit limit` are zero. `statement` and `tab` are not zero and were read: every hit is a SQL statement or a UI tab. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://raw.githubusercontent.com/tastyigniter/core/master/database/migrations/system/2015_03_25_000001_create_tables.php · retrieved 2026-09-10 adversarially verified

A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.

payments-split-tender

Resolved from `unknown`. Two published mechanisms put more than one tender against one check. The Waiter Management `Split Bill Mode` screenshot settles a selected subset with 'Pay Selected (£17.60)' against a £106.70 check, so the remainder is settled separately; and the Gift Up! documentation states that where the gift card is worth less than the order, 'the customer will be prompted to pay the remaining balance using other payment methods' . Shortfall: the POS payment dialog itself takes one method per settlement (Cash, Card, COD, Other) with a received-amount and change field, and nothing published describes splitting by seat, by even shares or by arbitrary amount, or states any cap. Graded C — screenshot and sell page. https://raw.githubusercontent.com/avisaas/extension-screenshots/main/waiter/screenshot-5.jpg · retrieved 2026-09-10 adversarially verified

Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.

payments-refund-void-controls

Refunds are supported via the WithPaymentRefund trait and admin actions are permission-gated, but no immutable audit log identifying an approver is documented. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator

payments-chargeback-tooling

PayRegister documents five gateways — Authorize.Net AIM, Mollie, PayPal Express, Square, Stripe — all online/hosted-checkout drivers, with configuration limited to API credentials, order fee, minimum order total and order status mapping. No dispute object, evidence upload or representment workflow exists in the platform; chargebacks are handled entirely in the merchant's own gateway dashboard. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03

Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator

payments-card-on-file

The trait is real (`supportsPaymentProfiles()`, `updatePaymentProfile()`, `payFromPaymentProfile()`), but it is an OPT-IN capability a gateway driver may implement — the docs nowhere enumerate which of the five shipped gateways actually do. Card-on-file is therefore documented at the framework layer, not guaranteed at the product layer. Partial. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01 adversarially verified

Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator

payments-payout-timing

Deposit timing is set by the merchant's own gateway; TastyIgniter publishes no schedule and offers no funding product. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.

payments-p2pe-pci4

Self-hosted open-source software; the vendor publishes no AoC or P2PE listing and the merchant/host carries PCI responsibility. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.

kitchen-station-routing

Shortfall: routing is order-level, not item-level. The Kitchen Display manual (the extension is open source and documented, contrary to the earlier reading) configures each display with Locations, Order Types and Menu Categories filters plus up to five board columns mapped to order statuses, and its worked example names a display 'Pizza Station' - so routing by category, order type and location is real and operator-configurable. But the board renders whole order cards, so an order spanning two categories appears in full on both boards, and there is no per-item or revenue-centre routing. https://github.com/igniter-labs/ti-ext-kitchendisplay/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.

kitchen-expo-consolidation

Per-station boards are possible — a display filters by location, order type and menu category, and the docs' own example names are "Main Kitchen" and "Pizza Station" — but the unit is the order, not the item. Each of the up-to-five board columns binds to one ORDER status, BoardItem carries a single statusId, and bumping calls updateOrderStatus(), one global value; so a bump on any station's board moves that order on every station's board. There is no per-station or per-item bump state, hence no all-stations-contributed completion condition. https://tastyigniter.com/docs/extensions/kitchendisplay · retrieved 2026-09-07

Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator

kitchen-course-firing

Resolved from `unknown`, on the same evidence as `order-capture-coursing-hold-fire` and with the same shortfall. Firing from the terminal is visible: the vendor's published waiter check has a `Kitchen` action alongside void and settle, and the extension is sold as 'Waiter service management with course ordering' . What is not published anywhere is the course mechanism itself — no per-item course assignment, no held state, no fire-next-course that releases one course only. Neither the Waiter nor the POS extension has a doc page. https://tastyigniter.com/marketplace/item/avisaas-waiter · retrieved 2026-09-10 adversarially verified

Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator

kitchen-prep-time-pacing

The Kitchen Display manual's Wait Time Management section is the whole of the product's cook-time handling: an operator clicks the order time and picks a +15/+30/+45 preset or types a custom HH:MM. That is a manual, order-level promise-time push. No per-item cook time exists in the menu model and nothing staggers item display so lines finish together. https://github.com/igniter-labs/ti-ext-kitchendisplay/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator

kitchen-order-throttling

'Limit Orders' caps orders per timeslot and lead/delay times extend the quote, but the trigger is a static slot cap, not measured kitchen load or ticket times. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator

kitchen-channel-pause-propagation

No connected marketplaces exist to propagate to. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator

kitchen-order-ready-callback

A readiness trigger genuinely exists and this is the near-miss on the record: Uber Direct dispatches when "the order status changes to "Ready for Pickup" (configurable in settings)", Shipday has the same "Delivery Ready for Pickup Status", and the KDS Ready column sets exactly such a status — so couriers ARE dispatched on actual readiness. What does not exist is the claim's subject. No third-party marketplace injects orders into TastyIgniter, so there is no marketplace to send an order-ready event back to; Uber Direct and Shipday are courier networks carrying the operator's own web orders outbound. https://tastyigniter.com/docs/extensions/uberdirect · retrieved 2026-09-07

KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.

kitchen-bump-bar-hardware

Resolved from `unknown`. The complete Kitchen Display manual now readable — installation, configuration, board columns, viewing, status updates, wait-time management, real-time updates and permissions — documents click interaction only ("Click Next button, then select a status"; "Click Pause button"), names no input peripheral, and the extension's settings model exposes no device configuration. The claim requires documented supported models; the vendor documents none, for any device. https://tastyigniter.com/docs/extensions/kitchendisplay · retrieved 2026-09-07

An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.

kitchen-all-day-counts

Resolved from `unknown` against the source of the only kitchen display in the ecosystem. The board's unit of display is `BoardItem` , whose complete constructor is id, statusId, statusName, customerName, time, formattedTime, type, typeName, details and availableStatuses — one object per ORDER. The widget filters those items into status columns and offers a board view and a list view; nothing aggregates a quantity across orders, per item or per modifier. The manual agrees, configuring each display with location, order-type and category filters, an orders limit and up to five status columns. https://raw.githubusercontent.com/igniter-labs/ti-ext-kitchendisplay/master/src/Data/BoardItem.php · retrieved 2026-09-10 adversarially verified

Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.

kitchen-sla-alerts

The Kitchen Display manual enumerates the configuration surface exhaustively - 'The following settings are available': Title, Locations, Order Types, Menu Categories, Orders Limit, five Board Columns and Hide card details. No target cook time, threshold, colour escalation or audible alert appears there or in the usage section. The only time control is manual: click the order time and add a +15/+30/+45 preset or a custom HH:MM. https://github.com/igniter-labs/ti-ext-kitchendisplay/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator

kitchen-printer-fallback

Resolved from `unknown` — the prior note's premise that DocketPrint publishes no documentation is false; it has a 16 KB manual on the vendor's own doc site. Detection and recovery are real: print jobs are queued and their state is visible under Tools > Printers > Print Jobs, the troubleshooting section directs the operator to 'Check Tools → Printers → Print Jobs for failed jobs and error notes' , a `retry` service method re-queues a failed job, and the extension registers a mail template whose stated purpose is an 'Alert sent to the site email after repeated print failures for a printer' . Shortfall, which is the whole claim: nothing automatic. An operator may configure several printers per location, but no designated backup takes over a failed printer's tickets, so a failure needs a human before the ticket moves. https://tastyigniter.com/docs/extensions/docketprint · retrieved 2026-09-10 adversarially verified

KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator

kitchen-offline-operation

The display is an admin-panel page served by the central Laravel application: "This extension uses event broadcasting to provide real-time updates to the kitchen display when new orders arrive or order statuses change. You must have the TastyIgniter broadcast extension installed and configured for this feature to work." A 2026-03 migration adds a poll interval as the fallback path; both require the server. There are also no on-site POS terminals to receive tickets from — the published architecture is one PHP/MySQL host with browser clients. https://tastyigniter.com/docs/extensions/kitchendisplay · retrieved 2026-09-07

Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator

kitchen-item-build-screens

Resolved from `unknown` — the Kitchen Display manual the prior pass could not locate is public, and so is the view that renders the card. Each order card lists every line as quantity x item name and then a full modifier breakout beneath it, grouped by option group name with each selected option and its own quantity where greater than one, followed by the item's free-text comment. That is the claim's third disjunct. It is a modifier breakout only: there are no recipe steps and no portioning, because no recipe or cost model exists anywhere in the schema. https://raw.githubusercontent.com/igniter-labs/ti-ext-kitchendisplay/master/resources/views/_partials/widgets/kitchendisplay/card-details.blade.php · retrieved 2026-09-07

Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator

kitchen-pizza-fractional-display

No fractional placement exists in the menu model, so nothing fractional can be displayed. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.

kitchen-recall-refire

Shortfall: order-level only. The Kitchen Display manual describes advancing a card with the Next button and 'then select a status from the dropdown' - arbitrary status selection, not a one-way bump - plus a Pause button that moves an order to On Hold, so a bumped order can be moved back to New or Preparing. Nothing recalls or refires an individual line, and reprinting is a separate paid extension (DocketPrint, $75/yr) with no documented refire hook. https://github.com/igniter-labs/ti-ext-kitchendisplay/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator

kitchen-order-modification-alerts

Resolved from `unknown`. BoardItem is the complete card payload and carries exactly id, statusId, statusName, customerName, time, formattedTime, type, typeName, details and availableStatuses — no added/changed/removed flag, no previous-state field and no dirty marker. The board re-renders current order state on a broadcast event or poll, so an edit simply replaces the card's contents with no visual indication that anything moved. https://raw.githubusercontent.com/igniter-labs/ti-ext-kitchendisplay/master/src/Data/BoardItem.php · retrieved 2026-09-07

Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator

kitchen-guest-ready-notification

I could not independently confirm the SMS Notify leg — that extension did not surface in the marketplace listing I retrieved, and the cited source is the cart docs rather than a notification doc. Native status-change email is credible; the SMS half of a 'yes' is unverified, and SMS in any case runs on the operator's own provider account with 10DLC entirely on them. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01 adversarially verified

Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.

kitchen-waste-logging

Resolved from `unknown`. Waste logging exists in this ecosystem but not at the kitchen screen. The Kitchen Display widget's complete action surface is status advance, pause to an on-hold column, a wait-time bump and a board/list view toggle; there is no waste, spoilage or remake action and no reason-code vocabulary in the extension at all. The waste that does exist is a `waste` stock-movement type in the Restaurant Production Pro ERP, entered from the admin Production module against an ingredient — see `inventory-waste-logging` — which is neither at the kitchen screen nor reason-coded. https://raw.githubusercontent.com/igniter-labs/ti-ext-kitchendisplay/master/src/Widgets/KitchenDisplay.php · retrieved 2026-09-10 adversarially verified

Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.

kitchen-speed-of-service-reporting

Reports extension ships Best/Worst Selling Items and Top/Bottom Customers only. No ticket-time or station-time reporting. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.

kitchen-prep-forecasting

The Reports extension documents four built-in dashboard datasets (Best Selling Items, Worst Selling Items, Top Customers, Bottom Customers) plus a developer report builder with filter operators, column types and CSV export. No forecasting model of any kind is documented, and with no recipe or ingredient model there is no prep quantity to forecast — ingredient-level inventory is still an open, unimplemented feature request (#1149). https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-03

Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).

delivery-driver-roster

Resolved from `unknown` against core's own schema rather than the avisaas listing. Orders carry `assignee_id` and `assignee_group_id` , and `assignable_logs` retains every assignment as its own row, so per-assignee history is native and reportable. Shortfall against a claim that asks for a first-class driver module: drivers are ordinary staff filtered by group, there is no clock-in or clock-out anywhere in the 108-table schema, and there is no assignment state — nothing distinguishes in-store from on-run from returning. The `staff_groups` table does carry `auto_assign_mode` , `auto_assign_limit` and `auto_assign_availability` , but those three columns are read by no file in the 1,740 fetched, so the availability concept they name is vestigial schema, not a feature. https://raw.githubusercontent.com/tastyigniter/core/master/database/migrations/admin/2020_02_25_000300_create_assignable_logs_table.php · retrieved 2026-09-10 adversarially verified

Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).

delivery-dispatch-board

Resolved from `unknown`. Assignment in TastyIgniter is one order at a time from that order's own detail page: the Shipday manual's own procedure is to open the order, click the Assignee panel, pick a group, then pick a user. There is no screen that lists undispatched orders, no driver-availability view, no elapsed-time column and no way to attach two orders to one driver as a run. Where a dispatch board exists it is Shipday's product, reached by leaving TastyIgniter. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://raw.githubusercontent.com/igniter-labs/ti-ext-shipday/master/docs/index.md · retrieved 2026-09-10 adversarially verified

Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator

delivery-route-map

Resolved from `unknown`. Nothing in the ecosystem sequences a multi-stop run. Geocoding exists for delivery-area polygons and address validation, and the DocketPrint delivery docket prints a per-order barcode and a QR code that opens that one address in a map when scanned — a per-order link to an external map, which is the static address list the claim excludes. No route, leg, stop-order or optimisation vocabulary occurs anywhere. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://raw.githubusercontent.com/igniter-labs/ti-ext-shipday/master/docs/index.md · retrieved 2026-09-10 adversarially verified

Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator

delivery-driver-tracking

Resolved from `unknown`. TastyIgniter ships no driver-facing application of any kind, so there is no origin for a GPS position, and no dispatch screen to surface one onto. The tracking the ecosystem offers is explicitly someone else's: the Shipday manual says customers 'can track their delivery in real-time through Shipday' , and Uber Direct's tracking is Uber's. The only positional data the platform stores is the customer address and the location latitude and longitude. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://raw.githubusercontent.com/igniter-labs/ti-ext-shipday/master/docs/index.md · retrieved 2026-09-10 adversarially verified

Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator

delivery-zones-polygon

The Local extension defines each delivery area as type 'address', 'circle' or 'polygon'. Polygon takes an explicit vertex ring (documented example [[[0.0,0.0],[0.0,1.0],[1.0,1.0],[1.0,0.0],[0.0,0.0]]]); circle takes a centre and radius; address takes priority-ordered components such as ['type' => 'locality', 'value' => 'London', 'priority' => 0]. Charges attach per area with conditions of type 'all', 'above' or 'below' an order total. Native, free, and configured by the operator. https://tastyigniter.com/docs/extensions/local · retrieved 2026-08-03 adversarially verified

Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.

delivery-zone-pricing

Each area carries conditional delivery charges (fixed, below-threshold, above-threshold, prioritised for tiering) and its own minimum order total. A per-zone quoted promise time is not documented — lead time is per-location. https://tastyigniter.com/docs/extensions/local · retrieved 2026-08-01

Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.

delivery-address-validation

The local docs I read document boundary types (polygon vertices, circle centre/radius, address components), a `boundaries` attribute, conditional charge `conditions`, and `checkMinimumOrderTotal()`. Geocoding is referenced, but the specific checkout-time rejection flow the researcher asserts is not spelled out in the documentation. Coverage checking is clearly implied by the model; 'rejected before acceptance' is inference presented as documented. https://tastyigniter.com/docs/extensions/local · retrieved 2026-08-01 adversarially verified

Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator

delivery-driver-comp

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No mileage, reimbursement or driver-pay table, and no payroll export of any kind. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.

delivery-cash-reconcile

Resolved from `unknown`. There is no driver bank, settle-up or over/short flow, and no table that could hold one — the 108-table schema has no drawer, bank, till, shift or reconciliation entity. Run as stems over every corpus, `drawer` , `reconcil` , `closeout` and `over/short` are all zero, and the only `shift` hit in 1,740 source files is a call to array_shift in the form builder. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://raw.githubusercontent.com/tastyigniter/core/master/database/migrations/system/2015_03_25_000001_create_tables.php · retrieved 2026-09-10 adversarially verified

Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.

delivery-daas-dispatch

Both couriers are first-party Igniter Labs publications: Uber Direct for TastyIgniter at $28.00/yr with 20 installs, and Shipday: Local Delivery free with 1,091 installs. Neither documents auto-dispatch rules, fee quoting before dispatch, or courier assignment logic in public. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator

delivery-daas-fallback

Resolved from `unknown` — both courier extensions now have full published configuration docs, and neither supports overflow. Shipday's Delivery Type is a single global setting, "In-House Delivery" or "On-Demand Delivery", chosen once rather than per order; its only automatic choice is between third-party services ("Auto Select Delivery Service With Lowest Fee"), which is courier selection, not in-house-to-DaaS overflow. Uber Direct's only fallback runs the other way and at cart time, not dispatch time: the cart condition "Falls back to the default delivery condition if Uber Direct is unavailable or if the delivery address is outside the service area". No driver-availability or wait-threshold rule exists in either. https://tastyigniter.com/docs/extensions/shipday · retrieved 2026-09-07 adversarially verified

Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator

delivery-3p-direct-integration

No DoorDash, Uber Eats or Grubhub marketplace integration on the marketplace or in core. Uber Direct is courier dispatch, not the Uber Eats marketplace. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.

delivery-3p-injection

No third-party marketplace integration is published. The complete first-party extension catalogue (one unpaginated page, read 2026-08-09) contains no Uber Eats, Deliveroo, Just Eat, DoorDash, Deliverect, Otter or Chowly connector; the two delivery items it does list, Uber Direct for TastyIgniter ($28/yr, 'Support local deliveries for your TastyIgniter store with Uber Direct order delivery') and Shipday (free), are last-mile dispatch of the operator's own orders, not marketplace order injection. The vendor's own comparison page treats Uber Eats as a competitor to run alongside, not to integrate: 'Keep your Uber Eats listing for discovery while driving repeat customers to your direct ordering page.' An operator could build injection themselves on the open write API (POST /api/orders). https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-09 adversarially verified

Menu, pricing, modifiers, and photos publish from the POS master menu out to connected third-party marketplaces, including channel-specific price markups, without maintaining a separate menu in each portal.

delivery-menu-push

The full public marketplace listing (47 extensions, retrieved today) contains no DoorDash, Uber Eats, Grubhub, Deliveroo or Just Eat marketplace connector. The only courier-shaped entries are Uber Direct ($28.00/yr, 20 installs) and Shipday: Local Delivery (free, 1,091 installs), both last-mile dispatch rather than a marketplace channel. With no marketplace channel connected there is no menu, price or photo sync to push, and no per-channel markup rule. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).

delivery-86-sync

Local 86ing is real — the stocks table carries stock_qty, is_tracked and low_stock_threshold, a 2026-02 migration adds out_of_stock_override with out_of_stock_type and out_of_stock_until, and it applies per menu item and per menu option value — but there is no channel to push it to. The complete marketplace contains no aggregator integration: the delivery items are Shipday and Uber Direct (courier dispatch) and AVi SaaS Delivery Management (in-house driver assignment), while Multi Vendor turns the operator's own site into a marketplace rather than connecting to one. https://tastyigniter.com/marketplace/extensions · retrieved 2026-09-07

Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.

delivery-store-pause

A location can be disabled in admin (and doing so has itself caused a 500-error bug), but there is no marketplace pause with timed reactivation. https://github.com/tastyigniter/TastyIgniter/issues · retrieved 2026-08-01

Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator

delivery-3p-reconciliation

The full public marketplace listing (47 extensions, retrieved today) contains no DoorDash, Uber Eats, Grubhub, Deliveroo or Just Eat marketplace connector. The only courier-shaped entries are Uber Direct ($28.00/yr, 20 installs) and Shipday: Local Delivery (free, 1,091 installs), both last-mile dispatch rather than a marketplace channel. No marketplace payout statements ever arrive, so there is nothing to reconcile order-by-order against deposits. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator

delivery-injection-error-visibility

Shortfall: outbound calls only, no per-channel connection state, and no alerting. Integration failures are genuinely visible rather than silent — each webhook publishes "Recent Deliveries: A list of recent webhook deliveries, including the status of each delivery (success or failure) and the response from the payload URL", backed by an igniterlabs_webhook_logs table with is_success, payload, response and exception columns, with a configurable retry count and timeout; Shipday keeps its own dispatch log with request_data, response_data and status per delivery. But no third-party channel injects orders here, so there is no failed-injection surface; what exists per webhook is an enabled/disabled flag, not connection health; and nothing raises an alert — the operator must open the log. https://tastyigniter.com/docs/extensions/webhook · retrieved 2026-09-07

Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.

delivery-tracking-page

Guests get an order-status page and status-change emails on the restaurant's own domain and branding — genuinely first-party. Live driver-position tracking is not core. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator

delivery-promise-time

Promise time is lead time plus a configurable per-status delay — a static per-location constant, not load- or driver-aware. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.

delivery-offline-behavior

Shipday and Uber Direct are the only delivery-dispatch documentation the vendor publishes, and neither states any offline behaviour: no cash-delivery, driver-assignment or driver-settlement path is described for a loss of connectivity, and both work by calling a remote API and receiving a webhook back. Uber Direct's only degradation clause is about the courier service rather than the network — the cart condition "Falls back to the default delivery condition if Uber Direct is unavailable or if the delivery address is outside the service area" — which still requires the operator's own server to be up. https://tastyigniter.com/docs/extensions/shipday · retrieved 2026-09-07

Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.

digital-first-party-web

Homepage states verbatim 'GBP 0 - Self-hosted, forever free. The complete ordering system with no usage limits', 'Zero commission' and 'No hidden fees. No commission. No contracts.' First-party ordering on the restaurant own domain and theme is the entire product, not an add-on channel. https://tastyigniter.com/ · retrieved 2026-08-03

The web/app ordering menu is generated from the same POS menu record as in-store — one item edit propagates to all first-party digital channels without a separate digital menu build.

digital-menu-single-source

One menu-item record per location assignment drives the storefront. There is only one first-party channel, so single-source is inherent rather than engineered. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator

digital-native-app

Resolved from `unknown`. There is no branded native app: `App Store` , `Play Store` , `native app` and `PWA` occur zero times across the doc site, help centre, marketplace and source tree, and the 193-page marketplace has no app product. What does exist — and is why this is not merely undocumented — is an unlisted progressive web app: the avisaas screenshots repository carries a `pwa/` folder its own README omits, whose first image (https://raw.githubusercontent.com/avisaas/extension-screenshots/main/pwa/screenshot-1.jpg) is an iPhone home screen with the storefront and the admin panel installed side by side as home-screen icons. That is an installable web app, not a store-published native binary, so the claim fails on its own terms rather than for want of evidence. https://tastyigniter.com/marketplace/extensions · retrieved 2026-09-10 adversarially verified

Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.

digital-account-saved-payment

Customer accounts with saved addresses and tokenised payment profiles are documented. One-tap reorder from order history is not explicitly documented. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator

digital-upsell-engine

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No upsell, cross-sell or recommendation extension is published, and core checkout has no attach prompt or attach-rate reporting. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.

digital-scheduled-pacing

Scheduled orders with slot intervals, lead time, advance windows and a per-location order limit per slot are all core. Marked partial because multiple open issues report the Limit Orders setting failing to save and scheduling rules misbehaving. https://github.com/tastyigniter/TastyIgniter/issues · retrieved 2026-08-01

Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.

digital-fulfillment-modes

Delivery and collection/pickup are core order types with per-type fees and timing, and custom order types can be coded. Dine-in requires the paid Dine-In Management extension; curbside with arrival check-in is absent. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.

digital-qr-table

Resolved from `unknown`; the prior note treated this as marketplace listing copy only, and that premise is false — the Table Ordering marketplace page carries a full feature specification. Scan-to-order is real and detailed: a QR at the table routes the guest into the table-order flow with the table preselected, optional table locking, an optional confirmation page, per-location enablement, and three independent anti-spoofing modes the vendor enumerates as a GPS location check, waiter confirmation, and a table code that 'can be a rotating per-minute code shown on a display screen, or a manual code written on a board' . Shortfall: it opens a new customer order rather than attaching to an existing POS check, there is no scan-to-pay, and the guest flow exposes no split. Graded C — a sell page. https://tastyigniter.com/marketplace/item/avisaas-tableorder · retrieved 2026-09-10 adversarially verified

Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator

digital-kiosk

No kiosk product. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.

digital-group-ordering

Resolved from `unknown` — the prior note's premise, that a zero-install extension with only a marketplace card cannot support a verdict, was wrong on the second half: Group Order has a 13 KB manual on the vendor's own doc site. Every element of the claim is documented. A host starts an order and sends an invite by email to a join link; guests join by name and email and add their own items; the host may lock, cancel, extend the deadline or remove a guest. The spend cap and the payment mode are the same call: the documented start signature takes `split_bill` true or false and a `spending_limit` used when split_bill is true, so per-person capping and split-or-single payment are both first class. Global and per-location settings add an order deadline and a minimum-guests-required threshold. https://tastyigniter.com/docs/extensions/grouporder · retrieved 2026-09-10 adversarially verified

Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator

digital-catering-portal

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No catering portal, catering menu, lead-time rule set, quote, deposit or invoice-terms capability exists in core or on the marketplace. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator

digital-voice-ai-phone

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No AI phone-ordering extension is published and no certified voice partner is named anywhere on the site. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.

digital-drivethru-ai

The full public marketplace listing (47 extensions, retrieved today) contains no DoorDash, Uber Eats, Grubhub, Deliveroo or Just Eat marketplace connector. The only courier-shaped entries are Uber Direct ($28.00/yr, 20 installs) and Shipday: Local Delivery (free, 1,091 installs), both last-mile dispatch rather than a marketplace channel. There is no voice or drive-thru AI extension on the marketplace, and no drive-thru order type in core for one to attach to. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.

digital-sms-ordering

The free SMS Notify extension sends outbound notifications only; there is no conversational text-to-order. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator

digital-google-order

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No Order with Google, Google Business Profile or food-ordering-schema provisioning extension exists, and the site makes no such claim. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.

digital-apple-business-connect

The full public marketplace listing (47 extensions, retrieved today) contains no DoorDash, Uber Eats, Grubhub, Deliveroo or Just Eat marketplace connector. The only courier-shaped entries are Uber Direct ($28.00/yr, 20 installs) and Shipday: Local Delivery (free, 1,091 installs), both last-mile dispatch rather than a marketplace channel. There is likewise no Apple Business Connect, Apple Maps or Order with Google provisioning extension, and the site makes no such claim. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.

digital-loyalty-attach

Regraded D to B on better evidence, verdict unchanged. The prior citation was the marketplace index; the Loyalty Points extension has a 26 KB manual. Points attach to the online order natively: a `loyalty-form` component on the checkout page lets a signed-in customer redeem points against the cart, a `loyalty-dashboard` component shows balance and history, and registration and review bonuses accrue without an order. Shortfall keeping this at partial: it attaches to the web ordering flow only — there is no in-person or POS attach path, since the POS extension is separate, closed-source and undocumented. https://tastyigniter.com/docs/extensions/loyaltypoints · retrieved 2026-09-10 adversarially verified

Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.

digital-subscriptions

Resolved from `unknown`. Run as stems so inflections cannot hide, `subscription` , `membership` and `meal plan` are zero across every corpus. `recurring` is not zero and every hit was read: coupon validity ('Recurring' as a schedule for when a code is live), menu mealtime schedules, and the loyalty extension's spending-validity window. None is billing. There is no recurring-charge entity in the 108-table schema and no subscription product on the 193-page marketplace. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://tastyigniter.com/marketplace/extensions · retrieved 2026-09-10 adversarially verified

Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.

digital-promo-parity

The free Coupons extension (31,789 installs today) defines discount codes once for the storefront. Parity is trivially satisfied because there is only one channel — there is no POS, kiosk or marketplace stream for a promotion to diverge across. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator

digital-guest-data-ownership

Self-hosted MIT application: the operator holds the MySQL database outright and the free REST API exposes customers directly. No fee, no approval, no vendor copy. https://github.com/tastyigniter/TastyIgniter · retrieved 2026-08-01

Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.

digital-checkout-pci-sca

Stripe, Square, Mollie, PayPal and Authorize.Net gateways keep card data off the merchant's own form and carry 3DS/SCA at the gateway. But TastyIgniter publishes no PCI DSS 4.0 compliance statement and no position on the March-2025 client-side script-integrity requirements — self-hosting pushes that onto the operator. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator

digital-surcharge-transparency

PayRegister documents five gateways — Authorize.Net AIM, Mollie, PayPal Express, Square, Stripe — all online/hosted-checkout drivers, with configuration limited to API credentials, order fee, minimum order total and order status mapping. No surcharge, cash-discount or dual-pricing engine exists on any channel, so there is no pre-tender disclosure of a fee to render. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-03

Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.

guest-loyalty-unified-profile

One customer record with customer groups spans all locations in the install. There is no POS or kiosk stream to merge, and no documented dedup/merge behaviour on phone or email match. https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator

guest-loyalty-thirdparty-identity-attach

No marketplace order ever arrives, so nothing lands to attach. The complete extension marketplace contains no DoorDash, Uber Eats, Grubhub, Deliveroo or Deliverect integration, and the order model has no channel or external-source column — orders are web-checkout or admin-entered carts tied to a customer_id or a guest email. Uber Direct and Shipday move the operator's own orders outbound to couriers and bring back only delivery status. https://tastyigniter.com/marketplace/extensions · retrieved 2026-09-07

Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.

guest-loyalty-accrual-models

Paid 'Loyalty Points' extension ($30/yr) provides points-per-purchase earn and redeem. Only one accrual model, and it is a bolt-on, which is what this criterion is specifically testing against. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator

guest-loyalty-tiers

Customer groups exist as a manual classification (Admin.CustomerGroups permission). No rolling-window automatic promotion or demotion. https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator

guest-loyalty-offline-behavior

The Loyalty Points documentation is the vendor's complete published account of the programme — configuration, checkout integration, the customer dashboard, programmatic earn and redeem, points events, permissions and three API endpoints — and it states no offline behaviour at all: "offline", "queue", "reconcile" and "connectivity" occur zero times in it against 28 occurrences of "redeem". Accrual and redemption run server-side inside the checkout request against the operator's own MySQL database, so there is nothing client-side to queue; but the claim asks for documentation of the behaviour, and none exists. https://tastyigniter.com/docs/extensions/loyaltypoints · retrieved 2026-09-07

Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator

guest-loyalty-offer-stacking-rules

Resolved from `unknown`, and the answer is structural rather than a documentation gap: the cart cannot stack offers, so it exposes no rules for doing so. A coupon is applied through `applyCondition('coupon', ['code' => $code])` , which fetches the single cart condition registered under the name `coupon` and overwrites its metadata, so a second code replaces the first. The `igniter_coupons` column set is closed and carries no exclusivity, combinability or precedence field, and `combinable` and `exclusive` occur zero times in 1,740 source files. Order of application does exist, but only in code: each condition class hardcodes a priority — Tip 100, Coupon 200, Tax 300, PaymentFee 600 — which the claim's 'as configuration' requirement excludes. https://raw.githubusercontent.com/tastyigniter/ti-ext-cart/master/src/Classes/CartManager.php · retrieved 2026-09-10 adversarially verified

Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator

guest-loyalty-targeted-offers

Non-broadcast targeting DOES exist — the correction to this record's old rationale. The vendor's walkthrough of the coupon Restrictions tab lists Minimum Order Total Amount, Order Restriction, Redemptions, Customer Redemptions, Customers ('Limit the coupon to specific customers'), Customer Groups, Location(s) and 'Apply this coupon on'. But it is a manual roster: a named-customer list, or a static customer group whose table carries only group_name, description, approval and is_default, with no behavioural criteria. The ceiling is the schema rather than that article, which is a floor (it omits min_menu_quantity, added 2025-11): the coupons migrations define every column — validity windows, totals, redemption caps — and the model every relation, and the four audience-side joins are customers, customer_groups, categories and menus. Nothing computes over recency, frequency, spend or items purchased. https://tastyigniter.com/support/articles/discount-with-several-conditions · retrieved 2026-09-07

Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator

guest-loyalty-rfm-segmentation

Reports ships Top Customers and Bottom Customers datasets only — spend ranking, not lifecycle segmentation. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.

guest-loyalty-lifecycle-automation

The Automation extension is a real event → condition → action engine (e.g. CustomerRegisteredEvent → SendMailTemplate) running on Laravel queues, and abandoned-checkout automation exists. But it ships no prebuilt birthday, first-visit or lapsed win-back campaigns — the operator builds each rule. https://tastyigniter.com/docs/extensions/automation · retrieved 2026-08-01

Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator

guest-loyalty-native-email-sms

Transactional email is native via mail templates; SMS via the free SMS Notify extension using the operator's own provider. Bulk marketing campaign sending with list management is not documented. https://tastyigniter.com/docs/extensions/automation · retrieved 2026-08-01

Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.

guest-loyalty-consent-management

Resolved from `unknown`; the prior note guessed 'a basic opt-in flag likely exists but I could not verify its shape' , and the shape is now verified. It is one nullable boolean, `customers.newsletter` , created in the 2015 base migration and documented in the customer resource as 'Whether the customer opts into newsletter marketing' . That is the entire consent model: no channel dimension separating email from SMS from push, no consent timestamp, no source-of-consent field, and no revocation record — the flag is simply overwritten. The closed `customers` column set contains no other consent column. https://raw.githubusercontent.com/tastyigniter/ti-ext-api/master/docs/customers.md · retrieved 2026-09-10 adversarially verified

Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.

guest-loyalty-10dlc-registration

SMS runs through the operator's own provider account via SMS Notify, so A2P 10DLC brand and campaign registration is entirely the operator's problem. The vendor neither handles nor documents it. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator

guest-loyalty-campaign-attribution

Shortfall: per-redemption rows tied to check totals, but no campaign object and no incrementality. This overturns the record's previous rationale. Marketing > Coupons > Redemptions is a real attribution list whose published column set is date used, coupon name, code, order id, customer name, minimum total, discount amount and order_total — the last an accessor resolving to the redeemed order's own total — so redemption IS tied to the actual check total, per offer, and the list is searchable by coupon name. Missing is the rest of the claim: no campaign or send object to attribute to (the automation engine's only send action is SendMailTemplate, logged separately and never joined to a redemption), no baseline or control group, and so no incremental-sales figure. https://raw.githubusercontent.com/tastyigniter/ti-ext-coupons/master/resources/models/redemptions.php · retrieved 2026-09-07

Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator

guest-loyalty-data-export-portability

The MIT source registers a `customers` API resource with actions index:admin, show:admin, store:admin, update:users, destroy:admin, and CustomerTransformer returns the full Customer model with `addresses`, `orders` and `reservations` as includes - the guest list with contact PII plus each guest's transaction history. The extension is free, and the operator mints its own admin token (`php artisan igniter:api-token --admin` or POST /api/token), so there is no fee and no support ticket. Being self-hosted and MIT, the operator also holds the database outright. One correction to the CSV half: the free Import & Export Tool's marketplace card advertises 'Import/Export Menu Items, Orders, Customers from/into any CSV', but the shipped v4 extension contains only menuexport/menuimport models - the working export route is the API or direct SQL, not that tool. https://github.com/tastyigniter/ti-ext-api/blob/master/src/Extension.php · retrieved 2026-08-09 adversarially verified

Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator

guest-loyalty-review-capture-routing

The trigger half ships out of the box: ti-ext-local registers the automation preset `chase_review_after_one_day`, named 'Send a message to leave a review after 24 hours', firing on OrderSchedule with action SendMailTemplate (template `igniter.local::mail.review_chase`, send_to customer) under condition ReviewCount is 0. The routing half does not exist. Across every extension that registers automation rules, the only actions are AssignToGroup and SendMailTemplate, and no condition reads a review's score - ReviewCount counts reviews rather than rating them, and the other conditions are OrderAttribute, OrderStatusAttribute, CustomerAttribute, ReservationAttribute and ReservationStatusAttribute. There is no score branch, no private-recovery path and nothing that pushes a guest toward a public review site. https://github.com/tastyigniter/ti-ext-local/blob/master/src/Extension.php · retrieved 2026-08-09 adversarially verified

Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.

guest-loyalty-referral-program

Resolved from `unknown`. As a stem, `referral` is zero across every corpus, and the `refer` hits were all read: they are documentation cross-references and foreign-key declarations. The Loyalty Points extension is the only loyalty product and its manual enumerates the complete set of ways points may be earned — an order, plus registration and review bonus points — so a referral earn is excluded by the vendor's own list rather than merely unmentioned. There is no per-guest code or link, no first-order attribution and no two-sided reward anywhere. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://tastyigniter.com/marketplace/extensions · retrieved 2026-09-10 adversarially verified

Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator

guest-loyalty-wallet-pass

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No Apple Wallet or Google Wallet pass issuance extension exists; the Loyalty Points extension ($30/yr) is an in-account points balance only. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.

guest-loyalty-privacy-rights-tooling

Admin.DeleteCustomers permission allows deleting a guest record, and self-hosting gives the operator complete database-level access to locate and export anything. But there is no purpose-built DSAR workflow and no propagation guarantee into loyalty or marketing records held by extensions. https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.

guest-loyalty-redemption-fraud-controls

Resolved from `unknown` — the prior note's premise that these are undescribed is false; the Loyalty Points manual is 26 KB and enumerates its redemption restrictions in full. Real controls exist: a minimum-points-per-redemption floor, a Maximum Order Percentage capping how much of a bill points may cover, a minimum basket value, an order-type restriction, a restriction to selected categories or items, a Points Valid After delay in hours before earned points may be used, a Points Expire After window, and a Spending Validity schedule limiting redemption to fixed dates, a range or recurring days and times. Every transaction lands in a loyalty history table with customer, order, type, points earned, points used, status and validity period, which is the audit log. Shortfall, and it is the specific list the claim names: no redemption velocity limit, no manager-approval step on a manual adjustment, and no flagging of employee self-redemption — the two permissions are only Manage and View. https://tastyigniter.com/docs/extensions/loyaltypoints · retrieved 2026-09-10 adversarially verified

Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator

guest-loyalty-ai-offer-recommendation

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No AI or ML feature is published in core, in the marketplace, or on the site — no next-best-offer, no propensity model, no send-time optimisation. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.

guest-loyalty-stored-value-gift

Free 'Gift Up!' extension integrates an external gift-card provider. Balances live with that provider, not tied to the native guest profile. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.

labor-clock-in-at-pos

No timeclock and no POS terminal. Staff records exist for admin access and order handling only. https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator

labor-photo-punch-verification

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No punch mechanism exists to photograph. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator

labor-offline-time-punch

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. There is no punch of any kind to buffer offline, and no local runtime to buffer it in. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.

labor-granular-rbac

Real permission-per-action model (Admin.Orders, Admin.Customers, Admin.DeleteCustomers, Admin.Impersonate, Admin.StaffGroups...) with staff groups and per-location restriction. Marked partial because the enumerated POS actions this criterion tests — void, comp, discount, drawer open, price change — have no corresponding permissions, and one open issue reports the location restriction leaking. https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.

labor-manager-override-audit

No override workflow and no immutable audit trail documented. https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator

labor-native-scheduling

Locations and staff have working-hours settings that gate order acceptance, not shift schedules for employees. https://tastyigniter.com/docs/extensions/local · retrieved 2026-08-01

Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator

labor-demand-labor-forecast

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No hours, wage or schedule data exists to forecast against. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator

labor-realtime-labor-percent

No labour cost data exists in the system. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator

labor-overtime-prevention

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No clocked hours exist, so weekly-hour projection and approaching-overtime alerting have nothing to run on. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator

labor-break-compliance-by-state

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No break, meal-period or jurisdiction rule table exists. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.

labor-minor-labor-rules

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. Staff records carry no date of birth, no minor flag and no hour caps; there is nothing to enforce a minor-labour rule against. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.

labor-tip-pooling-rules

ti-ext-user/src/Models is the complete staff and customer domain: Address, AssignableLog, Customer, CustomerGroup, Notification, User, UserGroup, UserPreference, UserRole. There is no shift, punch, timesheet, pay-rate, tip or payslip entity anywhere in it, and the marketplace lists no labour, scheduling or payroll extension at any price. Tip pooling has no data model to run on. https://github.com/tastyigniter/ti-ext-user/tree/master/src/Models · retrieved 2026-08-03 · not refetchable · site policy · graded A when read adversarially verified

Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.

labor-tip-distribution-audit-trail

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. Tips are an order-level amount on order_totals with no employee attribution, so there is no distribution to audit. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator

labor-qualified-tips-w2-reporting

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No payroll or earnings data exists, so no W-2 Box 12 TP / Box 14b treatment is possible. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator

labor-native-payroll

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No pay rate, no earnings, no tax withholding and no pay-run table. There is no payroll product. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).

labor-payroll-export-formats

No Gusto, ADP, Paychex or QuickBooks payroll connector on the marketplace or in core. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator

labor-shift-swap-workflow

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No shift entity exists, so no swap, pickup or manager-approval workflow can exist. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator

labor-server-performance-metrics

Reports covers items and customers only; no per-employee sales metrics. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.

inventory-recipe-bom-costing

Free community 'Restaurant Production Pro' extension is described as an ERP managing food cost, recipes and inventory. Multi-level sub-recipes and automatic plate-cost recalculation on ingredient price change are unverified. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.

inventory-unit-conversion-yields

Resolved from `unknown` — the prior note's premise, that this rests on the Restaurant Production Pro listing, is superseded: the extension is public and GPL-3.0 at Paolorox/ti-ext-restapro, last pushed 2026-07-30, so its schema settles the cell. Every element is present. `fc_units` carries `base_unit_id` and a decimal `conversion_factor` , so derived units resolve to a base unit. The three units the claim asks for are distinct columns on distinct tables: the purchase unit on `fc_purchase_order_items.unit_id` , the recipe unit on `fc_recipe_ingredients.unit_id` , and the stocking unit on `fc_ingredients.unit_id` . The yield is explicit — `fc_ingredients.yield_percentage` , whose field label in the extension's English language file reads 'Yield percentage after peeling/waste. E.g. 80% for potatoes.' — and `fc_recipes` adds `yield_amount` with `yield_unit_id` for batch output. Recorded against a third-party extension, not core, which has no recipe model at all. https://raw.githubusercontent.com/Paolorox/ti-ext-restapro/main/database/migrations/2024_01_01_000011_add_yield_to_fc_ingredients_table.php · retrieved 2026-09-10 adversarially verified

Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator

inventory-theoretical-vs-actual

Resolved from `unknown`. Half the inputs exist and the report does not. Theoretical usage is genuinely computed: on payment the ERP resolves each ordered item's recipe, explodes sub-recipes recursively, converts units and writes negative `sale` movements. What is missing is the other half and the join — there is no physical count entity, so there is no actual usage to compare against, and no variance output in either units or currency. `variance` is zero across every corpus as a stem, and the single `theoretical` hit in 1,740 source files is a changelog line about adjusting theoretical COSTS for yield, not usage. Bounded to the whole published surface as of 2026-09-10: the 106-loc /docs family of the 1,722-loc sitemap (97 answered 200; the 9 that did not returned a body byte-identical to a fabricated slug), the 76-page help centre, the 193 marketplace pages, and 1,740 source files — the complete MIT source of core v4.4.1 and seventeen first-party extensions plus the GPL-3.0 Restaurant Production Pro. It does not bound the closed-source avisaas POS suite, which publishes no doc page. https://raw.githubusercontent.com/Paolorox/ti-ext-restapro/main/src/Models/StockMovement.php · retrieved 2026-09-10 adversarially verified

Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator

inventory-realtime-depletion

Core natively decrements stock quantity on menu items and on individual option values as orders are placed — including modifier-driven depletion. But it depletes the sellable item, not ingredients; ingredient-level depletion would need the community ERP extension. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator

inventory-86-auto-sync

Stock hitting zero makes the item unavailable on the storefront automatically. There is no POS or third-party channel to sync to. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.

inventory-count-modes

Resolved from `unknown` against a genuinely closed enumeration: `StockMovement` declares its types as PHP constants and there are exactly four — `purchase` , `sale` , `waste` and `adjustment` . None is a count. There is no count entity, no count period, no scheduling and therefore no per-count variance history; the nearest mechanism is a manual `adjustment` movement, whose help text in the extension's English language file reads 'Enter a positive amount for waste or positive/negative for manual adjustments.' , which overwrites the on-hand figure without recording what was counted against what. `stocktake` , `physical count` and `cycle count` are zero across every corpus. https://raw.githubusercontent.com/Paolorox/ti-ext-restapro/main/src/Models/StockMovement.php · retrieved 2026-09-10 adversarially verified

Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.

inventory-mobile-count-offline

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No mobile counting application is published; stock is edited in the browser admin against the operator's own server, so a count cannot be taken without connectivity. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator

inventory-vendor-catalogs-edi

No Sysco, US Foods or PFG catalogue integrations on the marketplace. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator

inventory-invoice-ocr

Complete model set of the Cart extension, which owns the entire menu and order domain: Cart, CartSettings, Category, Ingredient, Mealtime, Menu, MenuCategory, MenuItemOption, MenuItemOptionValue, MenuOption, MenuOptionValue, MenuSpecial, Order, OrderMenu, OrderMenuOptionValue, OrderTotal, Stock, StockHistory. Stock/StockHistory is a plain count against a menu item or an option value with a low-stock alert; `Ingredient` is the renamed allergens table (migration 2022_02_03_000300_rename_allergens_to_ingredients_table), not a recipe component. There is no purchase order, supplier, invoice or document model at all, so there is nothing for OCR to populate. https://api.github.com/repos/tastyigniter/ti-ext-cart/contents/src/Models · retrieved 2026-08-03

Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator

inventory-price-change-alerts

Complete model set of the Cart extension, which owns the entire menu and order domain: Cart, CartSettings, Category, Ingredient, Mealtime, Menu, MenuCategory, MenuItemOption, MenuItemOptionValue, MenuOption, MenuOptionValue, MenuSpecial, Order, OrderMenu, OrderMenuOptionValue, OrderTotal, Stock, StockHistory. Stock/StockHistory is a plain count against a menu item or an option value with a low-stock alert; `Ingredient` is the renamed allergens table (migration 2022_02_03_000300_rename_allergens_to_ingredients_table), not a recipe component. No supplier price is ever stored, so a period-over-period cost-increase alert has no data to run on. https://api.github.com/repos/tastyigniter/ti-ext-cart/contents/src/Models · retrieved 2026-08-03

Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator

inventory-par-auto-suggest

Core supports only a per-item minimum-quantity stock alert. No par-driven suggested purchase orders and no forecast-driven mode. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.

inventory-waste-logging

Resolved from `unknown` — the prior note's premise, that waste is undescribed, is false now that the extension's source is in hand. `waste` is one of the four declared stock-movement types, the admin action is labelled 'Add Movement/Waste' in the extension's English language file , and a waste row debits the ingredient and records quantity, unit cost, the acting user and a timestamp in a history the vendor describes as complete traceability. Shortfall on both of the claim's remaining halves: the reason is a free-text `notes` column with no reason-code vocabulary anywhere in the extension, and waste cost is never reported separately — there is no waste report at all, and no usage-variance report to report it separately FROM. https://raw.githubusercontent.com/Paolorox/ti-ext-restapro/main/src/Models/StockMovement.php · retrieved 2026-09-10 adversarially verified

Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.

inventory-shelf-life-expiry

Complete model set of the Cart extension, which owns the entire menu and order domain: Cart, CartSettings, Category, Ingredient, Mealtime, Menu, MenuCategory, MenuItemOption, MenuItemOptionValue, MenuOption, MenuOptionValue, MenuSpecial, Order, OrderMenu, OrderMenuOptionValue, OrderTotal, Stock, StockHistory. Stock/StockHistory is a plain count against a menu item or an option value with a low-stock alert; `Ingredient` is the renamed allergens table (migration 2022_02_03_000300_rename_allergens_to_ingredients_table), not a recipe component. Stock is a scalar count with no lot, batch, received-date or use-by attribute, so shelf-life tracking and expiry alerting are not modelled. https://api.github.com/repos/tastyigniter/ti-ext-cart/contents/src/Models · retrieved 2026-08-03

Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.

inventory-bar-partial-bottle

Complete model set of the Cart extension, which owns the entire menu and order domain: Cart, CartSettings, Category, Ingredient, Mealtime, Menu, MenuCategory, MenuItemOption, MenuItemOptionValue, MenuOption, MenuOptionValue, MenuSpecial, Order, OrderMenu, OrderMenuOptionValue, OrderTotal, Stock, StockHistory. Stock/StockHistory is a plain count against a menu item or an option value with a low-stock alert; `Ingredient` is the renamed allergens table (migration 2022_02_03_000300_rename_allergens_to_ingredients_table), not a recipe component. Stock decrements in whole units of a menu item or option value; there is no weight, tenth-of-a-bottle or partial-unit measure. https://api.github.com/repos/tastyigniter/ti-ext-cart/contents/src/Models · retrieved 2026-08-03

Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.

inventory-cogs-gl-export

No QuickBooks, Sage or NetSuite connector on the marketplace and no GL mapping in core. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator

inventory-native-not-partner

Simple item and option-value stock counting is genuinely native and free. Recipe costing and anything resembling real F&B cost control requires the separately-installed Restaurant Production Pro community extension. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Joins recipe cost to actual item sales mix to report contribution margin per menu item, and flags items whose margin fell below a configured threshold after ingredient cost changes. differentiator

inventory-menu-margin-linkage

Resolved from `unknown`. The cost side is fully built and cost changes do propagate: `fc_recipes` joins a recipe to a TastyIgniter `menu_id` and stores `calculated_cost` against a `target_food_cost` threshold, the extension ships a per-recipe margin view, and the extension's own in-product guide text states it computes 'the total cost, cost per portion, actual food cost percentage (compared to menu price), and margin' , recalculating the weighted average cost and propagating it to affected recipes whenever a purchase order is received. Shortfall: margin is computed against the menu PRICE, never against actual sales mix — nothing joins recipe cost to units sold, so there is no contribution-margin-per-item report. And while `target_food_cost` is a per-recipe threshold, no alert fires when an ingredient cost change pushes a recipe past it; the only threshold alerts in the extension are low stock and ingredient expiry. https://raw.githubusercontent.com/Paolorox/ti-ext-restapro/main/database/migrations/2024_01_01_000005_create_fc_recipes_table.php · retrieved 2026-09-10 adversarially verified

Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.

reporting-realtime-dashboard

Admin dashboard with chart widgets (best/worst sellers, top/bottom customers) reflecting live data, accessible in any browser including mobile. No dedicated mobile app. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.

reporting-eod-closeout

Resolved from `unknown`. The Reports extension ships a closed set of five report rules — Menu Items, Hourly Sales, Order Transactions, Discount Breakdown, and a generic Orders filter — and the widest of them, Order Transactions, defines exactly eight columns: order status, date, order id, menu id, quantity, menu item, amount, payment. Nothing reconciles a day. There is no gross-to-net line, no tax or tip total, no refund total, no tender-type summary and no expected cash deposit, which is unsurprising given the platform has no cash drawer: `drawer` , `till` , `closeout` , `end of day` and `Z-report` are zero across every corpus. The custom report builder could be pointed at these tables, but the tables hold no declared cash, so the reconciliation the claim asks for is not constructible either. https://raw.githubusercontent.com/igniter-labs/ti-ext-reports/master/src/ReportRules/OrderTransactionsRule.php · retrieved 2026-09-10 adversarially verified

Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.

reporting-pmix-modifier-level

Best Selling Items and Worst Selling Items datasets exist. Modifier/option-value level PMIX, and daypart or revenue-centre filtering, are not documented as built-in. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.

reporting-comps-voids-audit

No comp/void/override model exists to report on. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.

reporting-cash-over-short

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. There is no drawer, till, cash session or blind-count table, so declared-versus-expected cash cannot be reported. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.

reporting-labor-productivity

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. No clocked hours and no wage figures exist, so sales-per-labour-hour and labour percentage cannot be computed. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator

reporting-server-scorecards

https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator

reporting-channel-profitability

Shortfall: revenue by order type only — no margin, no marketplaces, no commission netting. Resolved from `unknown`: OrderRule declares order_type among its filter axes and carries order type and order total among its columns, so the Report Builder can split revenue between delivery and collection and export it, and HourlySalesReportRule and OrderTransactionsRule sit alongside it. But there is no dine-in channel (no POS) and no third-party marketplace connects at all, so those axes cannot exist; and margin is uncomputable in principle here — the 92-table schema holds only selling prices (menu_price, special_price, new_price, order_option_price) and carries no cost, commission or fee-basis column anywhere. https://api.github.com/repos/igniter-labs/ti-ext-reports/contents/src/ReportRules · retrieved 2026-09-07

Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.

reporting-scheduled-delivery

No scheduled report email delivery documented. The platform does have a task scheduler an operator could script against. https://tastyigniter.com/docs · retrieved 2026-08-01

Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator

reporting-public-api

ti-ext-api's registerApiResources() registers fifteen resources - categories, currencies, addresses, customers, locations, location_settings, menus, menu_options, menu_item_options, orders, reservations, reviews, tables, status and users (Staff) - each with a per-action authorisation context such as 'index:users, show:users, store:users, update:admin, destroy:admin' on orders; ti-ext-coupons adds `coupons` and ti-ext-webhook adds `webhooks`. It is free, self-serve and needs no agreement: tokens come from `php artisan igniter:api-token` or POST /api/token. Partial because payments and labour are not covered - ti-ext-payregister registers no API resource at all, so payment data is reachable only as a `payment_method` include on an order, and there is no labour data in the product to expose. Note that the published docs page under-lists, naming nine resources and omitting currencies, addresses, menu options, menu item options, tables, status and staff, and describing all nine with one blanket 'List, create, retrieve, update and delete' line. https://github.com/tastyigniter/ti-ext-api/blob/master/src/Extension.php · retrieved 2026-08-09 adversarially verified

Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator

reporting-webhooks

Re-sourced from the marketplace sell page to the extension's own manual. The free first-party Webhooks extension (Igniter Labs, MIT, built on spatie/laravel-webhook-server) documents a per-webhook 'Secret Signature: A secret key used to sign the webhook payload for verification', a configurable Webhook Signature Header Name, a Webhook Retry Count, a timeout, SSL verification and a Recent Deliveries log carrying status and response per attempt. The event catalogue is enumerated: Category, Customers, Menu items, Orders, Reservations and Tables, each on created/updated/deleted. Order lifecycle is covered; there is no discrete payment event, but no payment object exists separately from the order. https://github.com/igniter-labs/ti-ext-webhook/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator

reporting-api-not-upcharged

Read off the extension's own registration and boot code rather than the docs index: the entire access-control surface of ti-ext-api is the Igniter.Api.Manage admin permission, Sanctum token abilities (per-controller `$requiredAbilities`, e.g. `orders:*`) and a rate limit of 60 requests per minute keyed on user id or IP. There is no licence check, entitlement lookup, tier flag, seat count or usage meter in the extension. It installs with `composer require tastyigniter/ti-ext-api -W` and is listed Free on the vendor's marketplace (23,492 installs, 2026-08-09). No per-location fee, revenue share or enterprise contract exists because the platform sells no subscription tiers at all. https://github.com/tastyigniter/ti-ext-api/blob/master/src/Extension.php · retrieved 2026-08-09 adversarially verified

Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator

reporting-tier-paywall

Shortfall: nothing is tier-gated because there are no tiers, but two of the four report families the claim names do not exist at all. The Reports extension is free and documented, shipping a generic Report Builder (Tools > Report Builder, column selection, filter operators and input types, CSV export) plus four dashboard datasets - Best Selling Items, Worst Selling Items, Top Customers, Bottom Customers. Labor vs sales is structurally impossible (no labour data model); comps/voids audit is absent; PMIX and multi-location comparison are themselves only partial on this record. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-03 adversarially verified

Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator

reporting-history-retention

Shortfall: no documented retention window at all, and a thin reporting surface. The Reports docs describe four dashboard datasets (Best Selling Items, Worst Selling Items, Top Customers, Bottom Customers) plus a Report Builder under Tools, with report queries expressed as arbitrary Carbon ranges - the docs' own example is YourModel::query()->whereBetween('created_at', [$start, $end]) - so there is no built-in date cap. The core package also ships no pruning job (src/System/Console/Commands holds only extension, theme, install, update, up/down, passwd and util commands; the Purgeable trait is a form-field helper and Flame/Currency/Console/Cleanup touches exchange rates), and app/Console/Kernel.php schedules nothing. Retention is therefore bounded only by the operator's own database and no archive-retrieval fee can exist - but no vendor document states 24 months or any other window, and year-over-year comparison must be hand-built in the Report Builder rather than queried from a packaged report. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-02 adversarially verified

Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator

reporting-anomaly-alerts

No threshold or deviation alerting. The Automation engine could be scripted toward it by a developer. https://tastyigniter.com/docs/extensions/automation · retrieved 2026-08-01

Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.

reporting-nl-query

The Reports extension documents four built-in dashboard datasets (Best Selling Items, Worst Selling Items, Top Customers, Bottom Customers) plus a developer report builder with filter operators, column types and CSV export. There is no natural-language query box, no assistant and no AI/ML surface documented anywhere in the product. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-03

Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator

reporting-guest-cohorts

Top Customers and Bottom Customers datasets tie to identifiable customer records. New-versus-returning counts, frequency and lifetime-spend cohorts are not built in. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator

reporting-sales-forecast

https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.

reporting-tip-tax-compliance

Tips are captured and attribution is in principle derivable — a Tip cart condition adds a fixed or percentage guest tip at checkout into order_totals, and orders carry assignee_id — which corrects this record's old rationale. What does not exist is the report. The Reports extension's complete BUILT-IN rule set is five classes: DiscountBreakdown, HourlySales, MenuItems, Order and OrderTransactions; third parties may add rules, so five is a floor on rules, but the Report Builder can only filter and column over the axes a chosen rule declares, and no shipped rule declares an employee axis — OrderRule's filters are location, customer, email, customer group, date, time, order type, delivery address, categories and menus. Tokenised, 'tip', 'gratuity', 'staff', 'assignee', 'tax', 'payroll' and 'jurisdiction' occur zero times in that extension's source; the seven raw 'tip' matches are every one of them inside 'multiple'. No declared-versus-charged capture, tip-pool distribution or jurisdictional tax summary exists anywhere in the 92-table schema. https://api.github.com/repos/igniter-labs/ti-ext-reports/contents/src/ReportRules · retrieved 2026-09-07

Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.

multi-location-org-hierarchy

Locations are a flat list. Staff can be restricted to locations, but there is no region/group tier that reporting or permissions can be scoped to. https://tastyigniter.com/docs/extensions/local · retrieved 2026-08-01

A corporate-level menu can be authored once and published to a chosen set of locations in a single action, with a publish/version history showing what was pushed, when, and by whom.

multi-location-central-menu-publish

Menu items are single records with a location-selection field, so one edit reaches every assigned location — effectively central authoring. But there is no publish action, no version history, and no record of what was pushed, when, or by whom. https://tastyigniter.com/docs/extensions/cart · retrieved 2026-08-01

Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.

multi-location-price-zones

Resolved from `unknown` — the prior note left it open as 'not documented either way' , and the schema answers it. A menu item carries exactly one price column, `menus.menu_price` . Locations attach through the polymorphic `locationables` pivot, whose trait is a visibility scope that attaches and detaches records and carries no price override; the menus API returns the same `menu_price` whichever location is filtered on. `price zone` , `price tier` , `price band` and `price book` are zero across every corpus. The one axis that does vary a price on the same record is time, not place: `menus_specials.special_price` with a date range or a recurring schedule. https://raw.githubusercontent.com/tastyigniter/core/master/database/migrations/system/2015_03_25_000001_create_tables.php · retrieved 2026-09-10 adversarially verified

Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.

multi-location-consolidated-reporting

One install, one database, one admin view across all locations, so aggregate figures are available. Store-vs-store ranking and variance flagging are not shipped reports. https://tastyigniter.com/docs/extensions/reports · retrieved 2026-08-01

Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.

multi-location-cross-location-giftcard

Resolved from `unknown`. Cross-location redemption is structural rather than a feature: the Gift Up! settings form has exactly three fields — an info partial, a staging/live toggle and a single `api_key` — so an install has one Gift Up! account, and the redemption manager sends `'locationId' => null` , meaning a card is never scoped to a location and is redeemable at any of them. Shortfall on the rest of the claim, and it is most of it: balances live in Gift Up!, not TastyIgniter, so there is no outstanding-liability figure anywhere in the admin and no inter-store settlement or redemption reconciliation between owners. Gift cards are also not issued at a location in the first place — they are sold through a Gift Up! checkout component. https://raw.githubusercontent.com/igniter-labs/ti-ext-giftup/master/resources/models/settings.php · retrieved 2026-09-10 adversarially verified

A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.

multi-location-cross-location-loyalty

Customer accounts are install-wide, so a Loyalty Points balance would naturally span locations. Not verified in the extension's own documentation. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator

multi-location-multi-brand

The paid Multi Vendor extension ($149/yr) supports multiple distinct vendors with separate menus in one install. There is no shared terminal or drawer to separate, so the criterion only half applies. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.

multi-location-multi-tax-jurisdiction

Tax settings are per-location, and a free 'Tax Classes' extension adds VAT class management. Prepared-food versus grocery rules, inclusive/exclusive handling and per-location exemptions are not documented in detail. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.

multi-location-central-labor-policy

Complete admin migration set of tastyigniter/core (55 files, read through the GitHub contents API) enumerates every table the platform creates: locations and location_areas, menus/options/specials/mealtimes, orders, order_totals, order_menu_options, reservations and reservation_tables, staffs + staff_groups + staff_roles + locationables, stocks, payment_profiles, payment_logs, assignable_logs, working_hours and settings. There is no time-clock, shift, punch, break, pay-rate, till/drawer or payroll table anywhere, and src/Admin/Models contains only Staff.php, Status.php and StatusHistory.php. There are no labour rules to author centrally or enforce per location. https://api.github.com/repos/tastyigniter/core/contents/database/migrations/admin · retrieved 2026-08-03

The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator

hardware-commodity-devices

The vendor's download page states the whole requirement: 'PHP 8.1 or higher', 'MySQL 5.7+ or MariaDB 10.3+', 'Apache or Nginx'. It is a server-rendered Laravel application with no client binary, no vendor device and no certified terminal list, so the client is any browser on hardware the operator already owns. Note what the yes means here: the product ships no POS terminal software at all, so there is nothing proprietary to run. https://tastyigniter.com/download · retrieved 2026-08-03 adversarially verified

Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.

hardware-os-platforms

Shortfall: only the server side is specified, and the vendor's own pages disagree. The download page states PHP 8.1 or higher, while the application skeleton's composer.json requires php ^8.3 with laravel/framework ^12.0 and tastyigniter/core ^4.3 - two minor versions apart. Client operating systems, minimum browser versions and device specifications are published nowhere, because the vendor ships no client software and treats the client as any browser. https://github.com/tastyigniter/TastyIgniter/blob/master/composer.json · retrieved 2026-08-03 adversarially verified

Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.

hardware-handheld-purpose-built

No handheld device of any kind is sold, certified or listed. The product is a browser application; staff use whatever tablet or phone the operator already owns. https://tastyigniter.com/ · retrieved 2026-08-03

The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator

hardware-handheld-battery-swap

The vendor sells no hardware at all. The homepage positions the product as 'Free & open-source · Zero commission · Self-hosted' at '£0 - Self-hosted, forever free', and the site carries no hardware store, device catalogue, accessory page or compatibility list of any kind. No handheld exists, so battery life and hot-swap are not vendor-published facts. https://tastyigniter.com/ · retrieved 2026-08-03

Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.

hardware-handheld-lte

The vendor sells no hardware at all. The homepage positions the product as 'Free & open-source · Zero commission · Self-hosted' at '£0 - Self-hosted, forever free', and the site carries no hardware store, device catalogue, accessory page or compatibility list of any kind. No handheld and no vendor-supplied connectivity option, cellular or otherwise. https://tastyigniter.com/ · retrieved 2026-08-03

Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).

hardware-offline-mode

No terminal software and no offline capability. The vendor publishes nothing on degraded operation because there is no local runtime. https://tastyigniter.com/docs · retrieved 2026-08-01

Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.

hardware-kds

Shortfall: three of the claim's four elements are missing or partial. Kitchen Display is first-party (Igniter Labs) and free, with touch input, five configurable status columns, per-display Location/Order Type/Menu Category filters and real-time updates - though real-time requires separately installing the Broadcast extension. Bump-bar input is undocumented, station routing is order-level rather than item-level, and course/fire timing does not exist at all: the only timing control is a manual +15/+30/+45 wait-time bump. https://github.com/igniter-labs/ti-ext-kitchendisplay/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator

hardware-kiosk

https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.

hardware-drive-thru

The vendor sells no hardware at all. The homepage positions the product as 'Free & open-source · Zero commission · Self-hosted' at '£0 - Self-hosted, forever free', and the site carries no hardware store, device catalogue, accessory page or compatibility list of any kind. No order confirmation board, headset, loop detector or lane hardware is sold or supported. https://tastyigniter.com/ · retrieved 2026-08-03

Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.

hardware-printer-compatibility

Paid 'DocketPrint' extension ($75/yr) handles automatic order/docket printing. No published ESC/POS compatibility list, no named Epson or Star models, no LAN printer documentation. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.

hardware-peripherals

No cash drawer, barcode scanner, scale or customer-display support, and no compatibility list. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.

hardware-p2pe-terminal

No card-present entry at all; no PTS device, no stated SAQ type. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator

hardware-tap-to-phone

The vendor sells no hardware at all. The homepage positions the product as 'Free & open-source · Zero commission · Self-hosted' at '£0 - Self-hosted, forever free', and the site carries no hardware store, device catalogue, accessory page or compatibility list of any kind. No card-present acceptance path of any kind, so no SoftPOS/Tap to Pay offering on iPhone or Android. https://tastyigniter.com/ · retrieved 2026-08-03

Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator

hardware-pricing-transparency

Scored no because the criterion is literally unmet - there is no published device price list - but the reason is that the vendor sells no hardware at all, which is favourable to the operator rather than adverse. Read it alongside commercial-hardware-purchase-outright. https://tastyigniter.com/ · retrieved 2026-08-03

Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator

hardware-ownership-vs-lease

Shortfall: the vendor states nothing about hardware, because it sells none. The installation docs specify only server-side requirements - Apache with mod_rewrite or Nginx, PHP 8.3+ with bcmath/ctype/curl/dom/exif/gd/intl/json/mbstring/openssl/pdo_mysql/tokenizer/xml/zip, MySQL 8.0+ or MariaDB 10.6+, on shared hosting, VPS, Docker or a local machine - and the product is reached through a standard web browser. No vendor hardware programme exists, so no lease is possible and every device the operator runs on is bought outright from third parties; but there is equally no vendor terminal spec, no compatibility list and no purchase-versus-lease statement, which is what this claim asks the vendor to state. https://tastyigniter.com/docs/installation · retrieved 2026-08-02 adversarially verified

Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator

hardware-usable-after-churn

Shortfall: no vendor documentation addresses post-cancellation hardware use, because no device is ever purchased from the vendor. The nearest first-party evidence is the DocketPrint listing, which documents 'Multiple connection types: Local/USB thermal, Epson ePOS over the network, and raw ESC/POS over IP (port 9100)' - open, generic protocols on printers the operator sources independently, so no peripheral is vendor-provisioned or software-locked. Second shortfall: the extensions that drive peripherals are annual licences (DocketPrint $75/yr, the third-party POS $49/yr) and the effect of letting one lapse is undocumented, even though the MIT core is perpetual. https://tastyigniter.com/marketplace/item/igniterlabs-docketprint · retrieved 2026-08-02 adversarially verified

Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator

hardware-rma-sla

The vendor supplies no hardware, so there is no warranty term or exchange SLA to publish. The only warranty language it publishes is a disclaimer rather than cover: "We provide access and use of the Website on the basis that we exclude all representations, warranties and conditions to the maximum extent permitted by law", and the software ships under MIT's as-is clause. Printing goes to the operator's own Epson ePOS or Star CloudPRNT device through a helper application the operator installs. https://tastyigniter.com/terms-and-conditions · retrieved 2026-09-07

Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.

hardware-byod

Any staff device with a browser can reach the admin panel, and access is governed by the permission model with per-location restriction. But there is no documented BYOD security posture, no MDM story, and no core MFA (that is a $49/yr extension). https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator

hardware-remote-device-management

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. The vendor supplies no devices, publishes no fleet console extension, and has no enrolment, remote-update or lock/wipe surface. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Integrates with specialty beverage hardware — self-pour tap walls, flow meters, or liquor pour spouts — such that pours post to a POS tab automatically.

hardware-selfpour-scales

The vendor sells no hardware at all. The homepage positions the product as 'Free & open-source · Zero commission · Self-hosted' at '£0 - Self-hosted, forever free', and the site carries no hardware store, device catalogue, accessory page or compatibility list of any kind. No self-pour wall, RFID card, flow meter or scale integration is sold or documented. https://tastyigniter.com/ · retrieved 2026-08-03

Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.

hardware-callerid-integration

The complete public marketplace (47 extensions, retrieved today) and the complete core model set were both enumerated. No caller-ID, CTI or VoIP pop extension exists and core has no inbound-call surface — a real gap for the UK takeaway operators this product otherwise serves. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03

Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.

extensibility-public-api-docs

The page returns 200 to an unauthenticated fetch with no login, NDA, partner agreement or sales call, and documents installation, token issuance (POST /api/token with is_admin, email, password, device_name and an optional abilities array), `Authorization: Bearer` usage including the Apache .htaccess rewrite, the Igniter.Api.Manage permission, how to register custom resources, and a list of resource endpoints. Correcting the earlier wording: it is not a full API reference. There are no per-endpoint paths, parameter tables, payload schemas or status codes, and the resource list is incomplete against the code. The complete contract is readable only from the MIT source at github.com/tastyigniter/ti-ext-api. Note also that robots.txt disallows /api-docs/ for every user agent, so that path was not fetched. https://tastyigniter.com/docs/extensions/api · retrieved 2026-08-09 adversarially verified

API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator

extensibility-api-access-cost

The API extension is installed with `composer require tastyigniter/ti-ext-api -W` and is listed Free on the vendor marketplace (23,492 installs, 2026-08-09). Its source contains no licence key check, entitlement lookup, tier flag or usage meter; access is governed only by the Igniter.Api.Manage admin permission, Sanctum token abilities and a 60 requests-per-minute rate limit. There is no per-location fee, no surcharge and no plan upgrade because the core platform is MIT-licensed and sells no plans - the vendor's revenue is per-extension licences and monthly Premium Support, neither of which gates the API. https://github.com/tastyigniter/ti-ext-api/blob/master/src/Extension.php · retrieved 2026-08-09 adversarially verified

A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator

extensibility-free-sandbox

The whole product installs free locally from the documented Composer install, which serves as a sandbox in practice. But there is no hosted sandbox with seeded data, no test credentials issued on sign-up and no partner test tenant. https://tastyigniter.com/docs/installation · retrieved 2026-08-03

Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).

extensibility-oauth-partner-apps

Laravel Sanctum bearer tokens, scoped to abilities (e.g. orders.*), issuable per admin or customer context and individually revocable — better than a shared static key. But it is not OAuth 2.0: no authorisation-code flow, no operator consent screen for third-party apps. https://tastyigniter.com/docs/extensions/api · retrieved 2026-08-01

The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.

extensibility-webhooks-push

Shortfall: the event verbs are CRUD, not order lifecycle. Delivery is genuine push, and the catalogue is enumerated in the extension manual - Category, Customers, Menu items, Orders, Reservations and Tables, each wired to Eloquent created/updated/deleted events, with a second path through Automation Rules ('Send payload to Webhooks' with conditions). But there is no paid, voided or refunded event: a consumer must diff the order payload to infer those transitions. https://github.com/igniter-labs/ti-ext-webhook/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator

extensibility-webhook-reliability

Shortfall: no replay. Signing and backoff are both present, contrary to the earlier reading - the extension is built on spatie/laravel-webhook-server, whose signature is hash_hmac('sha256', payload, secret) in a configurable header, surfaced as a per-webhook Secret Signature plus a settable Webhook Signature Header Name, and whose default ExponentialBackoffStrategy retries three times at 10s/100s/1000s with the retry count exposed as a setting. What is missing is the third element: Recent Deliveries shows status, response code and payload, but no redeliver or replay action for a missed event is documented. https://github.com/igniter-labs/ti-ext-webhook/blob/master/docs/index.md · retrieved 2026-08-03 adversarially verified

A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.

extensibility-order-injection-api

Verified at the endpoint, not from the resource index. POST /api/orders is registered in ti-ext-api as `store:users` on the orders resource, guarded by the `orders:*` ability, and Orders::restAfterSave() attaches `order_menus` through addOrderMenus() (line items with their option values), `order_totals` through addOrderTotals(), applies `status_id` through updateOrderStatus(), and on `processed=1` calls markAsPaymentProcessed(), which dispatches OrderPaymentProcessedEvent - the same admin.order.paymentProcessed event the Cart extension registers as its OrderPlaced automation trigger. PATCH /api/orders/{orderId}/status is registered as a first-class route as well. The row created is an ordinary Order model, which is what the Kitchen Display boards (columns mapped to order statuses) and the Reports extension read, so an injected order is indistinguishable from a web order downstream. Auto-printing needs a separately paid extension (DocketPrint $75/yr or Star CloudPRNT $50/yr) for native and injected orders alike. https://github.com/tastyigniter/ti-ext-api/blob/master/src/ApiResources/Orders.php · retrieved 2026-08-09 adversarially verified

Menu items, modifiers, and prices can be written and updated via API, not just read. differentiator

extensibility-menu-write-api

Confirmed at source rather than from the published reference, which omits three resources. ti-ext-api 4.x ships seventeen resource controllers including Menus, MenuOptions and MenuItemOptions; Menus declares restConfig actions index, store, show, update and destroy behind requiredAbilities ['menus:*'], validated by Cart's MenuRequest. Modifiers and option values are writable, not just menu headers. https://github.com/tastyigniter/ti-ext-api/blob/4.x/src/ApiResources/Menus.php · retrieved 2026-08-03 adversarially verified

The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator

extensibility-doordash-preferred

DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means when it says the roster is tracked in real time, and it is a CENSUS rather than a floor: every provider integrated with DoorDash appears in it with a tier, so a vendor that is absent altogether is not in the programme at any tier. This vendor appears nowhere in the 64 entries, under any provider id or friendly name — checked mechanically against both fields, with the only near-misses being substring coincidences (Speedline against Lightspeed, vroom_restaurant against Restaurant365) that were read and rejected. SUPERSEDES the 2026 announcement post most of this corpus cited: that post introduces its ten names with the word `include`, which makes it a floor and never a ceiling, and reading it as a ceiling is what produced this cell's prior grade. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11

Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator

extensibility-first-party-delivery-integrations

No DoorDash, Uber Eats or Grubhub marketplace integrations exist, first-party or otherwise. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).

extensibility-middleware-compatibility

Resolved from `unknown`. Measured on the middleware's side, not TastyIgniter's. Deliverect publishes a per-system integration page for everything it supports — 617 of the 10,169 locs in its sitemap sit under `/en/integrations/` — and Chowly publishes a `/pos/chowly-for-<system>/` family. Both directories discriminate: Square, Toast, Lightspeed, Revel and Clover each resolve to a page on Deliverect, Lightspeed, Revel and Clover on Chowly, while a fabricated system name resolves on neither. TastyIgniter is absent from both, so it is a supported endpoint of zero of the two, not the two the claim requires. Two cautions recorded rather than leaned on: the seven `tasty` hits in Deliverect's sitemap are tastycloud and tastyfuture, different products; and ItsaCheckmate's sitemap lists Toast but not Square, so it is a floor and was not counted either way. https://www.deliverect.com/en/integrations/square · retrieved 2026-09-10 adversarially verified

Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.

extensibility-accounting-connectors

No QuickBooks Online connector and no other GL integration on the marketplace or in core. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.

extensibility-payroll-export

No payroll providers integrated, and no hours data to send them. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.

extensibility-app-marketplace

Public marketplace at tastyigniter.com/marketplace with browsable named extensions and themes, free and paid, advertised as '1-click easy to install' with no coding required and visible install counts. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.

extensibility-headless-embedded

The write API can drive orders from an external UI, and the theme layer is replaceable outright. But there is no documented headless mode or supported decoupled-frontend contract. https://tastyigniter.com/docs/extensions/api · retrieved 2026-08-01

A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator

extensibility-data-portability-exit

There is no exit. The operator already holds the complete database and the MIT-licensed source; orders, customers, menu and payment metadata are all directly queryable forever at no cost. https://github.com/tastyigniter/TastyIgniter · retrieved 2026-08-01

Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.

reliability-offline-order-entry

Server-rendered web application with no local runtime. Lose connectivity to the host and order entry stops entirely. https://github.com/tastyigniter/TastyIgniter · retrieved 2026-08-01

Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator

reliability-offline-card-auth

No store-and-forward. Gateway integrations are synchronous online calls. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator

reliability-offline-decline-liability

The claim asks for two published things and the vendor publishes neither. The complete Pay Register documentation states no per-transaction or cumulative offline cap and never addresses who bears a post-reconnect decline, because there is no store-and-forward path to reconnect from: all six gateway classes authorise synchronously. The merchant contracts directly with Stripe, PayPal, Square, Mollie or Authorize.Net, so any such term would be that processor's, not TastyIgniter's. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-09-07

Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator

reliability-lan-degraded-multi-terminal

There are no terminals to degrade. The published requirements are one Apache or Nginx host running PHP 8.3+ and one MySQL 8.0+ or MariaDB 10.6+ database; every client is a browser session against that single application, and all check state lives in the orders, order_menu and order_totals tables on that one server. The source tree contains no LAN peer service, no local write store and no second write path, so when the server is unreachable there is no degraded mode to fall into — there is nothing at all. https://tastyigniter.com/docs/installation · retrieved 2026-09-07

The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator

reliability-local-transaction-engine

This is the researcher constructing an offline story the vendor never makes. Offline is a flagged highest-bar cell. There is no local transaction engine — there is a server-rendered app that, if you happen to host it in the building, keeps serving LAN clients. The vendor documents no offline architecture, no degraded mode, no sync model, and the overwhelmingly common deployment is shared hosting. Inferring partial from a deployment topology is exactly the over-generosity we are correcting for. https://tastyigniter.com/docs · retrieved 2026-08-01 adversarially verified

Kitchen display and/or kitchen printer routing continues to function while offline.

reliability-offline-kds-printing

Same inference chain, same problem, and the researcher's own note concedes it is 'not a documented feature and not true for the common shared-hosting deployment'. A cell whose own justification disclaims itself should not score partial. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01 adversarially verified

The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.

reliability-printer-fallback

No backup printer failover or staff alerting documented for DocketPrint. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).

reliability-sync-conflict-handling

Nothing is documented because nothing partitions: a single MySQL database is the only writer of record and every device is a browser session against it, so there is no two-device offline edit to reconcile on reconnect. The vendor's developer documentation describes no merge, versioning, last-write-wins or operator-prompt behaviour anywhere, and no conflict-handling vocabulary appears on the product surface. https://tastyigniter.com/docs/installation · retrieved 2026-09-07

The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).

reliability-offline-feature-matrix

The vendor publishes no offline feature matrix anywhere in its documentation. https://tastyigniter.com/docs · retrieved 2026-08-01

A public, per-component status page exists showing current and historical incident state without a login.

reliability-public-status-page

No status.tastyigniter.com or equivalent is linked anywhere on the site. Partly structural - there is no vendor-run production service, since every install is the operator own - but the vendor also publishes no uptime history for the marketplace or update servers that installs do depend on. https://tastyigniter.com/ · retrieved 2026-08-03

24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.

reliability-247-live-support

Hard documented no. Support is weekdays 9am-5pm GMT only, and even that requires a paid plan starting at $80/month. There is no phone channel at all — email, Discord and GitHub only. Free users get community forum and Discord. https://tastyigniter.com/premium-support · retrieved 2026-08-01

The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator

reliability-onsite-install

The services page lists four offerings: an Installation service - 'We install TastyIgniter on your server, configure extensions and payments, apply your branding, and deliver an onboarding video' - plus Premium Support, quote-based Custom Development and Bug Fix sessions from $120. All of it is remote server work. No in-person go-live is offered anywhere on the site and there is no dealer or reseller network. https://tastyigniter.com/support/services · retrieved 2026-08-03 adversarially verified

The vendor performs the initial menu build as part of onboarding rather than leaving it entirely to the operator. differentiator

reliability-menu-build-service

The Premium Support page excludes menu migration and points to 'our installation & dev services'; that services page lists Installation (server install, extension and payment configuration, branding, onboarding video), Premium Support, Custom Development and Bug Fix sessions - no menu build. The initial menu build is left to the operator, or becomes bespoke quote-based development. Note the vendor's own pages disagree about whether menu migration is purchasable, and neither publishes a price. https://tastyigniter.com/support/services · retrieved 2026-08-03 adversarially verified

A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.

reliability-hardware-replacement-sla

Nothing is sold that could be replaced. TastyIgniter distributes software only — MIT core plus priced marketplace extensions — and the published commercial terms carry no equipment, replacement or advance-exchange obligation, only a blanket exclusion of "all representations, warranties and conditions to the maximum extent permitted by law". The paid Premium Support tiers cover weekday assistance with the software, not devices. https://tastyigniter.com/terms-and-conditions · retrieved 2026-09-07

The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.

reliability-pci-dss-4-attestation

No AoC, no P2PE listing, no compliance page. Self-hosted software shifts PCI scope onto the merchant and its host. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.

reliability-mfa-role-based-access

Upheld on the RBAC leg (core permission model is real), but strengthen the criticism: the 2FA extension is third-party (avisaas) at $49/yr with 0 installs. So MFA on the admin panel is not merely paid, it is unproven in the field. The dossier's conclusion is right and its evidence is weaker than it says. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01 adversarially verified

A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.

reliability-self-serve-training

Free public documentation, a help centre, a community forum and Discord are all open with no login. But there is no video/LMS training library and no practice or training mode. https://tastyigniter.com/docs · retrieved 2026-08-01

Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator

reliability-failover-terminal-role

No terminal roles exist, so none can be assumed. The published architecture is one PHP application server and one MySQL database with browser clients: there is no master or primary terminal, no local store server, no election or promotion mechanism anywhere in the source tree, and no first-party high-availability arrangement is offered. The single point of failure is the operator's own host, which is the operator's to duplicate. https://tastyigniter.com/docs/installation · retrieved 2026-09-07

Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.

reliability-cellular-backup

The vendor ships no terminals and no networking equipment, so there is nothing to give a cellular fallback to. The published requirements name only a web server, PHP and MySQL, and across the 397-page product surface (blog held out, 404s excluded) 'cellular' and 'LTE' each occur zero times while five controls fire — so no cellular failover, first-party or documented third-party, is offered or described. (The source tree's eleven 'lte' matches are Laravel's less-than-or-equal validation rule, not the radio technology; the count is named here because it is exactly the kind of substring that would otherwise read as a hit.) Connectivity is wholly the operator's hosting and in-store network arrangement. https://tastyigniter.com/docs/installation · retrieved 2026-09-07

Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator

commercial-month-to-month-contract

The core licence is MIT, verbatim 'Permission is hereby granted, free of charge, to any person obtaining a copy of this software' (copyright Samuel Adepoyigi). It is perpetual and has no term, so there is no contract to be locked into at all. Premium Support, the only recurring commitment the vendor sells, is published as 'billed monthly, cancel anytime' on all three plans. https://raw.githubusercontent.com/tastyigniter/TastyIgniter/master/LICENSE.md · retrieved 2026-08-03

Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator

commercial-no-early-termination-fee

An early-termination fee is structurally impossible on a perpetual, irrevocable, royalty-free MIT grant running on the operator own server; the vendor has no ability to switch the software off or invoice for stopping. Support plans are month-to-month with cancel-anytime stated. https://raw.githubusercontent.com/tastyigniter/TastyIgniter/master/LICENSE.md · retrieved 2026-08-03

The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.

commercial-autorenew-terms-published

Shortfall: monthly billing and 'cancel anytime' are stated on the plan cards and extension licences are priced per year, but no renewal date, no notice period and no auto-renewal clause is published in any MSA - there is no MSA. The Terms and Conditions cover website and marketplace use, not a subscription term. https://tastyigniter.com/premium-support · retrieved 2026-08-03

The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator

commercial-processing-not-bundled

Five gateways ship (Stripe, PayPal Express, Square, Mollie, Authorize.Net) plus a documented framework for building others. The vendor has no processing business, so there is nothing to lock the merchant into. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator

commercial-interchange-plus-published

The vendor publishes no processing rate of any structure because it is not in the payments business. Rate terms come from the merchant's chosen gateway. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator

commercial-rate-increase-clause

No processing agreement exists between vendor and merchant, so no rate-increase protection is offered — but equally no vendor can raise the merchant's card rate. Exposure sits entirely with the merchant's own processor contract. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).

commercial-pricing-published

Verified verbatim: Solo $80/mo 'Guaranteed 24-hour response time', Pro $240/mo at 12 hours, Enterprise $400/mo at 8 hours, all 'Billed monthly - cancel anytime', all weekdays 09:00-17:00 GMT, all 'Unlimited priority support via email, Discord, and GitHub'. Every marketplace extension carries a public price. Two presentation inconsistencies: the homepage now shows Premium Support as 'Custom' rather than the figures, and advertises extensions 'from GBP 29' while the marketplace quotes USD with $6 and $10 one-offs at the bottom. https://tastyigniter.com/premium-support · retrieved 2026-08-03 adversarially verified

Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator

commercial-module-unbundling

Literal, structural unbundling, with the count corrected. The org holds 30 repositories: fifteen live ti-ext-* packages (cart, socialite, payregister, local, coupons, user, translate, reservation, pages, frontend, broadcast, automation, api, plus debugbar and dusk which are developer tools), ti-theme-orange, core and the application skeleton; three ti-ext-* repos are archived (drivers, onlinetracker, eventrules). Roughly thirteen are operator-facing. All are MIT, separately versioned and independently installable or removable via Composer, and every paid capability is its own marketplace purchase on its own annual licence, so there is no bundle to reprice. https://api.github.com/orgs/tastyigniter/repos?per_page=100&sort=pushed · retrieved 2026-08-03 adversarially verified

All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.

commercial-hardware-purchase-outright

Shortfall: the 'at a published price' half of the claim is unmet and inapplicable. The vendor sells, leases and certifies no hardware, so there is no mandatory lease to avoid - but there is also no device catalogue, accessory list, compatibility matrix or hardware price anywhere on the site, marketplace or services pages. Every terminal, screen and printer is bought from a third party at that third party's price. https://tastyigniter.com/ · retrieved 2026-08-03 adversarially verified

Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator

commercial-hardware-not-locked

Shortfall: the only first-party hardware documentation is a paid extension's sell page. DocketPrint (Igniter Labs, $75/yr, 1 install) documents 'Local/USB thermal, Epson ePOS over the network, and raw ESC/POS over IP (port 9100)' - genuinely open protocols on printers the operator sources itself - but the extension is closed source with no public repository, no Packagist package and no documentation page, so the claim rests on grade-C marketing copy. The MIT core ships no printer driver and no cash-drawer support of any kind. https://tastyigniter.com/marketplace/item/igniterlabs-docketprint · retrieved 2026-08-03 adversarially verified

Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.

commercial-data-export-self-serve

OrderTransformer returns `order_totals` and `order_menus` (line items with their selected option values) for every order, with customer, location, address, payment_method, status, status_history, assignee and assignee_group as includes; the orders resource exposes index and show, reachable with an admin Sanctum token the operator mints itself (`php artisan igniter:api-token --admin`). The extension is free, so no ticket and no fee, and because the product is self-hosted and MIT the operator additionally has direct SQL access to the entire schema. Two limits worth stating plainly: the free Import & Export Tool's CSV path ships only menu import/export models in v4 despite a marketplace card naming Orders and Customers, and there is no payment-transaction or labour resource - payments appear only as a payment_method reference plus order totals, and labour data does not exist in the product. https://github.com/tastyigniter/ti-ext-api/blob/master/src/ApiResources/Transformers/OrderTransformer.php · retrieved 2026-08-09 adversarially verified

Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator

commercial-export-customer-and-loyalty

Shortfall: one of the claim's three data types is unconditionally exportable, one needs a paid add-on, one is not held by the platform at all. Customers are a first-class API resource with full CRUD and sit in the operator's own MySQL database. Loyalty point ledgers exist only if the operator has bought Loyalty Points ($30/yr, Igniter Labs, 6 installs) - a base install has no ledger. Gift-card liability is held by Gift Up!, an external SaaS reached through a free connector, so those balances cannot be exported from TastyIgniter at all. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-03 adversarially verified

Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator

commercial-post-termination-export-window

Shortfall: no contractual or documented retrieval window of any length. The Terms and Conditions provide for termination of website access but contain no clause on data retrieval, export or deletion afterwards; the Privacy Policy addresses only website-visitor personal data. What is documented sits upstream of the question: LICENSE.md is verbatim MIT, granting perpetual rights to use, copy and modify, and the installation docs place the application and its MySQL 8.0+/MariaDB 10.6+ database on the operator's own hosting, so there is no vendor-held copy to cut off. The operator's practical position is better than any published window, but the vendor publishes no window, so this is not a documented yes. https://tastyigniter.com/terms-and-conditions · retrieved 2026-08-02 adversarially verified

Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator

commercial-data-ownership-clause

I read both published legal documents linked from the site footer. The Terms and Conditions (governing law England and Wales) cover usage restrictions, prohibited activities, liability disclaimers, a 30-day marketplace refund guarantee and a right to terminate website access for non-payment or breach - they contain no statement of who owns merchant transaction or customer data and no constraint on vendor use or resale of it. The Privacy Policy governs tastyigniter.com website visitors only ('We will not share any of your personal data with any third parties for any purposes') and does not reach data held in a self-hosted installation. LICENSE.md is the plain MIT text and concerns the software only. So no published data-ownership clause exists. This means 'no clause is published', not 'the vendor takes your data': under self-hosting the vendor never receives it, but that protection is architectural rather than contractual, and a Premium Support engagement explicitly grants the vendor admin access to the operator's installation. https://tastyigniter.com/terms-and-conditions · retrieved 2026-08-02 adversarially verified

Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.

commercial-pci-p2pe-tokenization

Gateway tokenisation via payment profiles keeps PANs off the merchant's systems, and hosted gateway fields reduce scope in practice. But the vendor names no applicable SAQ, publishes no P2PE validation, and self-hosting means the operator owns the assessment. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01

Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.

commercial-pci-dss-4-controls

Fails on both named controls: MFA on admin access is not in core (paid $49/yr extension only), and the vendor documents no payment-page script-integrity monitoring for Req 6.4.3 / 11.6.1. https://tastyigniter.com/marketplace/extensions · retrieved 2026-08-01

Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.

commercial-privacy-dsar-tooling

Admin can delete customer records under a discrete permission, and self-hosting gives complete access to locate and export any individual's data. But there is no DSAR workflow, no deletion-propagation guarantee across extensions, and no published DPA — arguably no DPA is needed since the vendor is not a processor of operator data. https://tastyigniter.com/docs/extensions/user · retrieved 2026-08-01

Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator

commercial-wcag-kiosk-accessibility

No VPAT, no ACR and no WCAG conformance claim for the consumer ordering surface anywhere on the site or in the docs. There is no kiosk at all, so the kiosk half of the criterion cannot be met either. https://tastyigniter.com/ · retrieved 2026-08-03

POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator

commercial-dual-pricing-compliant

No dual pricing, cash discount or surcharging engine exists, so none of the debit-exclusion or disclosure requirements are met. https://tastyigniter.com/docs/extensions/payregister · retrieved 2026-08-01