Flipdish

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

CLAIM: graphical floor-plan editor with sections, tables of varying shape/capacity, MULTIPLE saved layouts per location, and sections assigned to servers. VERDICT: partial. EVIDENCE: 'Set Up Your Table Layout and Floorplan' (https://help.flipdish.com/en/articles/9585182, dated April 14 2025) documents a real drag-and-place editor at portal.flipdish.com under Properties > Settings > Restaurant Layout, requiring Owner or Managed Owner access: "Find the correct table type from the options on the floating box. You can also pick a colour here. Click once where you want to put it. Click on the number to rename the table"; "Click the table in question. You'll get a menu to change the appeareance. You can also delete the table here"; "If you have more than one room, floor or area in your store you may wish to create Zones. To do this ... Click on 'Manage Zones'." A second, separate editor serves the QR product - 'Configure Your QROP Seating Plan' (https://help.flipdish.com/en/articles/9585334): "You will have the possibility to configure and set up your store floor plans straight in the Flipdish portal. The floor plan that you set up in the portal will be reflected in real-time in the product", with named Sections ("All tables must belong to a Section: Indoor, Outdoor, Upstairs etc"), bulk creation ("Select how many tables you want to create") and alphanumeric table names. SHORTFALL: exactly one layout per property is described and Save overwrites it - no multiple named saved layouts; table CAPACITY is not a table property (covers are entered per order at the till); and no section is assignable to a server - server attribution is per-order ("Select your server from the drop-down menu at the top", https://help.flipdish.com/en/articles/9585200). BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585182 · retrieved 2026-09-17 adversarially verified

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

CLAIM: order lines can be tagged to a seat number at entry, and the check split by seat afterward without re-keying items. VERDICT: no. EVIDENCE: the dine-in order-entry manual (https://help.flipdish.com/en/articles/9585200) takes orders at table granularity only - "Choose Server and Assign Table: Select your server from the drop-down menu at the top. Click on the table in your floor plan to add COVERS ... Add items to the order and the table's tab" - covers are a headcount entered against the table, never a per-line attribute, and no seat picker appears at any step of order entry or payment. The two split articles (https://help.flipdish.com/en/articles/9585190, https://help.flipdish.com/en/articles/9585222) offer only item selection and amount entry. CONTROLS: 'seat number' 0, 'per seat' 0; 'seat' 17 hits, every one either 'seating plan'/'seating' (the QROP article) or a kiosk dine-in label - zero attach a seat to an order line. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585200 · retrieved 2026-09-17 adversarially verified

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

Flipdish's POS back office (rms.portal.flipdish.com) assigns courses per menu item. The item and modifier tag dialogues show a <KdsCourseNameTagComponent caption="KDS Course Name Tags" hintText="Select KDS course name tags for menu item"> stored as sourceConfiguration.kdsConfiguration.kdsCourseName (views/modules/menus/menu/categories/category/CategoryItemTagsDialogue.js, .../modifiers/modifier/ModifierItemTagsDialogue.js; chunk 9565.0be7035c). A tag of type KDSCourseName ("KDS Course Name", utils/domain/constants.js, main.cc20af4c.js) needs a sequence: "Enter sequence of the Course Name. Smaller number will be printed first. (Required)" (views/setup/system/lookups/tags/Tag.jsx, chunk 3413.47948fe5). Met: items are assigned to courses, and courses print in sequence. Missing: any hold state, and any fire-next-course action from a handheld or terminal. This matches the existing kitchen-course-firing partial. https://rms.portal.flipdish.com/static/js/9565.0be7035c.chunk.js · retrieved 2026-09-15 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

CLAIM: split by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, plus merging checks or tables, including after partial payment. VERDICT: partial. EVIDENCE - BY ITEM: 'Split Payments by Item with Your Flipdish POS' (https://help.flipdish.com/en/articles/9585190): "Select the items from the list that the first customer wishes to pay for ... Click 'Yes' in the pop-up box to confirm that you understand this is just a partial payment ... the paid-for items will have a tick beside them. Repeat this process if there are more than two customers." BY ARBITRARY AMOUNT: 'Split Payments by Payment Type with Your Flipdish POS' (https://help.flipdish.com/en/articles/9585222): "Enter the cash amount and then click the 'cash' button at the top of the screen. (This leaves the outstanding balance, shown in the top left corner). Now we enter the remaining balance using the digit buttons." MERGE: 'Manage Dine-In Open Table Tabs' (https://help.flipdish.com/en/articles/9585200): "Click on the table in your floor plan to add covers. Hold down on a second table to merge, then use the plus button to add covers." AFTER PARTIAL PAYMENT: covered by the tick-and-repeat flow above, which explicitly confirms a partial payment and returns to the order summary. SHORTFALL: no split BY SEAT (no seat concept exists - see order-capture-seat-level) and no even N-WAY split control; the N-person case is documented only as repeating an item selection or keying amounts by hand, and no percentage split is offered. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585190 · retrieved 2026-09-17 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

CLAIM: opens a bar tab against a card pre-authorization with a configurable auth amount, incremental re-auth as the tab grows, and auto-close of stale tabs at end of day. VERDICT: no - zero of the three conjuncts, against the article that documents the whole tab lifecycle. EVIDENCE: 'Manage Dine-In Open Table Tabs' (13 Apr 2025) is a complete step-by-step of an open tab and never touches a card until the customer asks to pay: 'Login: Begin by logging into the point-of-sale system using your five-digit PIN code. Select Dispatch Type: Choose Dine-In... Choose Server and Assign Table: Select your server from the drop-down menu at the top. Click on the table in your floor plan to add covers. Hold down on a second table to merge, then use the plus button to add covers'; items are added to 'the table's tab'; then 'Print Bill/Check... When the customer wishes to pay'; 'Splitting the Bill (if necessary)'; 'For cash payment, enter the amount... For card payment, click the credit button. The total cost appears on the card machine screen.' The tab is opened by selecting a table, not by holding a card. 'What payment types are accepted by the Flipdish Point of Sale?' enumerates the whole payment surface as 'cash, card, and cash/card combinations' and says card is 'Only available if you have a functioning card reader connected'. CONTROLS: `pre-auth`/`preauth` 0, `preauthoris*` 0, `incremental` 0, `bar tab` 0, `open tab` 0 across all 518 articles - and the v1.0 API's PaymentAccountType enum is closed at Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken with no authorisation/capture split. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585200-manage-dine-in-open-table-tabs · retrieved 2026-09-17 adversarially verified

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

CLAIM: an open check can be transferred between servers, tables and devices, and the transfer is recorded in an audit log naming both employees. VERDICT: no. EVIDENCE: the dine-in tab lifecycle article assigns a server once, at order start ('Select your server from the drop-down menu at the top'), and the only table-level manipulation it documents is merging at that same moment ('Hold down on a second table to merge'); there is no step, anywhere in the 518 articles, that moves an existing tab to another server, table or device. CONTROLS: `reassign*` 0, `move order` 0, `switch table` 0, `change table` 0; `merge*` scores 2 in total (this article, plus an unrelated FAQ) and `transfer*` scores 16, every one of them money - bank transfers, payout transfers, a chargeback transfer. The audit surface is now measured rather than assumed, and it is the wrong shape twice over: the only order-log statement Flipdish publishes is 'Will I be able to see each Order Status change in the logs? If updated manually, will we see the user who updated it?' (17 Jul 2026) - 'Yes, orders that have changed states manually and via automation will be available in the logs. Automated state changes will be marked as made by Flipdish, manual changes will be marked as made by whomever the authenticated user making the change was. Note: Please, notice that these logs are available for online ordering orders' - so it is a STATUS log, scoped to ONLINE ordering orders, not to dine-in tabs, and it names one user not two. The portal's Audit Logs are configuration-level: 'Audit logs track what settings have been changed and by which teammate in your account... Main - Shows Audit logs for items around the majority of the portal configuration, such as bank accounts, sales channels, teammates, online ordering, apps, kiosk configurations and settings. RMS - Shows Audit logs for items around your organisation and your POS configuration and settings' with filters 'sales management, menu management, property management, staff management' - settings, not order handovers. There is no dedicated audit-log article among the 518. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585200-manage-dine-in-open-table-tabs · retrieved 2026-09-17 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

Verified verbatim: 'All-in-one device for taking orders and payments' with 'built-in payment terminal and printer', 'bring the ordering and payment experience directly to the customer', and a 'Tipping Prompt'. hardware-handheld-lte likewise verified: 'built-in SIM connectivity means it keeps working wherever you need it.' Confirmed no battery life, no drop/IP rating, no price and — notably — no offline capability claim, so the offline unknowns are correctly left open. https://www.flipdish.com/handheld-pos · retrieved 2026-08-01 adversarially verified

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

Upheld, and re-homed off the quarantined help.flipdish.com FAQ onto two hosts this sweep may read. Flipdish's three POS product pages -- /pos-system, /pos-system/hardware and /pos-system/order-management, 21,069 stripped characters together, fetched 2026-09-09 -- contain the tokens `offline`, `internet` and `connection` ZERO times each; the product is sold purely as cloud POS. Independently, the developer surface has no offline construct either: a fresh crawl of all 96 live pages in developers.flipdish.com's 98-URL sitemap (542,871 chars) returns `reconnect` 0, `store and forward` 0, one `queue` hit in the webhooks page and exactly ONE `offline` hit, which is a FALSE FRIEND -- the `sales_channel.snoozed.v1` event, "A sales channel is snoozed (temporarily taken offline)". Matcher proven in the same run (`flipdish` 96 of 96, a nonsense control 0). Recorded as a floor on the API side, since an ingestion contract is not where a terminal's offline mode would be documented; the load-bearing evidence is the product pages' silence plus the sibling offline cells in this record, which were read on 2026-08-04 before the policy bar and quote the vendor directly. Grade C: vendor product pages. https://www.flipdish.com/pos-system · retrieved 2026-09-09

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

CLAIM: guest QR at-table ordering writes items onto the SAME open check as server-entered items rather than creating a separate ticket. VERDICT: no - the vendor says the opposite in its own FAQ. EVIDENCE: 'Table Ordering and QR Code FAQ' (https://help.flipdish.com/en/articles/9585439): "Can I get the orders assigned to the tables I have set up on our POS? - Not at the moment, the table numbers are going to your POS as a NOTE. They will be printed on your receipts and depending on your setup they can go to your Kitchen Screens as well." The same FAQ: "Can my customers open a tab and pay at the end of their meal? - No, customers must pay in advance for their order unless they choose to pay cash and not card", and the recommended service pattern is "to have staff visit tables regularly to prompt the customer to RESCAN the QR code to place additional drinks and dessert orders" - i.e. every scan is a fresh, separately-paid order, not an addition to an open check. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585439 · retrieved 2026-09-17 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

First-party kiosks run the same online-ordering menu as Flipdish websites; accessibility is an aspiration (WCAG 2.1 AA / EAA) with no ACR and admitted gaps. https://www.flipdish.com/online-ordering/kiosks · 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

The v1.0 Order schema assigns a pickup point to each order: DropOffLocationId and DropOffLocation ('Represents table service drop off location'), an OrderDropOffLocation object of {OrderId, LocationId, LocationAreaId}, PickupLocationType TakeOut|TableService|DineIn, and a closed TableServiceCatagory enum of Generic, Villa, House, Room, Area, Table, ParkingBay, Gate, DriveThrough, Team. The receipt payload echoes it as TableServiceCategory plus PickupLocationOptionValue (/v1.0/reference/getreceipt). So a drive-through window or a numbered parking bay can be assigned to an order and printed - the pull-forward/parking-spot leg of the claim. Named shortfall: that is the whole of it. DeliveryType is a two-value enum (Delivery|Pickup), so there is no order-point / pay-window / pickup-window separation; nothing in the 1,064-page v1.0 reference or the 99-page v3.0 reference models a lane, a tandem-lane assignment or an order sequence, and no pull-forward action exists as an operation. Flipdish's own hardware page (www.flipdish.com/pos-system/hardware) lists no drive-thru peripheral. Scored on the API surface; the merchant manual (help.flipdish.com) is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getorderbyid · retrieved 2026-08-09

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

order-capture-drive-thru-timers

CLAIM: captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders. VERDICT: no. EVIDENCE: 'Configure Drive-Through Collection' (https://help.flipdish.com/en/articles/9689466) is the whole of the drive-through feature and it is a pickup-LOCATION feature, not a timing one: "Your restaurant does not need to have a traditional 'drive-through' window or setup to activate this option. We can create a customized list of locations to suit your store's set-up and location" (examples: "Zone A", "Car park spot A2837"); its only throughput advice is "we strongly recommend enabling order throttling", and enabling it requires emailing Flipdish. ENUMERATION: the help centre carries one article per report and this census holds all of them - Overview, Sales, Sales Summary, Sales Tax, Store Operations, Business Review, Performance Summary, Customers, Ordered Items, Orders, End of Day, Campaign Performance, Tips and FPM, plus 25 POS/RMS reports (Sales Overview, Hourly Sales, Hourly Reporting Tags Sales, Menu Items Sales, Sales by Product, Sales by Driver, Reporting Tag Sales, Sales Discounts, Sales Refunds, Menu Item Refunds, Sales VAT, Sales Projections, Till Status, Venue, Venue Commissions, Upselling Points, Staff Meals, Guest Meals, Freebies Meals, Fixed Costs, Costs Overview, Daily Payroll Costs, COGs Summary, Wastages, Discrepancies) - none is a speed-of-service, lane or timer report. CONTROLS: 'drive-thru' 0, 'speed of service' 0, 'bump time' 0; POISON: 'timer' 2 hits, both a kiosk sleep timer; 'drive through'/'drive-through' 12 hits, all inside 9689466 and the kiosk-configuration article. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9689466 · retrieved 2026-09-17 adversarially verified

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

Upheld on far better evidence than the researcher used. Citing https://www.flipdish.com/phone-agent-draft — a '-draft' slug — was a real sourcing failure. But the product is corroborated by a company newsroom release (GlobeNewswire, 19 Nov 2025, launched at Dished Live '25): 'available now for restaurant and takeaway operators in the UK, Ireland, and select international markets', answers calls, confirms modifiers and delivery details, upsells, 'takes secure payment during the call', integrates with Flipdish POS, kitchen printers and loyalty. Two caveats the dossier omits: it is geographically https://www.globenewswire.com/news-release/2025/11/19/3190837/0/en/flipdish-launches-ai-phone-agent-to-ensure-every-call-becomes-an-order.html · retrieved 2026-08-01 adversarially verified

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

Partial: the documented load-management mechanism is snooze, not throttling. Flipdish exposes it in both directions - inbound events menu.item.snoozed.v1 / unsnoozed.v1 and sales_channel.snoozed.v1 / unsnoozed.v1 'with optional expiry', and outbound Operations Updates endpoints POST .../item-snooze-status and POST .../store-snooze-status whose only payload field is requestedStatus, 'Snooze or UnSnooze'. www.flipdish.com/pos-system/order-management markets the same thing: 'pause sales channels directly from the POS when things start heating up'. Named shortfalls: snooze is binary on/off per item or per sales channel, so there is no per-channel capacity limit, no per-time-slot order quota, and no automatic quote-time extension when kitchen load crosses a threshold - the corpus contains no capacity, throttle, quote-time or prep-time field anywhere, and requestedFulfillmentTime plus desiredAsap is the only fulfilment-timing input. Note the Operations Updates endpoints and v3 webhooks are in closed beta ('Email integrations@flipdish.com to request access'). https://developers.flipdish.com/docs/build-a-marketplace-integration.md · retrieved 2026-08-09

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

Help Centre: scheduled/pre-orders sit in a Pending state and, with 'Automatically print KOT when an order becomes active' enabled, the Kitchen Order Ticket 'prints only when the order becomes Active' — the doc's own example is a 4:00 PM order for 6:00 PM delivery printing 'closer to the scheduled preparation time'. Pre-ordering is configured per channel with wholly independent collection and delivery settings — lead time, order interval, capacity limits, days-in-advance (e.g. 2 or 30) and an order cutoff time ('Configure Pre-Ordering', help article 9585385) — and POS lead times support per-dispatch-type, per-day/time overrides (article 9585541). Caveat: fire-at-time KOT printing is a setting, not the default; without it the KOT may print on receipt. https://help.flipdish.com/en/articles/13941944-automatically-print-kot-when-an-order-becomes-active-in-pos · retrieved 2026-09-17

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

CLAIM: a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue. VERDICT: no. EVIDENCE/CONTROLS: 'catering' = 1 hit in the 518-body census and it is POISON (a sample address-rejection message naming a store "Mexican Catering"); 'balance due' 0, 'event schedule' 0; 'quote' hits are all sales-team price quotes for hardware, and every 'deposit' hit is a bank payout or the till Cashing Up deposit (https://help.flipdish.com/en/articles/9585298). The complete documented set of dispatch types is delivery, collection, dine-in, kiosk, drive-through collection and scheduled pre-orders, all of which land in the single order queue. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9689466 · retrieved 2026-09-17 adversarially verified

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

The marketplace integration guide documents the exact signal: a marketplace subscribes to sales.pos.status.updated.v1, described as 'Kitchen / POS state changed (e.g. SALE_PREPARED_BY_KITCHEN)', and the worked payload carries orgId, propertyId, salesChannelId, saleId, the marketplace's own externalId and "status": "SALE_PREPARED_BY_KITCHEN". The testing section ties it explicitly to in-store state rather than a tablet tap: 'push a real sale ... and confirm you receive sales.created.v1 followed by sales.pos.status.updated.v1 as the merchant's POS / kitchen progresses'. The successor event sale.status.updated.v1 unifies POS and delivery status and carries the same SALE_PREPARED_BY_KITCHEN value for sales on any channel (/docs/sale-events). Caveats: DoorDash specifically is not a Flipdish marketplace channel - the sales-channel type enum names UberEats, JustEats and Deliveroo - and the newer sale.* family is in closed beta, while the sales.* family that carries this event is generally available but marked 'Deprecating soon'. https://developers.flipdish.com/docs/build-a-marketplace-integration.md · retrieved 2026-08-09

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

Permissions gate who can 'give freebies or discounts'; reason codes and an exception report are not documented. https://www.flipdish.com/pos-system · retrieved 2026-08-01

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

The published menu schema makes modifier nesting recursive and unbounded, with independent selection counts at each level. ModifierResponseSchema carries min ('The minimum number of items that can be selected'), max, canSameItemBeSelectedMultipleTimes and hiddenInOrderFlow; it extends ContainerResponseSchema whose items[] are CategoryItemResponseSchema, and those items themselves carry modifierMembers[], each with its own nullable min and max plus parentModifierId - so an item inside a modifier group can reference further modifier groups without limit. The docs say so outright: modifierItems allow 'any depth of nesting (e.g. a pizza item -> size modifier -> topping modifier -> extra-cheese modifier)' and 'Nested modifiers (recursive - same structure at any depth)', restated in prose in the Sales Management API guide as 'Items nest recursively ... so any depth of modifier ... is expressed as nested items'. Forced selection is expressed as min >= 1 rather than a separate boolean flag; this record's existing modifier evidence independently describes portal-side nesting ('nesting a new modifier inside a size option (Level 2)') and min/max controls. Note all Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

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

Positive absence: the AI Menu Editor modifier guide gives each modifier option a single price plus tax, and the pricing guide (article 14484417) varies prices only by dispatch type and price band — never by parent item or selected size. Reusing a modifier links it to another item with identical option prices, and the documented mechanisms for per-parent variation are 'Deep copy / Deep paste' of the whole modifier group or nesting a new modifier inside a size option (Level 2) — exactly the duplication the claim excludes. The enumerated 'Additional settings' (multiple selection, hide group in order flow, conditional modifiers) contain no price matrix. https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-09-17

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

menu-pricing-fractional-placement

Positive absence in the vendor's own menu model. The Menu Management schema gives a modifier member parentModifierId, caption, min, max, enabled and canSameItemBeSelectedMultipleTimes, and gives a modifier item pricingProfiles keyed by priceBandId with four dispatch-type prices - there is no placement, position, section, portion, half, quarter or fraction attribute anywhere, and the same is true of the sale line schema (menuItemId, quantity, unitPrice, notes, modifierItems), which the docs describe as the one PublicSale object used for creation, retrieval and webhooks. Flipdish's own canonical pizza example in the same docs is flat - 'a pizza item -> size modifier -> topping modifier -> extra-cheese modifier' - with no notion of which side a topping lands on, so a half-topping has nowhere to travel except the free-text notes field. This record independently carries menu-pricing-half-and-half-rule as a grade-B no from the vendor's modifier documentation ('No half-and-half pricing rules (charge higher, average, per-section) documented anywhere'). The only available construction is duplicated per-section modifier groups, which is the workaround this claim excludes. Hedge: Menu Management endpoints carry a Beta Notice, and the merchant-facing manual is excluded from this sweep by policy. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

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

Positive absence: Flipdish modifier system allows single price per option, per-dispatch-type variants only. No half-and-half pricing rules (charge higher, average, per-section) documented anywhere. https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-09-17

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

Positive absence: the modifier guide's enumerated settings offer only 'Enable multiple selection — allows customers to select the same option more than once', which is precisely the add-the-modifier-twice model this claim distinguishes from tiering. No light/regular/extra/double tiers and no per-tier price multiplier appear anywhere in the AI Menu Editor documentation; option pricing is a flat per-option price with per-dispatch-type variants only (article 14484417). https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-09-17

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

Positive absence. In the published menu model an item's entire pricing surface is pricingProfiles[], and each profile is keyed by exactly one priceBandId and carries exactly four base prices - collectionPrice, deliveryPrice, dineInPrice, takeawayPrice - each with its own taxable/tax and upselling-points fields. The axes are therefore price band and dispatch type; there is no variant, option-set, matrix or grid construct, and no per-cell price override on a base item. Size and style are modelled as ordinary modifier groups whose options each carry their own flat price, so a Large-Thin cell cannot be priced independently of a Large-DeepPan cell except by building a second modifier group nested inside each size option - duplication, not a grid. This record independently carries menu-pricing-modifier-price-by-parent-size as a grade-B no from the vendor's own modifier and pricing guides, which 'var[y] prices only by dispatch type and price band - never by parent item or selected size' and whose enumerated additional settings 'contain no price matrix'. Hedge: Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

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

Positive absence: the modifier guide's only quantity controls are minimum/maximum selection counts ('Minimum = least number of options a customer must pick'), and option pricing is a flat per-option price. No included-modifier allowance, first-N-free overage-only charging, or substitution credit/forbid configuration appears in the enumerated modifier settings (min/max, multiple selection, hide group, conditional modifiers) or in the pricing surface (base price, price by dispatch type, price bands — article 14484417). https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-09-17

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

The v1.0 Menu API builds meals out of option sets. A MenuItemOptionSet carries MinSelectCount ('Minimum items must be selected'), MaxSelectCount, DisplayOrder, and IsMasterOptionSet - documented verbatim as 'Usually it is true if the option could be considered a standalone item as opposed to an addition ("with ketchup") or modifier ("large")'. Each MenuItemOptionSetItem carries its own Price, its own TaxRateId/TaxValue, IsAvailable, and NextMenuItemOptionSetId ('if null, next option set is next. if -1, this is the final option set'), so an operator can compose a meal from standalone components and swap each one at its own price delta, in a defined sequence. Named shortfall: the second half of the claim has no representation at all. Neither the 1,064-page v1.0 reference nor the 99-page v3.0 Menu Management schema defines a combo, meal, bundle or set entity (a v3.0 menu is exactly categories[], modifiers[] and categoryGroups[], the latter documented as cosmetic UI grouping), and nothing expresses a cart rule. The v1.0 VoucherType enum is closed at PercentageDiscount, LumpDiscount, AddItem, CreditNote and FreeDelivery, and the v3.0 sale discount type enum at Voucher|Loyalty|Spot|Other applied sale-level only - so automatic detection of eligible a-la-carte items in the cart and conversion to a combo price is not a documented behaviour in either version. Scored on the API surface; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getmenuitemoptionsetbyid · retrieved 2026-08-09

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

'Menu upsells automatically show your customers other popular items' on kiosk and online; no per-channel rule config or attach-rate reporting documented. https://www.flipdish.com/online-ordering/kiosks · retrieved 2026-08-01

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

Menu Management API v3.0 (beta): POST /menuManagement/orgs/{orgId}/menus/{menuId}/snoozes snoozes an item or option with snoozeStart, snoozeEnd ('Time period of the snooze in seconds') and an optional propertyIds array - 'If omitted, the snooze applies to all properties using the menu'. The snooze is held on the menu, and a sales channel carries a required menuId, so one 86 reaches every channel bound to that menu; menu.item.snoozed.v1 and sales_channel.snoozed_menu_items.updated.v1 broadcast it to subscribers. No propagation latency is published anywhere in the v3.0 corpus, nothing states that KDS receives it, and the endpoint carries the standing 'Beta Notice: this endpoint is currently in beta and may change or be deprecated at any time without notice'. https://developers.flipdish.com/reference/post__menumanagement_orgs__orgid_menus__menuid_snoozes_12 · retrieved 2026-08-09 adversarially verified

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

Vendor's own FAQ states the limitation: 'At this time, no, there is no notification when an item is almost out of stock. It is the responsibility of the admin to manage the inventory through the Flipdish Portal and send order requests to their suppliers as necessary.' 86ing is the manual Menu Snooze flow — snooze an item 'for a preset amount of time or leave it in Manual to snooze it indefinitely' (article 9585219). A timed un-snooze exists, but no per-item countdown/par count that decrements on sale and auto-86s at zero is documented anywhere in the menu or inventory docs. https://help.flipdish.com/en/articles/9585304-are-staff-notified-when-an-item-is-out-of-stock-or-almost-out-of-stock-when-using-the-flipdish-point-of-sale · retrieved 2026-09-17

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

Availability scheduling is real and precisely specified; price scheduling is not. Both CategoryItemResponseSchema and CategoryResponseSchema carry availabilityOverrides[], each override having name, enabled, mondayEnabled through sundayEnabled, fromTime and toTime (example '10:00'), plus optional scoping by dispatchTypes (DineIn|TakeAway|Collection|Delivery), propertyIds and venueCodes (Property|MobileApp|WebApp|Deliveroo|UberEats|JustEats|ExternalApp|Flipdish); the marketplace integration guide maps availabilityOverrides[] to 'Day-and-time availability rules'. Whole menus are scheduled a level up through opening-hours endpoints per property and per sales channel, and a property record carries an IANA timeZone (example 'Europe/Dublin'). Named shortfalls: (1) no price can be scheduled - an item's pricingProfiles are keyed by priceBandId with four fixed dispatch-type prices and carry no day, time or date dimension at all, so a timed price change means republishing the menu or reassigning the channel's price band; (2) the schema does not state which timezone fromTime/toTime are evaluated in, so the claim's 'in the location's own timezone' is documented for the property record but not for override evaluation. Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

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

Menu Structure v3.0: 'Each item (CategoryItem or ModifierItem) can have multiple PricingProfiles, one per price band. Each profile defines separate prices for four dispatch types: Collection, Delivery, DineIn, and TakeAway.' Binding is per channel: the SalesChannel schema (GET /orgManagement/.../salesChannels/{id}) lists priceBandId and menuId as REQUIRED fields, and the channel type enum is POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats, Deliveroo - so each marketplace listing can be priced off its own band. Shortfall: prices are entered per item per band (the PriceBand object is only id/name/code/notes); no percentage-markup or derived-price rule appears anywhere in the v3.0 or v1.0 corpora, and the endpoints are beta. https://developers.flipdish.com/docs/menu-structure-v3 · retrieved 2026-08-09 adversarially verified

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

The documented pricing surface enumerates its dimensions and payment method is not among them: item prices vary by dispatch type and price band only (articles 14484417, 9585264), per-channel pricing is done by assigning separate menus per storefront (9585270), and the only documented order-fee mechanism is a per-sales-channel percentage service charge — 'Set a custom percentage, such as 5% or 12%', mandatory or optional (9585753). No cash/card price differential, cash-discount or surcharge configuration exists anywhere in the Help Centre, and the payment-types article lists methods with no price effect. https://help.flipdish.com/en/articles/9585753-configure-service-charges-in-the-flipdish-portal · retrieved 2026-09-17

Menu changes can be staged as an effective-dated version, previewed before publish, and rolled back to a prior version after publish. differentiator

menu-pricing-versioning-effective-dates

Menu Management API v3.0 (beta). Menus carry a revisionId 'incremented on each save'; GET /menus/{menuId}/revisions lists them and GET /revisions/{revisionId} returns any one, so a prior version can be inspected before use. Rollback after publish is supported by republishing an earlier revision: POST /menus/{menuId}/revisions/{revisionId}/publish takes an 'Optional list of Sales Channel IDs to publish to'. Shortfall: publishCheck ('Check if menu can be published') is a validation gate, not a rendered preview, and there is no effective-dating - grep of the entire v3.0 corpus returns no scheduled-publish, effective-date or go-live field on any menu endpoint. All Menu Management endpoints carry the beta notice. https://developers.flipdish.com/reference/post__menumanagement_orgs__orgid_menus__menuid_revisions__revisionid_publish_18 · retrieved 2026-08-09 adversarially verified

Supports a central corporate menu template pushed to locations with field-level governance controlling which attributes a location may override. differentiator

menu-pricing-franchise-hierarchy

Org Management API v3.0 (beta) models org -> brand -> property -> sales channel, and a menu is owned by the org and published downward: POST /menus/{menuId}/revisions/{revisionId}/publish takes an 'Optional list of Sales Channel IDs to publish to', and GET /menus/{menuId}/references returns 'all properties and sales channels referring to a menu'. Central-to-local propagation is expressed by SalesChannelHierarchy, type Primary|Linked, 'Indicates if the sales channel is dependent on another or if updates to this channel will impact other linked channels', with linkedSalesChannelIds / primarySalesChannelId. Shortfall: governance is all-or-nothing at the channel level. There is no field-level override policy - a location cannot be granted, say, price-only override rights; the only local variation documented is AvailabilityOverrides scoped by property, and those are authored inside the central menu, not by the location. https://developers.flipdish.com/reference/getsaleschannelbyid · retrieved 2026-08-09 adversarially verified

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

Allergen flags are a first-class per-item field; nutrition is entirely absent. BaseItemSchema - described in the spec as 'Base schema for an item, including visuals, allergens and availability' - carries allergens[] as a closed enum of 19 values: Alcohol, Mild Spice, Medium Spice, Hot Spice, Celery, Crustaceans, Egg, Fish, Gluten, Lupin, Milk, Molluscs, Mustard, Nuts, Peanuts, Sesame, Soybeans, Sulphur Dioxide, Wheat, plus a separate required boolean 'alcohol'. Because these ride on the menu object that menu.published.v1 delivers and that marketplaces are instructed to map onto their own listings, they do publish to online ordering and to third-party menus. Named shortfalls: (1) there is no nutrition field of any kind - no calories, energy, macronutrients or serving size anywhere in the item, modifier or menu schema, and the 99-page corpus has zero occurrences of 'nutrition'; (2) there is consequently no recipe-component linkage and no derived nutrition, because the menu model has no recipe or ingredient entity at all; (3) the allergen list is a fixed enum with no free-text or custom allergen, and three of its 19 values are spice-heat levels rather than allergens. Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

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

POS feature list includes 'Recipe builder', 'Inventory management' and 'Food sales and costs calculations'; depletion-on-sale and item-level theoretical cost are not explicitly documented. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01

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

Menu synchronisation to Just Eat, Uber Eats and Deliveroo is claimed; API exposes menu publish-status updates and a menu.validation.failed webhook, but per-item marketplace rejection surfacing is not documented. https://www.flipdish.com/pos-system/order-management · 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

Only the channel limb of this claim is met, and only statically. A SalesChannel record carries priceBandId as a required field (/reference/getsaleschannelsbyorgidandpropertyid), and every item pricingProfile is keyed by priceBandId, so the same item can carry a different price on the POS, kiosk, web app, mobile app and each marketplace; Flipdish exposes a GET price bands endpoint for an org, and the marketplace guide maps pricingProfiles[] to per-dispatch-type pricing. Named shortfalls: (1) a price band is a static price list, not a rule - there is no condition, trigger, schedule, date, day or time field on a pricing profile or a price band anywhere in the schema; (2) there is no demand, load, inventory or occupancy input to pricing anywhere in the corpus; (3) there are no floor or ceiling guardrail fields, so nothing bounds an automated change; (4) demand- and event-based pricing appears on the Flipdish Labs page only as an innovation the company is 'excited about', which is not evidence that it ships. Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

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

Positive absence. The vendor's own hardware FAQ answers the question directly: 'Can I accept payments with the Flipdish POS? Yes. The Flipdish POS comes with integrated payments and you will need to purchase a Flipdish card reader to take payments.' The same page's neighbouring answers show the hardware flexibility on offer is about registers, printers and drawers ('Can I mix and match different hardware brands? Yes'), not about the acquirer. No list of supported processors or gateways is published anywhere on either permitted host: www.flipdish.com/integrations categorises partners as Point of Sale, Last mile delivery + Driver Management, and Other Integrations, with no payments category at all; the 99-page developer corpus names no gateway or processor (zero occurrences of Adyen, Worldpay, Stripe, Checkout.com, Braintree, Elavon or Global Payments) and the sale paymentMethod enum is a closed list of tender categories - Cash, Credit, Online, PhonePayment, ExternalPayment - naming no processor; and www.flipdish.com/pos-system/payments markets Flipdish Pay as 'one solution for online and in-store payments ... All under one roof. One brand. One support team.' The T&Cs reinforce it at clause 1.3, re-verified verbatim on 2026-08-09: 'You agree that we will be your exclusive provider of technological solutions similar or equivalent to any of the Services that you use.' The one qualification, from the same clause, is that a merchant is 'not restricted from using similar third-party offerings for components of the Services that you don't currently use' - so a stand-beside terminal from another acquirer is contractually permissible, but that is not integrated processor choice within the POS, which is what this claim asks about. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-09

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

payments-published-rates

Flipdish repeatedly asserts 'transparent transaction fees' / 'no hidden fees' but publishes no rate figure on any pricing page. https://www.flipdish.com/us/pricing · 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

Two exhaustive schemas settle this. (1) Price storage: in v1.0 a MenuItemOptionSetItem and a menu item each carry exactly one Price (plus an optional DepositReturnFee), and in v3.0 an item's whole price surface is pricingProfiles keyed by priceBandId with four dispatch-type prices. Price bands vary price by sales channel and dispatch type, never by tender; there is no cash price, card price or tender dimension in 27.6MB of v1.0 reference or the 99-page v3.0 dump. (2) Receipt: GetReceiptByOrderIdQueryResponse is enumerated as LogoUrl, Address, VatNumber, PaymentMethodDescription, TsOrderPlacedLocal, TsRequestedForLocal, DepositReturnFeesSummary and a PreviousOrder block of DeliveryType, PaymentAccountType, OrderId, LocalOrderId, CustomerName, Currency, ProcessingFee, ServiceChargePercentage, ServiceChargeAmount, TipAmount, DeliveryAmount, DepositReturnFeeAmount, TotalTax, TotalAmount, Items[] and TaxRates[] - one TotalAmount and one payment method, with no cash-total/card-total pair to print. What Flipdish does have is a tender-differentiated fee, not a second price: ProcessingFeeConfig sets PercentFee and FixedFee 'to customer' per store per PaymentAccountType (/v1.0/reference/getprocessingfeeconfigsbystoreidandpaymentaccounttype). Consistent with this record's earlier help-centre reading (2026-08-03, before the policy exclusion), which found payment types documented as cash, card and combinations only and price bands as per-sales-channel lists. Flipdish's core IE/UK/EU markets also restrict consumer-card surcharging. Scope caveat: the receipt schema above is the order receipt Flipdish itself renders; a POS printer template is not published. https://developers.flipdish.com/v1.0/reference/getreceipt · retrieved 2026-08-09

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

The v1.0 API publishes a per-location, per-tender consumer fee. ProcessingFeeConfig is documented as {StoreId, PaymentAccountType, PercentFee 'Percent fee to customer, including VAT', FixedFee 'Fixed fee to customer, including VAT'}, readable at /api/v1.0/stores/{storeId}/processingfeeconfigs and /api/v1.0/stores/{storeId}/processingfeeconfigs/{paymentAccountType}. The order schema corroborates that the fee lands on the guest: ProcessingFee is 'the online ordering processing fee. For card payments this is charged directly to the customer and for cash orders it is paid by the customer to the store.' So a card fee exists, is charged to the cardholder, and is configured per location and per tender - the per-location enable/disable leg of the claim. Named shortfall: the guardrails are absent. PaymentAccountType is a closed ten-value enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken) that treats every card as one type, so debit and prepaid cannot be distinguished, let alone excluded; grep across the 1,064-page v1.0 reference and the 99-page v3.0 dump returns zero BIN, card-product-code, debit or prepaid attribute; and there is no percentage-cap or network-limit field anywhere - nothing enforces a scheme cap. In v3.0 a surcharge could only be recorded as an untyped 'Other' charge (charges[] is Delivery|Service|Tip|Other). This record's earlier census of all 13 help-centre collections (2026-08-03, before the policy exclusion) found no surcharging article; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getprocessingfeeconfigsbystoreidandpaymentaccounttype · retrieved 2026-08-09

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

payments-emv-nfc

Kiosk card readers 'support a variety of payment cards and NFC-enabled device payments'; POS 'Accept contactless'. Apple Pay and Google Pay are not named, and no EMV/PTS device model is published. https://www.flipdish.com/online-ordering/kiosks · retrieved 2026-08-01

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

Positive absence, from the vendor's own hardware FAQ: 'Can I accept payments with the Flipdish POS? Yes. The Flipdish POS comes with integrated payments and you will need to purchase a Flipdish card reader to take payments.' The page enumerates the device catalogue - POS register with optional 10.1-inch customer-facing display, cash drawer, kitchen printer, wifi-connected card reader and card-reader mount, RFID card reader for staff login, and the K2, K2 Mini and D2S kiosks (each with its own built-in card reader) - and it contains no phone-based acceptance, no Tap to Pay on iPhone and no Android tap-to-pay. The handheld is sold as a device with a built-in payment terminal, i.e. dedicated acceptance hardware rather than software-only acceptance on a commodity phone, and /pos-system/payments markets contactless acceptance and custom-branded card readers in the same terms. Nothing in the 99-page developer corpus references a software point-of-sale, NFC acceptance or a mobile acceptance SDK. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-09

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

Handheld setup guide lists an 'NFC reader', 'Magnetic card reader' and built-in 80mm printer on the device, has the operator pair a 'Stripe Reader' credit-card terminal, and instructs 'Choose Card as the payment method. The card option should display a contactless icon.' Tipping is a documented POS prompt ('automatically prompt customers with a tipping option when they go to complete a transaction in store'). The dine-in tabs guide covers printing the bill at the table and 'Splitting the Bill (if necessary): If customers want to split the bill by items, click on the items in the payment summary.' https://help.flipdish.com/en/articles/11508326-getting-started-with-flipdish-handheld-pos · retrieved 2026-09-17

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

CLAIM: guest scans a QR 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. VERDICT: no. EVIDENCE: https://help.flipdish.com/en/articles/9585439 - "Can my customers open a tab and pay at the end of their meal? - No, customers must pay in advance for their order unless they choose to pay cash and not card, in which case it would be your responsibility to collect the payment when you see fit." Flipdish's QR estate is ordering-first: stickers and table tents link to the menu ("it will provide the customer with an instant link to your online ordering menu"), and QR orders cannot attach to a POS table at all (see order-capture-qr-same-check), so there is no open POS check for a scan to view or settle. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585439 · retrieved 2026-09-17 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

Shortfall: on-device prompt only, no tip adjustment after authorization. The POS tips article documents configuring the reader so staff 'automatically prompt customers with a tipping option when they go to complete a transaction in store', with fixed or percentage defaults, a 'Cut-off Bill Amount for Percentage', and a customer custom-amount option; it requires 'the Flipdish card payment reader'. No pre-auth-then-tip-adjust flow, no stated batch/adjust window, and no unadjusted-tip manager screen appears in the help centre - the only post-hoc tip surface documented is a read-only Tips Report. https://help.flipdish.com/en/articles/9704177-enable-and-configure-tips-on-your-flipdish-pos · retrieved 2026-09-17

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

Upheld, and now carried by a permitted host rather than the quarantined help centre. The Sales Management API field reference publishes the sale payload's complete charge model, and it is a closed four-value enum with no staff dimension: the `charges[]` array takes a `type` of `Delivery`, `Service`, `Tip` or `Other`, with an optional `itemId` for line-level charges and nothing else -- no employee, staff, shift, role or allocation field anywhere in the sale contract. Across a fresh crawl of all 96 live developer-docs pages (542,871 chars, 2026-09-09), tokenised: `tip pool` 0, `pooling` 0, `gratuity` 0, and the single `tip` hit is that enum member. A platform whose sale record cannot say who a tip belongs to cannot pool or distribute one. Grade A: the vendor's own API reference. https://developers.flipdish.com/docs/sales-management-api · retrieved 2026-09-09

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

Vendor FAQ: 'The Flipdish POS does not support an offline mode'. Store-and-forward requires offline capability which Flipdish lacks. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

Vendor FAQ states verbatim: 'The Flipdish POS does not support an offline mode', recommending 'setting up a backup hotspot network' for persistent connectivity issues. There is no store-and-forward payment capability at all, so no stored offline transactions exist to decline on reconnect, no liability allocation is published, and no post-reconnect failed-offline-payment report exists. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

CLAIM: first-party gift cards with real-time balance tracking, redeemable across every location and through online ordering. VERDICT: no - the vendor denies it in terms. EVIDENCE: 'Does the Flipdish Point of Sale support Gift Cards?' (https://help.flipdish.com/en/articles/9585173): "At this time, we do not support gift cards the common way. Option 1: We have a concept of issuing voucher codes which can be redeemed by scanning the QR code on the POS. This voucher could be used online but works similarly to how Online Ordering vouchers work now. You have to apply the voucher code and it applies the entire balance of the voucher to the order. Option 2: If you want to use your own 'gift cards', then those can be redeemed as defining custom payment type. However, in this case, we don't validate or track the balance on the 'card'." Both named options fail the balance-tracking conjunct explicitly. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585173 · retrieved 2026-09-17 adversarially verified

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

payments-house-accounts

CLAIM: house/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation. VERDICT: partial - the feature exists as 'Credit Books'. EVIDENCE: 'Create and Manage Credit Books and Accounts' (https://help.flipdish.com/en/articles/9585149): "This functionality is for customers who receive a lot of corporate orders and hold an account for each of their corporate customers. This will make tallying up all their purchases at the end of the month to bill them easier." Requirements: "Must have owner access for creating a credit book account and depositing the amount" and "Must have an active Account Subscription on the POS." Multiple books are supported ("you can create multiple credit books like Staff, Friends etc"), each holding named Credit Accounts. At the till: "After placing an order go to 'Pay' ... Click On 'Others' ... Click 'Credit Book' ... Select the Credit Book and Account ... Click On Confirm Payment." In the back office there is a 'Credit Account Status' page where the owner selects a credit book and posts a debit or a deposit. SHORTFALL: no per-account CREDIT LIMIT field appears anywhere in the creation flow, and no statement or invoice is generated - the vendor's own framing is that the feature makes manual "tallying up all their purchases at the end of the month to bill them" easier. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585149 · retrieved 2026-09-17 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

Multi-tender is representable, but only on an access-gated surface. The v3.0 PublicSale object -- which the docs state is the one schema used for the create request, every org-wide GET and the sale.* webhooks -- carries payments[] as an array in which each line has type (Sale|Refund), paymentMethod (Cash|Credit|Online|PhonePayment|ExternalPayment), amount, paidAt and two free-text description fields, with no documented maximum number of lines, so settling one sale with several tenders of arbitrary amounts is representable and there is no cap below eight ways. Availability: Sales Management carries the 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice', and the marketplace guide puts the Sales API in closed beta -- 'Email integrations@flipdish.com to request access and credentials' -- so this is a gated surface, not a shipped one. On the generally-available v1.0 API there is no payments array at all: an Order carries a single PaymentAccountType (e.g. Card) plus PaymentAccountDescription, so multi-tender is not expressible there. Named shortfalls: (1) split by seat cannot be expressed -- the dineIn object is documented exhaustively as tableId and guests, sale lines carry no seat attribute, and 'seat' appears zero times in the 27.6MB v1.0 corpus; (2) split by item cannot be expressed -- a payment line has no itemId and cannot be attributed to specific lines, and the docs state 'Discounts always apply at the sale level - there is no per-line discount'; (3) there is no even-N-way split construct, only free amounts; (4) this is a sale-recording schema, so it evidences that the platform stores multi-tender settlements, not that the till UI offers the four split modes the claim lists, and the till manual on help.flipdish.com is excluded by policy. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09 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

Flipdish's product feature list states 'Manager Approvals - Specify when your staff would need manager approval for actions like applying discounts or refunds' and 'Roles and Permissions - Assign custom roles to store staff ensuring they have the correct permissions'. That is a first-party feature page, not documentation: it names the approval gate but not what is recorded. The v3.0 API offers no support - /auditLogs/orgs/{orgId} is POST-only ('Publish an audit log entry to the Org audit trail'), a beta endpoint for an integrator to file its own {status,name,message,data} events, with no query endpoint and no approver identity field; v1.0 exposes /orders/{id}/refund with no documented role gate. Approver attribution on a void or refund, and immutability of the log, remain undocumented on any permitted host - the merchant manual is on help.flipdish.com, which robots.txt closes to us. https://www.flipdish.com/products-overview · retrieved 2026-08-09 adversarially verified

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

payments-chargeback-tooling

Shortfall: no in-product dispute dashboard or evidence-submission workflow. Flipdish's 'Manage Chargebacks' article documents that a chargeback deducts 'The order amount, and A chargeback fee (usually around $15/EUR15/GBP15)', that 'Once a chargeback is registered, Flipdish automatically blocks the customer from making future card payments on the platform', and that the merchant should 'Contact the customer directly' and 'Submit evidence... (e.g. order confirmation, delivery records, customer communication)' - but names no Portal screen for listing open disputes or uploading that evidence, and states 'the final decision is made by the issuing bank'. The marketing page's 'Dispute tools - Manage and resolve chargebacks quickly' is unsupported by any documentation. https://help.flipdish.com/en/articles/9585375-manage-chargebacks · retrieved 2026-09-17

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

Shortfall: online/app channels only - no phone-order or in-store reuse. Tokenization is explicit: 'Neither Flipdish nor the store you have ordered from have access to your debit/credit card details. These are stored securely by a third-party payment provider, Stripe, who then sends Flipdish a unique token which we use to charge the card.' Reuse spans the platform - 'if you consent to have your card details retained, they will be available when you place a digital order from a different store if it is also on the Flipdish Platform' - but only for digital orders. Phone orders are handled by a texted or emailed payment link the customer completes themselves ('Direct the customer to check their text message or email inbox'), not by charging a card on file, and no in-store POS card-on-file flow is documented. https://www.flipdish.com/consumer-information/card-details · retrieved 2026-08-08

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

payments-payout-timing

Schedule is published: 'Weekly payouts: Issued every Monday, or on Tuesday if Monday falls on a holiday. Covering sales from Monday through Sunday of the previous week' and 'Daily payouts: Issued each business day. Please note: This may incur an additional monthly charge.' Funds timing is stated too - 'Funds usually arrive in your bank account on the same day the payout is processed', with Ireland/UK bank processing given as 1-3 business days. The accelerated option is chargeable but offered. https://help.flipdish.com/en/articles/9585397-how-and-when-are-flipdish-payouts-issued · retrieved 2026-09-17

A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator

payments-multi-entity-routing

Three v1.0 endpoint families establish this. (1) Separate merchant accounts per location: GET /api/v1.0/{appId}/customconnect/{storeId} returns StripeCustomConnectedAccount, documented as 'Flipdish Stripe Custom Connected Account associated to the Store', carrying StoreId ('Physical Restaurant Id'), StripeId ('Stripe's own connected account identifier'), CardPaymentsStatus, TransfersStatus and AccountStatus - i.e. each store can hold its own acquiring account, with its own business type (/customconnect/bank-account/{bankAccountId}/businesstype), its own verification status and its own payout schedule (/customconnect/update-payout-schedule/{stripeConnectedAccountId}/{interval}). (2) Separate settlement destinations per location or legal entity: a BankAccountDetail carries AccountName, Iban, Swift, NationalClearingCode, BankCountryCode, AccountHolderAddress, AccountHolderCountryCode, VatNumber, CurrencyCode and a StoreIds[] array, and POST /api/v1.0/{appId}/bankaccounts/{bankAccountId}/store/{storeId} is literally 'AttachBankAccountToStore'. Distinct VAT numbers and account holders per bank account is exactly the separate-legal-entity case. (3) Unified reporting: GET /api/v1.0/{appId}/payouts queries payouts across the whole app with a payoutRequestIds.bankAccountIds filter ('List of bank account ids to search for'), GET /{appId}/payouts/summaries rolls them up, and Payout Report 3 gives per-payout overview, details and exports of orders, POS sales, chargebacks, refunded orders and ledger entries. One caveat recorded for the reader: this is the v1.0 surface, the older of Flipdish's two published API versions, and the v3.0 root index does not list bank-account or payout endpoints at all. https://developers.flipdish.com/v1.0/reference/getcustomconnect · retrieved 2026-08-09

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

CLAIM: vendor provides point-to-point encryption AND a current PCI DSS 4.x AoC / P2PE listing available to merchants on request. VERDICT: no - neither conjunct, and the merchant-facing manual that the prior note called unreachable is now read in full. EVIDENCE: the single compliance statement Flipdish makes to merchants anywhere is a bare unversioned bullet. 'What are the benefits of processing payments through Flipdish's payment technology on the Point of Sale?' (6 Jun 2025) lists 'Benefits of Flipdish payment processing: No need for a separate account / No setup or monthly fees / Simple setup / PCI Compliant' and then enumerates the payment features (card reader configuration through the portal, configurable tipping, split payments, refunds from POS, payout data in the portal, single invoice). That is the ONLY `PCI` hit in 518 articles. CONTROLS: `P2PE` 0, `SAQ` 0, `tokeniz*` 0, `encrypt*` 1 (and that one is the cookie-modal article), `trust cent*` 0 across all 518; `attestation` scores 4 and all four are bank-account attestations in the IE and UK payout verification articles, not an AoC - a trap worth naming. No article tells a merchant how to request an AoC or names a standard version. The readers are Stripe Terminal hardware (BBPOS/Chipper, WisePad 3, WisePOS E, Verifone P400 in the v1.0 cardreaders DeviceType enum), so card data is protected by Stripe's hardware - but Stripe's validation is Stripe's, Flipdish claims no P2PE of its own, and www.flipdish.com/legal remains a closed index of exactly five documents (T&Cs, Privacy Policy, Cookie Policy, EU DSA, EU Accessibility Act). BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585216-what-are-the-benefits-of-processing-payments-through-flipdish-s-payment-technology-on-the-point-of-sale · retrieved 2026-09-17 adversarially verified

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

Verified verbatim, though weaker than the dossier's phrasing suggests: 'Prepare orders faster by sending them to different stations – if that's how you prefer to work.' The dossier also quotes 'Organise tickets by station and dispatch types', which I did not find on this page. One hedged marketing sentence supports the capability existing; no routing-rule configuration is documented. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01 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

KDS station profiles include 'Cook, Drinks, Fry, and Packing stations. The packing station is designated as the final step in the process, where orders are packed up for collection or delivery' (9585121); items bump per item from prep stations to the pack station or to dispatch (9585308), and KDS/station tags route items and modifier options to stations (15656778). Shortfall: no documentation states the order is only marked complete when every contributing station has bumped its items — the all-stations completion-gating half of the claim is undocumented. https://help.flipdish.com/en/articles/9585121-edit-kds-station-settings · retrieved 2026-09-17

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

Course assignment IS documented, refuting the earlier 'no course management' claim: KDS Course Tags are created in Portal > Sales Channels > Settings > Tags with 'a tag code which can be... starter, main course, drinks or dessert' and 'a number to highlight in which sequence the courses should appear', applied per item under Kitchen Operations, with a 'Display course name' toggle on the KDS and 'Ticket-specific printing... ensuring that items like appetizers, main courses, or desserts are printed on separate tickets'. Shortfall: the hold-and-fire half of the claim is absent — no hold or fire-on-demand action from a server terminal, handheld or expo screen appears anywhere (Help Centre searches for 'fire', 'hold' and 'coursing' on 2026-08-05 return only course-tag grouping/sequencing articles). Course grouping and sequencing without on-demand firing is partial, not no. https://help.flipdish.com/en/articles/9619311-apply-kds-course-tags-to-menu-items · retrieved 2026-09-17 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

CLAIM: per-item cook times are configurable AND the KDS staggers item start/display times so an order's items finish simultaneously. VERDICT: no. EVIDENCE: pacing on the Flipdish KDS is ORDER-level, never item-level. 'Change Order Sequence and Due Time on Your KDS' (https://help.flipdish.com/en/articles/9587775): "Orders can be sequenced by due time on the KDS instead of appearing in the order that they are received ... You can configure default due times by Storefront in your Flipdish POS back office, but you can also adjust individual order due times right from the KDS", with an order-level hold-and-release: "The order will disappear if the lead time is now longer than the prep time you have set for your orders. The order will reappear when the new prep time arrives." The only per-item time field in the whole product is a food-safety one - the stock item's "Prep Profile Tab: ... The prep time of the item in HOURS. Expiry time for the item in hours. Minimum number of expiry labels to be printed each day" (https://help.flipdish.com/en/articles/9585131) - which feeds build plans and expiry labels, not the KDS. CONTROLS: 'stagger' 0, 'finish together' 0, 'cook time' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9587775 · retrieved 2026-09-17 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

The v1.0 API publishes an order-capacity limiter per store. POST /api/v1.0/{appId}/storeordercapacity/{storeId} takes a StoreOrderCapacityConfigEditModel of OrderCapacityPeriods[], each a StoreOrderCapacityPeriod of {MaxOrderNumberPerStoreInterval, DayOfTheWeek, PeriodStartHour, PeriodStartMinutes, PeriodEndHour, PeriodEndMinutes}, and the schema explains it verbatim: 'The maximum number of orders per each store order interval in this order capacity period. E.g. for a period from 9:00 till 11:00, if the store's interval is 10 minutes, and MaxOrderNumberPerStoreInterval is set to 5, it means that within each 10-minute interval between 9:00 and 11:00 (i.e. 9:00-9:10, 9:10-9:20, .., 10:50-11:00) it will be possible to request at most 5 orders.' It is set separately per delivery type (Delivery|Pickup) and read back at GET /storeordercapacity/{storeId}/{deliveryType}. That is a configurable order-volume threshold that paces incoming digital orders per location. Named shortfall: it is a static weekly schedule, not a load-responsive rule. Nothing measures current kitchen load or ticket time and feeds it back - the trigger is the clock and a fixed count, never a ticket-time threshold - and crossing the cap blocks further slots rather than delaying release or extending the quoted prep time (lead times are a separate, fixed per-store default at /stores/{storeId}/leadTimes). Grep for throttle, pacing and capacity-by-load across both API versions returns nothing else; the only other load-shedding primitive is manual snoozing of an item or a channel. Scored on the API surface; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/updatestoreordercapacityconfig · retrieved 2026-08-09

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

v3.0 marketplace guide, 'Item and store availability': 'When a merchant marks an item or sales channel as unavailable on the Flipdish portal' Flipdish fires menu.item.snoozed.v1 / menu.item.unsnoozed.v1 and sales_channel.snoozed.v1 / sales_channel.unsnoozed.v1, and the instruction to the integrator is 'Mirror these onto your marketplace listing'. Shortfall, twofold: the propagation step is delegated to the marketplace's own webhook consumer rather than performed by Flipdish, and the enumerated sales-channel types are POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats, Deliveroo - DoorDash and Grubhub appear nowhere in either corpus and would arrive only as a generic ExternalApp channel. Nothing documents a KDS-originated pause. Sales API, Operations Updates and v3 webhooks are all in closed beta ('Email integrations@flipdish.com to request access'). https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

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

Correction to the earlier note, which claimed no page documents Flipdish propagating readiness back to a marketplace: the marketplace integration guide does exactly that. Its end-to-end diagram runs 'Flipdish --sales.created.v1 / sales.pos.status.updated.v1 / sales.delivery.status.updated.v1 / sales.cancelled.v1--> your platform' then 'Update marketplace order, dispatch driver', and it publishes the payload verbatim with '"eventType": "sales.pos.status.updated.v1"' and '"status": "SALE_PREPARED_BY_KITCHEN"'. Readiness is a modelled state: the sale lifecycle table lists SALE_PREPARED_BY_KITCHEN 'Kitchen has finished preparing the sale' between SALE_ACCEPTED and SALE_DISPATCHED. Named shortfalls, all about availability rather than modelling. (1) Neither carrier is on a shipped tier: sales.pos.status.updated.v1 is marked 'Deprecating soon' ('Do not build new integrations against sales.*'), and its replacement sale.status.updated.v1 is Beta and, per llms.txt, 'in closed beta -- request access by emailing integrations@flipdish.com'. (2) The callback goes to a subscriber endpoint the marketplace builds; no native Uber Eats / Deliveroo / Just Eat / DoorDash ready-callback connector is documented on either developer host. (3) On the generally-available v1.0 API the OrderState enum is exhaustive and contains no kitchen-prepared state at all -- Created, PlacedCanBeCancelled, ReadyToProcess, AcceptedByRestaurant, Dispatched, Delivered, Cancelled, ManualReview, RejectedByStore, RejectedByFlipdish, RejectedAutomatically, RejectedAfterBeingAccepted, AcceptedAndRefunded -- so readiness cannot be emitted from the shipped surface. (4) Whether the KDS bump is what sets the status is a portal-manual question and help.flipdish.com is excluded by policy. Also withdrawn: the earlier note leaned on the events (v3) catalogue as an exhaustive list; it is not, since sale.accepted.v1 is documented in the Sale webhook events guide and is absent from that catalogue. https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

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

kitchen-bump-bar-hardware

CLAIM: supports a physical bump bar / keyboard peripheral at the KDS. VERDICT: no. EVIDENCE: the portal's Device Network Diagram is an enumeration of every peripheral the platform models against a POS or KDS station - "The diagram displays the POS name plus all configured connected devices or peripherals such as a Receipt printer, Card Reader, Caller ID, kitchen printers(KOT) and Label printers ... The diagram will allow you to View or Configure each of them" (https://help.flipdish.com/en/articles/12742087) - and no input device of any kind is among them. Every documented KDS interaction is touch: "click on the logo in the top left of the order on the KDS Screen" (https://help.flipdish.com/en/articles/9585308), "Click on the settings wheel in the bottom right corner of the KDS" (https://help.flipdish.com/en/articles/9585535), "Tick the 'allow drag and drop' box - Drag and drop tickets into the preferred position" (https://help.flipdish.com/en/articles/9587775). CONTROLS: 'bump bar' 0, 'bumpbar' 0, 'keypad' 0 in a KDS sense. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/12742087 · retrieved 2026-09-17 adversarially verified

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

kitchen-all-day-counts

CLAIM: an all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station. VERDICT: no. EVIDENCE: every documented KDS view control is per-ticket or ticket-ordering - the Display list (modifiers on/off, modifiers one per line, change highlighting, unpaid warning, header/item/modifier font sizes, ticket width slider, sound volume) at https://help.flipdish.com/en/articles/9585535; drag-and-drop resequencing, due-time sorting and a flashing late-order warning at https://help.flipdish.com/en/articles/9587775; and filtering, grouping menu items WITHIN a ticket, course tags and station tags in their own articles. No aggregate or quantity roll-up view is offered by any of them, and the station-profile model (Cook, Drinks, Fry, Packing - https://help.flipdish.com/en/articles/9585121) routes tickets rather than summing them. CONTROLS: 'all day counts' 0, 'all day view' 0; POISON: 'all-day'/'all day' 2 hits each and both are unrelated - "Charge the device overnight to ensure ALL-DAY performance" (handheld guide) and "Breakfast vs ALL-DAY" (menu zones). BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585535 · retrieved 2026-09-17 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

'Customise your ticket layout, order due time, notifications and more'; no configurable per-station target time or colour-escalation detail published. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01

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

The vendor's documented response to a failed receipt or KOT printer is a manual in-store troubleshooting guide — reboot, reseat cables, reselect the printer in POS settings, re-run the Configuration Wizard, update the printer IP in the Portal, then 'contact our support team and include your AnyDesk address' (9585705). The printer configuration surface (printers assigned per KDS station in 9585121; Portal > Devices > Receipt Printers) has no backup-printer or failover option, and the POS has no offline mode (9585187). No automatic failover, staff alert on printer loss, or ticket-preservation mechanism appears anywhere in the printer or KDS documentation. https://help.flipdish.com/en/articles/9585705-troubleshoot-pos-receipt-printer-and-kot · retrieved 2026-09-17

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

kitchen-offline-operation

KDS is cloud-based component. Vendor FAQ confirms no offline mode: 'The Flipdish POS does not support an offline mode.' KDS requires internet. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

'Items and ingredients that need to be added or removed are colour-coded and clearly visible' — full modifier breakout, but no recipe-step or portioning build screen. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01

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

CLAIM: sectioned/fractional topping placement (halves, quarters, specific sections) rendered visually and unambiguously on the make-line screen or ticket. VERDICT: no. EVIDENCE: the modifier and KDS surfaces are both fully documented now and neither has a placement attribute. Menu structure is built in the AI Menu Editor (menu / category / item / price, tags, modifiers, menu zones, display columns, schedules) and AI may 'Generate item descriptions (if missing) / Fix spelling and grammar / Apply VAT or tax settings based on predefined rules / Assign kitchen stations for correct order routing' - an enumeration of every attribute AI can set, with no fraction, half or placement among them. The KDS articles enumerate what a ticket can do - KDS course tags, station tags, group menu items, consolidate identical receipt items, remove/highlight completed items, change order sequence and due time, filter orders, screen sizes - and none of them sections an item. CONTROLS: `fraction*` 0, `halves` 0, `left half` 0, `whole pizza` 0 across 518 articles; `half` scores 9 and every hit is unrelated (a half-day installation fee, a power-adapter article, a refund); `portion*` scores 1, inside the Spanish VeriFactu tax article; `quarter*` scores 1, a calendar quarter in the Customers report. `section*` scores 251 and is pure poison - website sections and report sections. This matches the prior pass's finding that the v1.0 MenuItemOptionSet schema has no fraction, portion, placement, half or section field. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/14484403-how-to-use-ai-features-in-ai-menu-editor · retrieved 2026-09-17 adversarially verified

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

kitchen-recall-refire

CLAIM: a bumped ticket can be recalled/unbumped, and an individual item refired or reprinted without re-entering the order. VERDICT: no. EVIDENCE: the KDS manual is a bounded cluster inside this census (create a new KDS station, edit KDS station settings, set up your KDS, customise KDS display, filter orders, group menu items, apply KDS course tags, configure KDS and station tags, change order sequence and due time, remove/highlight completed items, bump orders and print, restart the KDS, screen size options, consolidating identical items) and nothing in it un-bumps. 'Bump Orders and Print via the KDS' (https://help.flipdish.com/en/articles/9585308) documents bumping one way only: "To bump an item to the pack station or to dispatch, click on the logo in the top left of the order on the KDS Screen." The nearest thing to a recall is cosmetic and forward-only: "Completed items can be highlighted in yellow by clicking on the item and you also have the option to HIDE the item from the ticket in order to clean up your KDS screen" (https://help.flipdish.com/en/articles/9585532), gated by a Control setting called 'allow removing sale items'. Reprint exists only from the live ticket or the register: "To print items populating on a KDS, staff must press the printer icon on the right-hand side of the order or beside each item in the order ... If the entire order needs to be printed, this can come directly from the POS register." CONTROLS: 'refire' 0, 're-fire' 0, 'unbump' 0, 'un-bump' 0; POISON: 'recall' has exactly 1 hit and it is the kiosk Local Order ID being "a shorter, easy-to-RECALL identifier they can use when collecting their orders". BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585308 · retrieved 2026-09-17 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

CLAIM: 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. VERDICT: yes. EVIDENCE: 'Customise KDS Display' (https://help.flipdish.com/en/articles/9585535) lists the KDS Display settings and includes, verbatim: "Display changes in existing orders: if a change is made to an order, for example, an item is added or removed, we'll notify you so you don't miss it." It sits in the same togglable Display list as "Displaying modifiers", "Displaying modifiers as one line", "Warning for unpaid orders: now clearly stated on the ticket instead of appearing as a red border around the order", font sizes, ticket width and sound - i.e. it is a ticket-rendering behaviour, applied by "Click on the settings wheel in the bottom right corner of the KDS, Click 'Display' on the list, Tick the relevant box beside the item you wish to display or remove." Grade B (vendor product documentation), which clears the differentiator grade floor. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585535 · retrieved 2026-09-17 adversarially verified

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

Digital signage for order collection is a listed POS feature and SMS/email receipts exist; an explicit bump-triggered guest notification is not documented. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01

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

kitchen-waste-logging

Flipdish's live merchant-portal bundle (index-Be9zTRhC.js; public source map file src/components/RMS/Reports/Reports.tsx) lists {title:"Wastages",subtitle:"Inventory_Wastages",path:"/inventory/wastages"} in the RMS Inventory report group, which is gated by subscription pos.inventory. Its English is "Wastages" / "Inventory Wastages", and it sits alongside Purchase Orders, Discrepancies, Inventory Status and Daily COGS Summary. The bundled dictionary also carries a lookup pair "Wastage reasons" / "Manage wastage reasons lookup", listed beside the Allergies, Nutrition, Packaging types and Venues lookups. So wastage is recorded against inventory, reported, and has a configurable reason list. Shortfall: the claim requires capture at the kitchen/KDS screen, and nothing shows where a wastage entry is made. That the entry depletes stock is not stated, and remakes are not mentioned. The reason-lookup strings have no consumer in this bundle's code, so their screen is not visible. Wastage also needs the paid pos.inventory add-on. https://portal.flipdish.com/static/index-Be9zTRhC.js · retrieved 2026-09-14 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

The Flipdish merchant portal's shipped bundle (index-Be9zTRhC.js; public source map file src/components/RMS/Reports/Reports.tsx) lists, in the RMS Sales report group gated by subscription pos.base, a report {title:"Kitchen_Timings_Report",subtitle:"Kitchen_Timings_Report_Subtitle",path:"/sales/timings"}, unlike several sibling reports without a deprecation redirect. The bundled English dictionary renders these as "Kitchen Timings Report" / "Kitchen Prep, Distpatch and Delivery Timing Analytics" (vendor's spelling), and the Sales menu's search aliases include 'Kitchen Timings Report'. So a native report of kitchen prep, dispatch and delivery timing exists. Shortfall: the claim asks for ticket and per-station times with averages and percentiles, sliced by daypart, station and channel, and exportable to CSV or an API. None of that is visible, because the report body is rendered by the RMS service rather than this bundle. The report also needs the POS base subscription, and no online-only client sees it. https://portal.flipdish.com/static/index-Be9zTRhC.js · retrieved 2026-09-14 adversarially verified

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

CLAIM: generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list. VERDICT: no. EVIDENCE: the Inventory module's own field-by-field documentation is now read, and its prep surface is static per-item data, not a forecast. 'Add and Edit Stock Items' (28 Jul 2026) enumerates every tab: Overview (stock item code, name, category, Is Product, Measurement Type, Measurement Unit, Minimum Inventory Quantity, Markup Rate Percentage, Is Wastage Tracked, Is Inventory Tracked, Notes), Property level overrides, Prep and Recipe ('a base quantity for this recipe, Base Quantity Unit, Where the item participates in the build plan'), Units (conversion factor, operational unit), 'Prep Profile Tab: This is where you can add: The prep time of the item in hours / Expiry time for the item in hours / Minimum number of expiry labels to be printed each day', Cooking and Storage Temperature Profiles, Nutrition, Allergy, Image. A minimum daily label count is not a predicted prep quantity. 'Manage Inventory Tracking Profiles' (18 Feb 2026) is the only thing surfaced to staff and it is manual: 'Tracking profiles are valuable for use when performing stock takes or checks... This helps your staff know when to perform checks or take stock of particular items.' CONTROLS: `forecast*` 0, `prep list` 0, `par level` 0, `par` 0, `production plan` 0, `stock take` 0 across all 518 articles; `predict*` scores 1 (an unrelated sentence in a terminal article); `build plan` scores 1 and is never defined anywhere. www.flipdish.com's 'Smart sales forecasts' is a sales figure in marketing copy (grade C) and /labs still lists predictive ordering as unshipped R&D. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585131-add-and-edit-stock-items · retrieved 2026-09-17 adversarially verified

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

Drivers are first-class in the shipped v1.0 API, so the roster half is better attested than the marketing page allowed, but the surface is bounded and it is not a roster module. The app permission enumeration carries exactly five driver verbs - InviteDriverToApp, GetDriverForApp, RemoveDriverFromApp, AssignDriverToOrder, UnassignDriverFromOrder - plus UpdateOrdersDeliveryTrackingStatus, and the fields that travel with a driver anywhere in 27.6MB are DriverId, DriverName and DriverImage only. Assignment state is modelled per order as DeliveryTrackingStatus [Unassigned, Unaccepted, Accepted, Carrying, OnTheWay, ArrivedAtLocation, Delivered, CannotDeliver] (/v1.0/reference/getorderbyid). Named shortfall: no clock-in/out (zero hits for ClockIn, shift or roster across the v1.0 dump), no driver shift or run-history entity, and no per-driver report - the index of 1,064 v1.0 pages contains no driver-scoped reporting endpoint at all. The previous note's marketing quotes are withdrawn as the basis; www.flipdish.com/pos-system/delivery-driver-tracking is a grade-C feature page and was cited at grade B. https://developers.flipdish.com/v1.0/reference/setappconfig · retrieved 2026-08-09 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

Assignment is documented in the shipped v1.0 API rather than only on a marketing page: an order carries DriverId ('Assigned driver identifier') and DeliveryTrackingStatus [Unassigned, Unaccepted, Accepted, Carrying, OnTheWay, ArrivedAtLocation, Delivered, CannotDeliver], and AssignDriverToOrder / UnassignDriverFromOrder / UpdateOrdersDeliveryTrackingStatus are named permissions. The KDS feature page adds 'Assign orders to your delivery drivers at the touch of a button, right from your tickets' and 'Orders are grouped and auto-assigned to maximise efficiency'. Named shortfall: there is no dispatch or expo resource in the API - no queue of undispatched orders, no driver-availability collection, no elapsed-time field, and no run or batch object that groups two or more orders under one driver; the 1,064-page v1.0 index has no dispatch endpoint. Whether the merchant portal renders such a screen is documented on help.flipdish.com, which is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). https://developers.flipdish.com/v1.0/reference/getorderbyid · retrieved 2026-08-09 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

Geocoded stop data and live courier position are real, but only on the third-party courier leg and with no sequencing. The v1.0 Stuart job resource (/api/v1.0/stuart/jobs/{jobId}) returns a JobDriver with Latitude and Longitude, a JobDeliveryDetail for both Pickup and Dropoff each carrying Latitude/Longitude and an address, a JobEta with Pickup and Dropoff times, and job-level Distance and Duration - that is a live, mappable position plus geocoded stops. Named shortfalls: (1) it is Stuart's courier job, not an in-house driver - the native customer-tracking payload (CustomerDeliveryTrackingOrder) carries the CUSTOMER's Latitude/Longitude with DriverId, DriverName and DriverImage but NO driver coordinates; (2) there is no route object and no sequencing anywhere - 'route' and 'optimi' are zero-hit across the whole 27.6MB v1.0 dump, and no waypoint or stop-order construct exists in either version; (3) whether the portal renders a map view at all is help.flipdish.com territory, excluded by policy. Marketing's 'monitor your riders' locations in real-time' (www.flipdish.com/pos-system/delivery-driver-tracking, grade C) is a claim about the integrated stack. https://developers.flipdish.com/v1.0/reference/stuart_getjob · retrieved 2026-08-09 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

Position tracking exists but is the courier partner's, not a Flipdish driver app. Positive evidence from the shipped v1.0 reference: the native customer delivery-tracking payload (CustomerDeliveryTrackingOrder) enumerates its fields as OrderId, Address, DeliveryNotes, StorePhoneNumber, AppIconUrl, OrderTrackingCode, payment fields, order lines, TotalAmount, Currency, Latitude and Longitude described as 'Customer Location Latitude/Longitude', Placed, RequestedFor, DriverId, DriverName, DriverImage and EstimatedMinutesForDelivery - the driver appears as an identity and a picture with NO coordinates. What Flipdish does hold natively is the assignment plus the eight-state DeliveryTrackingStatus lifecycle [Unassigned, Unaccepted, Accepted, Carrying, OnTheWay, ArrivedAtLocation, Delivered, CannotDeliver] (/v1.0/reference/getorderbyid). Driver GPS enters only through a courier partner: /api/v1.0/stuart/jobs/{jobId} returns a JobDriver with Latitude and Longitude, DisplayName, Phone, PictureUrl and TransportType, and Stuart is configured per store at /api/v1.0/stuart/settings/{storeId}. Named shortfall: no Flipdish-operated driver app position feed. The previous note's help.flipdish.com citation is withdrawn - that host disallows ClaudeBot by name and may not be used as evidence here. https://developers.flipdish.com/v1.0/reference/stuart_getjob · retrieved 2026-08-09 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 shipped v1.0 API defines a delivery zone as arbitrary spatial geometry. GET/POST /api/v1.0/stores/{storeId}/deliveryzones returns a DeliveryZone whose WellKnownText property is described as 'Spatial data in Well Known Text format. We also support CIRCLE((0 0, 200)) - (centerLong centerLat, radius in m)', and the worked example is 'POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))' - an arbitrary five-vertex polygon, with the radius form offered as an additional option rather than the only one. Zones are full CRUD (AddDeliveryZone, UpdateDeliveryZone, RemoveDeliveryZone) and emit store.delivery_zone.created/updated/deleted webhooks. Drive-time isochrones are not supported ('isochrone' is zero-hit in both corpora), but the claim is satisfied by the polygon limb: areas are not restricted to a radius or a postcode list. https://developers.flipdish.com/v1.0/reference/getdeliveryzones · retrieved 2026-08-09 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

Two of the three legs are documented at grade A and the third is positively absent. The DeliveryZone object (GET /api/v1.0/stores/{storeId}/deliveryzones) has exactly six properties - Id, FeeChargedToStore, DeliveryFee ('Delivery fee (will not be set below 0)'), MinimumDeliveryOrderAmount ('Minimum delivery order amount (will not be set below 0)'), WellKnownText and IsEnabled - so per-zone fee and per-zone order minimum are independently configurable, and a separate per-zone fee override exists at /api/v1.0/stores/{storeId}/feeConfig/deliveryZones (StoreDeliveryZoneFeeConfig = DeliveryZoneId + Fee). The order carries DeliveryFeeAreaId ('Delivery area identifier'), which is how the matched zone is applied. Named shortfall: there is no per-zone promise or prep time. The zone schema is closed and contains no time field; the only delivery time estimates in v1.0 are store- or integration-level (EstimatedMinutesForDelivery / EstimatedMinutesForCollection), never zone-level. Marketing's 'Set minimum order amounts and delivery charges for multiple areas' is consistent with this and says nothing about time. https://developers.flipdish.com/v1.0/reference/getdeliveryzones · retrieved 2026-08-09 adversarially verified

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

Spatial zone matching is documented at grade A, address validation as such is not. Delivery zones are stored as Well Known Text geometry (DeliveryZone.WellKnownText, 'POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))', with CIRCLE also supported) and the resulting zone is carried onto the order as DeliveryFeeAreaId ('Delivery area identifier'), so a checkout address must be resolved to a point and tested for containment for the right fee and minimum to apply. Named shortfalls: no mapping or geocoding provider is named anywhere and 'geocod' is zero-hit across both the 27.6MB v1.0 dump and the 99-page v3.0 dump, as are 'autocomplete' and any address-validation operation - there is no CanDeliver, IsDeliverable or ValidateAddress endpoint in the 1,064-page v1.0 index. Nothing states what happens to an address outside every zone. The API's address surface is formatting only: 'Get address templates' (POST /orgManagement/orgs/{orgId}/addresses/templates/query) returns per-country field layouts and is explicitly marked 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice', while the v3 sale's delivery.location carries 'Optional geographic coordinates for the drop-off point'. Consumer checkout behaviour is documented on help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/getdeliveryzones · retrieved 2026-08-09 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

CLAIM: tracks per-delivery driver compensation inputs - mileage or distance per run, per-delivery flat reimbursement, and driver-retained tips - and exports them to payroll as separate reimbursement vs wage lines. VERDICT: no, and this one is now closed by an enumeration inside the payroll report family itself. EVIDENCE: the driver report LIVES under payroll - 'Click on Reports... Select the RMS tab... Click on Payroll... Click on Sales by Driver' - and its complete field list is two figures: 'Key Terms - Sale Count: Order Count, the total number of orders fulfilled by the delivery driver... Cash Paid Amount: Any cash payments taken by the delivery driver that require the driver to cash up at the till', with the scope note 'This report does not populate third-party delivery driver information.' No mileage, no per-run rate, no tip attribution. The Payroll Calculator enumerates the whole payroll output - 'A wages summary - Planned wage, Holiday pay, Bonuses and more. A taxes summary - Employee and employer NI contributions, Pension contributions, PAYE and more. An employer summary - Net wage, Total pension and HMRC contributions and total payroll costs', and per staff member 'Gross wage / Net wage / Net wage to pay / Total NI Contribution / Total HMRC Contribution / PAYE' - there is no reimbursement line of any kind. 'Monitor Driver Performance' shows 'All the unpaid sales amounts receivable against the deliveries made by your drivers / The total deliveries / The total amount due / How many cancelled orders', i.e. cash owed to the till, not pay owed to the driver; and the updated 'How the delivery driver list works in POS' (5 Mar 2026) is workload display only. CONTROLS: `mileage` 0, `driver pay` 0, `per delivery` 0 across 518 articles; `reimburs*` scores 1, inside the chargebacks article. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585495-pos-sales-by-driver-report · retrieved 2026-09-17 adversarially verified

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

CLAIM: a driver cash bank / settle-up flow reconciling cash collected, orders assigned and tips owed at end of shift, producing a per-driver over/short figure. VERDICT: partial. EVIDENCE: 'Cash Up From Deliveries with the Flipdish POS' (https://help.flipdish.com/en/articles/9585298): "Cashing up refers to when delivery drivers accept cash as a form of payment during the delivery. This cash will need to be deposited. Managers will navigate to the reports section of the POS. When they cash up or choose to make a deposit/withdrawal, this will be recorded appropriately in the till." The flow requires Store or Staff Manager permission and runs POS > nine dots > 'Cashing Up' > enter amount > Deposit or Withdraw > "Select reason to deposit (in this case, we'll select 'Change Returned')" > "If requested, select the Staff Member"; "This deposit will be recorded in your report and will be assigned to the staff member who deposited it", withdrawals landing in the expenses report. A POS Sales by Driver Report (https://help.flipdish.com/en/articles/9585495) and 'Monitor Driver Performance' (https://help.flipdish.com/en/articles/9585333) sit alongside it, as does 'Manage Your Float Session, Cash Discrepancy and End-of-Day Report'. SHORTFALL: this is a till deposit/withdrawal attributed to a staff member, not a driver bank - no expected-cash figure is derived from the driver's assigned orders, so no per-driver over/short is produced, and tips owed are not part of the flow. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585298 · retrieved 2026-09-17 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

Native, documented, and in the shipped v1.0 API rather than only on a price list. Flipdish exposes a first-party courier surface at /api/v1.0/stuart/settings/{storeId} (GET and POST) whose StuartSettings object is configured per store - ClientId, ClientSecret, Enabled, WebhookUrlBasicAuthentication, OverrideWebhookUrl, MinutesToPickupBeforeThanDeliveryTime, PackageType [Xsmall..Xlarge], TransportType [Bike, Cargobike, Cargobikexl, Motorbike, Motorbikexl, Car, Van], CancelOrderIfStuartCancelDelivery and a TransportPrices map ('If the order exceeds are certain amount this configuration will determine a new vehicle type'). The courier job comes back into the order record: GET /api/v1.0/stuart/jobs/{jobId} returns Status, PickupAt, DropoffAt, Distance, Duration, a JobPricing block (Currency, PriceTaxIncluded, PriceTaxExcluded, TaxAmount, InvoiceUrl - the quote), per-delivery Status, PickedAt, DeliveredAt, TrackingUrl, Eta and Proof, and a JobDriver with Latitude/Longitude; the job can be cancelled from Flipdish (Stuart_CancelJob), and CancelOrderIfStuartCancelDelivery ties courier cancellation back to the Flipdish order. The order itself carries DeliveryTrackingStatus and a tracking URL. DoorDash Drive Order Fulfillment is a separately monitored production component on status.flipdish.com (operational, created 2022-12-07, last updated 2026-06-16), and www.flipdish.com/integrations lists Okestro, Ondway, Nash, Stuart and VROMO under last-mile delivery. Commercially, Uber Direct is sold as a separate add-on on the pricing page - a packaging point, not a capability limit. https://developers.flipdish.com/v1.0/reference/stuart_getstuartsettings · retrieved 2026-08-09 adversarially verified

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

Both halves of a hybrid model are documented and the automatic switch between them is not. In-house: drivers are first-class in v1.0 (InviteDriverToApp, AssignDriverToOrder, DeliveryTrackingStatus). Third-party: a per-store Stuart courier configuration at /api/v1.0/stuart/settings/{storeId} plus Okestro, Ondway, Nash, Stuart and VROMO on www.flipdish.com/integrations, with v3 modelling the distinction as delivery.deliveredBy ['Client' - the restaurant fulfils the delivery itself; 'External' - a marketplace or third-party courier delivers]. Named shortfall: the StuartSettings object is closed and its only automatic rules are TransportPrices ('If the order exceeds are certain amount this configuration will determine a new vehicle type' - order value to vehicle class, not in-house to courier) and CancelOrderIfStuartCancelDelivery (courier cancellation to order cancellation). There is no no-driver-available trigger, no out-of-zone trigger and no wait-time threshold anywhere in the 27.6MB v1.0 reference or the v3.0 reference, and deliveredBy is set on the sale at ingest rather than re-evaluated. Any portal-side dispatch rule would be documented on help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/stuart_getstuartsettings · retrieved 2026-08-09 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

One of the three named marketplaces is a first-party channel; two are not. The sales-channel schema enumerates type as a closed list - POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats, Deliveroo - with no DoorDash and no Grubhub, and 'grubhub' is a zero-hit across all four Flipdish corpora (v1.0 reference, v3.0 reference, the ten off-index guides, and www). Correction to the earlier note, which said DoorDash 'is not named': Flipdish's status page publishes a live production component 'DoorDash Drive Order Fulfillment' (operational, created 2022-12-07, last updated 2026-06-16) and the v3 audit-log schema uses 'doordash.job_updated' as its worked example event name. That is DoorDash DRIVE - white-label courier fulfilment - not the DoorDash marketplace, so it does not satisfy this claim, but the blanket absence statement was wrong and is withdrawn. The GA v1.0 surface cannot enumerate marketplaces at all: its Channel object is {ChannelId, TranslationKey, Source Internal|External, LogoUri, Available, MaintainedExternally} behind /api/v1.0/{appId}/channels/available-channels, a data-driven list with no vendor names. Middleware paths remain on offer alongside the direct ones - Deliverect, ItsaCheckmate and UrbanPiper are all named on www.flipdish.com/integrations. The v3 sales-channel endpoints carry the beta notice. https://developers.flipdish.com/reference/getsaleschannelsbyorgidandpropertyid · retrieved 2026-08-09 adversarially verified

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

Re-grounded on the GA v1.0 API; the previous grade-B citation was a marketing feature page. An order arriving from an external channel is an ordinary Flipdish Order object, not a separate marketplace ticket type: the Order schema carries Channel (a $ref to the Channel object), 'ChannelOrderId' described as 'ChannelOrderId from external channel' and 'ChannelOrderDisplayId' likewise, alongside exactly the same DeliveryType, OrderItems, FulfillmentStatus state machine and OrderDropOffLocation as a first-party order, so nothing has to be re-keyed. Manual accept is optional rather than mandatory: the store payload carries 'AutomaticallyAcceptOrders' - 'True if the stores orders are automatically accepted in Flipdish' - and the permission set includes UpdateOrdersAccept / UpdateOrdersDispatch for the manual path. Printers are modelled as store-assigned devices (PrinterAssignedToStoreEvent, PrinterUnassignedFromStoreEvent, PrinterTurnedOnEvent/OffEvent, PrinterHub), and flipdish's status page runs 'Third Party Delivery Integrations' and 'SIM Printers' as live production components. Marketing corroborates in plain words - 'Flipdish automatically syncs orders from all your marketplace platforms straight into your POS and kitchen' - and no injection-latency figure or failure-mode documentation is published in either API version. https://developers.flipdish.com/v1.0/reference/getorderbyid · 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

Correction: the earlier shortfall - 'channel-specific markups are not documented (price bands exist as a separate object)' - is withdrawn, because the sales channel is what a price band binds to. The sales-channel schema carries both 'menuId' and 'priceBandId', and the v3 menu structure gives every CategoryItem and ModifierItem a pricingProfiles[] array with 'one per price band', each profile defining 'separate prices for four dispatch types: Collection, Delivery, DineIn and TakeAway'. Channel-specific pricing is therefore exactly what the model is for. Menu, modifiers and photos all travel: menu.published.v1 fires 'when a menu is (re)published to a sales channel that belongs to your marketplace' and 'the payload includes the full published snapshot so you usually don't need a follow-up GET' - categories, items, modifiers, pricingProfiles, charges - with imageUrl on category, item and modifier group; Menu Management also exposes /menuManagement/orgs/{orgId}/menus/headers, /menus/{menuId}/current and /revisions/{revisionId}. The real shortfall is that Flipdish does not write to the marketplace. The guide's own sequence is 'Flipdish - menu.published.v1 webhook - your platform / Your platform GETs the menu revision from Menu Management API', after which the partner POSTs .../salesChannels/{salesChannelId}/menu-publish-status 'so the merchant sees the publish status in the portal'. A listing is only in sync if the partner implements the mirror, and the whole v3 surface carries the beta notice. https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

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

Bidirectional and documented, but partner-mediated. Outbound: menu.item.snoozed.v1 / unsnoozed.v1 carry menuId, menuRevisionId, menuItemId and an expiry ('Null if the snooze is indefinite'), and the guide tells the marketplace to 'Mirror these onto your marketplace listing'. Inbound: 'If a snooze on your marketplace originates from your side (e.g. driver reports an item out), report it via the Operations Updates API' - POST /operations-updates/orgs/{orgId}/properties/{propertyId}/salesChannels/{salesChannelId}/item-snooze-status with requestedStatus Snooze|UnSnooze. Item and item-option are both covered (the menu snooze itemType enum is menu.item|menu.option). The GA v1.0 surface has no snooze vocabulary at all ('snooze' is a zero-hit across its 1,064 pages); its nearest equivalent is the permission UpdateMenuItemsHideTemporarily, so the two-way contract above is v3-only and carries the beta notice. Shortfall: no near-real-time figure or SLA is published, and Flipdish emits the event but does not itself write to the marketplace. Correction to the earlier note, which said DoorDash is absent 'from the whole corpus': DoorDash is absent from the sales-channel type enum (UberEats, JustEats, Deliveroo), which is the sense that matters here, but it is not absent from Flipdish's material - the status page carries a live 'DoorDash Drive Order Fulfillment' component and the v3 audit-log schema uses 'doordash.job_updated' as its example event name. Both are courier fulfilment, not a snoozeable marketplace listing. https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

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 whole sales channel can be snoozed from Flipdish, and the snooze is timed: the sales_channel_snoozed_v1 payload requires 'expiry' - 'The expiry datetime of the snooze in ISO-8601 UTC format. Null if the snooze is indefinite' - so auto-reactivation at a set time is documented, contrary to an earlier reading. The channel is identified by salesChannelType from the enum UberEats, JustEats, Deliveroo, ExternalApp, POS, KIOSK, MobileApp, WebApp, Flipdish*. Shortfall: Flipdish publishes the event and the marketplace integrator is instructed to mirror it onto its listing, so Flipdish does not itself pause the third-party storefront; the reverse-direction endpoint POST .../store-snooze-status takes only requestedStatus and success, with no expiry; and DoorDash and Grubhub are not enumerated channel types. All beta. https://developers.flipdish.com/reference/post_sales-channel-snoozed-v1 · retrieved 2026-08-09 adversarially verified

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

CLAIM: 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. VERDICT: partial - the commission itemisation exists per marketplace and is documented; the DEPOSIT MATCH and the missing-order detection do not. EVIDENCE FOR: 'POS Venue Commissions Report' - 'The POS Venue Commission Report is a breakdown of commissions per venue (Ordering Channel). Your ordering channels include both first-party Flipdish orders and any third-party marketplaces integrated with your POS', with 'Key Terms - Net Order Price Incl Tax... Venue Commission: Any commissions charged to your restaurant by your Ordering Channels. Commission %: The % of the Net Order Price, Including Tax, that applies to Venue Commission', grouped Property > Venue Code over a chosen date range. SHORTFALL (named): the report is built from POS-recorded orders and never touches a marketplace deposit; there is no marketing-fee line, no refund/adjustment line and nothing that flags an order the marketplace did not pay for. The payouts documentation ('How do I understand my payouts?', 'How and when are Flipdish payouts issued?') reconciles the FLIPDISH payout into the merchant's bank account only - Uber Eats, Just Eat and Deliveroo pay the merchant directly and none of the 3rd-Party Order Management articles mentions their deposits. CONTROLS: `reconcil*` scores 9 across 518 articles and every hit is Flipdish-payout or sales-report arithmetic; `marketplace` 56, all menu sync, opening hours, order ingest or US marketplace-facilitator tax. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585497-pos-venue-commissions-report · retrieved 2026-09-17 adversarially verified

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

Re-grounded on the shipped surface. v1.0 publishes a per-delivery webhook log at GET /api/v1.0/{appId}/webhooks/{oauthAppId}/subscriptions/{webhookSubscriptionId}/logs whose WebhookLog schema carries WebhookEventName, WebhookSubscriptionCallbackUrl, HttpResponseStatusCode, HttpResponseStatus, RequestHeaders, RequestBody, ResponseHeaders, ResponseBody, Duration and RetryCount, alongside a test-fire endpoint at .../events/{eventName}/test; both are unmarked in a corpus that marks its exceptions (8 of 1,064 v1.0 pages carry a marker, all ALPHA). On v3.0, menu.validation.failed.v1 is 'Generally available' and fires when 'a menu fails validation after a publish attempt', which is the documented way to detect a failed publish rather than inferring it from silence. Named shortfalls. (1) The injection-error half is weaker than previously recorded: the menu-publish-status callback an integration reports failures through belongs to Operations Updates, which the marketplace guide places in closed beta behind integrations@flipdish.com, and sales.pos.status.updated.v1 -- cited in the earlier note -- is marked 'Deprecating soon'. (2) Everything above is programmatic and integrator-facing: no operator-facing channel-health dashboard, connection-status view or failure alerting is documented on either developer host, and the portal manual (help.flipdish.com) is excluded by policy, so the operator-visibility half of the claim is unevidenced rather than refuted. https://developers.flipdish.com/v1.0/reference/getwebhooklogs · retrieved 2026-08-09 adversarially verified

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

Guest-facing and explicitly documented, but on Flipdish's domain rather than the restaurant's - which is the half of the claim that fails. GET /api/v1.0/orders/{orderId}/deliveryinfo is described as 'Returns an orders delivery information. This would be used to display the latest known delivery information on a screen' and returns OrderDeliveryInformation {OrderId, ExternalReferenceId, TrackUrl, Status, DeliveryStatusNotes, ErrorMessage, IntegrationCode, IntegrationName}; the page's own worked response is TrackUrl 'https://deliverytracking.flipdish.com/713144192', Status 'Accepted', DeliveryStatusNotes 'Driver: Ryan (+353 20 913 2725)', IntegrationName 'Flipdish Delivery'. The state driving it is real driver state, not order state alone: Status is the enum None|Unassigned|Unaccepted|Accepted|Carrying|OnTheWay|ArrivedAtLocation|Delivered|CannotDeliver, mirrored on the order itself as DeliveryTrackingStatus alongside DriverId and a 6-character OrderTrackingCode, and there is a dedicated customer-side event, OrderCustomerTrackingCreatedEvent, whose payload CustomerDeliveryTrackingOrder is documented as 'the order data required for customer driver tracking' (order lines, prettified address, delivery notes, store phone number, AppIconUrl, OrderTrackingCode, payment method, last four digits). Shortfalls: the tracking host is deliverytracking.flipdish.com, a Flipdish domain, and the only branding field in the customer payload is AppIconUrl, so this is not the restaurant's own domain; no SMS-link surface is documented in either API version (Twilio SMS and Vonage SMS appear only as status-page components); and live driver coordinates exist but on the operator side - the Stuart courier job exposes JobDriver {DisplayName, Phone, PictureUrl, TransportType, Latitude, Longitude} and a JobEta {Pickup, Dropoff} through /api/v1.0/stuart/jobs/{jobId}, with nothing documenting that a map is rendered to the guest. https://developers.flipdish.com/v1.0/reference/getdeliveryinformation · retrieved 2026-08-09 adversarially verified

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

The v1.0 API defines the quote as a constant. GET/POST /api/v1.0/stores/{storeId}/leadTimes returns OrderLeadTimes, documented verbatim as 'When orders are accepted, and no lead time is specified by the operator, this is the lead time that will be applied to the order', with LeadTimeMinutes as 'Mapping from the type of order to the default lead time that will be applied to those orders. The lead time is an integer number of minutes', and a LeadTime object requiring DispatchType ('There are two valid values for this field - collection and delivery') and LeadTimeMinutes. So the promise is a fixed per-store, per-dispatch-type number, with the only variation being a manual operator override at acceptance (the order's AcceptedFor field, 'Time store has accepted the order for'). None of the three inputs the claim requires feeds that number. Zone drive time: the DeliveryZone schema is fully enumerated as {Id, FeeChargedToStore, DeliveryFee, MinimumDeliveryOrderAmount, WellKnownText spatial polygon, IsEnabled} with no drive-time, ETA or travel-duration field. Kitchen load: the one load-aware control, StoreOrderCapacityConfig, caps how many orders may be requested per interval rather than lengthening the quote when load rises, and over-capacity is handled by rejection (the order RejectionReason enum includes 'TooBusy'). Driver availability: correcting an earlier statement that the driver surface is 'invite/assign/unassign only' - it is not. Flipdish's Stuart courier surface (/api/v1.0/stuart/jobs/{jobId}) returns JobEta {Pickup, Dropoff}, a JobDriver with Latitude and Longitude, a job Duration and a per-delivery TrackingUrl, and the order-ingest/submit endpoint accepts an inbound EstimatedDeliveryTime from an external channel. But all of that is post-dispatch courier telemetry or a third party's own figure arriving with the order; nothing feeds either back into leadTimes, and the quote the guest sees at order time remains the stored constant. Flipdish also makes no dynamic-ETA claim on www: /pos-system/delivery-driver-tracking mentions 'tracking rider availability and optimising order preparation' but never says the guest-facing quote moves, and /delivery is silent on ETAs. Scope note: this scores the documented quoting mechanism across Flipdish's own v1.0 and v3.0 APIs; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/setstoreleadtimes · retrieved 2026-08-09 adversarially verified

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

delivery-offline-behavior

CLAIM: vendor documents explicit offline behaviour for delivery (cash orders, driver assignment, driver settlement) during an outage. VERDICT: partial - a blanket statement exists, nothing delivery-specific. EVIDENCE: 'Is there an offline mode on the Flipdish Point of Sale?' (https://help.flipdish.com/en/articles/9585187) states in full: "The Flipdish POS does not support an offline mode. If you encounter persistent internet connectivity issues, it may be advisable to consider setting up a backup 'hotspot' network." 'Can the KDS and POS be set up on different internet networks?' (https://help.flipdish.com/en/articles/9585311) adds "Orders are synchronized through Flipdish services, allowing the devices to operate from different network connections" and instructs "Keep devices connected to the internet at all times"; its first troubleshooting step for tickets not reaching the KDS is "Confirm both devices have internet access." The vendor's own continuity article, 'How to keep accepting online orders if your Flipdish Terminal is not operational' (https://help.flipdish.com/en/articles/12733400), offers only two CLOUD routes - the Flipdish Terminal Android app or portal.flipdish.com Live View - and never a local one. SHORTFALL: no article states what happens to cash-on-delivery capture, to the POS driver list (https://help.flipdish.com/en/articles/13925672) or to the Cashing Up settle-up flow (https://help.flipdish.com/en/articles/9585298) during an outage; the global "does not support an offline mode" answers the delivery question only by implication. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585187 · retrieved 2026-09-17 adversarially verified

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

Branded ordering website sold on a flat per-site subscription (from EUR49 / USD119 per month) with no per-order marketplace commission; explicitly positioned as a Just Eat / Seamless alternative. https://www.flipdish.com/online-ordering · retrieved 2026-08-01

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 record feeds every channel. The SalesChannel schema makes menuId a required property of each channel, and the type enum spans POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats and Deliveroo - so the till, the website, the app and the kiosk can all reference the same menuId. POST /orgManagement/.../salesChannels/{id}/menu/publish publishes a menu to a channel, POST /menuManagement/orgs/{orgId}/menus/{menuId}/revisions/{revisionId}/publish takes an 'Optional list of Sales Channel IDs to publish to', and GET /menuManagement/orgs/{orgId}/menus/{menuId}/references returns 'all properties and sales channels referring to a menu'. No separate digital menu build is documented anywhere. Caveats: the schema notes a channel 'can have a different menu associated with it', so single-source is a configuration rather than an enforced invariant, and these endpoints are in beta. https://developers.flipdish.com/reference/publishmenutosaleschannel · retrieved 2026-08-09 adversarially verified

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

Branded mobile apps are a distinct product and price tier (Website & Mobile App from EUR79 / USD199 per month). https://www.flipdish.com/online-ordering/mobile-apps · retrieved 2026-08-01

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

Consumer profile carries saved card and saved address across every Flipdish-powered site: 'if you consent to have your card details retained, they will be available when you place a digital order from a different store if it is also on the Flipdish Platform', and 'your details, such as name and delivery address, will appear when you are logged in to any Flipdish-powered app or website'. Cards are tokenized by Stripe, not stored by Flipdish or the store. Repeat ordering is attested only on the vendor's mobile-app marketing page (grade C): 'Flipdish saves your customer's last order so they can quickly go through the ordering flow' and 'From automatically populating addresses to remembering their last order'. https://www.flipdish.com/consumer-information/card-details · retrieved 2026-08-08

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

Rules-light 'menu upsells' surface popular items at checkout/kiosk; no attach-rate reporting documented. https://www.flipdish.com/online-ordering · retrieved 2026-08-01

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

Upgraded on evidence the first pass missed by searching only the 99-page v3.0 corpus: the throttling half is documented on the generally-available v1.0 API. GET /api/v1.0/{appId}/storeordercapacity/{storeId}/{deliveryType} and POST /api/v1.0/{appId}/storeordercapacity/{storeId} read and write a StoreOrderCapacityConfig of OrderCapacityPeriods, each a StoreOrderCapacityPeriod with DayOfTheWeek, PeriodStartHour/PeriodStartMinutes, PeriodEndHour/PeriodEndMinutes and MaxOrderNumberPerStoreInterval, documented verbatim: 'The maximum number of orders per each store order interval in this order capacity period. E.g. for a period from 9:00 till 11:00, if the store's interval is 10 minutes, and MaxOrderNumberPerStoreInterval is set to 5, it means that within each 10-minute interval between 9:00 and 11:00 (i.e. 9:00-9:10, 9:10-9:20, .. , 10:50-11:00) it will be possible to request at most 5 orders.' It is set per deliveryType (Delivery|Pickup), there is a matching portal permission EditStoreOrderCapacity and a store.order_capacity.updated event, so slots are capped per daypart and stop taking orders once the cap is reached. The slot grid itself comes from PreOrderConfig at /api/v1.0/stores/{storeId}/preorderconfig/{deliveryType} (LeadTimeMinutes, IntervalMinutes, MaxOrderAheadDays, CutOffTimeCurrentDayBasic, CutOffTimePreviousDayBasic, IncludeAsap, RequireExplicitSelectAlways) with a /preview endpoint. Scheduled orders themselves stay documented on v3.0: a sale carries requestedFulfilmentTime plus isAsap, and 'if requestedFulfilmentTime is more than ~1 hour away the requested time is honoured and the sale is treated as scheduled'. Maturity: every v1.0 page cited here is unmarked in a corpus that marks its exceptions (only 8 of 1,064 v1.0 pages carry a marker, all ALPHA, none of them these). Residual gap: the cap counts orders, not items, per slot. https://developers.flipdish.com/v1.0/reference/getstoreordercapacity · retrieved 2026-08-09 adversarially verified

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

The generally-available v1.0 Order schema enumerates the fulfilment surface: DeliveryType [Delivery, Pickup]; PickupLocationType [TakeOut, TableService, DineIn]; and TableServiceCatagory [Generic, Villa, House, Room, Area, Table, ParkingBay, Gate, DriveThrough, Team] -- so a parking-bay (curbside) and a drive-through collection point are modelled, which the earlier note missed. Store settings carry per-mode switches: TakeOutEnabled, TableServiceEnabled, DineInEnabled, PickupEnabled, DeliveryEnabled, PreOrderEnabled and AllowPreOrdersAndTableService. Mode-specific fees and prep timing are documented too: menu pricingProfiles carry collectionPrice / deliveryPrice / dineInPrice / takeawayPrice, charges[] has a Delivery type, and PreOrderConfig (lead time, interval, cut-off) is configured per deliveryType. v3.0 adds dispatchType [DineIn, TakeAway, Collection, Delivery] on the sale object. Named shortfalls. (1) Arrival check-in is not documented anywhere on either developer host: the only arrival concept in the 1,064-page v1.0 corpus is the courier-side DeliveryTrackingStatus value ArrivedAtLocation, and there is no guest 'I am here' signal, so curbside is a location type rather than a check-in flow. (2) The string 'QR' appears zero times in both developer corpora (99-page v3.0 and 1,064-page v1.0), so the earlier note's 'QR table ordering exists' is not supported by the developer documentation -- table service is modelled, but the QR mechanism is a portal/marketing claim and help.flipdish.com is excluded by policy. https://developers.flipdish.com/v1.0/reference/getorders · retrieved 2026-08-09 adversarially verified

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

Shortfall: the QR order does not attach to a POS check, and there is no tab or bill split. Guest-facing scan-to-order works and table-specific codes pre-fill the table number at checkout, but Flipdish's Table Ordering FAQ states 'Can I get the orders assigned to the tables I have set up on our POS? Not at the moment, the table numbers are going to your POS as a note. They will be printed on your receipts', and 'Can my customers open a tab and pay at the end of their meal? No, customers must pay in advance for their order unless they choose to pay cash'. Tipping is available on the online checkout via Portal tip configuration; splitting the QR bill is not documented anywhere. https://help.flipdish.com/en/articles/9585439-table-ordering-and-qr-code-faq · retrieved 2026-09-17

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

K2 (24" floor/wall), K2 Mini (15" tabletop) and D2S countertop kiosks with integrated card readers, running the same online-ordering menu; loyalty and tipping supported. Accessibility is aspirational rather than certified. https://www.flipdish.com/online-ordering/kiosks · 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

CLAIM: 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. VERDICT: no. EVIDENCE: the multi-participant case the vendor addresses is the dine-in QR flow, and there each participant places a SEPARATE prepaid order: "customers must pay in advance for their order", and to add more courses the guest must "RESCAN the QR code to place additional drinks and dessert orders" (https://help.flipdish.com/en/articles/9585439). No shared cart, invite link or cap exists anywhere in the ordering documentation. CONTROLS: 'group order' 0, 'group ordering' 0, 'shareable link' 0, 'spend cap' 0, 'per-person limit' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585439 · retrieved 2026-09-17 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

CLAIM: a distinct catering ordering portal or flow. VERDICT: no. EVIDENCE/CONTROLS: 'catering' has exactly 1 hit across all 518 bodies and it is POISON - a worked example of a rejected delivery address naming a fictional store, "Sorry, your order can not be accepted by Mexican CATERING as there is an issue with your address or location"; 'banquet' 0, 'event order' 0. The dispatch types the vendor does enumerate are delivery, collection, dine-in/table, kiosk, drive-through collection (https://help.flipdish.com/en/articles/9689466) and scheduled pre-orders ('Configure Pre-ordering'), all landing in the one order queue. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9689466 · retrieved 2026-09-17 adversarially verified

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

Same as order-capture-voice-ai: upheld, but re-source off the '-draft' page onto the launch release. Note it is a priced add-on, not included in the EUR99 bundle, and restricted to UK/IE plus unnamed 'select international markets'. https://www.globenewswire.com/news-release/2025/11/19/3190837/0/en/flipdish-launches-ai-phone-agent-to-ensure-every-call-becomes-an-order.html · retrieved 2026-08-01 adversarially verified

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

digital-drivethru-ai

CLAIM: AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers, with escalation-to-human handoff. VERDICT: no. EVIDENCE: Flipdish's drive-thru product is now documented and it is a COLLECTION POINT, not a lane. 'Configure Drive-Through Collection' (4 May 2025): 'Drive-through collection with Flipdish allows you to offer a convenient pickup option where customers can collect their orders without leaving their car. Your restaurant does not need to have a traditional drive-through window or setup to activate this option'; 'Supported locations: Flipdish allows for customized location naming... Some examples include: Zone A / Zone B / Car park spot A2837 / Car park spot A2838'; 'To enable this feature, please contact [support]'. The order is placed on web or app first ('Example of Drive-Through on Web / Example of Drive-Through on Mobile App') and throttling is recommended. CONTROLS: `lane` 0, `speech` 0, `headset` 0 across all 518 articles; `drive-thr*`/`drive-through` scores 12 and ALL TWELVE are inside this one collection article; `voice` scores 2 - the recorded message in Flipdish Phone Marketing and a printer's voltage voice broadcast; `intercom` scores 518 and is the Intercom help-centre platform footer on every page, never a speaker post. The only conversational product in the corpus is Flipdish Phone Marketing, an inbound IVR on a Flipdish-issued VOIP number that offers the caller 'Receive an SMS with a link to visit your website or download your mobile app' or 'Be put through to the restaurant' - it takes no order. This matches the v1.0 PickupLocationType enum (Generic, Villa, House, Room, Area, Table, ParkingBay, Gate, DriveThrough, Team) and the closed sales-channel enum Ios, Android, Web, Kiosk, Pos, Google. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9689466-configure-drive-through-collection · retrieved 2026-09-17 adversarially verified

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

digital-sms-ordering

The text-a-link branch of the claim is documented as a product feature: 'Automatically send an SMS to your phone customers to prompt them to order online, freeing up staff and increasing revenues' -- an automated outbound SMS that diverts a caller into Flipdish's own ordering flow, whose orders land in the Flipdish POS and KDS ('All your delivery orders flow straight into your Flipdish POS system, where they get categorised, colour-coded, and displayed on your Flipdish Kitchen Display System', /delivery). Named shortfalls: it is a one-way prompt, not an ordering channel -- the guest completes the order on the web, not over SMS; no conversational SMS or chat ordering, reordering-by-text or two-way message parsing is documented on www or in the 99-page developers.flipdish.com corpus, whose only conversational product is the inbound AI Phone Agent (voice). Elsewhere on www SMS appears purely as a marketing channel (/marketing) and as a receipt/notification channel. Grade C: this is a vendor feature page, not documentation. [Retrieved via: direct fetch of www.flipdish.com (permitted host; no ClaudeBot directive in robots.txt).] https://www.flipdish.com/online-ordering · retrieved 2026-08-09

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

Flipdish's own product-update post documents the integration: 'It pulls the menu from your Flipdish website into Google Search and Google Maps, so people can order, without leaving Google.' Named shortfalls: (1) this is a grade-D vendor announcement -- the claim carries differentiator weight, which needs grade A or B for a yes, and the configuration documentation sits in help.flipdish.com, excluded from this sweep by policy; (2) the post states the feature 'will be rolling out to stores across the UK' over the following weeks and no permitted page states current availability outside the UK; (3) neither 'Google Business Profile' nor 'Preferred by Business' appears -- nothing on a permitted host says the direct ordering link is provisioned as the preferred ordering action ahead of marketplace links, which is the part of the claim that distinguishes real placement from mere presence. www.flipdish.com/integrations does not list Google in any category. [Retrieved via: direct fetch of www.flipdish.com (permitted host; no ClaudeBot directive in robots.txt).] https://www.flipdish.com/us/resources/blog/the-dish-september-23 · retrieved 2026-08-09

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

CLAIM: 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. VERDICT: no, on an asymmetry that is now measurable: Flipdish ships a documented listings-management integration for GOOGLE and none for Apple. EVIDENCE: three dedicated articles cover the Google side - 'Sync your Google Business Profile through the Flipdish Portal', 'How to optimise your Google Business Profile (GBP)' and 'Google Business Profile: adjust map pin to sync with Flipdish' - and `Google Business Profile` scores 37 hits across the corpus with a portal sync surface and a teammate permission. CONTROLS: `Apple Business Connect` 0, `Apple Maps` 0, `business connect` 0 across all 518 articles; `listing*` scores 11 and every hit is Google Business Profile or a signage player list. The `Apple` hits in the corpus are the Apple Developer account / App Store distribution articles and Apple Pay. Consistent with the prior pass: Order with Google is plumbed as a first-class channel (voucher ChannelRestrictions closed at Ios, Android, Web, Kiosk, Pos, Google; StoreFeeConfig carries PercentFeeOrderWithGoogle and FixedFeeOrderWithGoogle) while there is no listings, place or business-profile resource for Apple in either API version. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/12089204-sync-your-google-business-profile-through-the-flipdish-portal · retrieved 2026-09-17 adversarially verified

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

Marketing-page only, and thin. The single accrual description is 'Reward customers who order regularly. Flipdish will even let them know how close they are to their next discount!' The kiosk page adds 'redeem vouchers and collect loyalty'. There is no documentation of enrolment, identity resolution across channels, ledger, or redemption at POS — and no customer or loyalty object exists in the public API to corroborate any of it. https://www.flipdish.com/marketing · retrieved 2026-08-01 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

CLAIM: guest subscription / membership programmes (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform. VERDICT: no. EVIDENCE: the guest-side monetisation primitives documented are vouchers, loyalty campaigns, retention campaigns and Credit Books - and the last of these is a B2B corporate account settled by manual monthly billing, not a recurring guest charge (https://help.flipdish.com/en/articles/9585149). No recurring guest billing appears anywhere in the census. CONTROLS, where the poison is overwhelming: 'subscription' 108 hits, every one either FLIPDISH'S OWN BILLING TO THE MERCHANT ('Subscription billing information', 'Monthly Invoices', 'Update subscription payment method', 'How can I request my Flipdish subscription invoices') or a MODULE ENTITLEMENT ("an active 'Inventory Management' service subscription", "an active Account Subscription on the POS", "A subscription to our Food safety module"); 'membership' 27 hits, ALL of them Apple Developer Membership renewal articles. Guest-facing recurring billing: 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585149 · retrieved 2026-09-17 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

Vouchers, discounts and loyalty are defined centrally and run across Flipdish channels; per-channel eligibility controls are not documented. https://www.flipdish.com/marketing · retrieved 2026-08-01

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

T&Cs: 'You retain ownership of all content and data provided by you', and marketing positions Flipdish as building the operator's own customer database. But the privacy policy states Flipdish acts as controller for consumer ordering data and processes it 'for its own independent purposes, such as platform security, analytics, and service improvement', and no fee-free self-serve bulk export is documented. https://www.flipdish.com/privacy-policy · 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

Flipdish operates the checkout itself rather than handing card fields to the restaurant's own page -- ordering runs on Flipdish-built websites, apps and kiosks with 'Integrated payments' (/docs/pos-features) and Flipdish 'Securely accept credit and debit cards with leading payment processors around the world' -- and it asserts 'Built-in PCI compliance to prevent security breaches and card data theft'. Named shortfalls, each a specific element of the claim left unpublished on the permitted hosts: (1) no PCI DSS version is stated anywhere on www, so the 4.0 requirement is unevidenced -- the only versioned mention is a competitor-fee explainer defining 'PCI DSS Monthly Fees' generically (/us/resources/blog/payment-processing-fees); (2) no client-side script-integrity or payment-page-script-inventory claim (the 6.4.3 / 11.6.1 requirements effective March 2025) appears at all; (3) no Attestation of Compliance, Level, or trust/security page exists -- www.flipdish.com/legal links only T&Cs, privacy, cookies, the EU DSA statement and the EU Accessibility Act statement; (4) 3DS/SCA is documented by Flipdish only in help.flipdish.com, which is excluded from this sweep by policy, so it cannot be cited here. /pos-system/payments itself says only 'Fraud detection that works' and 'Advanced tools spot risks early'. [Retrieved via: direct fetch of www.flipdish.com (permitted host; no ClaudeBot directive in robots.txt).] https://www.flipdish.com/products-overview · retrieved 2026-08-09

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

Partial. Present: fee configuration is channel-aware and does pass to the guest. StoreFeeConfig (/v1.0/reference/getstorefeeconfig) is a per-store matrix of percent and fixed fees split by tender and channel - PercentFeeCardOrders / PercentFeeCashOrders, ...Web, ...Kiosk, ...LocationService, PercentFeeCardPosTransaction, PercentFeeDelivery, PercentFeeTips / TipsCollection / TipsDelivery, PercentFeeOrderWithGoogle - and each digital channel has an explicit guest pass-through pair, e.g. PercentFeeCardOrdersChargedToCustomerIncludingVat and FixedFeeCardOrdersKioskChargedToCustomerIncludingVat, alongside a TaxRatePercent. ProcessingFeeConfig (/v1.0/reference/getprocessingfeeconfigsbystoreid) states the intent in words: per store and per PaymentAccountType (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken), a PercentFee and FixedFee described as 'Percent fee to customer, including VAT'. A separate store-level ServiceCharge object (/v1.0/reference/configurestoreservicecharge) carries PercentageValue ('The Default Service Charge Value'), Enabled, IsOptional ('Sets the service charge to be optional'), DisplayWithProcessingFee ('Display service charge together with processing fee') and IncludesVouchers, and is set on the store rather than per channel, so it applies uniformly. Named shortfalls: (1) surcharging is dimensioned by payment ACCOUNT TYPE, not by card brand - there is no Visa/Mastercard/Amex attribute and nothing that could suppress a surcharge for a prohibited brand; (2) there is no jurisdiction, state or country attribute on any fee object, so no prohibited-jurisdiction handling is expressible; (3) there is no dual-price pair on a menu item and no cash-discount construct anywhere in the 27.6MB v1.0 dump or the 99-page v3.0 dump; (4) the only guest-facing disclosure control is the DisplayWithProcessingFee boolean - there is no disclosure-text field; (5) parity with the POS is not actually symmetric: the POS lines PercentFeeCardPosTransaction and FixedFeeCardPosTransaction have no ...ChargedToCustomer counterpart, so guest pass-through is configured for web, kiosk and location service but not, in this schema, for the POS card transaction. StoreFeeConfig's own field descriptions are empty strings; the reading rests on the field names plus ProcessingFeeConfig's explicit wording. help.flipdish.com is excluded by policy, so the merchant-facing fee screens were not read. https://developers.flipdish.com/v1.0/reference/getstorefeeconfig · retrieved 2026-08-09

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

A marketing CRM aggregates customer value and order frequency across Flipdish channels; documented dedup/merge behaviour between POS, web and kiosk identities is absent. https://www.flipdish.com/marketing · 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

The sale 'customer' object carries id (Flipdish customer UUID), externalId, name, contactPhoneNumber and emailAddress, and the guide publishes explicit availability tables for what marketplaces actually deliver. Present: 'Marketplace order with international-format phone - UberEats, Deliveroo, JustEat, etc. forward a phone already in international format'. Absent: 'Most major marketplaces (UberEats, Deliveroo, JustEat) do not share customer email addresses for privacy/contractual reasons - emailAddress will be absent for these orders', and where a platform masks the number 'The relay is not the customer's real number, so contactPhoneNumber is absent' (only contactMaskingCode is set). Shortfall: marketplace orders are therefore not anonymous tickets - a name and usually a phone attach - but email is documented absent for the three major marketplaces, Deliveroo arrives masked, and nothing in the 99-page developer documentation says a marketplace order creates or links to a native Flipdish customer profile (customer.id: 'If provided, must reference an existing customer - omit or leave empty if unknown'). Whether the Portal attaches these to a guest profile is a product-manual question and help.flipdish.com is excluded by policy. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09

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

Loyalty rewards recurring customers with visible progress toward a discount; only one accrual model is described publicly. https://www.flipdish.com/marketing · retrieved 2026-08-01

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

guest-loyalty-tiers

Positive absence, from the complete schema of the loyalty program itself. The v1.0 API defines loyalty as one object, LoyaltyCampaign, created and updated through /api/v1.0/{appId}/campaigns/loyalty, and its full property list is CampaignId, PublicId, AppId, Stores / StoreIds, Statistics, IsEnabled, OrdersBeforeReceivingVoucher ('Number of orders customer needs to make, before receiving voucher'), PercentDiscountAmount (1-100), MaxDiscount, RoundingStrategy, ShouldIncludeOrdersWithLoyaltyVoucher, VoucherValidPeriodDays (1-300), IncludeDeliveryFee, AutoApplyResultingVouchers, IncludeExistingOrders and ForceDiscount. That is a single-threshold stamp card: count orders, issue one percentage voucher. There is no tier, level, status, rank, points-balance, rolling-window, promotion or demotion field; the campaign has no spend dimension at all, only an order count. Corroborating in the same corpus: the closed voucher sub-type enum is None, SignUp, Loyalty, Loyalty25, Retention, SecondaryRetention, Custom (/v1.0/reference/updatevoucher), which is the platform's complete set of automatically issued lifecycle vouchers and contains no tier; the Customer object is CustomerId, RegistrationDate, PhoneNumber, CashOrdersEnabled, CardOrdersEnabled, MarketingEnabled with no status field (/v1.0/reference/getcustomerbyid); the App permission enum's loyalty entries are View/Create/Update/DeleteCampaignsConfigurations plus StampLoyaltyCardAgainstCampaignsConfigurations (/v1.0/reference/getapp-1) - the vendor's own word for the mechanic is a stamp card; and the strings 'tier' and 'Tier' occur zero times in the 27.6MB v1.0 dump and zero times in the 4.6MB v3.0 dump. www.flipdish.com/marketing describes the same single threshold in prose: 'Reward customers who order regularly. Flipdish will even let them know how close they are to their next discount.' Scope of the finding: loyalty is fully modelled in the published API rather than being Portal-only, so this is an enumeration of the loyalty program, not merely of an integration surface; help.flipdish.com was not read. https://developers.flipdish.com/v1.0/reference/createloyaltycampaign · retrieved 2026-08-09

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

guest-loyalty-offline-behavior

CLAIM: documents explicitly what loyalty lookup, accrual and redemption do when the POS loses connectivity. VERDICT: partial. EVIDENCE: 'Is there an offline mode on the Flipdish Point of Sale?' (https://help.flipdish.com/en/articles/9585187) states in full: "The Flipdish POS does not support an offline mode. If you encounter persistent internet connectivity issues, it may be advisable to consider setting up a backup 'hotspot' network." 'Can the KDS and POS be set up on different internet networks?' (https://help.flipdish.com/en/articles/9585311) adds "Orders are synchronized through Flipdish services, allowing the devices to operate from different network connections" and instructs "Keep devices connected to the internet at all times"; its first troubleshooting step for tickets not reaching the KDS is "Confirm both devices have internet access." The vendor's own continuity article, 'How to keep accepting online orders if your Flipdish Terminal is not operational' (https://help.flipdish.com/en/articles/12733400), offers only two CLOUD routes - the Flipdish Terminal Android app or portal.flipdish.com Live View - and never a local one. SHORTFALL: no queue-and-reconcile or blocked-at-till statement is made for loyalty specifically in 'Omni-channel Loyalty: Overview' (https://help.flipdish.com/en/articles/9585702) or 'Enable omni-channel loyalty across all my Flipdish products' (https://help.flipdish.com/en/articles/10670564); the only documentation is the blanket no-offline-mode answer. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585187 · retrieved 2026-09-17 adversarially verified

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

guest-loyalty-offer-stacking-rules

Partial. Present: the v1.0 voucher object exposes precedence and exclusion as real configuration. Each voucher carries TakesPriority ('Takes priority'), ForceDiscount ('Force the discount to be applied which bypasses some menu restrictions'), IsAutomaticallyApplied, ValidOnOrdersOver ('Valid on orders on or above'), IsValidOncePerCustomer, IsValidOnlyOnce, IsValidForFirstOrderOnly, MaxRedemptions, ValidityPeriods (day-of-week windows) and ChannelRestrictions (Ios, Android, Web, Kiosk, Pos, Google); LoyaltyCampaign and RetentionCampaign each carry their own ForceDiscount, 'Controls whether the voucher generated from this campaign will override discount exclusions'. The exclusion side is set on the menu: the v3.0 menu item schema has disableVouchers ('Whether vouchers are disabled for this item') and excludeFromVoucherDiscounting. Named shortfalls: an order carries exactly ONE voucher - the v1.0 Order schema's Voucher property is a single OrderVoucherSummary object, not an array (/v1.0/reference/getorderevents) - and the v3.0 sale schema states 'Discounts always apply at the sale level - there is no per-line discount'. So there is no combinable-versus-exclusive setting because combining is not expressible, no ordered application sequence and no priority ranking beyond the single TakesPriority boolean, and no rule that says which of two priority vouchers wins. The Portal offer builder is documented on help.flipdish.com, which is excluded by policy, so the merchant-facing wording of these switches was not read. https://developers.flipdish.com/v1.0/reference/updatevoucher · retrieved 2026-08-09

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

Automated discounts can be sent to target customer segments built from customer value and order frequency; the rule surface is not documented. https://www.flipdish.com/marketing · retrieved 2026-08-01

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

Partial. Present: the platform computes lifecycle state itself. RetentionCampaign (/api/v1.0/{appId}/campaigns/retention) is defined by NotifyCustomerAfterMinutes - 'Time in minutes, after which customer will receive retention voucher if he/she does not order', minimum 1440 - so recency is evaluated per customer by Flipdish and a voucher is issued automatically; LoyaltyCampaign does the same on frequency via OrdersBeforeReceivingVoucher; and the closed voucher sub-type enum None, SignUp, Loyalty, Loyalty25, Retention, SecondaryRetention, Custom (/v1.0/reference/updatevoucher) names the resulting states - newly signed up, regularly ordering, lapsed, and a second lapse stage. The operator sets a threshold, not a query. Named shortfalls: there is no monetary dimension anywhere - no lifetime-value, average-spend or VIP construct on the Customer object, which is only CustomerId, RegistrationDate, PhoneNumber and three consent booleans (/v1.0/reference/getcustomerbyid); there is no segment, audience or cohort resource in any of the 1,064 v1.0 pages or the 99 v3.0 pages, and 'segment' occurs zero times in either dump, so a segment cannot be named, listed, counted or exported as an object; and the lifecycle states are not surfaced as labels on the guest, only as triggers that mint a voucher. What the Portal's customer screens show is documented on help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/createretentioncampaign · retrieved 2026-08-09

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

Retention campaigns automatically target inactive customers and acquisition campaigns target first orders; birthday and first-visit automations are not documented. https://www.flipdish.com/marketing · 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

Partial is correct but the note misstates it. SMS is NOT a self-serve native campaign tool — on /marketing it sits under the 'MANAGED MARKETING' heading as a done-for-you paid service ('our team will send SMS campaigns'), and Managed Marketing is listed as a separately-sold add-on on the pricing page. Email campaigns are confirmed absent from the page. So the partial rests on push notifications plus a paid managed service, not on native SMS. https://www.flipdish.com/marketing · retrieved 2026-08-01 adversarially verified

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

Shortfall: consent is a single global 'Receive promotions' boolean, not per-channel, and no timestamp or source-of-consent record is documented. What IS documented: customers default to opted-OUT with a GDPR-designed affirmative opt-in at signup (article 9585259); per-customer opt-in status is visible in the Portal; and revocation is honoured by several means — the profile toggle on web/app, an opt-out link in every marketing SMS (article 9585359), and staff-initiated opt-out from the Portal, which staff cannot reverse (only the customer can re-opt-in). POS-side opt-in for phone orders is a verbal confirmation logged against Caller ID (article 9585218) with no consent-source logging documented. https://help.flipdish.com/en/articles/9619309-customer-opt-in-out-for-marketing · retrieved 2026-09-17

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

guest-loyalty-10dlc-registration

CLAIM: handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform. VERDICT: no - neither limb, and the SMS product's own documentation now shows why. EVIDENCE: 'How do I send an SMS marketing campaign?' (6 Jan 2026) opens 'Requirements: UK and IE clients' - the operator-sent SMS product is not offered in the US or Canada at all, the only jurisdictions where 10DLC applies. Within UK/IE, FLIPDISH is the sender and the biller: 'There is a cost of GBP0.05/EUR0.05 per SMS sent payable before the campaign will be sent', 'the character limit is 160 of which 21 are reserved for the marketing opt-out link that we are legally required to include', and 'Finally you will be prompted for payment to complete the setup. Campaigns will not be sent if payment has not been made.' The second SMS path is the same shape: Flipdish Phone Marketing issues its own VOIP number ('Flipdish creates a new telephone number (VOIP) and assigns it to your online store') and sends the link SMS itself. Nowhere in the fully documented campaign flow (name, voucher, content, store selection, audience filter, schedule, pay) is there a registration step, a brand, a campaign id or a carrier-vetting wait. CONTROLS: `10DLC` 0, `A2P` 0, `brand registration` 0, `campaign registration` 0, `twilio` 0, `short code` 0, `sender id` 0 across all 518 articles - and 0 in both API dumps, where the only SMS config is SmsProviderCredential {OrgId, BrandId, SmsServiceType (Nexmo|Twilio|Default|MessageBird), SenderId, Username, AuthToken} with no registration field. `opt-out` scores 19 and is consent, not registration. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/11028817-how-do-i-send-an-sms-marketing-campaign · retrieved 2026-09-17 adversarially verified

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

guest-loyalty-campaign-attribution

'Campaign performance' is named as one of the Report Types: 'View reports on Costs, Sales, Sales Channels, Customers, Campaign performance, Payments, Staff Upsells, Menu Items Ordered, Mileage, Inventory, Payroll, Hourly Turnover and more.' www.flipdish.com/pos-system/reporting-and-analytics gives the matching use case - 'Easily highlight opportunities for growth such as continuing a marketing promotion that boosted sales'. Shortfall: this is a marketing feature list (grade D), which the differentiator grade floor bars from carrying a yes, and nothing on either permitted host states that redeemed offers are tied to actual check totals or that incremental (lift) sales are computed rather than gross sales inside a campaign window. The report's contents are documented only on help.flipdish.com, which is excluded from this sweep by policy. https://www.flipdish.com/products-overview · retrieved 2026-08-09

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 org-scoped read API documents 'List sales - paginated complete sale objects for sync or export', cursor-paginated with after/before filters on createdAt, returning the full PublicSale payload including the nested customer object (id, externalId, name, contactPhoneNumber, emailAddress). Credentials are self-provisioned: create a free account at portal.flipdish.com/signup, then Developer tools > OAuth apps > Add New, and use client_credentials (Getting Started). Shortfall: this is transaction history from which a guest list must be derived, not a guest list - the 90-page API reference exposes no customer, guest or loyalty-balance resource - the endpoint carries 'Beta Notice: this endpoint is currently in beta and may change without notice', the Sales Management API states 'Contact integrations@flipdish.com to request access', which is exactly the support ticket the claim excludes, and emailAddress is documented as absent for most major marketplace orders. Whether the Portal offers a self-serve CSV guest export is a product-manual question and help.flipdish.com is excluded by policy. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-09

Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator

guest-loyalty-cdp-event-api

Guest data is queryable but not subscribable. The v3.0 catalogue -- 'This page lists every event type available through Flipdish Webhooks (v3)' -- enumerates thirteen types across Menu Publishing, Menu Validation, Snoozes and Sales, and there is no customer, guest, loyalty or marketing-consent event among them; the sale.* family carries a customer object inline but fires on the sale, not on the guest. Correcting the previous note: guest resources DO exist on the v1.0 surface -- GET/POST /api/v1.0/{appId}/customers, GET /api/v1.0/{appId}/campaigns/loyalty, and two event logs, GET /api/v1.0/{appId}/events/customer/{customerId} and GET /api/v1.0/{appId}/events/order, both filterable by eventType, date range and storeIdList. The shortfall is the delivery model, not the data: both event logs make customerId a REQUIRED path or query parameter, so they are per-guest lookups for a customer you already know, not a feed a CDP can sweep or subscribe to. Ignore the boilerplate in the createWebhookSubscription blurb that names 'customer.created' as an example -- no such type appears in the catalogue. https://developers.flipdish.com/docs/flipdish-events-v3-overview · 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

A 'Customer Feedback App' is sold as a priced add-on; score-based routing to private recovery vs public review sites is not documented. https://www.flipdish.com/pricing · retrieved 2026-08-01

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

CLAIM: a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards. VERDICT: no. EVIDENCE: the guest-marketing mechanics documented across the census are loyalty campaigns (https://help.flipdish.com/en/articles/9585702), retention campaigns, vouchers and discount codes (created in the portal or on the POS, redeemable at checkout or by barcode scanner), push notifications, SMS campaigns and Flipdish Phone Marketing - none of which mints a per-guest code or attributes a referred guest's first order. CONTROLS: 'referral' 0 and 'refer a friend' 0 across all 518 bodies. (Flipdish's own 'Share Flipdish' scheme on www.flipdish.com is a B2B introduction bounty paid to merchants, not a merchant-configurable guest feature, and it does not appear in the product documentation at all.) BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585702 · retrieved 2026-09-17 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

CLAIM: issues an Apple Wallet or Google Wallet LOYALTY PASS with push-updatable balance, as an alternative to requiring a branded app download. VERDICT: no. EVIDENCE: loyalty here is account- and phone-number-based and is delivered inside the web/app ordering account - 'Omni-channel Loyalty: Overview' (https://help.flipdish.com/en/articles/9585702), 'Enable omni-channel loyalty across all my Flipdish products' (https://help.flipdish.com/en/articles/10670564), 'How can customers track their loyalty campaign progress' and 'On the Flipdish Point of Sale, what does the option to "Pay" with loyalty card mean' - and the handheld guide's loyalty instruction is "Ask customers for their phone number so they can earn loyalty rewards" (https://help.flipdish.com/en/articles/11508326). CONTROLS: 'Apple Wallet' 0, 'loyalty pass' 0, 'pkpass' 0, 'add to wallet' 0; POISON: 'wallet' 15 hits and 'Google Wallet' 5 are all PAYMENT wallets - 'Pay with Google Pay / Apple Pay on mobile applications' walks the guest through installing the Google Wallet app to hold a CARD, not a loyalty pass. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585702 · retrieved 2026-09-17 adversarially verified

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

A self-service deletion path is documented, with its propagation stated: on web and iOS 'you can select "Delete Account" under the "About my Data" section', and 'an account deletion is irreversible and affects your account across all Flipdish-powered restaurants - this includes any progress toward loyalty campaigns, and your order histories etc.' Shortfall: the tooling is guest-facing, not operator-facing. Kiosk and Android users must email Flipdish Support with the registering phone number plus an order ID or the last 4 digits of the payment card; access rights are handled by Flipdish ('Any requests to exercise any Data Subject Right will be dealt with in accordance with Data Protection Laws') and the privacy policy routes them to a data-protection address. No admin screen for fulfilling guest access or deletion requests is described on either permitted host, and the Portal manual on help.flipdish.com is excluded from this sweep by policy. https://www.flipdish.com/consumer-information/data-protection · retrieved 2026-08-09

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

Shortfall: the only documented integrity control is manual — 'Customers can be blocked from placing further orders if necessary to maintain the integrity of the loyalty campaign.' No redemption velocity limits, no manager approval on adjustments (progress is order-count based; there is no adjustable points ledger at all), no employee self-redemption flagging and no loyalty-specific audit log appear anywhere in the loyalty docs (9585533, 9585702). Loyalty vouchers auto-apply; POS discount permissions exist per staff role but are not tied to loyalty redemption. https://help.flipdish.com/en/articles/9585533-create-and-manage-loyalty-campaigns · retrieved 2026-09-17

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

CLAIM: vendor documents AI/ML-generated recommendations for offer CONTENT, target AUDIENCE, or send TIMING, as a shipped feature not a roadmap statement. VERDICT: partial - one of the three disjuncts is shipped and documented, the other two are manual. EVIDENCE FOR (shipped, dated, in the merchant manual): the SMS campaign builder drafts the offer copy with AI - 'Edit the text in your message; our AI prompts will give some starting points but you can edit these yourself. Remember to replace [WEBSITE] and [VOUCHER] with the relevant information' ('How do I send an SMS marketing campaign?', 6 Jan 2026). SHORTFALL (named): the AUDIENCE is chosen by hand - 'Select which stores customers you would like to send this message to... You can further filter who receives this message using the Filter by selection. Some quick filters of popular options are available, or you can use custom filtering to define your own criteria' - with audience sizing done by downloading the Customers Report and cross-referencing it manually. TIMING is chosen by hand - 'click Schedule campaign... You can choose a specific date and time to send the message, or opt for it to be sent immediately' - `send time` scores 0 across 518 articles and there is no send-time optimisation. The DISCOUNT VALUE is recommended by a human rule of thumb, not a model: Retention Campaigns' 'Amount of discount: Select the percentage discount you would like the system to send. We usually find 20% is the sweet spot', and every other campaign field is a deterministic threshold (Send discount code after N days, Voucher will be valid for N days, Does it cover delivery fees, Does it apply automatically to orders). And the corpus's 319 `AI` hits are overwhelmingly the AI MENU EDITOR, whose AI is scoped by its own enumeration to menu metadata: 'Across both options, AI can: Generate item descriptions (if missing) / Fix spelling and grammar / Apply VAT or tax settings based on predefined rules / Assign kitchen stations for correct order routing'. `machine learning` 0. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/11028817-how-do-i-send-an-sms-marketing-campaign · retrieved 2026-09-17 adversarially verified

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

Partial. Present: a native decrementing balance exists. The v1.0 voucher type enum is PercentageDiscount, LumpDiscount, AddItem, CreditNote, FreeDelivery, and the CreditNote variant carries CreditNoteDetails with a RemainingCredit field ('Remaining credit', double) - a balance that persists between orders rather than a one-shot discount. The same voucher object carries CustomerId ('Customer UserID', nullable), which ties an instrument to one guest profile, and Stores / StoreNames ('Stores that this voucher applies to'), which lets it be honoured across the brand's locations, plus MaxRedemptions and ExpiryDate. Named shortfalls: it is a credit note, not a gift card - there is no purchase, activation, load or reload operation anywhere in the 1,064-page v1.0 reference, so nothing lets a guest BUY value; the balance lives on a voucher rather than on the guest, and the Customer object (CustomerId, RegistrationDate, PhoneNumber, CashOrdersEnabled, CardOrdersEnabled, MarketingEnabled) has no balance field, so a guest cannot hold one wallet across instruments; there is no stored-value tender in the closed PaymentAccountType enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken) nor in the v3.0 sale paymentMethod enum (Cash, Credit, Online, PhonePayment, ExternalPayment), so a redemption is recorded as a discount rather than as a gift tender; and the word 'gift' appears in the 27.6MB v1.0 dump only inside the App Store category name GiftCard - Flipdish's own App Store category enum lists GiftCard as a partner-integration category alongside PointOfSale, CRM, Accounting and LoyaltyAndMarketing (/v1.0/reference/getappstoreapp), which is where a gift-card product appears to come from. www.flipdish.com/products-overview's phrase 'view their purchase history, loyalty and account balances' is consistent with the CreditNote balance but names no gift card. help.flipdish.com is excluded by policy. https://developers.flipdish.com/v1.0/reference/updatevoucher · retrieved 2026-08-09

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

Attendance is tracked against rotas with 'live updates' from the POS ('keep an eye on who's working'); a PIN/badge punch mechanism is not explicitly documented. https://www.flipdish.com/pos-system/payroll-management · 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

CLAIM: captures a photo at punch (or performs facial verification) attached to the timecard entry. VERDICT: no. EVIDENCE: the only identity factors documented at the till are a PIN and an RFID card - 'Staff Login Options - PIN Code or RFID Cards' (https://help.flipdish.com/en/articles/9585307) - and the clock-in procedure uses "your staff-specific PIN code" alone (https://help.flipdish.com/en/articles/9585332). The handheld hardware guide (https://help.flipdish.com/en/articles/11508326) lists a camera and a front camera among the device's labelled parts but binds them to nothing in the labour module. CONTROLS: 'facial' 0, 'face recognition' 0, 'punch photo' 0; POISON: 'biometric' 1 hit and 'fingerprint' 2 hits are all the Google Pay / Apple Pay CONSUMER wallet security paragraph ("Multiple layers of security along with biometrics, such as fingerprint readers and face identification are used to ensure users can leverage Google & Apple Pay's secure authentication process"), and 'photo' 14 hits are menu-item images, site logos and bank-verification document uploads. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585332 · retrieved 2026-09-17 adversarially verified

Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.

labor-geofenced-mobile-punch

CLAIM: mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal. VERDICT: no. EVIDENCE: the punch is defined as a terminal act. https://help.flipdish.com/en/articles/9585332 states as a requirement "Have access to a Flipdish POS FRONT-OF-HOUSE DEVICE (staff pin)", and both procedures begin "Log into your Flipdish Point of Sale using your PIN or RFID Card reader". No mobile punch exists to geofence; the staff-facing mobile surface in the census is the POS app itself. CONTROLS: 'geofence' 0, 'geo-fence' 0, 'location validation' 0; POISON: 'GPS' 5 hits, all in 'Does GPS need to be enabled to use the Android and iOS app?' and the customer location-services articles - the CONSUMER ordering app's delivery-address lookup, not a staff punch. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585332 · retrieved 2026-09-17 adversarially verified

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

Flipdish POS does not support offline mode. Time punching requires cloud connectivity. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

'Set permissions per module' and 'Easily control who can get access to what, give freebies or discounts'; per-discrete-action and per-location granularity is not documented. https://www.flipdish.com/pos-system · 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

Partial. Present: attribution and queryability are both documented. The v1.0 API exposes a read API over the platform's event log - GET /api/v1.0/{appId}/events/user/{userId}, /events/order/{orderId}, /events/store/{storeId}, /events/customer/... and /events/{eventId} - each taking limit, page, start and end date-time parameters, so the trail can be queried after the fact by actor, by order or by window. The events that correspond to manager overrides carry the actor: OrderRefundedEvent and OrderRejectedEvent each embed User (UserEventInfo - UserId, UserName, UserPhoneNumber, UserEmail) together with IpAddress, CreateTime and, for the rejection, Reason; configuration changes do the same and add a diff, e.g. StoreFeeConfigUpdatedEvent carries User, IpAddress and Changes ('Diff between before and after'), and StoreServiceChargeUpdatedEvent carries User and the resulting ServiceCharge. www.flipdish.com/products-overview confirms the gate these events sit behind: 'Manager Approvals - Specify when your staff would need manager approval for actions like applying discounts or refunds', with Roles and Permissions and RFID Login identifying the individual. The Portal exposes the same trail through about twenty distinct view permissions in the App resource enum (ViewOrdersAuditLogs, ViewUserEventsAuditLogs, ViewVouchersAuditLogs, ViewTeammatesAuditLogs, ViewCampaignsAuditLogs, ViewStoreAuditLogs and more, /v1.0/reference/getapp-1). Named shortfalls: (1) immutability is asserted nowhere on either permitted host - no retention period, no tamper-evidence, no write-once statement; (2) the coverage is uneven at exactly the point the claim cares about - VoucherAppliedEvent carries VoucherId, OrderId, CreateTime, AppId and IpAddress but NO User block, so a discount applied at the till is not attributed to an individual in the published event schema, while a refund is; (3) the only audit endpoints in the newer v3.0 surface are write-only and beta (POST /auditLogs/orgs/{orgId}, 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice'), so the queryable trail is the older v1.0 surface. help.flipdish.com is excluded by policy. https://developers.flipdish.com/v1.0/reference/getuserevents · retrieved 2026-08-09

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

Native, first-party, and documented step-by-step in the Flipdish Help Centre (article dated 2026-06-30). Portal > Add-ons > Payroll > Rota; load a date range, then 'Click a day of the week you wish to add working hours to for a particular staff member', set start/end via 'from' and 'to' dropdowns, Save. Shifts can be replicated with Copy/Paste across days, and the rota is committed with 'Click Publish at the top of the page once you have completed the rota'; 'This rota will then show in the Rota section of your Point of Sale.' Pending holiday requests render in-grid as blue boxes against hours worked in black boxes, and Add-ons > Payroll > Holiday Planner approves via an 'Approve Booking Request' dropdown with an 'Is Holiday Paid' flag. Requires store-manager-level access. No partner scheduling vendor is involved. Not documented: forecast-driven or demand-based scheduling, labour-cost-target enforcement at build time, shift swaps, or predictive-scheduling compliance. https://help.flipdish.com/en/articles/9585183-manage-staff-rotas · retrieved 2026-09-17 adversarially verified

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

CLAIM: generates recommended staffing levels or labour hours by daypart from the operator's own POS sales history, not just a static template. VERDICT: no. EVIDENCE: the only projection in the product is a sales one, and it is a naive year-over-year restatement that recommends nothing about staffing - 'POS Sales Projections' (https://help.flipdish.com/en/articles/9587780): "The POS Sales Projections Report can be used to give a year-over-year (YoY) comparison of Sales ... Projected Retail Order Price: Projected data is based on the previous years' data (year over year)", grouped Property > Venue > Year > Month > Day of Week. The rota editor (https://help.flipdish.com/en/articles/9585183) is a blank weekly grid the manager fills in by hand with copy and paste, with no demand input. CONTROLS: 'forecast' 0 across all 518 bodies, 'recommended staffing' 0, 'labour hours' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9587780 · retrieved 2026-09-17 adversarially verified

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

Live wage-cost monitoring alongside real-time sales; labour as a percentage of sales on a manager view is not explicitly stated. https://www.flipdish.com/pos-system/payroll-management · 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

CLAIM: warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. VERDICT: no. EVIDENCE: 'How to Use the Clock In and Clock Out Feature on Flipdish POS' (https://help.flipdish.com/en/articles/9585332) documents the complete punch flow - log in by PIN or RFID card, "Click 'Clock in' at the bottom of the screen. (This is linked to the staff rota and the payroll system in the back office of the POS. Our system tracks the clock-in and clock-out of each staff member which should then line up with their shift for the day)", enter the staff PIN, and where applicable "If you have more than one role, select which role you want to clock in as" - with no test of any kind against scheduled or accrued hours. The only automatic behaviour described is the opposite kind of guard: "If a staff member forgets to clock out using their PIN on the Point of Sale, the system will automatically perform a forced clock-out once the configured time-out period has been reached." The Rota editor (https://help.flipdish.com/en/articles/9585183) holds start/end times, copy/paste across days and Publish, and no hours cap or threshold field. CONTROLS: 'overtime' 0 across all 518 bodies. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585332 · retrieved 2026-09-17 adversarially verified

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

The staff-management collection documents the complete timekeeping surface and it contains no break handling: clock-in/out is PIN or RFID with role selection and an automatic forced clock-out after a configured timeout (9585332); the rota is a manual from/to dropdown grid with copy/paste and Publish (9585183); the rota/clock-in report offers only print/export of hours worked and holiday requests (9585292); and the payroll calculator's per-staff outputs are gross/net wage, NI, HMRC and PAYE with no premium-pay concept (9585185). No jurisdiction-configurable break rules, break attestation prompts or missed-break premium flags exist anywhere in the documented labor surface. https://help.flipdish.com/en/articles/9585332-how-to-use-the-clock-in-and-clock-out-feature-on-flipdish-pos · retrieved 2026-09-17

Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.

labor-fair-workweek-support

CLAIM: supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay for employer-initiated changes. VERDICT: no. EVIDENCE: the rota is publish-and-edit-freely, with no notice clock and no change ledger: "Click 'Publish' at the top of the page once you have completed the rota ... You can EDIT THE ROTA AT ANY TIME by coming to this page and clicking on the hours you wish to edit and entering new times" (https://help.flipdish.com/en/articles/9585183). The payroll vocabulary throughout is UK/Irish statutory - Employer NI Allowance, HMRC Payment Reference, employee and employer NI contributions, pension contributions, PAYE, holiday pay (https://help.flipdish.com/en/articles/9585185, https://help.flipdish.com/en/articles/9585188) - with no US municipal scheduling concepts anywhere. CONTROLS: 'predictive scheduling' 0, 'predictability pay' 0, 'fair workweek' 0, 'advance notice' 0, 'clopening' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585183 · retrieved 2026-09-17 adversarially verified

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

labor-minor-labor-rules

Scheduling is documented as an unconstrained manual grid — click a day, 'Select the start time and end time using the from and to dropdowns', copy/paste hours across days, Publish (9585183) — with no rule engine of any kind, and clock-in enforces only PIN/RFID identity plus a forced clock-out timeout (9585332). No age, minor, school-day or prohibited-time-window concept appears anywhere in the staff-management collection, so there is no enforcement point at either scheduling or clock-in. https://help.flipdish.com/en/articles/9585183-manage-staff-rotas · retrieved 2026-09-17

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

CLAIM: computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role). VERDICT: no. EVIDENCE: tips are captured and reported but never distributed. The documented tip surface is 'Enable and Configure Tips on your Flipdish POS' (https://help.flipdish.com/en/articles/9704177), 'Configure Online Tipping' (https://help.flipdish.com/en/articles/9585243) and the Tips Report; and the Payroll Calculator's per-staff breakdown (https://help.flipdish.com/en/articles/9585185) consists of gross wage, net wage, net wage to pay, total NI contribution, total HMRC contribution and PAYE, with no tip allocation line. CONTROLS: 'tip pool' 0, 'tip-out' 0, 'tipout' 0, 'tip share' 0, 'gratuity distribution' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585185 · retrieved 2026-09-17 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

Positive absence: the Tips Report doc enumerates every metric in Flipdish's tip reporting — total tips, delivery vs pick-up tips, refunded tips, tips per store, tips per week — all at store/channel level, none per employee or per shift. The per-staff payroll breakdown enumerates gross/net wage, NI, HMRC contribution and PAYE only, with no tips line (payroll calculator, article 9585185), and no tip-pooling, contribution or distribution feature appears anywhere in the Help Centre title census. A per-shift, per-employee record of pool contributions and distributions cannot be produced from the documented surface. https://help.flipdish.com/en/articles/9585606-tips-report · retrieved 2026-09-17

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

CLAIM: tracks and reports tips for statutory wage reporting (qualified tips / W-2). VERDICT: no. EVIDENCE: the payroll module is UK/Irish statutory throughout - Employer NI Allowance, HMRC Payment Reference, employee and employer NI contributions, pension contributions, PAYE (https://help.flipdish.com/en/articles/9585185) - and produces no filing artefact at all; the one region-specific compliance article in the census is Spanish VeriFactu tax and invoice compliance, not US wage reporting. CONTROLS: 'W-2' 0, 'Form 8027' 0, 'allocated tips' 0, 'qualified tips' 0, 'IRS' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585185 · retrieved 2026-09-17 adversarially verified

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

Positive absence. The App object's AppResourceSet ('Constitutes a list of available resources') is the closed enum of every permissioned resource on the platform - 204 members covering apps, teammates, orders, stores, menus, vouchers, campaigns, bank accounts, payouts, kiosks, catalogs, the App Store, and the back-office suite (Accounts bills/categories/credit accounts/credit books/expenses/transaction accounts, Inventory purchase orders/stock items/suppliers/tracking profiles, Document Explorer). Its entire payroll section is seven members: ViewPayrollReports, EditPayrollHoliday, ViewPayrollHoliday, EditPayrollRota, ViewPayrollRota, EditPayrollStaff, ViewPayrollStaff. There is no payroll-run, pay-period, payslip, tax-filing, statutory-return or employee-payment resource, and no such endpoint exists in the 1,064-page v1.0 reference or the 99-page v3.0 reference; the only money-out objects in the platform are BankAccount and its payouts, chargebacks and refunds, all of which pay the MERCHANT (/api/v1.0/{appId}/bankaccounts/{bankAccountId}/payouts/{payoutId}). 'Payroll' occurs zero times in the v3.0 corpus and only inside those seven permission strings in v1.0. Both first-party product descriptions match: www.flipdish.com/pos-system/payroll-management offers 'easy rota creation, real-time tracking, and efficient payroll oversight ... Keep an eye on wage costs with up-to-date tracking. Plus, handle holiday requests easily', and www.flipdish.com/products-overview says 'Payroll - Use the payroll calculator to work out the wages that have been paid previously and also the upcoming payroll so you know how much to budget for staff wages for the next period.' Neither mentions tax filing, direct deposit, payslips or an employer-of-record arrangement. Scope of the finding: this asserts Flipdish does not itself process payroll as a first-party product, not that the rota and wage-cost module lacks other features; help.flipdish.com is excluded by policy and was not read. https://developers.flipdish.com/v1.0/reference/getapp-1 · retrieved 2026-08-09

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

CLAIM: exports timecards, wages and tips in documented formats or via direct integration for at least two major payroll providers. VERDICT: no - same evidence as extensibility-payroll-export. BOUND on the labour module specifically: its complete documented surface in this census is Add-ons > Payroll > {Rota (https://help.flipdish.com/en/articles/9585183), Holiday Planner (https://help.flipdish.com/en/articles/9585188), Payroll Calculator (https://help.flipdish.com/en/articles/9585185)}, the POS-side Rota / Holidays / Clock-in screens (https://help.flipdish.com/en/articles/9585332, https://help.flipdish.com/en/articles/9585328, 'Check Your Weekly Rota'), the 'Access Rota / Clock-In Report' article (https://help.flipdish.com/en/articles/9585292) and the POS Daily Payroll Costs Report (https://help.flipdish.com/en/articles/9585492). Every output is an on-screen grid or an ad-hoc report download; no named payroll provider and no export format appears in any of them. CONTROLS: 'Gusto' 0, 'ADP' 0, 'Paychex' 0, 'Paylocity' 0, 'QuickBooks' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585185 · retrieved 2026-09-17 adversarially verified

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

CLAIM: employees can request shift swaps or claim open shifts in a self-service app, under a manager approval workflow that enforces overtime and role eligibility. VERDICT: no. EVIDENCE: the staff-facing self-service surface is bounded and contains exactly two actions - 'Apply for Time Off' (https://help.flipdish.com/en/articles/9585328: "Log into your Flipdish Point of Sale using your PIN or RFID Card reader ... Click on the 9 dots in square arrangement to open the menu ... Click on 'Holidays' ... If you are looking for a partial day off click on the dropdown menu ... Use the Instructions box to input any details you would like management to know about this request ... Await your manager's approval") and 'Check Your Weekly Rota'. The manager counterpart, 'Manage Staff Holiday / Time Off Requests' (https://help.flipdish.com/en/articles/9585188), approves or declines HOLIDAY bookings only ("Approve Booking Request", "Is Holiday Paid", "Approval Reason"; or "Decline booking request", "Rejection Reason") and applies no overtime or role test. No shift is ever published to, offered to, or traded between employees. CONTROLS: 'open shift' 0, 'shift swap' 0, 'pick up a shift' 0; POISON: 'swap' has exactly 1 hit and it is swapping the BANK ACCOUNT assigned to a store. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585328 · retrieved 2026-09-17 adversarially verified

Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.

labor-digital-onboarding-i9

CLAIM: digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission. VERDICT: no. EVIDENCE: adding a person to the system is a permissions task, not an onboarding flow - 'Add New Staff Members and Staff Roles in your Flipdish Portal' (https://help.flipdish.com/en/articles/9585306) and 'Invite Teammates to your Flipdish Portal' (https://help.flipdish.com/en/articles/9585557) create a login and a role, and there is no document-collection step anywhere in the labour cluster (rota, holiday planner, payroll calculator, clock-in, staff login options). CONTROLS: 'I-9' 0, 'W-4' 0, 'E-Verify' 0, 'new hire' 0, 'right to work' 0; POISON: 'onboarding' has 24 hits and every single one is FLIPDISH onboarding the MERCHANT - the onboarding engineer who configures peripherals, the Activations team, 'Onboarding: rates and fees, additional services' - never an employee. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585306 · retrieved 2026-09-17 adversarially verified

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

Per-staff reporting is claimed twice on this page: 'Customisable Reports - Build your own reports and quickly drill into your data to see how your store, your products and your staff are performing', and 'Staff Upsells' is one of the named Report Types ('View reports on Costs, Sales, Sales Channels, Customers, Campaign performance, Payments, Staff Upsells, Menu Items Ordered, Mileage, Inventory, Payroll, Hourly Turnover and more'). Shortfall: 'Staff Upsells' - an attachment-rate metric - is the only per-employee measure named anywhere on the two permitted hosts; average check per server, void rate and comp rate by employee are named on neither this page nor www.flipdish.com/pos-system/reporting-and-analytics, whose sales-report examples are by channel, dispatch type, payment method and store. The evidence is a vendor marketing feature list (grade D), which the differentiator grade floor bars from carrying a yes, and the report catalogue itself is documented on help.flipdish.com, excluded from this sweep by policy. https://www.flipdish.com/products-overview · retrieved 2026-08-09

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

'Recipe builder' and inventory cost insight 'even on the level of single-ingredient items'; multi-level sub-recipes and automatic plate-cost recalculation are not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · 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

Stock items store a Measurement Type/Unit plus named stock units each with an explicit conversion factor — 'Enter the conversion factor (This is how you will typically break down the unit, for example, an onion, which would be within a bag of onions which would be the unit in this case)' — separate operational units per stock-item operation type, and recipe profiles with a base quantity and base-quantity unit (9585131). Shortfall: no yield or waste percentage applied to raw-to-usable conversion is documented anywhere — wastage exists only as an 'Is Wastage Tracked' flag feeding a POS Wastages Report, not as a conversion-time yield factor. https://help.flipdish.com/en/articles/9585131-add-and-edit-stock-items · retrieved 2026-09-17

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

Cost reporting covers 'COGs, inventory, wastage, discrepancies, and profitability' — 'discrepancies' implies variance, but no theoretical-vs-actual methodology is documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

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

CLAIM: depletes ingredient on-hand quantities in NEAR REAL TIME as orders are fired at the POS, including modifier-driven depletion. VERDICT: partial. EVIDENCE: recipe-based consumption is real. 'Add and Edit Stock Items' (https://help.flipdish.com/en/articles/9585131) gives each stock item an Overview tab carrying "Is Inventory Tracked", "Is Wastage Tracked", "Minimum Inventory Quantity", "Measurement Type", "Measurement Unit (this is how you are recording the stocks, packs, kgs etc)" and "Markup Rate Percentage (%)"; a Units tab with a "conversion factor"; and, for a Prep Item, a "Recipe Profile: This is only relevant if the item you are adding is a product which will be sold on your menu, and if that product has multiple other ingredients that make it up and that would need to be TRACKED WHEN THIS PRODUCT IS SOLD. You will then be able to assign this product to a menu item in the menu editor" (worked example: chicken, bun, lettuce, sauce, with a base quantity and base quantity unit). The consumption surfaces in the POS COGs Summary Report, which "will only populate if you have entered your RECIPES within each product on your menus" (https://help.flipdish.com/en/articles/9585513). SHORTFALL: every consumption surface the vendor documents is a DAILY batch - "Daily COGS Summary" (https://help.flipdish.com/en/articles/9585513) and "Daily Discrepancies Report" (https://help.flipdish.com/en/articles/9585512) - and no article says on-hand quantity moves at fire time; modifier-driven depletion is nowhere documented, the recipe binding being to a menu item rather than to a modifier. CONTROLS: 'depletion' 0, 'deplete' 0, 'stock level' 0, 'real-time inventory' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585131 · retrieved 2026-09-17 adversarially verified

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

CLAIM: automatically 86s items on the POS, online ordering and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. VERDICT: no - the vendor denies the trigger exists. EVIDENCE: 'Are staff notified when an item is out of stock or almost out of stock when using the Flipdish Point of Sale?' (https://help.flipdish.com/en/articles/9585304), in full: "At this time, no, there is no notification when an item is almost out of stock. It is the responsibility of the admin to manage the inventory through the Flipdish Portal and send order requests to their suppliers as necessary." A "Minimum Inventory Quantity" field exists on the stock item (https://help.flipdish.com/en/articles/9585131) but nothing in the census fires on it. Every 86 path the vendor documents is a manual human action - snoozing, hiding or overriding a menu or item from the portal, POS or terminal ('Managing menu overrides on the Flipdish Point of Sale: how to snooze, override, hide menus or specific items'; 'Show / Hide Menu Items Using the Flipdish Terminal'; 'How to toggle menu item visibility & set custom menu item timings via the portal'). BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585304 · retrieved 2026-09-17 adversarially verified

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

CLAIM: full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history. VERDICT: partial. EVIDENCE: 'Flipdish RMS (Restaurant Management System) App Overview' (https://help.flipdish.com/en/articles/9585175) enumerates the tablet app's screens and includes "Stock Taking - where you can take stock of items BI-WEEKLY, DAILY, MONTHLY OR WEEKLY" alongside Wastage, Purchase Order, Build Plans, Compliance Report and Appliance Service; the app requires "An Android or iOS Tablet (not compatible with phone or laptop)" and activation by the Flipdish Activations team, plus "A subscription to our Food safety module". Subsetting runs through 'Manage Inventory Tracking Profiles' (https://help.flipdish.com/en/articles/9585124): "Tracking profiles are valuable for use when performing stock takes or checks. These profiles can be assigned to specific stock items and will be visible in your Restaurant Management System App. This helps your staff know when to perform checks or take stock of particular items" (needs Owner access and an active "Inventory Management" service subscription). Variance is reported by the POS Discrepancies Report (https://help.flipdish.com/en/articles/9585512), which "tracks differences between Stock items tracked in the Flipdish Portal Inventory Tab and Items that were purchased by customers, logged as Staff Meals and/or Guest/Freebie Meals", defaulting to Property > Stock Item > Date. SHORTFALL: the vendor never distinguishes a FULL physical count from an ad-hoc spot count, and variance is surfaced as a date-ranged discrepancy report rather than a per-count record with its own retained history. CONTROLS: 'cycle count' 0, 'variance' 0 - the vendor's word is 'discrepancy'. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585175 · retrieved 2026-09-17 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

A mobile counting app exists, refuting the earlier 'no': the Flipdish RMS app (Google Play / Apple App Store) includes 'Stock Taking - where you can take stock of items bi-weekly, daily, monthly or weekly', plus wastage logging and purchase orders, with per-item tracking profiles assigned from the Portal surfacing in the app (9585124). Shortfalls: tablet-only ('not compatible with phone or laptop'), gated behind a Food safety / Inventory Management subscription and activation by the Flipdish team; barcode scanning is documented only as a USB scanner on the POS front-of-house device (9585145), not in the RMS counting flow; and offline count capture with sync-on-reconnect is documented nowhere — the POS offline FAQ (9585187) covers the POS, not this app, so the claim's offline half is unverified rather than supported. https://help.flipdish.com/en/articles/9585175-flipdish-rms-restaurant-management-system-app-overview · retrieved 2026-09-17 adversarially verified

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

CLAIM: pre-built electronic vendor catalogue and order-transmission integrations with named broadline distributors (Sysco, US Foods, PFG) that send POs and receive invoices electronically. VERDICT: no. EVIDENCE: 'Add and Manage Suppliers' (https://help.flipdish.com/en/articles/9585126) enumerates the entire supplier record and it is an address book: a General tab ("Name, Address, Phone Number, Email Address, Web Site, Notes"), a Service Profile tab ("Here you can add what type of service this supplier provides your business") and a Logo tab. There is no catalogue import, price file, account number or transmission endpoint. The article's stated purpose is manual: "Adding suppliers to your inventory management module allows you to be able to issue purchase orders easily from the Restaurant Management System app", and the RMS app's PO screen is a creation form - "Purchase Order - where you can create new purchase orders for the stock you are running low on" (https://help.flipdish.com/en/articles/9585175). CONTROLS: 'Sysco' 0, 'US Foods' 0, 'Performance Food Group' 0, 'EDI' 0, 'punchout' 0, 'supplier catalog(ue)' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585126 · retrieved 2026-09-17 adversarially verified

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

CLAIM: ingests supplier invoices from photo, PDF or email and extracts line-item detail into the inventory ledger without manual line entry. VERDICT: no. EVIDENCE: the purchasing surface is wholly manual - the supplier record has no document intake of any kind (https://help.flipdish.com/en/articles/9585126) and the RMS app's Purchase Order screen is a creation form, not a capture one (https://help.flipdish.com/en/articles/9585175). CONTROLS: 'OCR' 0, 'invoice capture' 0, 'scan the invoice' 0, 'line-item extraction' 0. POISON WARNING, and it is severe: 'invoice' has 81 hits across the 518 bodies and essentially every one is FLIPDISH'S OWN SUBSCRIPTION BILLING TO THE MERCHANT ('Monthly Invoices', 'Subscription billing information', 'How can I request my Flipdish subscription invoices') or the Spanish VeriFactu e-invoicing compliance article - not a supplier invoice entering inventory. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585126 · retrieved 2026-09-17 adversarially verified

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

CLAIM: tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. VERDICT: no. EVIDENCE: the stock item record carries a single current cost basis (Unit Cost in the reports, "Markup Rate Percentage (%)" on the item) with no price-history collection (https://help.flipdish.com/en/articles/9585131); the supplier record carries no pricing at all (https://help.flipdish.com/en/articles/9585126); and the vendor states plainly that the inventory module raises no stock-condition alerts whatever: "At this time, no, there is no notification when an item is almost out of stock. It is the responsibility of the admin to manage the inventory through the Flipdish Portal and send order requests to their suppliers as necessary" (https://help.flipdish.com/en/articles/9585304). CONTROLS: 'price change' 0, 'price increase' 0, 'price history' 0, 'contracted price' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585304 · retrieved 2026-09-17 adversarially verified

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

Flipdish's live RMS back office lets you set a "Minimum Inventory Quantity" (hint "Enter minimum quantity to be maintained in the inventory") on each stock item, and override it for a single "Property" (views/setup/inventory/stockItems/components/overview/Details.jsx, PropertyLevelOverride.jsx; chunk 4072.65d96c6b). When a purchase order is built, inventoryUtil.getSuggestedReorderQuantityInSupplierUnits compares current inventory with that minimum. It returns 0 if stock is at or above the minimum. Otherwise it suggests (minimum - on hand), converts that to supplier units and raises it to the supplier's minimum order quantity. getReorderItems uses the result to fill in the order lines, and the order screen shows "Suggested Reorder:" / "Current Inventory:" / "Minimum Inventory:" (views/modules/inventory/purchaseOrders/utils/inventoryUtil.js, components/purchaseOrderItems/ItemInventoryComponent.jsx). Missing: no mode uses a sales forecast, since the static minimum is the only input. The field is labelled a minimum rather than a par, and the suggestion only orders back up to that minimum. https://rms.portal.flipdish.com/static/js/7079.86bfdb49.chunk.js · retrieved 2026-09-15 adversarially verified

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

inventory-waste-logging

Wastage is a named line in cost reporting; a structured reason-coded logging workflow is not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.

inventory-transfers

The only stock movement between sites in Flipdish's RMS back office runs from the central kitchen to a property, and it is recorded as a linked purchase and sale, not as a transfer. The receiving property raises a purchase order (PurchaseOrderStatusType Draft/Submitted/Received/Voided, utils/domain/constants.js). The kitchen's sale record holds purchaseOrderId and purchaseOrderContext {franchisorId, franchiseeId, propertyId}. SelectedSale.jsx loads that order from /inventory/purchaseOrders/<id> and matches sale lines to order lines, and CentralKitchenSaleStatusType Open/Approved/Dispatched/Cancelled plus "Order Recalled" (SelectedSale/CaptionPanel.jsx) give it approval and dispatched states. The stock-event enum (utils/domain/inventoryConstants.js: sale, build, wastage, purchase, stockTake, centralKitchenSale="centalKitchenSale") has a separate kitchen-side event but no transfer type. Missing: store-to-store transfers, at-cost transfer (the movement is priced), and any frontend proof that the kitchen's stock is actually debited. https://rms.portal.flipdish.com/static/js/4103.d0da1bb3.chunk.js · retrieved 2026-09-15 adversarially verified

Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.

inventory-commissary

Flipdish's live merchant-portal bundle (index-Be9zTRhC.js, with a public source map) defines three pieces of the central-kitchen model. First, the RMS subscription enum includes CENTRAL_KITCHEN="pos.central-kitchen", and the portal offers a Central Kitchen property type (CreatePropertyTypeEnum.CentralKitchen). Second, the add-on routes (src/components/RMS/CentralKitchen/centralKitchen.routes.tsx) sit under /add-ons/central-kitchen, each gated by subscription pos.central-kitchen: an order-management page titled "Central Kitchen Sales & Order Management" (module centralKitchens, url configurations/franchisors/centralKitchens/sales), and a Central Kitchen Management page. Third, that management page carries its own "Menus" ("Edit the central kitchen menu"), stock item categories, stock items ("Manage list of stock items for the central kitchen"), suppliers and inventory tracking profiles. The add-on landing page, a lazy chunk whose strings are in this bundle's dictionary, describes the service as "Manage orders, view sales and dispatches for the central kitchen service". So a paid central-kitchen service exists that holds its own stock and a sellable menu, takes orders and records sales and dispatches. Shortfall: nothing states that the buyers are the brand's own locations rather than any customer. Production of prep items from recipes is not shown, and no transfer or issue cost computation is visible. It is also a separate add-on subscription (pos.central-kitchen). https://portal.flipdish.com/static/index-Be9zTRhC.js · retrieved 2026-09-14 adversarially verified

Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.

inventory-lot-traceability

CLAIM: captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace. VERDICT: no. EVIDENCE: https://help.flipdish.com/en/articles/9585131 is a field-level ENUMERATION of the stock item record, tab by tab: Overview (stock item code, name, category, Is Product, measurement type, measurement unit, minimum inventory quantity, markup rate percentage, Is Wastage Tracked, Is Inventory Tracked, notes), Property level overrides, Prep and Recipe (recipe profile, base quantity, base quantity unit, build-plan participation), Units (unit name, conversion factor, notes, operational unit type), Prep Profile (prep time in hours, expiry time in hours, minimum expiry labels per day), Cooking Temperature Profile and Storage Temperature Profile (min/max temperature, temperature log type, minimum logs required, auto-correction logs, hazard types) and Nutrition (fats, carbohydrates, sugar, protein). There is no lot, batch, received-date or supplier-reference field in any of them. The RMS app's traceability artefacts are expiry/allergy/nutrition labels and a date-ranged Compliance Report (https://help.flipdish.com/en/articles/9585175) - a date trace, not a batch trace. CONTROLS: 'lot number' 0, 'batch number' 0, 'traceability' 0, 'recall trace' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585131 · retrieved 2026-09-17 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

Flipdish's Health and Food Safety module has staff 'log opening and closing checks, appliance temperatures, and food expiry dates - all from one simple dashboard', and the kitchen printer prints 'clear labels showing expiry dates, allergen, and nutritional information'. So use-by dates are captured on prepped/labelled items and on logged stock. The shortfall: the page describes proactive alerting only generically ('alerts via email and SMS flagging any hazards or food safety issues') and names no expiring-soon report, no configurable lead time and no per-item expiry alert; nor does it say expiry is captured at receiving against supplier deliveries. This is a vendor feature page (grade C), not documentation - the module's actual fields are in the help centre, which is excluded on this record by policy. https://www.flipdish.com/pos-system/health-food-safety-management · retrieved 2026-08-09

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

inventory-bar-partial-bottle

CLAIM: partial-bottle liquid inventory by weight (scale integration) or by bottle fraction, for bar and beverage counting. VERDICT: partial - fractional-unit stock counting is documented and generic; the scale/pour half of the claim is a documented absence. EVIDENCE FOR: the Inventory module records a stock item with a 'Measurement Type', a 'Measurement Unit (this is how you are recording the stocks, packs, kgs etc)', a 'Minimum Inventory Quantity', an 'Is Wastage Tracked' flag, and a Units tab where you 'Enter the conversion factor (This is how you will typically break down the unit, for example, an onion, which would be within a bag of onions which would be the unit in this case)' plus an 'Operational Unit' with a 'stock item operation type' - so a bottle can be declared a unit and counted in fractions of it by weight or by measure, and a recipe can consume a 'base quantity' of it. SHORTFALL (named): nothing in the module is beverage-aware and there is no automatic capture - `pour` 0, `keg` 0, `flow meter` 0, `tap wall` 0, `dispense*` 0, `liquor` 0 across all 518 articles; `scale*` scores 1 (image scaling on a kiosk home screen) and `weigh*` 1 (website fonts); `bottle*` scores 11 and EVERY hit is the Deposit Return Scheme for plastic bottles, a trap worth naming. Counting is a manual stock take prompted by a Tracking Profile in the RMS app, not a pour posting to a tab. The POS module list ('Caller ID, CRM, Float Management, KDS & CDS interface, Inventory & Menu Management, Staff Rota, Payroll, Health & Food Safety Management, Order Ingest (Marketplaces)') contains no beverage module, matching the v1.0 App Store category enum. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585131-add-and-edit-stock-items · retrieved 2026-09-17 adversarially verified

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

CLAIM: exports period COGS and accounts-payable invoice detail in a NAMED accounting system's import format, with GL account mapping configurable per item category. VERDICT: no. EVIDENCE: COGS exists, but only as an in-portal grid. 'POS COGs Summary Report' (https://help.flipdish.com/en/articles/9585513) is reached at Reports > RMS > Costs > Daily COGS Summary and is defined as "Cogs = Cost of Goods is calculated using Total Sale Cost + Total Wastage Cost + Total Discrepancy Cost", with drag-and-drop row grouping defaulting to Property > Category > Stock Item > Date. No export target is named in it or in any of the other 24 RMS/POS report articles, and no GL account field exists on the stock item (https://help.flipdish.com/en/articles/9585131), the stock item category, or the menu item. CONTROLS: 'QuickBooks' 0, 'Xero' 0, 'Sage' 0, 'NetSuite' 0, 'Intacct' 0, 'chart of accounts' 0, 'GL account' 0; POISON: 'journal' 2 hits, neither an accounting journal. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585513 · retrieved 2026-09-17 adversarially verified

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

The cited /docs/pos-features page is, despite the /docs/ path, a marketing feature list — I read it end to end and it is a flat bullet grid ('Inventory management', 'Recipe builder', 'Food sales and costs calculations') with no screenshots, no configuration detail, and no statement of first- vs third-party provenance. Flipdish's own integrations directory is dominated by other vendors' POS systems, so 'nothing contracted out' cannot be inferred from a bullet. First-party is plausible but undocumented. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01 adversarially verified

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

Reporting joins 'food sales and costs' and profitability with best-selling item data; a per-item contribution-margin view with threshold flagging is not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

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

Reports available 'in real-time, from your mobile, POS, or back office'; a management app is a listed POS feature. https://www.flipdish.com/pos-system/reporting-and-analytics · 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

Partial: an end-of-day report is a first-class documented resource, but a narrow one. GET /api/v1.0/stores/{storeId}/endofdayreport takes a store and a date and returns StoreEndOfDayReport, whose published response enumerates OrderCount, OrderValue, OrderValueExcludingDeliveryFees, the collection/delivery split (CollectionOrderCount/Value, DeliveryOrderCount/Value) and the tender split (CashOrderCount/Value, PaidOnlineOrderCount/Value, and the same excluding delivery fees) plus StartTime, EndTime and Currency; the v1.0 App permission catalogue gates it as ViewSalesEndOfDayStatistics (/v1.0/reference/getapp-1). Shortfall: that schema carries no tax, no tips, no discounts, no refunds and no expected cash deposit, and tender resolution stops at cash vs paid-online - the sale-level fields for tax, tips, discounts and refunds exist only in the separate v3.0 Sales Management API, not in this report. Whether the merchant portal renders a richer single reconciling document is in-product behaviour documented in help.flipdish.com, which is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getendofdayreport · retrieved 2026-08-09

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 menu items, hourly sales and sales by channel/dispatch type/payment method are documented; modifier-level PMIX is not. https://www.flipdish.com/pos-system/reporting-and-analytics · 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

Partial: GET /api/v1.0/{appId}/events is a queryable audit feed filterable by storeId, storeIdList, storeGroupId, userId, userEmail, userName, voucherCode, eventType and a start/end date range. Its published examples show OrderRefundedEvent carrying RefundedAmount, a User object (UserId, UserName, UserEmail), IpAddress and CreateTime ('Store refunded 2,00 from 15,00 for an order (#1234)'), and OrderRejectedEvent carrying Reason ('TIMED_OUT') plus the same User block; VoucherCreatedEvent/VoucherUpdatedEvent are likewise user-attributed. The App permission catalogue exposes ViewOrdersAuditLogs and ViewVouchersAuditLogs as separate grants. Shortfalls against the claim as worded: refunds and rejections are the only order-side exception events - there is no comp or void object distinct from a refund, no price-override event, no manual-discount-applied event with an operator (voucher.applied carries no User at all), no manager/approver attribution anywhere, and no reason code on a refund. Whether the portal renders these as a single exception report is help-centre material, excluded by policy. https://developers.flipdish.com/v1.0/reference/getevents · retrieved 2026-08-09

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

The Flipdish back-office daily summary report builds one table per float session, titled "Float Session" with an optional "(Float ID: ...)". It computes the expected cash as opening balance + cash sales - cash refunds - cash expenses - net safe transfers - net change given, and shows it as "Estimated Closing Balance" beside the counted "Closing Cash" (with cash-count breakdown child rows). The footer is "Discrepancy in Closing Balance" = closingBalance - expected (views/reports/accounts/floatSessions/dailySummaryReport/utils/dailySummaryReportUtils.ts, getFloatSessionTableData). Property float setup has 'Display Closing Balance Discrepancy' and cash-count toggles 'On Opening Session' / 'On Closing Session' (views/setup/organization/property/propertyFloatConfiguration/components/PropertyFloatConfigurationComponent.jsx, chunk 716.325e3b5a). Met: counted vs expected from cash tenders and paid-outs, per float session (shift/drawer). Missing: no over/short rolled up by employee; the session only records who started and closed it ("Started by" / "Closed by"). https://rms.portal.flipdish.com/static/js/63.d2b37e4a.chunk.js · retrieved 2026-09-15 adversarially verified

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

Wage cost is tracked live against sales; sales per labour hour by hour/department/employee is not documented. https://www.flipdish.com/pos-system/payroll-management · retrieved 2026-08-01

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

CLAIM: per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. VERDICT: partial. EVIDENCE: 'Staff Upselling Performance Reports' (https://help.flipdish.com/en/articles/9585217): "Our systems tracks and prompts your staff to upsell certain products when speaking to your customers. It will then awards points to your staff members if they upsell a product you have selected to have upsell points ... You will be able to see every staff member's sales for that day, the previous week and the previous month and be able to see how many upsell points they have earned on the right-hand side." The points basis is category-configurable ("When we are setting up your menu please let us know which products you would like to have upsell points assigned to, as you might not want them on all your added extras"), which is the attachment-rate conjunct expressed as points, and a POS Upselling Points Report exists alongside it. SHORTFALL: per-server output is sales totals plus upsell points only - no average check, no items per check, and no tips-as-a-percentage-of-sales; the Tips Report article does not break tips out per server. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585217 · retrieved 2026-09-17 adversarially verified

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

Sales by channel and dispatch type plus profitability reporting; margin net of marketplace commission per channel is not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator

reporting-multiloc-drilldown

Multi-location comparison reporting is documented ('full visibility on reports from all your sites from one place'); drill-down to an individual transaction is not stated, though listOrgSales/getSale provide it via API. https://www.flipdish.com/pos-system · retrieved 2026-08-01

Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator

reporting-custom-report-builder

The entire evidentiary basis is one marketing sentence: 'Tailor custom reports to suit the specific needs of your business so you can view only the information you need to see.' That describes column/filter selection on canned reports, not a dimension-and-measure report builder. No saved reports, no scheduling, no export — I confirmed the page makes no scheduling or export claim whatsoever. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01 adversarially verified

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

CLAIM: ANY report can be scheduled for automatic recurring delivery by email or to a shared destination, on a defined cadence and recipient list. VERDICT: partial - the mechanism is real but is not offered on every report. EVIDENCE: 'Download Report Data and Schedule Reports to Be Sent to Your Email' (https://help.flipdish.com/en/articles/9585608): "A number of reports available in the Portal allow you to receive the content to your email as a .pdf, .csv, or .png file. You can define when you'd like to receive these. Requirements: This applies to CERTAIN PAGES within the 'Reports' area of the Portal, INCLUDING: Customer Reports, Performance Summary." The flow satisfies cadence, recipients and format - "Open the three dots menu ... and select 'Schedule delivery' ... define when and how often you would like to receive the report. You will also need to enter at least one email address ... and to select the format", a Filters tab ("you might wish to receive the same report as both a weekly and monthly report, which is possible using the corresponding filters for two different schedules"), an Advanced options tab, a 'Test now' button, and Delete to stop. A second article, 'How can I set up automated email reports for weekly or monthly sales on Flipdish' (https://help.flipdish.com/en/articles/13638005), repeats the flow for sales reports. SHORTFALL: the vendor itself scopes this to "certain pages ... including" two named report families; none of the 25 RMS/POS report articles mentions scheduling, and email is the only destination offered (no shared drive, SFTP or webhook). BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585608 · retrieved 2026-09-17 adversarially verified

Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator

reporting-raw-warehouse-export

Automated transaction-level extraction is documented, but not to a vendor-managed destination. The org-scoped read endpoints (GET /sales for an org, and per-property) return 'paginated complete sale objects for sync or export', sorted by createdAt descending with pageSize + opaque cursor and optional after/before UTC filters - a resumable incremental pull of the full sale payload. In push form, the v3 webhook catalogue's sale.created.v1 / sale.updated.v1 'carry the full sale payload inline' to an HTTPS callback URL you control, with at-least-once retries. Named shortfalls: no S3, SFTP, Snowflake or BigQuery destination exists anywhere in the 99-page developer corpus (zero hits for any of them) - the customer must build and host the receiver or the polling job; and both routes are gated, the Sales Management API carrying 'Beta ... Contact integrations@flipdish.com to request access' and the sale.* events marked 'this event is in closed beta - request access by emailing integrations@flipdish.com'. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-09

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

Self-service credentials verified first-hand: 'To interact with the Flipdish API you will need a Flipdish account. You can create one for free at https://portal.flipdish.com/signup', then avatar -> Developer tools -> OAuth apps -> Add New yields a Client ID and Secret Key, exchanged at POST https://api.flipdish.co/identity/connect/token with grant_type=client_credentials and scope=api. No signed partner agreement and no human in the loop for the v1.0 surface. Coverage: v1.0 publishes 1,067 documented operations spanning orders (getorders, getorderbyid, acceptorder, rejectorder, dispatchorder), customers, menus, stores and store settings, vouchers and loyalty, and payment settlement (reporting/reports/payouts3 overview, details and refundedOrders plus five CSV exports); v3.0 adds Org Management, Menu Management, Sales, Consumer Orders (still on v1.0), Operations Updates, Audit Logs, Webhook Subscriptions and Webhook Events at base URL https://api.flipdish.co. Maturity, now recorded: the v1.0 corpus marks its exceptions and only 8 of 1,064 pages carry a marker -- '[ALPHA - this endpoint is under internal development, it is not available just yet to use in your production system]' on order-ingest/submit, the two getconfiguredapps pages and five payout endpoints -- everything else is unmarked and shipped; on v3.0 the Sales API, Operations Updates and v3 webhooks are in closed beta, 'Email integrations@flipdish.com to request access and credentials'. No labor or timeclock endpoints exist, Flipdish shipping no labor product. The docs state no rate limits, no sandbox and no deprecation policy, so extensibility-published-rate-limits and extensibility-free-sandbox correctly remain unknown. https://developers.flipdish.com/docs/getting-started · 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

Outbound webhooks to a customer-supplied HTTPS endpoint are real and self-serve (Portal Settings -> Webhooks, Owner or Managed Owner role), and the retry half is documented: 'Acknowledge with any 2xx', 'Retries are automatic (at-least-once semantics). Handlers must be idempotent', and the marketplace guide adds 'Flipdish times out after 10 seconds and retries'. Named shortfalls. (1) Signature verification is not shipped on the surface that publishes it: the same webhooks-v3 page that gives an HMAC-SHA256 verification code sample lists, in its delivery-contract table, '(planned) X-Flipdish-Signature -- HMAC-SHA256 signature for payload verification' and '(planned) X-Flipdish-Idempotency-Key' (page re-retrieved 2026-08-09, both lines still present). (2) The order and payment lifecycle events are not on a shipped tier: the v3 event catalogue marks only menu.published.v1, menu.validation.failed.v1, menu.item.snoozed/unsnoozed.v1 and sales_channel.snoozed/unsnoozed.v1 as 'Generally available'; sale.created.v1, sale.updated.v1 and sale.status.updated.v1 are Beta and llms.txt records them as 'in closed beta -- request access by emailing integrations@flipdish.com', while the legacy sales.* family is 'Deprecating soon' with 'Do not build new integrations against sales.*'. (3) The generally-available order-lifecycle webhook surface is v1.0 -- unmarked subscription CRUD at /api/v1.0/{appId}/webhooks/{oauthAppId}/subscriptions, plus getwebhookeventnames, a test-fire endpoint and delivery logs carrying RetryCount, over order.created / order.accepted / order.rejected / order.refunded -- but v1.0 documents no signing scheme at all ('HMAC', 'signature' and 'X-Flipdish' each appear zero times across the 1,064-page v1.0 dump), and webhooks-v3 characterises legacy verification only as 'Legacy app secret, varied patterns'. So: signed-and-retried webhooks exist for menu events, order/payment events require closed-beta access, and the shipped order-event surface is unsigned. https://developers.flipdish.com/docs/webhooks-v3 · retrieved 2026-08-09 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

API access is self-serve and free: v1.0 Getting Started tells any user to create a Flipdish account 'for free at portal.flipdish.com/signup', then create an OAuth app under Developer tools and request client-credentials tokens against https://api.flipdish.co/identity/connect/token; no plan tier, per-location fee or revenue share is attached anywhere in the developer docs, and the add-on list on flipdish.com/pricing (kiosks, managed marketing, KDS, Uber Direct, customer feedback app, phone marketing) contains no API or data SKU. Raw transaction data is on the same footing: the v1.0 API ships GET /api/v1.0/orders and /orders/{id} (full order payloads including OrderItems, OrderItemOptions, Voucher, PaymentAccountType and TipAmount), /orders/summaries, /apm/statistics/orders/{aggregateDataBy} and the payouts3 reporting family with per-payout order, refund, chargeback and ledger-entry exports. None of these carry a maturity marker: the string 'Beta' appears zero times in the 1,064-page v1.0 corpus, and the only 8 pages marked '[ALPHA - ... not available just yet to use in your production system]' are order-ingest submit, getconfiguredapps x2 and five getpayout* balance endpoints. The v3.0 Sales Management API and its sale.* events are behind 'Contact integrations@flipdish.com to request access', but that is a beta-access gate on the newer surface, not a charge or a tier, and the shipped v1.0 surface already returns transaction detail. https://developers.flipdish.com/v1.0/reference/getorders · 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

Flipdish's live merchant-portal bundle (index-Be9zTRhC.js; public source map files src/components/RMS/Reports/Reports.tsx and src/components/Reports/utils/getReportsMenuItems.tsx) gates each RMS report group by an RMS subscription. A group is shown only when the client's subscriptions include its requiredSubscription (function fv: `o?a.includes(o):!0`). Three groups require pos.base. Sales covers Sales Overview, VAT, End of Day, Kitchen Timings, Discounts, Refunds, Charges and Hourly. Costs covers Costs Overview, Wages Costs, Venue Commissions, Daily COGS Summary, Fixed Costs, and Staff, Guest and Freebies Meals. Menu covers Menu Item Sales, Hourly Menu Item Sales, Reporting Tag Sales and Menu Item Refunds. Payroll reports (Daily Payroll Costs, Daily Sales By Driver, Upselling Points) require pos.payroll, and Inventory reports require pos.inventory. Many base reports carry allowFranchisorLevel:true, and several are redirecting to new Looker dashboards (/reports/dashboards/global/...), which are filtered by client category rather than by any subscription. So PMIX, discounts, refunds and comps-style freebies reporting, wage cost and franchisor-level (multi-location) reporting come with the POS base subscription, not with a separate analytics SKU. Shortfall: the bundle does not map pos.base to a named plan (the public site lists Essentials/Pro/Advanced), so 'entry-level plan' is not established. Wage data plausibly depends on the pos.payroll add-on, since staff, rota and payroll calculator are payroll modules and Daily Payroll Costs points at the same /costs/wages route. Payroll and inventory reporting are explicitly add-on-gated, and no void audit report is named. https://portal.flipdish.com/static/index-Be9zTRhC.js · retrieved 2026-09-14 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

CLAIM: 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. VERDICT: no - the claim is about DOCUMENTATION and the documentation does not exist, now measured over the complete merchant manual as well as both API references. EVIDENCE: every report article (Sales Report, POS Sales Overview, POS Sales VAT, Customers, Tips, Performance Summary, Sales Summary, Sales by Driver, Venue Commissions, Hourly Sales, Rota/Clock-in, Campaign Performance) instructs the operator to 'Set your desired date range' or 'Select your desired date range' and not one of them states an earliest available date, a cap, a truncation rule or an archive tier or fee; `date range` scores 45 hits across 26 articles with no bound attached to any of them. CONTROLS: `24 months` 0, `two years` 0, `last 90 days` 0, `data export` 0, `RPO` 0, `RTO` 0 across all 518 articles. POISON, and it is the whole of the apparent signal: `retention` scores 45 and is almost entirely RETENTION MARKETING (21 in 'Create and Manage Retention Campaigns', 11 in Campaign Performance) - reading those as data retention would have manufactured a yes; `archive*` scores 4, all the sales-channel archive control; `up to 12` resolves to '12 WEEKS following' for a dispute reversal, not months of history. Combined with the prior pass's finding that v1.0's Events and Reporting APIs and v3.0's org sales endpoints all take free start/end filters with no documented floor, no window is published anywhere on any host Flipdish controls. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585609-sales-report · retrieved 2026-09-17 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

CLAIM: proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern. VERDICT: no. EVIDENCE: the only proactive reporting channel documented is a fixed-cadence email of an entire report, and its configuration surface is exhaustively listed as frequency, recipient addresses, format, a Filters tab and an Advanced layout tab (https://help.flipdish.com/en/articles/9585608; https://help.flipdish.com/en/articles/13638005 for the weekly/monthly sales case) - there is no condition, threshold or deviation test anywhere in it. The 39-article report catalogue (listed in full under order-capture-drive-thru-timers) contains no alerting report. CONTROLS: 'anomaly' 0, 'deviation' 0, 'void spike' 0; POISON: 'alert' 13 hits, all unrelated - food-safety incident handling (https://help.flipdish.com/en/articles/9585225), the kiosk "privacy service alert" during Android setup, and order-notification sounds. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585608 · retrieved 2026-09-17 adversarially verified

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

Flipdish's AI page lists four agents and marks the AI Copilot Agent 'Beta': 'Your personal analyst. An agent to chat with about your business ... "How many orders last night?" "What's my best seller this month?" Ask Flipdish Copilot in plain English and get a straight answer, no spreadsheets, no dashboards, no digging.' That is a natural-language assistant over the operator's own sales data, not a help-article bot - the page states every agent shares the platform's data layer (order history, menu data, customer profiles, revenue data). Named shortfalls: the vendor itself marks it Beta while the other three agents are 'Live'; the described output is a conversational answer explicitly 'no dashboards', so the claim's 'returns a figure or chart' is only half met; and nothing indicates it reaches labor/rota data, which sits in the separate payroll module. Grade C - this is a vendor feature page, and the product documentation that would confirm shipped behaviour is in the excluded help centre. Separately, Flipdish's MCP server (developers.flipdish.com/docs/connect-flipdish-mcp-server-to-claude) lets an external assistant query the account in plain language, but its documented tool areas are orgs/brands, sales channels, menus and opening hours - not sales analytics. https://www.flipdish.com/ai · retrieved 2026-08-09

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

Marketing CRM exposes customer value and order frequency per customer; new-vs-returning cohorts and lifetime-spend cohorting are not documented as reports. https://www.flipdish.com/marketing · 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

'Smart sales forecasts' is a named POS feature; granularity (daypart/hourly) and downstream consumption by scheduling are not documented. https://www.flipdish.com/docs/pos-features · 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

A Tips Report exists with total tips, delivery tips, pick-up tips, refunded tips, tips per store and tips per week, downloadable as CSV/PDF and schedulable by email (9585606). Shortfalls: it is store/channel-level only — no per-employee declared-versus-charged breakdown exists (the payroll calculator's per-staff outputs contain no tips field, 9585185), no tip-pool distribution detail exists anywhere in the enumerated 47-report catalogue, and there is no tip tax-liability summary — the separate Sales Tax Report covers sales tax by tax rate only (12549374). https://help.flipdish.com/en/articles/9585606-tips-report · retrieved 2026-09-17

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

The hierarchy is enforced in the schema, not just implied by URL nesting. In the v3.0 Org Management OpenAPI, SalesChannel requires BOTH brandId and propertyId ('A sales channel is a digital - non physical - version of a property. It is usually composed of one brand'), properties are created under /orgManagement/orgs/{orgId}/properties with type Store|CentralKitchen, and brands under /orgManagement/orgs/{orgId}/brands -- so org > brand and org > property > salesChannel are first-class objects with their own CRUD and archive/unarchive. Reporting scopes to them: listOrgSales and listPropertySales are separate endpoints and sale.* webhook payloads carry orgId, propertyId, salesChannelId and brandId. Permissions scope to them too, on the v1.0 surface: the teammate model carries an AppAccessLevel enum (None, Owner, StoreOwner, ManagedOwner, Integrator, StoreManager, StoreStaff, StoreReadOnlyAccess, FinanceManger, Onboarding, Support) plus HasAccessToAllStores and an explicit StoreIds list, 'Store IDs the user has access to (if HasAccessToAllStores is false)'. Boundary: every v3.0 Org Management endpoint carries 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice.' https://developers.flipdish.com/reference/getsaleschannelbyid · retrieved 2026-08-09 adversarially verified

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

Single-action fan-out is in the request body. POST /menuManagement/orgs/{orgId}/menus/{menuId}/revisions/{revisionId}/publish accepts 'selectedSalesChannelIds', described as an 'Optional list of Sales Channel IDs to publish to' with example ['sc1234','sc1235'] -- one call, a chosen set of destinations, omit it to publish everywhere the menu is referenced. Menus are org-level objects, so authoring is central by construction. The audit half: GET .../revisions lists every revision and the menu schema carries auto-generated createdAt, updatedBy ('Last updated by user'), updatedAt and revisionId; GET .../menus/{menuId}/published returns 'the revision from the most recent publish event for this menu (across all sales channels)' with a menuPublishId; GET .../menus/{menuId}/references returns every propertyName and sales channel using the menu; and GET .../revisions/{revisionId}/publishCheck is a pre-flight returning typed messages. Boundary: the whole Menu Management API carries 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice.' The per-channel POST .../salesChannels/{salesChannelId}/menuPublish the old note cited is the single-destination variant, not the fan-out. https://developers.flipdish.com/reference/post__menumanagement_orgs__orgid_menus__menuid_revisions__revisionid_publish_18 · retrieved 2026-08-09 adversarially verified

Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator

multi-location-local-override-policy

Partial: corporate menu control is real but the governance model is coarse-grained, not per-field. The v1.0 App schema publishes AppResourceSet, 'Constitutes a list of available resources', and its menu grants are exactly ViewMenu, CreateMenu, UpdateMenu, DeleteMenu, UpdateMenuLock, UpdateMenuItemsHideTemporarily and EditMenuImage - so the only sub-menu permission a location can be given is temporarily hiding items. The mechanisms that do vary a menu by location are: assigning a store its own (possibly cloned) menu (/api/v1.0/stores/{storeId}/menu/{menuId}, 'Clone a menu, (without attaching stores)', store.menu.assigned), the bulk show/hide item operations, and in v3.0 a price band per sales channel ('the price band that will be applied to the sales channel. If not provided, the default price band with code default.price.band will be applied', itself carrying a Beta notice) plus per-sales-channel item snooze. Shortfall: neither version defines a field-level override, a locked-attributes collection or a store-level patch of a corporate item - 'Lock/Unlock a Menu for Editing' is an editing lock on the whole menu, not per-field governance. Whether the merchant portal exposes franchisor field locks is help-centre material, excluded by policy. https://developers.flipdish.com/v1.0/reference/getapp-1 · retrieved 2026-08-09

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

Two of the claim's three axes are documented and the third is not. Menu Structure v3.0: 'Each item (CategoryItem or ModifierItem) can have multiple PricingProfiles, one per price band. Each profile defines separate prices for four dispatch types: Collection, Delivery, DineIn, and TakeAway.' The OpenAPI backs it -- BaseItemPricingProfileSchema carries priceBandId plus collectionPrice/deliveryPrice/dineInPrice/takeawayPrice with their own tax and taxable flags -- and the location-group binding is the required priceBandId field on SalesChannel, with price bands themselves listed org-wide via GET /orgManagement/orgs/{orgId}/priceBands. So one item record does carry different prices per location group and per order channel without duplication. The gap is the daypart. Correcting the previous note: the override model is documented, it simply is not a pricing lever -- AvailabilityOverrides 'control when and where a category or item is visible' by property, venue code, dispatch type, day-of-week flags and a fromTime/toTime window, and carry no price field. No time-of-day price schedule appears anywhere in the v3.0 menu schema. Beta Notice applies to the Menu Management API. https://developers.flipdish.com/docs/menu-structure-v3 · retrieved 2026-08-09 adversarially verified

Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator

multi-location-scheduled-publish

Partial: two of the three change types the claim names behave differently. Promos ARE future-datable - the v1.0 Voucher schema carries StartDate ('Voucher Starts On (Time in UTC)') and ExpiryDate ('Voucher Expires On (Time in UTC)') plus day-of-week ValidityPeriods and ChannelRestrictions (Ios, Android, Web, Kiosk, Pos, Google) - and loyalty campaigns carry per-store start times ('Stores this campaign applies to with campaign start time in Utc'). Rollback is documented: v1.0 exposes 'Get a Menus Checkpoints' and 'Restore a Menu to a checkpoint', and v3.0 exposes menu revisions with republish of a prior revision. Shortfalls: (a) menu and price changes have no scheduling field at all - no publishAt, effectiveFrom or scheduledAt exists anywhere in the 1,064-page v1.0 reference or the 99-page v3.0 dump, and neither publishMenuToSalesChannel nor the revision publish endpoint accepts a future time; (b) the promo scheduling that does exist is expressed in UTC, not interpreted in each target location's own timezone, even though stores and properties carry a timezone attribute used for opening hours. Whether the portal offers scheduled menu activation is help-centre material, excluded by policy. https://developers.flipdish.com/v1.0/reference/getvoucherbyid · retrieved 2026-08-09

A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator

multi-location-new-store-template

Cloning exists, but one level below the location. POST /orgManagement/orgs/{orgId}/properties/{propertyId}/salesChannels/{salesChannelId}/clone is documented as 'A cloned sales channel is a copy of an existing sales channel. This makes it easier to create similar sales channels quickly', and its only body field is the new channel's type, from the enum FlipdishKIOSK|FlipdishMobileApp|FlipdishWebApp|FlipdishPhoneAgent -- note POS is a valid SalesChannel type but is not clonable. Its sibling createLinkedSalesChannel goes further: the resulting channel gets a SalesChannelHierarchy of type Linked pointing at a primarySalesChannelId, which 'indicates if the sales channel is dependent on another or if updates to this channel will impact other linked channels', i.e. ongoing inheritance rather than a one-time copy. Shortfalls: a sales channel is 'a digital - non physical - version of a property', so this provisions an ordering channel, not a store; the property itself is created field-by-field via createPropertyForOrg with no template or clone operation anywhere in the v3.0 Org Management reference; taxes, roles, printers, modifiers and tenders are not named as cloned artefacts; and no expected time-to-open is published. Beta Notice applies. https://developers.flipdish.com/reference/clonesaleschannel · retrieved 2026-08-09 adversarially verified

The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator

multi-location-corp-vs-franchisee-roles

Partial: the model is delegated roles inside one tenant, not two tenants. The v1.0 Teammate schema carries AppAccessLevel with the enum None, Owner, StoreOwner, ManagedOwner, Integrator, StoreManager, StoreStaff, StoreReadOnlyAccess, FinanceManger, Onboarding, Support, plus HasAccessToAllStores ('The user has access to all stores for the app (including new stores that added later)') and StoreIds ('Store IDs the user has access to (if HasAccessToAllStores is false)'); the App schema adds PropertyOwner and PropertyManager and gates who may create each level (CreateTeammateOwner, CreateTeammateManagedOwner, CreateTeammateStoreOwner, CreateTeammatePropertyOwner, ...). Some franchisee-owned finance is supported: bank accounts are assignable per store (/api/v1.0/{appId}/bankaccounts/{bankAccountId}/store/{storeId}, ViewAssignedBankAccount, a FinanceManger role, per-account payouts and payout schedules). Shortfalls: there is no second tenant type for an independently-owned franchisee and no cross-org or cross-app visibility grant in either API version - a franchisee is a store-scoped teammate inside the franchisor's own App/Org, so the franchisee does not own a separate tenant for its employees or labor data, and v3.0's only cross-tenant operation is Transfer-brand, which moves a brand between orgs outright. The portal's own role matrix is in help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/getteammatesbyappid · retrieved 2026-08-09

Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator

multi-location-royalty-calculation

CLAIM: calculates franchise royalty, ad-fund and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis. VERDICT: no. EVIDENCE: the multi-location financial reports the product ships are the POS Venue Report, the POS Venue Commissions Report and the group-level sales reports, and none of the 39 report articles computes a fee owed by a franchisee. No royalty rate, basis or schedule field exists in any documented settings screen. CONTROLS: 'royalty' 0, 'ad fund' 0, 'advertising fund' 0, 'franchise fee' 0; POISON: 'franchise' 3 hits - generic prose about who must comply with Spanish tax rules ("neighborhood bars, food trucks, dark kitchens, franchises, and large corporations are all equally obligated"), a Back Office "Franchise level view" that is simply the organisation-level store selector, and an account-recovery instruction that a request "should come directly from the main franchiser (if applicable)". BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585513 · retrieved 2026-09-17 adversarially verified

Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.

multi-location-royalty-collection

CLAIM: automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged. VERDICT: no. EVIDENCE: the portal's own surface is enumerated twice over and there is no franchise money-in anywhere. 'Flipdish Portal Overview' (11 Jul 2025) lists every screen - 'Sales, Reports, Properties, Marketing, Sales Channels, Pay Outs, Add-ons, Settings, Organisation, Subscriptions & Subscription Invoices, Advanced, Sales Channel Groups, Customer Messages, Settings > Sales Channel General Settings, Audit Logs' - and the Add-ons list is closed at 'App Store, Accounts, Documents, Food Safety, Inventory, Payroll, Signage, Central Kitchen, Terminals'; the POS module list is closed at 'Caller ID, CRM, Float Management, KDS & CDS interface, Inventory & Menu Management, Staff Rota, Payroll, Health & Food Safety Management, Order Ingest (Marketplaces)'. Money flows one way in that structure: Payouts to the merchant's own bank account, and Flipdish's own subscription invoices to the merchant. CONTROLS: `royalt*` 0, `direct debit` 0, `ACH` 0 across all 518 articles; `franchis*` scores 4 and every hit is incidental (a Spanish tax article, a QR code article, an upselling report, an email-change article). The account model is Organisation > Brand > Property > Sales Channel, a multi-brand hierarchy with no franchisee-billing entity. Matches the prior pass: v1.0's banking plumbing (customconnect, bankaccounts, payouts, payouts3) is all merchant money-out, with no royalty or fee-ledger object. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/10131355-flipdish-portal-overview · retrieved 2026-09-17 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

'Get full visibility on reports from all your sites from one place'; listOrgSales returns sales across an entire org in one authenticated call. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-01

Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator

multi-location-normalized-item-rollup

The data model supports cross-location item rollup where locations share a menu. Menus are org-level objects published to individual sales channels; every sale references 'the exact menu revision it was placed against' and every line carries menuItemId (a UUID that 'must match an item in the menu/revision referenced by the sale's menuId/menuRevisionId') alongside a per-line unitPrice, so locally different prices do not break the item identity, and the org-wide read endpoints return complete sale payloads for the whole org in one query. Named shortfalls: the shared identifier is a per-menu UUID, not a corporate SKU - an org running two different menus across its estate has two different menuItemId sets for the same dish and no normalisation object is documented to bridge them; a store cannot locally rename an item in this model at all, so the claim's 'even when stores have renamed' case is unaddressed rather than solved; and the org-wide read endpoints are in beta behind 'Contact integrations@flipdish.com to request access'. Whether the portal's own reporting presents a cross-location item rollup is in the excluded help centre. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09

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

CLAIM: gift cards issued at one location redeemable at any other, with an outstanding-liability balance and inter-store settlement. VERDICT: no, because the predicate does not exist. EVIDENCE: https://help.flipdish.com/en/articles/9585173 - "At this time, we do not support gift cards the common way ... we don't validate or track the balance on the 'card'." With no first-party balance ledger there is no liability figure and nothing to settle between stores. CONTROLS: 'gift card' 13 hits across the 518 bodies, all inside that one FAQ and its related-article links. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585173 · retrieved 2026-09-17 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

Loyalty and the customer record are brand-scoped, not per-location. The v1.0 LoyaltyCampaign schema is an app-level object (GET /api/v1.0/{appId}/campaigns/loyalty) whose Stores property is documented as 'Stores this campaign applies to with campaign start time in Utc', with OrdersBeforeReceivingVoucher, PercentDiscountAmount, MaxDiscount and campaign Statistics on the one campaign object; a per-store read (/api/v1.0/{appId}/campaigns/loyalty/{storeId}) returns the campaigns applying to that store rather than a store-owned campaign, and the App permission catalogue treats stamping as a single app-level grant (StampLoyaltyCardAgainstCampaignsConfigurations). The customer side matches: Customer is an app-level entity (CustomerId, RegistrationDate, PhoneNumber, marketing and payment consents) read via /api/v1.0/{appId}/customers/{customerId}, with 'Returns customers of the app to which you have access' and order history per customer across the app (/reporting/v1.0/{appNameId}/customers/orders, /api/v1.0/{appId}/events/customer/{customerId}). Caveat recorded rather than hidden: no stamp-balance object is published, so accrual scope is read from the campaign's own store list; and a chain running more than one Flipdish App would not share customers across them. https://developers.flipdish.com/v1.0/reference/getloyaltycampaignsforapp · retrieved 2026-08-09

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

Multi-brand is modelled at the property, not at the terminal. POST /orgManagement/orgs/{orgId}/properties/{propertyId}/salesChannels creates 'a new sales channel under a specific org and linked to a property and brand', with brandId in the required array, and SalesChannel is described as 'a digital - non physical - version of a property ... usually composed of one brand ... and can have a different menu associated with it'. Since a property may hold many sales channels, one location can run several brands with distinct menus, and revenue separates because sale.* webhook payloads carry brandId (the v3 events overview notes brandId 'is included where sales.* payloads don't carry it'). Shortfalls: nothing in the developer documentation or on flipdish.com describes two brands sharing one physical terminal and cash drawer, separate per-brand receipt branding at the point of sale, or a brand-level P&L report; POS is a SalesChannel type, so a second brand at one till would mean a second POS sales channel, which is not documented as sharing hardware. Withdrawing the previous note's transferBrand evidence: that endpoint is tagged 'Private' in the spec and moves a brand from one org to another, which is unrelated to this claim. Beta Notice applies. https://developers.flipdish.com/reference/createsaleschannelfororgandproperty · retrieved 2026-08-09 adversarially verified

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

Richer than previously recorded, but built for a single-rate VAT regime. GET /api/v1.0/menus/{menuId}/tax returns MenuTaxDetails with TaxRates[] (each a named MenuTaxRate with a percentage Rate), a TaxType enum of IncludedInBasePrice|ExcludedFromBasePrice, and ItemTaxes, an 'ItemIds and TaxIds' map -- so several named rates coexist and different items carry different ones, which is the prepared-food-vs-grocery distinction the claim asks for. They are writable (POST /menus/{menuId}/taxrate Add/Update a Tax Rate, POST /menus/{menuId}/tax/type/{type}, Set tax rate for menu item, Set Tax Rate on OptionSetItem, and a delete that 'can only remove a tax rate that does not have items/optionSetItems attached'). On v3.0, GET /orgManagement/orgs/{orgId}/properties/{propertyId}/vat returns per-property isVatApplicable, isVatInclusive, vatCaption, vatPercentage and operativeVatBands, 'the allowed list of VAT values that can be applied to prices', example [0, 9, 13.5, 23]. Shortfalls, which is why this is not a yes: no rate stacking -- ItemTaxes maps an item to ONE tax id and PropertyVATInfo exposes a single vatPercentage, so US-style simultaneous state/county/city rates on one line are not expressible; the tax-rate set is bound to the menu, not to the location, so per-location tax differences require per-location menus, which cuts against central publishing; the v3.0 property VAT endpoint is read-only with no update counterpart; and per-location exemption exists only as the blunt isVatApplicable boolean, with no exemption certificate or customer-level exemption anywhere. Beta Notice applies to the v3.0 endpoint. https://developers.flipdish.com/v1.0/reference/getmenutaxdetails · retrieved 2026-08-09 adversarially verified

Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator

multi-location-config-audit-log

The v1.0 Events API is a corporate-queryable configuration audit log. GET /api/v1.0/{appId}/events (plus scoped variants /events/store/{storeId}, /events/menu/{menuId}, /events/user/{userId}, /events/order/{orderId}, /events/customer/{customerId}) filters by storeId, storeIdList, storeGroupId, userId, userEmail, userName, menuId, campaignId, voucherCode, eventType and a start/end date range, with limit/page pagination. Its published examples enumerate 84 event types, and the configuration ones carry a User block (UserId, UserName, UserEmail), CreateTime, IpAddress, StoreId/StoreGroupId and the changed object: StoreUpdatedEvent ('1234 updated store 1234'), store.service_charge.updated, store.fee_config.updated, store.tip.updated, store.opening_hours.updated, store.delivery_zone.created/updated/deleted, store.kiosk_setting.updated, store.published/unpublished/archived, menu.updated ('1234 updated menu 1234', whose Menu payload includes TaxRates), menu.bulk.edit, catalog.item.created/updated/archived, voucher.created/updated/deleted, campaign.loyalty.* and campaign.retention.*, teammate.invite.sent/accepted, teammate.updated/deleted, user.created/updated/deleted/login, and webhook_subscription.*. Read access is separately gated per domain by the App permission catalogue (ViewStoreAuditLogs, ViewMenuAuditLogs, ViewVouchersAuditLogs, ViewTeammatesAuditLogs, ViewFeeConfigurationsAuditLogs, ViewOrdersAuditLogs, ViewUserEventsAuditLogs, ViewCatalogAuditLogs and eleven more). Two things are NOT documented and are recorded here rather than assumed: no statement of immutability or retention, and no bulk export of audit entries (the CSV exports are payout and customer exports). Note this is the v1.0 surface - in v3.0 the only audit-log endpoint is the write-only POST /auditLogs/orgs/{orgId}, and the v1.0 store/order audit-log POSTs carry '[BETA - this endpoint is under development]'. https://developers.flipdish.com/v1.0/reference/getevents · retrieved 2026-08-09

Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator

multi-location-enterprise-api

listOrgSales returns transaction-level sales across all properties in an organisation from a single org-scoped OAuth token — no per-location credentials. https://developers.flipdish.com/reference/listorgsales.md · 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

CLAIM: 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. VERDICT: no. EVIDENCE: the labour surface is now documented end to end and it is a rota plus a clock, with exactly one terminal-enforced behaviour and it is not one of the named rules. 'Manage Staff Rotas' is per-store hour entry ('you will have visibility of all your staff members registered for this store', pick from/to times, Copy/Paste across days, Publish) with no rule object. 'How to Use the Clock In and Clock Out Feature on Flipdish POS' (17 Feb 2026) documents the punch as PIN or RFID plus an optional role choice, with no warning, block or threshold, and the only automatic enforcement in the whole corpus is 'If a staff member forgets to clock out using their PIN on the Point of Sale, the system will automatically perform a forced clock-out once the configured time-out period has been reached' - a session timeout, not an overtime or break rule. CONTROLS: `overtime` 0, `predictive scheduling` 0, `labour rule` 0, `labor rule` 0 across all 518 articles; `threshold` scores 1 (the Spanish VeriFactu article); `break` scores 4 and all four are a report 'break down' or a page-break, never a meal or rest break. Matches the prior pass: the v1.0 App permission catalogue names EditPayrollRota/Staff/Holiday and ViewPayrollReports and there is no labor endpoint or rule schema in either API version. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585332-how-to-use-the-clock-in-and-clock-out-feature-on-flipdish-pos · retrieved 2026-09-17 adversarially verified

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

POS is marketed as cloud-based and 'runs on any device', but Flipdish also sells its own 15.6" registers and no supported third-party device list or minimum spec is published. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01

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

www.flipdish.com/posinstall names exactly one client operating system: 'Flipdish Windows application', offered as 'POS App 64bit' ('for anyone who would like to print their orders from a Windows PC and to be used for the PAR PixelPoint Integration') and 'POS App 32bit' ('to be used for the Oracle Micros RES3700 integration ... if your ODBC data source drivers are 32bit'). Shortfall: no minimum Windows version, no CPU/RAM/storage spec and no compatibility matrix are stated anywhere on www.flipdish.com, and no OS at all is named for the 15.6in register, the handheld, the 21.5in KDS or the K2/K2 Mini/D2S kiosks, which are sold as vendor-supplied appliances (pos-system/hardware). developers.flipdish.com carries no client-platform surface (zero occurrences of 'Android' or 'Windows' across the 99-page dump). https://www.flipdish.com/posinstall · retrieved 2026-08-09

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

Purpose-built handheld with integrated payment terminal and receipt printer, 'tough enough for fast-paced service'; no drop rating or IP rating is published. https://www.flipdish.com/handheld-pos · retrieved 2026-08-01

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

CLAIM: the handheld supports hot-swappable or field-replaceable batteries, OR the vendor publishes a rated battery life for a full shift. VERDICT: partial. EVIDENCE: 'Getting Started with Flipdish Handheld POS' (https://help.flipdish.com/en/articles/11508326) identifies the device as a Sunmi V3 Mix and labels its parts, among them a "Battery cover latch" - alongside NFC reader, printing paper container, flashlight, camera, indicator light, magnetic card reader, front camera, display/touch screen, pogo pin connector, loudspeaker, power button, volume button, barcode readers, USB Type-C, USB Type-A and the 80mm paper container latch - so the battery sits behind a user-openable cover rather than being sealed. SHORTFALL: no rated battery life or shift endurance figure is published anywhere in the 518-article census, hot-swap (continuing to run through a change) is never claimed, spare batteries are not listed in 'What are the replacement costs and warranty coverage for Flipdish terminals?', and the vendor's own guidance works around endurance instead: "Quick recharge: Charge the device overnight to ensure all-day performance." BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/11508326 · retrieved 2026-09-17 adversarially verified

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

'Built-in SIM connectivity means it keeps working wherever you need it.' https://www.flipdish.com/handheld-pos · retrieved 2026-08-01

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

Vendor explicitly states: 'The Flipdish POS does not support an offline mode.' All hardware runs cloud-connected only. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

First-party KDS product with station routing, drag-and-drop prioritisation, colour-coded modifiers, label printing and configurable ticket layout, plus a 21.5" kitchen display screen SKU. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01

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

Three form factors (K2 24" floor/wall, K2 Mini 15" tabletop, D2S countertop) with integrated card readers and NFC; ADA/WCAG conformance is stated as an aim under the EAA with no ACR and admitted gaps. https://www.flipdish.com/online-ordering/kiosks · 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 back office's hardware topology editor uses closed constant objects. TerminalTypes = {pos, kds, hardware, kiosk, kitchen, signage, central.kitchen.kds}. DeviceTypes = {receiptPrinter, labelPrinter, telephoneCli, creditCardReader, kotPrinter}. The payment-reader list names World Pay, Hand Point, Payment Sense and Stripe Reader (views/setup/networkDiagram/constants/index.js; minified in chunk 7425.69c97616 as B="receiptPrinter",W="labelPrinter",q="telephoneCli",R="creditCardReader",$="kotPrinter"). There is no speaker, headset, intercom, loop-detector or order-confirmation device. The only display hardware is generic signage ('Signage module allows you to advertise your goods or display information like menu board', PropertyLicenseSubscriptions.jsx; slides activeOrders/image/video/weather). That signage is not drive-thru-specific or outdoor. There is also no drive-thru speed-of-service timer. Graded B, not A: the POS terminal app's own device pairing was not inspected. The existing order-capture-drive-thru note records that Flipdish's hardware page lists no drive-thru peripheral. https://rms.portal.flipdish.com/static/js/7425.69c97616.chunk.js · retrieved 2026-09-15 adversarially verified

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

Hardware line-up includes the Epson TM-20III thermal receipt printer, Brother QL-800 label printer and an 80mm cloud thermal kitchen printer — multiple manufacturers, not vendor-only. https://www.flipdish.com/pos-system/hardware · 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

Cash drawer, barcode scanner, RFID card reader, caller ID and a 10.1" customer-facing display are listed; by-weight scales and a formal published compatibility matrix are absent. https://www.flipdish.com/pos-system/hardware · 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

Partial: the card-entry architecture is documented, the compliance statement is not. The v1.0 API enumerates the supported card readers by model - DeviceType enum CHIPPER_2X, COTS_DEVICE, VERIFONE_P400, WISEPAD_3, WISEPOS_E with a Status enum (Not_Connected, Connecting, Connected, Online...) on /api/v1.0/{appId}/cardreaders/kiosk/{deviceId}/bluetooth/status - and the payment path runs through Stripe Terminal: /api/v1.0/{appId}/payments/terminals/stripe/register and /unregister, /payments/terminals/stripe/{readerId}/processPaymentIntent, /stripeterminal/connectiontoken, /stripeterminal/location, with Emv as a PaymentAccountType on an order and firmware update endpoints per reader; status.flipdish.com publishes a component named 'Card Payments (Stripe)'. So card entry happens on an external reader driven by the app, not by keying into the POS. Shortfalls: (a) no PCI PTS listing reference, no validated P2PE solution listing and no statement of the merchant's SAQ type is published on either permitted host - the 27.6MB v1.0 corpus and the 4.6MB v3.0 corpus contain zero occurrences of PCI, P2PE and SAQ, trust.flipdish.com does not resolve in DNS and www.flipdish.com/security 404s (both re-probed 2026-08-09); (b) COTS_DEVICE in the same enum is a commercial-off-the-shelf device acceptance path, which cuts against the claim that the application device stays out of scope. The compliance documentation, if published, sits in the excluded help centre. https://developers.flipdish.com/v1.0/reference/getbluetoothterminalstatus · retrieved 2026-08-09

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 hardware page FAQ states the requirement directly: 'Can I accept payments with the Flipdish POS? Yes. The Flipdish POS comes with integrated payments and you will need to purchase a Flipdish card reader to take payments.' The device catalogue on the same page offers only a 'Wifi-connected card reader' and mount, and /pos-system/payments answers 'What hardware is included?' with 'a suite of devices including compact, contactless terminals and handheld POS systems'. Neither Tap to Pay on iPhone nor Tap to Pay on Android is named anywhere on www.flipdish.com or in the 99-page developer dump. This is a first-party statement that a separate reader must be bought, not a technical enumeration; help.flipdish.com is excluded by policy and could in principle document a later capability. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-09

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

hardware-pricing-transparency

The hardware page enumerates SKUs with no prices anywhere; the US pricing FAQ defers hardware cost to a quote. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01

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

US pricing FAQ refers to 'upfront costs for Flipdish hardware and implementation' with monthly installment options — implying purchase or financed purchase rather than a mandatory lease, but not stated explicitly. https://www.flipdish.com/us/pricing · retrieved 2026-08-01

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

The Terms of Service answer this against the operator. Section 12.2: 'You may not use the Hardware to run any software not approved or issued by us. Breaching this will incur additional charges based on the preferential pricing we gave you for Hardware. We will notify you of charges at the time. This Section 12.2 survives' termination. Section 11.1 additionally retains title to all Hardware until full payment, and 11.3 lets Flipdish 'recover the Hardware delivered under retention of title or recover or detach such Hardware' on non-performance. So hardware bought from Flipdish is contractually - not necessarily technically - locked to Flipdish-approved software, and that lock is expressly stated to survive the agreement. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

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 T&Cs publish a warranty term but no exchange SLA. Section 12.8: 'we warrant that on delivery and for a period of six (6) months from delivery, the Hardware will conform in material respects with its description and be free from material defects in design, material and workmanship'. Section 12.4.5: 'If we accept a claim of a Hardware fault due to manufacturing or workmanship defect, we may replace it free of charge or refund the purchase price, prorated for the defect'. Shortfall: no advance-exchange or depot-swap programme is offered and no turnaround time of any kind is stated; 12.3 makes returns discretionary ('Hardware is not returnable without our written consent and returns are at our sole discretion', and unboxed/used hardware is non-returnable); 12.4.4 imposes a 7-business-day inspection window on the buyer; and 12.1 puts maintenance on the operator 'unless maintenance is specifically included as a Service'. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

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

hardware-byod

CLAIM: staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model. VERDICT: partial - an arbitrary Android device can be enrolled and the enrolment is documented; personal ownership and a device-security model are not. EVIDENCE FOR: 'Download the Flipdish Terminal Android App' (5 Nov 2025) - 'The Terminal by Flipdish App allows you to do everything that a Flipdish Terminal is capable of doing from your android device. (**Excluding the print function) Requirements: Android device' - installed from the Play Store, then paired by a portal-side enrolment that is itself the permission model: 'Upon downloading and starting the app you will be presented with a 6-digit code... Log in to your Flipdish portal. Go to Add Ons... select Terminals... Select Add terminal... Add a terminal name... Select the store you want to link to the terminal. Add the pin code displayed on your android screen.' 'How to keep accepting online orders if your Flipdish terminal is not operational?' (3 Nov 2025) offers the same app as a sanctioned substitute, alongside the portal's Orders > Live View for 'Owner, Managed Owner, Property Owner, or Property Manager'. SHORTFALL (named): no Flipdish document says the device may be a STAFF MEMBER'S OWN phone - `own phone` 0, `BYOD` 0, `own device` 0 across all 518 articles, and the 3 `personal device` hits are in the Apple Developer account article. There is no device-ownership field, no MDM, remote-wipe or lost-device procedure, and no separate BYOD permission: front-of-house identity is still the shared-terminal model of PIN or RFID card ('Staff typically access the POS via a dedicated pin code. Alternatively, you can have the ability to add RFID card readers'). The app also cannot print 'regardless of if you attach a peripheral printer', and card payment needs a connected Stripe reader, so it is not a full payment device on a phone. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585661-download-the-flipdish-terminal-android-app · retrieved 2026-09-17 adversarially verified

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 v1.0 API exposes a real remote device surface, but only for kiosks and their paired card readers. /api/v1.0/{appId}/cardreaders/kiosk/{deviceId}/bluetooth/status, /bluetooth/{terminalType}/checkForUpdate, /installUpdate, /cancelUpdate, /pair and /unpair give remote reader status, firmware-version checking and remote update install; /api/v1.0/{appId}/kioskiot/timeseries/query (operationId QueryTelemetrySeries) returns kiosk IoT telemetry; and /api/v1.0/kioskiot/connect and /api/v1.0/terminaliot/connect register devices. Shortfalls: every one of these endpoints is flagged '[BETA - this endpoint is under development, do not use it in your production system]'; nothing covers printers or KDS screens; there is no remote reboot and no staged rollout of updates; and no management console (as opposed to API) is documented on either permitted host. status.flipdish.com reports platform components, not individual devices. https://developers.flipdish.com/v1.0/reference/initiatekioskbluetoothupdateinstall · retrieved 2026-08-09

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

CLAIM: integrates with specialty beverage hardware - self-pour tap walls, flow meters or liquor pour spouts - such that pours post to a POS tab automatically. VERDICT: no, and it now rests on a closed enumeration rather than an open marketing list. EVIDENCE: 'What additional Products and Modules can I add to my Flipdish Point of Sale?' (5 Apr 2025) is a closed list: 'In addition to register, KDS and CDS interfaces Flipdish Point of Sale supports the following modules: Caller ID / CRM / Float Management / KDS & CDS interface / Inventory & Menu Management / Staff Rota / Payroll / Health & Food Safety Management / Order Ingest (Marketplaces)'. The portal's Add-ons list is likewise closed at 'App Store, Accounts, Documents, Food Safety, Inventory, Payroll, Signage, Central Kitchen, Terminals'. The hardware articles enumerate the whole device estate - Flipdish Terminal and handheld, kiosks (D2S, T2-15, K2-24, K2 mini 15), Sunmi/Star/Bixolon/Zebra receipt, KOT and label printers, Stripe WisePad 3 / WisePOS E / BBPOS card readers, cash drawer, barcode scanner, RFID reader, KDS screens, CFD/signage players - with no beverage device of any kind. CONTROLS: `pour` 0, `keg` 0, `flow meter` 0, `tap wall` 0, `dispense*` 0, `liquor` 0 across all 518 articles; `bottle*` scores 11 and all eleven are Deposit Return Scheme plastic bottles. Matches the v1.0 App Store partner category enum (PointOfSale, DeliveryAndLogistics, CRM, GiftCard, Accounting, LoyaltyAndMarketing, Other). BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585226-what-additional-products-and-modules-can-i-add-to-my-flipdish-point-of-sale · retrieved 2026-09-17 adversarially verified

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

'Caller ID' is a listed hardware component in the Flipdish POS hardware line-up — relevant to phone-order-heavy takeaway operators. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01

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

extensibility-public-api-docs

developers.flipdish.com is fully public: API overview, error handling, webhooks guides, getting started, ~65 endpoint references, and an llms.txt index. No NDA, agreement or sales call required to read it. https://developers.flipdish.com/ · retrieved 2026-08-01

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 developer documentation documents the entire acquisition path and it contains no plan, fee or per-location gate. 'Build a POS sales analytics integration' step 1: 'Sign up at https://portal.flipdish.com/signup. The portal provisions a brand-new org for the account at signup; this is the org you'll use as your sandbox.' Getting Started: 'To interact with the Flipdish API you will need a Flipdish account. You can create one for free at https://portal.flipdish.com/signup', then 'Click on your avatar and then on Developer tools ... Click on OAuth apps and then on the red Add New button', then request a client-credentials token. The published pricing page sells a single bundled plan from EUR 99 per site per month and enumerates its paid add-ons (Self-Service Kiosks, Managed Marketing, Kitchen Display System, Uber Direct, Customer Feedback App, Restaurant Marketing, Phone Marketing) - no API, developer or integration tier among them. Caveat: no page states in words that API access is included, so this rests on a documented ungated path rather than an explicit price statement. https://developers.flipdish.com/docs/build-a-sales-analytics-integration · retrieved 2026-08-09

The vendor publishes its partner/marketplace commercial terms (referral fee, revenue share percentage, or per-location partner fee) in public documentation.

extensibility-partner-revshare

www.flipdish.com/partner-sign-up publishes the shape of the commercial relationship but not its numbers: 'Discover how you can earn monthly commissions and offer a satisfyingly simple restaurant management solution to your client network', under the heading 'Learn about our Referral and Reseller Programmes'. Shortfall: no commission percentage, no referral fee, no revenue-share split and no per-location partner fee is published anywhere - the rate is gated behind a demo form and a phone number. On the marketplace side, the developer guides 'What is the Flipdish App Store?' and 'How to create a Flipdish App Store app?' walk the whole flow (OAuth app, listing fields, permission level, store selector, configuration type, validation call, approval) and state no listing fee, no revenue share and no monetisation model at all. https://www.flipdish.com/partner-sign-up · retrieved 2026-08-09

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

extensibility-free-sandbox

A free sandbox does exist and is documented: 'Sign up at https://portal.flipdish.com/signup. The portal provisions a brand-new org for the account at signup; this is the org you'll use as your sandbox', with no paid production account required, and 'The same OAuth credentials work in both modes'. Shortfall, and it is the words of the claim: the sandbox ships with no seeded data. 'POST /salesManagement/orgs/{orgId}/sales is how you seed test data into your sandbox so the analytics read path has something to return' - the developer must construct the fixtures. There is also no synthetic webhook trigger: 'The Webhook Service API does not expose a synthetic trigger today, so test against real events on your sandbox org.' The org is a real org on the production endpoints rather than a separate sandbox host, and App Store apps stay sandbox-only until a manual validation call and approval. https://developers.flipdish.com/docs/build-a-sales-analytics-integration · retrieved 2026-08-09

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

OAuth2 client-credentials apps are created self-serve in the portal (Developer tools → OAuth apps) and docs include permission-request and tool-permission concepts; a published scope catalogue and per-operator revocable grants are not documented beyond scope=api. https://developers.flipdish.com/docs/getting-started.md · 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

Two push-webhook surfaces, and the shipped one is v1.0. The v1.0 'Webhook events' page enumerates the available events - order.created, order.accepted, order.rejected, order.refunded, order.tip.updated, order.rating.updated, plus menu.created/updated, customer.created/updated/consent.updated and store.* - and 'Using webhooks' states the purpose plainly: 'notify you of an order so that you can automatically enter it into your POS'. Subscriptions are self-serve (portal Developer tools > Webhooks, or the /api/v1.0/{appId}/webhooks/ subscription endpoints), and none of the v1.0 pages carries a maturity marker: 'Beta' appears zero times across the 1,064-page v1.0 corpus. Polling is documented only as the fallback for integrators who cannot receive webhooks. The newer v3 catalog adds sale.created.v1 / sale.updated.v1 / sale.status.updated.v1 (marked Beta, access by request) and menu.published.v1 and the snooze events (marked 'Generally available'), while the older sales.* events are marked 'Deprecating soon'. Not every state in the claim is a discrete event - there is no separate 'paid' or 'voided' event, payment state travels on the order payload and cancellation shows as order.rejected or sales.cancelled - but created, modified, refunded and status transitions are all pushed. https://developers.flipdish.com/v1.0/docs/webhook-events · retrieved 2026-08-09 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

Retries and a delivery log are documented; cryptographic signing and a replay are not, on the surface that actually ships. On v1.0 (unmarked, i.e. shipped - 'Beta' appears zero times in the 1,064-page v1.0 corpus) authenticity is a static shared secret, not a signature: 'When you set a secret you'll receive the X-Verify-Token header in the webhook POST request.' Retry is stated but unscheduled: 'If a webhook is not successfully received, Flipdish will continue trying to send the webhook for 24 hours', with no backoff curve or attempt count published, and 'When over 50% of webhooks receive a non-2xx response over a 72 hour period, your webhook will be disabled'. The log half is met: the portal Webhook details section shows 'a list of all attempted webhooks and the respective HTTP status codes we received', GET /api/v1.0/{appId}/webhooks/{oauthAppId}/subscriptions/{webhookSubscriptionId}/logs returns the same programmatically, and .../events/{eventName}/test fires a sample event - but nothing documents re-delivering a missed event. The v3.0 guide adds an HMAC-SHA256-over-'${timestamp}.${rawBody}' scheme with a timing-safe comparison example, and it is explicitly at-least-once ('Retries are automatic ... Handlers must be idempotent'), but its own delivery-contract table marks the signature header as not yet shipped: '(planned) X-Flipdish-Signature - HMAC-SHA256 signature for payload verification' and '(planned) X-Flipdish-Idempotency-Key'. For missed deliveries v3 prescribes reconciliation rather than replay: 'Run a periodic reconciler using the org-wide list endpoints.' https://developers.flipdish.com/v1.0/docs/using-webhooks · retrieved 2026-08-09 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

The write API exists and is documented to do what the claim asks, but neither version of it is available to an ordinary customer without asking Flipdish. On v3.0, POST /salesManagement/orgs/{orgId}/sales exists to 'Push sales from an external system (POS, marketplace, kiosk, ordering platform) into Flipdish so they appear in reporting, reconciliation, and the audit trail', carries an x-idempotency-key, fires sale.* webhooks, and sets a 'displayId' that is the 'short, human-readable label shown to restaurant staff on kitchen display systems (KDS) and printed on receipts' - so it is a first-class ticket by the claim's test. But the guide opens 'The Sales Management API is currently in beta. Endpoints may change. Contact integrations@flipdish.com to request access', and the org-wide query endpoints carry a second notice ('they may change without notice'). The older surface is a weaker gate, not an alternative: the only order-creation operation in the entire 1,064-page v1.0 reference is POST /api/v1.0/{appNameId}/order-ingest/submit, labelled '[ALPHA - this endpoint is under internal development, it is not available just yet to use in your production system]'; v1.0's other order operations (getorders, getorderbyid, acceptorder, rejectorder, dispatchorder) only act on orders Flipdish already created. An email-gated beta over an alpha endpoint is not a shipped, self-serve order-injection API. https://developers.flipdish.com/docs/sales-management-api.md · 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

Writable on two surfaces, and the price field is in the body. v3.0: POST /menuManagement/orgs/{orgId}/menus (CreateMenuSchema) and PUT /menuManagement/orgs/{orgId}/menus/{menuId} 'Update menu keeping the same revision' (UpdateMenuSchema) both accept the full object -- categories[] with items, modifiers[] with modifierMembers, and pricingProfiles[] carrying priceBandId with collectionPrice, deliveryPrice, dineInPrice and takeawayPrice plus their tax fields -- alongside DELETE (archive a menu), POST .../snoozes and .../un-snoozes, GET .../publishCheck and POST .../revisions/{revisionId}/publish. v3.0 Menu Management carries 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice.' The v1.0 reference, which carries no such notice, supplies the granular equivalent: Create/Update/Delete menu section item, Create/Update/Delete menu item option set item, Set tax rate for menu item, Set Tax Rate on OptionSetItem, and set/get metadata on both. So writes are not merely whole-document replacement, and the capability does not depend on the beta surface. https://developers.flipdish.com/reference/put__menumanagement_orgs__orgid_menus__menuid_8 · retrieved 2026-08-09 adversarially verified

Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator

extensibility-data-symmetry

Symmetric for four of the five objects the claim names, in the v1.0 API; not for inventory, and not on the v3.0 surface. In the 1,064-page v1.0 reference (OpenAPI 'Flipdish Open API v1.0'): customers are read AND written - GET /api/v1.0/{appId}/customers/{customerId} (GetCustomerById), POST /api/v1.0/{appId}/customers (CreateCustomer, body CustomerCreateModel) and POST /api/v1.0/{appId}/customers/{customerId} (UpdateCustomerById, body CustomerUpdateModel); employees likewise - GET /api/v1.0/{appId}/teammates and /{id}, POST create (CreateTeammate), POST update (UpdateTeammate), DELETE (DeleteTeammate); menus are full CRUD (create/update/delete of menus, sections, section items, option sets, option set items, zones, catalog groups/items and products); orders are readable (GET /api/v1.0/orders, /orders/{id}) and writable (POST /api/v1.0/{appNameId}/order-ingest/submit - OrderIngestSubmitNewOrder - plus accept, reject, refund, dispatch and updatedeliveryinformation). Named shortfalls: (1) INVENTORY has no endpoint at all in either version - the only occurrences of the word in the v1.0 corpus are teammate permission enum values (ViewInventoryStockItems / EditInventoryStockItems, ViewInventoryPurchaseOrders / EditInventoryPurchaseOrders, ViewInventorySupplier, ViewInventoryTrackingProfiles, ViewInventoryReports), so the product has inventory that the API cannot read or write; (2) the guest data that reporting exposes is read-only - GET /reporting/v1.0/{appNameId}/customermanagement and its /details and /orders variants have no write counterpart; (3) loyalty is writable only as campaign configuration (POST/GET /api/v1.0/{appId}/campaigns/loyalty), with no per-guest stamp or points object to read or write; (4) on the newer v3.0 surface reads and writes are split across two products - the org-level Sales API is explicitly "read-only endpoints for querying sales" and directs you to the separate Sales Management API to "create, cancel, or update a sale", and both are in beta. Corpora: the 1,064-page v1.0 reference and the 99-page v3.0 reference, both from developers.flipdish.com llms.txt indexes, dumped 2026-08-09. This note replaces an earlier one asserting there were no customer, employee, loyalty or inventory endpoints at all, which was written against the v3.0 corpus only and is false against v1.0. https://developers.flipdish.com/v1.0/reference/createcustomer · retrieved 2026-08-09 adversarially verified

API rate limits are published as specific numeric quotas with documented throttling behavior and headers.

extensibility-published-rate-limits

Rate limiting is acknowledged and polling budgets are published, but no quota is. The POS integration guide states 'Do not retrieve the full menu frequently to check for changes as this endpoint this is an expensive operation and therefore highly rate limited', and gives numeric cadence guidance instead of limits: 'We recommend that you poll the menu version number once per minute or less frequently' and 'We recommend that you poll for new orders at most every 20 seconds and at least every 60 seconds'. Shortfall: no requests-per-minute or per-hour quota is stated for any endpoint; the Error Handling guide's list of 'common HTTP codes returned in case of errors' runs 400, 401, 403, 404, 409, 414, 500 and omits 429 entirely; and no rate-limit headers are documented - the strings 'rate limit', 'throttl', '429', 'quota' and 'X-RateLimit' appear nowhere in the 4.6MB, 99-page developer corpus. https://developers.flipdish.com/docs/build-a-pos-integration · retrieved 2026-08-09

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

Score is right, source is wrong. /integrations does not name Just Eat, Uber Eats or Deliveroo anywhere. The correct citation is the order-management page: 'Receive and manage all your orders from Just Eat, Uber Eats and Deliveroo, while syncing menus, opening hours and more' and 'Update once in Flipdish POS, and see it go live on Just Eat, Uber Eats, and Deliveroo.' DoorDash and Grubhub confirmed absent from both pages. Partial stands. https://www.flipdish.com/pos-system/order-management · retrieved 2026-08-01 adversarially verified

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

extensibility-middleware-compatibility

Deliverect, ItsaCheckmate and UrbanPiper are all listed integrations, plus Zapier. https://www.flipdish.com/integrations · retrieved 2026-08-01

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

CLAIM: native, vendor-maintained connectors for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export. VERDICT: no. EVIDENCE: the help centre carries a dedicated overview article for every integration Flipdish ships - Deliverect, Lightspeed L-Series, Oracle Micros Simphony, Oracle Micros RES 3700, PAR PixelPoint, Captiva, Star Micronics, DoorDash Drive, Uber Direct, Stuart, Ryde, Vromo, Shipday, Glovo, Order with Google and Zapier - and there is no accounting integration article among them. The only generic bridge is Zapier, whose overview (https://help.flipdish.com/en/articles/9585401) is explicitly a third-party self-serve automation tool and not a mapped GL connector: "Zapier is a workflow automation tool that acts as a bridge between your Flipdish powered Online Ordering Platform and thousands of different web apps ... Each Zap has one app as the 'Trigger', where your information comes from and which causes one or more 'Actions' in another app." CONTROLS: 'QuickBooks' 0, 'Xero' 0, 'Sage' 0, 'NetSuite' 0 across all 518 bodies. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585401 · retrieved 2026-09-17 adversarially verified

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

extensibility-payroll-export

CLAIM: labour hours export natively to at least two NAMED payroll providers without manual re-keying. VERDICT: no. EVIDENCE: the Payroll add-on terminates in Flipdish's own calculator, not an export. 'Use the Payroll Calculator' (https://help.flipdish.com/en/articles/9585185) sits at Add-ons > Payroll > Payroll Calculator, takes "your Employer NI Allowance and HMRC Payment Reference if this is relevant to your region", and produces on-screen summaries only - "A wages summary - Planned wage, Holiday pay, Bonuses and more", "A taxes summary - Employee and employer NI contributions, Pension contributions, PAYE and more", "An employer summary - Net wage, Total pension and HMRC contributions and total payroll costs" - plus a per-staff breakdown of gross wage, net wage, net wage to pay, total NI contribution, total HMRC contribution and PAYE. No provider is named and no file format is documented anywhere in the census. CONTROLS: 'Gusto' 0, 'ADP' 0, 'Paychex' 0, 'Paylocity' 0, 'QuickBooks' 0, 'BrightPay' 0, 'payroll export' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585185 · retrieved 2026-09-17 adversarially verified

Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator

extensibility-bi-data-warehouse

Transaction-level data is fully extractable, but only by a pipeline the customer builds and runs. The v3.0 Sales API exposes org-level read endpoints described as 'paginated complete sale objects for sync or export' - List sales (org-wide), List sales for a property, Get a sale - and the sale.* webhook family 'delivers full sale payloads inline for every sale recorded on Flipdish, regardless of channel'. Flipdish publishes a whole guide for this, 'Build a POS sales analytics integration', covering onboarding, menu reference sync and reconciliation ('Run a periodic reconciler using the org-wide list endpoints'). Shortfall: there is no vendor-operated scheduled export at all - no S3, SFTP, warehouse or Snowflake destination is documented anywhere (zero occurrences of S3, SFTP or Snowflake in the 99-page corpus); the scheduling is advice to the integrator; the org-wide query endpoints carry the beta notice ('may change or be deprecated at any time without notice'); and the portal's own bulk file exports are limited to payout, order, refund and chargeback CSVs on v1.0. https://developers.flipdish.com/reference/sales · retrieved 2026-08-09

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

extensibility-app-marketplace

I read the full /integrations page. It is a static directory grouped by category (POS: Captiva, CES, Clover, Epos Now, HioPOS, Lightspeed, Oracle Micros, PAR PixelPoint, Restaurant Manager, Revel, Revopos, Square, Squirrel, Toast, TouchBistro; last mile: Okestro, Ondway, Nash, Stuart, VROMO; plus Deliverect, ItsaCheckmate, UrbanPiper, Zapier). Every entry routes to 'Contact sales', and the page says 'can't find your POS system? Just get in touch with our friendly Sales team.' The alternative is affirmatively enumerated: sales-gated directory, no browse-and-install, no per-app listings with ins https://www.flipdish.com/integrations · retrieved 2026-08-01 adversarially verified

Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.

extensibility-custom-fields-scripting

Operator-defined custom fields exist as arbitrary key/value metadata on menu objects, documented as a first-class integration mechanism: 'we allow you to store metadata alongside entities in the Flipdish menu. This means you can, if you wish, create a fully functional integration without creating any new datastore on your side ... you will save your associated product IDs/references as metadata for each MenuSectionItem or MenuOptionSetItem. This metadata will then be returned to you in each order notification webhook'. The v1.0 and v3.0 references back it with Get/Update/Delete menu item metadata, metadata-by-key and 'Get metadata for a specific menu item or modifier' endpoints. Shortfalls: it is API-only, so it is a developer facility rather than something an operator configures in the portal on either permitted host; it is scoped to menu entities - the same guide says 'It is not currently possible to add metadata to Customers'; it is unsafe for anything sensitive ('Metadata is not encrypted at rest'); and no vendor-hosted scripting or custom logic exists anywhere in the corpus - the extension model is external webhooks plus App Store apps you host yourself. https://developers.flipdish.com/docs/build-a-pos-integration · retrieved 2026-08-09

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

What exists is sale submission after the fact, not a headless transaction engine. The v3.0 Sales Management API accepts a completed sale 'from an external system (POS, marketplace, kiosk, ordering platform)' with items, charges, discounts and payment lines already priced by the caller, and Flipdish separately drives ordering on top of third-party POS systems. There is no documented API for a third-party UI to drive Flipdish's own transaction engine - no basket, pricing, tax-calculation, tender or payment-authorisation endpoints appear in either reference tree, and the 1,064-page v1.0 reference contains no consumer ordering or checkout operation at all. Access is a second limit: the Sales Management API states 'The Sales Management API is currently in beta. Endpoints may change. Contact integrations@flipdish.com to request access', and v1.0's only order-creation operation, order-ingest/submit, is marked '[ALPHA - ... not available just yet to use in your production system]'. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09 adversarially verified

The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.

extensibility-api-versioning-deprecation

Versioning and supersession are handled in the open; a changelog and a notice policy are not. The API Overview states 'The current API version is v3.0. Consumer Orders endpoints remain available on v1.0', with separate v3.0 and v1.0 reference trees and llms.txt indexes, and superseded guides carry explicit banners pointing at the replacement ('Superseded by the v3.0 sales analytics guide ... this page is kept for reference only'). Shortfall: no changelog is published - developers.flipdish.com/changelog returns the site's 404 shell (74,060 bytes, against ~6.5KB for a real page), 'changelog', 'breaking change' and 'sunset' appear zero times in the 99-page corpus, and the 'Product updates' footer link goes to a Beamer widget rather than an API changelog. Worse for the claim, the stated policy on the many beta endpoints is the opposite of a notice period: 'This endpoint is currently in beta and may change or be deprecated at any time without notice', repeated on essentially every org, brand, property and sales-channel endpoint. https://developers.flipdish.com/docs/api-overview · retrieved 2026-08-09

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

Most of the named data is retrievable through documented machine-readable endpoints at any time: complete paginated sale objects org-wide and per property (Sales API, 'paginated complete sale objects for sync or export'), full menu revisions plus 'Export menu in specific format', audit log queries, v1.0 customer list endpoints, and CSV exports of payouts, payout orders, refunds, chargebacks and other charges. Shortfalls: no contract-end export process or data package is documented anywhere; the menu export and the org-wide sales queries both carry the beta notice ('may change or be deprecated at any time without notice'); no format specification for a full historical dump is published; and the Terms of Service create no return obligation for operator business data - clause 14.2(f) covers only personal data processed by Flipdish as a processor ('at your choice, delete or return all such personal data processed on the termination'), while 5.6 provides that on termination 'all rights granted to you under this Agreement will cease immediately'. Extraction is therefore something the operator must do before the account ends, using beta endpoints, not an on-demand exit deliverable. https://developers.flipdish.com/reference/sales · retrieved 2026-08-09

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

reliability-offline-order-entry

CLAIM: order entry, ticket routing and check printing continue on-terminal when the internet is lost. VERDICT: no - the vendor states the capability does not exist. EVIDENCE: 'Is there an offline mode on the Flipdish Point of Sale?' (https://help.flipdish.com/en/articles/9585187) states in full: "The Flipdish POS does not support an offline mode. If you encounter persistent internet connectivity issues, it may be advisable to consider setting up a backup 'hotspot' network." 'Can the KDS and POS be set up on different internet networks?' (https://help.flipdish.com/en/articles/9585311) adds "Orders are synchronized through Flipdish services, allowing the devices to operate from different network connections" and instructs "Keep devices connected to the internet at all times"; its first troubleshooting step for tickets not reaching the KDS is "Confirm both devices have internet access." The vendor's own continuity article, 'How to keep accepting online orders if your Flipdish Terminal is not operational' (https://help.flipdish.com/en/articles/12733400), offers only two CLOUD routes - the Flipdish Terminal Android app or portal.flipdish.com Live View - and never a local one. CONTROLS: 'offline' 26 hits across the 518 bodies, none describing continued order entry (the senses are the article above, store 'offline'/closed states, and device power-off). BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585187 · retrieved 2026-09-17 adversarially verified

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

reliability-offline-card-auth

No offline mode exists, so offline card authorization is not possible. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

Flipdish has no offline mode and no store-and-forward capability, so declined offline-transaction liability allocation does not apply. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

CLAIM: multiple terminals keep sharing one check/table state over the LAN while the internet is down. VERDICT: no. EVIDENCE: 'Is there an offline mode on the Flipdish Point of Sale?' (https://help.flipdish.com/en/articles/9585187) states in full: "The Flipdish POS does not support an offline mode. If you encounter persistent internet connectivity issues, it may be advisable to consider setting up a backup 'hotspot' network." 'Can the KDS and POS be set up on different internet networks?' (https://help.flipdish.com/en/articles/9585311) adds "Orders are synchronized through Flipdish services, allowing the devices to operate from different network connections" and instructs "Keep devices connected to the internet at all times"; its first troubleshooting step for tickets not reaching the KDS is "Confirm both devices have internet access." The vendor's own continuity article, 'How to keep accepting online orders if your Flipdish Terminal is not operational' (https://help.flipdish.com/en/articles/12733400), offers only two CLOUD routes - the Flipdish Terminal Android app or portal.flipdish.com Live View - and never a local one. Shared state between devices is explicitly cloud-mediated ("Orders are synchronized through Flipdish services"), and POS and KDS need not even share a network - so there is no LAN-only degraded mode to fall back to. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585311 · retrieved 2026-09-17 adversarially verified

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

CLAIM: the vendor documents a local/on-premise transaction engine or edge server for the ordering path. VERDICT: no - the vendor documents the opposite. EVIDENCE: 'Is there an offline mode on the Flipdish Point of Sale?' (https://help.flipdish.com/en/articles/9585187) states in full: "The Flipdish POS does not support an offline mode. If you encounter persistent internet connectivity issues, it may be advisable to consider setting up a backup 'hotspot' network." 'Can the KDS and POS be set up on different internet networks?' (https://help.flipdish.com/en/articles/9585311) adds "Orders are synchronized through Flipdish services, allowing the devices to operate from different network connections" and instructs "Keep devices connected to the internet at all times"; its first troubleshooting step for tickets not reaching the KDS is "Confirm both devices have internet access." The vendor's own continuity article, 'How to keep accepting online orders if your Flipdish Terminal is not operational' (https://help.flipdish.com/en/articles/12733400), offers only two CLOUD routes - the Flipdish Terminal Android app or portal.flipdish.com Live View - and never a local one. 'Access your POS device network diagram via the Flipdish Portal' (https://help.flipdish.com/en/articles/12742087) enumerates everything the portal models as attached to a POS station - "the POS name plus all configured connected devices or peripherals such as a Receipt printer, Card Reader, Caller ID, kitchen printers(KOT) and Label printers", each with its own View/Edit page - and there is no local server, controller or back-office box among them. CONTROLS: 'edge server' 0, 'local server' 0, 'on-premise' 0. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585311 · retrieved 2026-09-17 adversarially verified

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

reliability-offline-kds-printing

CLAIM: kitchen display and/or kitchen printer routing continues to function while offline. VERDICT: no. EVIDENCE: 'Is there an offline mode on the Flipdish Point of Sale?' (https://help.flipdish.com/en/articles/9585187) states in full: "The Flipdish POS does not support an offline mode. If you encounter persistent internet connectivity issues, it may be advisable to consider setting up a backup 'hotspot' network." 'Can the KDS and POS be set up on different internet networks?' (https://help.flipdish.com/en/articles/9585311) adds "Orders are synchronized through Flipdish services, allowing the devices to operate from different network connections" and instructs "Keep devices connected to the internet at all times"; its first troubleshooting step for tickets not reaching the KDS is "Confirm both devices have internet access." The vendor's own continuity article, 'How to keep accepting online orders if your Flipdish Terminal is not operational' (https://help.flipdish.com/en/articles/12733400), offers only two CLOUD routes - the Flipdish Terminal Android app or portal.flipdish.com Live View - and never a local one. Ticket arrival at the KDS is a cloud sync, and the documented remedy for tickets not appearing is to restore internet access on both devices and restart the apps. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585311 · retrieved 2026-09-17 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

CLAIM: the system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff. VERDICT: no, and the printer failure surface is now an enumeration rather than a silence. EVIDENCE: 'Troubleshoot: POS Receipt Printer and KOT' (27 Feb 2026, 10.3 KB) is Flipdish's complete printer failure document and ends in a POS Portal General Printer Troubleshooting Guide table of Failure Symptoms / Possible Causes / Solutions covering power indicator off, abnormality indicator on, voltage, print-head overheating, paper blocked, network indicator off, unclear print, blank page. Every remedy is manual and human: reboot the printer, reseat cables, check the indicator lights, press the feed button three times, 'Verify if the correct printer is selected on the POS App', 'delete the existing POS receipt printer from the Flipdish portal and reconfigure it using the POS Configuration Wizard', log into the portal and 'Change its IP address to the current address shown on the printer's feed print', and finally 'contact our support team and include your AnyDesk address so we can provide remote assistance'. Routing is static: 'If kitchen tags are set for multiple stations on the Flipdish Point of Sale, but I have one printer, will three tickets print?' - 'Three tickets will print from the one printer set up.' Printer health is a pull, not a push: 'Test and Check the Printer Status on Your Terminal' has the operator exit the kiosk shell, open POS Steward and look for a green 'Normal' badge. And there is no degraded mode to fall back into: 'Is there an offline mode on the Flipdish Point of Sale?' answers 'The Flipdish POS does not support an offline mode.' CONTROLS: `backup printer` 0, `secondary printer` 0, `failover` 0, `unreachable` 0, `offline printer` 0 across all 518 articles; `printer status` scores 3, all in the manual-check article; `alert*` scores 13 and none concerns a printer. Matches the prior pass: v1.0 publishes printer.turned_on / turned_off / assigned_to_store / unassigned_from_store as subscribable events an integrator could alert on itself, with no reassignment field. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585705-troubleshoot-pos-receipt-printer-and-kot · retrieved 2026-09-17 adversarially verified

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

The vendor documents no conflict-resolution behavior, and its own FAQ forecloses the scenario the claim describes: 'The Flipdish POS does not support an offline mode' — devices do not operate through a network partition, so no divergent offline edits arise to reconcile, and no last-write-wins/merge/operator-prompt behavior is documented anywhere; the only documented mitigation is 'setting up a backup hotspot network'. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

Flipdish POS does not support offline mode, so no offline-feature matrix exists. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17

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

reliability-public-status-page

The earlier 403 does not reproduce. status.flipdish.com returned HTTP 200 with a full Atlassian Statuspage body on 2026-08-09, with no login anywhere in the flow. It shows 'All Systems Operational' over a per-component breakdown - Core service (99.99% uptime), Web Ordering (100.0%), Flipdish POS (99.97%), Mobile App Ordering, Hosted Websites, API, Kiosks, Flipdish Terminals, Third Party POS Integrations (99.97%), Third Party Delivery Integrations, Star Micronics Integrations, Card Payments (Stripe), Telephony System, Support phone lines, DoorDash Drive Order Fulfillment, CDN, SIM Printers and more - each with 'Uptime over the past 90 days' and a 'View historical uptime' link. Historical state is public too: a 'Past Incidents' timeline on the front page and an archive reachable without credentials (status.flipdish.com/api/v2/incidents.json returns 50 incidents). Email, SMS, Slack and webhook subscriptions are offered. https://status.flipdish.com/ · retrieved 2026-08-09

A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator

reliability-contractual-uptime-sla

T&Cs provide the services on an 'as is' and 'as available' basis with no uptime guarantee and no service-credit remedy. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

The vendor publishes written post-incident reports or root-cause summaries for major outages.

reliability-incident-postmortems

Flipdish publishes root-cause summaries inside its Statuspage incident timeline, but nothing more formal. The 6 August 2026 'Communication service is down' incident closes: 'We identified the root cause as a failed deployment to our Communication Service, which impacted multiple communication-related services, including SMS delivery and payment links. The previous stable deployment has now been successfully restored', with an earlier 'Identified' update timestamped 21:34 BST and the resolution at 21:55 BST. Shortfall: it is not the norm. Reading the public archive (status.flipdish.com/api/v2/incidents.json, 50 incidents on 2026-08-09), most resolutions - including several rated critical, such as 'Intermittent failures accepting payments online' (12 Feb 2026) and 'Orders processing performance issues' (29 Oct 2025) - close with a bare 'This incident has been resolved' or an all-clear with no cause given. No separate written post-incident report, RCA document or postmortem archive is published on either permitted host. https://status.flipdish.com/ · retrieved 2026-08-09

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

Included support comprises a dedicated account manager, Help Centre articles, Flipdish Academy videos and email, WhatsApp and phone support; 24/7/365 coverage is not stated. https://www.flipdish.com/pricing · 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 Terms of Service settle it in Flipdish's own contract, section 12.9 Installation: 'If you decide to use our hardware installation services ... An assigned technician, whether internal or outsourced, will install the hardware at your specified location. Failure to have the premise available or prepared on arrival may incur additional charges ... Any necessary non agreed work including infrastructure or cabling modifications will incur additional charges and may result in the installation appointment being cancelled on arrival.' Section 4.3 lists 'Hardware installation and cabling services' as a chargeable outlay and 4.2 charges 'An initial set-up fee relating to activation and set-up ... for each initial provisioning of the Services'. The hardware page FAQ says the same in sales language: 'to make sure you are setup right, right from the get-go, our team will visit you in person and help with your hardware installation.' So it is real, first-party or via an outsourced technician, and priced as an extra rather than included. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

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

reliability-menu-build-service

Checked on 2026-08-09 and found only indirect hints, not a statement. www.flipdish.com/pricing promises 'From making sure you are set up properly from the start' and 'A dedicated account manager', without saying who builds the menu. The Terms of Service imply Flipdish receives menu data during onboarding - clause 3.1.8 warrants that 'all pricing relating to food and other items that you make available for sale through the Services or provide to us for onboarding is transparent' - and clause 4.2 charges 'An initial set-up fee relating to activation and set-up ... for each initial provisioning of the Services', but neither says a menu build is performed or included. A grep of the 1,719-URL English www sitemap and of the 28 cached www pages for 'onboard', 'menu build' and 'build your menu' turns up nothing beyond that T&C clause. The API cuts the other way in both versions: v3.0 offers bulk menu create/clone and an AI menu editor, and the 1,064-page v1.0 reference adds 'Create a new menu from xlsx file', 'Clone a menu, (without attaching stores)', clone menu section and section item, and menu/section/item image upload - i.e. menu construction is tooled as an operator self-serve job. That is not evidence about what the onboarding team does. help.flipdish.com, where an onboarding article would live, is excluded from this record by policy. || 325th: MERGE HOLD (proposed no/B, held unknown): the priced-services table covers only work outside the original quote, so a menu build bundled into onboarding would not appear in it; the absence cannot carry a no. The agent flagged this as its weakest row. PROPOSAL AS WRITTEN: CLAIM: the vendor performs the initial menu build as part of onboarding rather than leaving it entirely to the operator. VERDICT: no - WEAKEST ROW IN THIS BATCH, see the caveat. EVIDENCE: 'Onboarding Rates and Fees: Additional Services' (23 Jul 2026) prices every onboarding and post-live service Flipdish performs: In-Person Installation, Training and Support (full day GBP750, half day GBP550, GBP90/hr extra), Kiosk Installation (GBP400), Site Survey (GBP200, 'Professional onsite review (up to 1 hour) of your operational set-up and POS hardware requirements'), POS Starter Kit In-Person Installation (GBP300), Onsite Support Call Out, and two data services - 'Loyalty Conversion: Convert and upload your CRM and Loyalty data into the Flipdish Platform. GBP79' and 'Inventory Configuration: Training with our specialist team on inventory configuration and best practices'. A menu build is not among them, although a directly analogous DATA CONVERSION for loyalty is, and priced. Against that, the menu is documented as the operator's own job, by role: 'Create a Menu for your Flipdish POS using AI Menu Editor' (30 Jun 2026) - 'Requirements: You must have access to the Flipdish Portal with one of the following roles: Owner / Managed Owner' - then New Menu, New Category, New Item, enter the price, assign to the property, Publish; plus 'Import a Menu in the AI Menu Editor' ('upload your menu') and the AI enhance pass. CONTROLS: `menu build` 0, `build your menu` 0, `menu upload` 0, and `we will build|create|set up` scores 1 across all 518 articles - and that one is Flipdish Phone Marketing issuing a phone number. CAVEAT, stated so the next pass can overturn it cheaply: the fees article covers 'potential costs that could be incurred outside of your original quote', so a menu build bundled INSIDE the original quote would not appear in it. Would overturn: an onboarding article or a sales page saying Flipdish builds the first menu. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. || 330th: MERGE HOLD (proposed no/B, held unknown): A self-serve curriculum does not bound a service. The academy teaches operators to build menus, and a course titled 'Self Serve with your Flipdish AI Menu Editor' presupposes a non-self-serve path; an onboarding menu build is delivered by an onboarding team under a quote, which no course catalogue enumerates (same shape as the on-site-install hold of the 327th). The 84/84 academy census stands as the bound for what Flipdish TEACHES, and its zero on 'we will build' vocabulary is recorded. PROPOSAL AS WRITTEN: NEW SURFACE that answers the 325th merge hold's caveat (a menu build bundled INSIDE the original quote would not show in the priced-services table): academy.flipdish.com, Flipdish's own customer training academy (Thinkific), never touched by a prior pass. Census: academy.flipdish.com/sitemap.xml = 87 URLs (83 /courses/, 3 /pages/, 14 /collections/); all 84 fetched 200 anonymously, 84,602 chars of extracted curriculum text; nonsense control https://academy.flipdish.com/courses/zzz-nope-nonsense-xyz returns a 165-char shell, i.e. real course pages are discriminated. The academy is the onboarding curriculum itself (collections '01 - Beginner - Get started with Flipdish', '05 - All things Menu', '04 - Flipdish Point of Sale'), and it assigns the first menu build to the OPERATOR by name. EVIDENCE: the beginner/menu course is titled 'Self Serve with your Flipdish AI Menu Editor' - 'Learn how to build and manage a complete menu with the Flipdish AI Menu Editor, from setting it up to publishing it live' - 32 lessons whose chapter 3 is 'Building Your Menu: Creating & Managing Categories / Creating & Managing Items / Introduction to Modifiers / Modifiers: Basic Configuration / Modifiers: Advanced Configuration' and chapter 4 'Getting Your Menu Live: Saving Your Menu / Associating to Channels & Locations / Publishing Your Menu'. 'Flipdish 101 - A comprehensive guide to your Flipdish product' (39 lessons) is the go-live path: chapter 5 'Your Menu' is 'How to make simple menu changes / How to add Menu Options-Extras / How to add Chefs Notes / Uploading Images to your menu', and chapter 8 'Getting ready for Go-Live' is Payout Schedule, Adding a bank account, Go-Live Success Checklist, How to get help, Apple developer account - no menu build by Flipdish anywhere in the go-live chapter. 'Menu Management - Flipdish Point of Sale Course' likewise teaches 'How to create a menu ... How to link a completed menu to a property'. By contrast the academy DOES document work Flipdish performs on the operator's behalf where it exists ('Unboxing and setting up your Flipdish Point of Sale hardware', 'An Introduction to Flipdish Managed Marketing'), so the vocabulary for a done-for-you service is present in this corpus. CONTROLS over the 84,602-char academy corpus, tokenised, case-insensitive: `menu[- ]build` 0, `build (your|the|a) menu` 0, `we (will|can) (build|create|set up|load|enter)` 0, `our (team|specialist|engineer)` 0, `done[- ]for[- ]you` 0, `data entry` 0, `implementation` 0, `migrat*` 0, `onboard*` 0; positive controls `menus?` 317 and `self[- ]serve` 7 prove the corpus and the regexes bite. Also re-fetched the rebuilt marketing site 2026-09-18: www.flipdish.com/sitemap.xml -> 4 locale sitemaps, 555 unique URLs; /gb/posinstall (2,736 chars), /gb/pos-system and /gb/pricing hold no menu-build offer - the only 'onboarding' strings on them are Trustpilot review text. Retrieved 2026-09-18. adversarially verified

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

reliability-hardware-replacement-sla

A replacement remedy is published; a turnaround is not. Terms of Service 12.8 warrants the hardware for 'a period of six (6) months from delivery' and 12.4.5 provides that 'If we accept a claim of a Hardware fault due to manufacturing or workmanship defect, we may replace it free of charge or refund the purchase price, prorated for the defect but we will not have any further liability to you'. Shortfall: there is no advance-exchange or cross-ship programme, purchasable or included, and no turnaround time is stated anywhere - not next-business-day, not any figure. The surrounding clauses run the other way: 12.3 makes returns discretionary ('returns are at our sole discretion', used or unboxed hardware not returnable), 12.4.4 puts a 7-business-day inspection duty on the customer, 12.1 leaves maintenance to the operator 'unless maintenance is specifically included as a Service', and 13.1 disclaims any availability commitment ('as is' and 'as available'). https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.

reliability-backup-restore

CLAIM: operators can trigger and retrieve their own data backup/restore, OR the vendor publishes RPO/RTO figures for data recovery. VERDICT: no - neither limb, now measured over the complete merchant manual that the prior note named as the one remaining gap. EVIDENCE: the only operator-retrievable data in the whole corpus is report output - CSV/download from the Sales Report, POS Sales VAT Report, Customers Report, Performance Summary, Tips Report, Rota Clock-in Report and the payouts screens - which is reporting, not a backup. CONTROLS: `RPO` 0, `RTO` 0, `data export` 0 across all 518 articles. POISON, and it is the whole of the apparent signal: `backup` scores 5 and every hit is something else - 'it may be advisable to consider setting up a backup hotspot network' (the offline-mode FAQ), a backup email, a backup order notification, and two factory-reset articles; `restore` scores 45 and every hit is FACTORY RESET of a device ('Restore Factory Settings on Your Kiosk', '...on Your Flipdish Terminal V2 Pro', '...V3H', 'Restore WisePad 3 Card Reader to Factory Settings', 'Steps to factory reset a terminal via boot recovery') - wiping hardware, the opposite of restoring data. No availability figure is published anywhere: www.flipdish.com/security 404s, trust.flipdish.com is NXDOMAIN, and the Terms of Service disclaim availability at 13.1 ('as is' and 'as available'). Matches the prior pass: v1.0's 'Get a Menus Checkpoints' and 'Restore a Menu to a checkpoint' are both labelled [PRIVATE API] and cannot be invoked by an operator or their integrator. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17 adversarially verified

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

CLAIM: the vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. a validated P2PE listing) covering the post-March-2025 future-dated requirements. VERDICT: no. EVIDENCE: the merchant-facing manual is now read in full and it contains exactly one compliance statement, unversioned and undocumented: 'Benefits of Flipdish payment processing: No need for a separate account / No setup or monthly fees / Simple setup / PCI Compliant' (6 Jun 2025). That bullet is the ONLY `PCI` hit in 518 articles. It names no standard version, no AoC, no SAQ, no validated solution and no way to obtain one. CONTROLS: `P2PE` 0, `SAQ` 0, `tokeniz*` 0, `trust cent*` 0, `ISO 27001` 0, `SOC 2` 0, `SOC2` 0 across all 518 articles, and 0 in the 1,064-page v1.0 and 99-page v3.0 API dumps. POISON: `attestation` scores 4 and all four are bank-account attestations in the IE/UK payout-verification articles. Meanwhile the vendor's own compliance index remains a closed list of five artefacts (www.flipdish.com/legal: T&Cs, Privacy Policy, Cookie Policy, EU Digital Services Act, EU Accessibility Act), /security and /gdpr 404, and trust.flipdish.com and security.flipdish.com are NXDOMAIN. Nothing is published. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585216-what-are-the-benefits-of-processing-payments-through-flipdish-s-payment-technology-on-the-point-of-sale · retrieved 2026-09-17 adversarially verified

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

reliability-mfa-role-based-access

Role-based permissions in the portal are documented; MFA is not documented anywhere we may read. Two first-party statements establish the roles half: the v3 webhooks guide's prerequisites state 'Only users with the Owner or Managed Owner role in the Flipdish portal can create webhooks, as these roles include the Edit Webhooks permission', and the Flipdish MCP server guide states that a passed-through session token means 'your existing role-based permissions are enforced. You only ever see the data and actions your Flipdish account already allows.' Neither page carries a maturity marker. Nothing establishes the MFA half: 'MFA', 'two-factor', 'multi-factor' and 'authenticator' return zero matches across the 99-page v3.0 corpus, the 1,064-page v1.0 corpus and the www.flipdish.com pages retrieved, and the only place enforcement policy would be published is help.flipdish.com, whose robots.txt disallows our crawler by name. An earlier note also asserted 'per-module permissions in the POS'; that is withdrawn as unlocatable in any source we may retrieve. https://developers.flipdish.com/docs/webhooks-v3.md · retrieved 2026-08-09 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

Flipdish Academy videos plus a Help Centre article library are named as included support resources; an on-terminal training mode is not documented. https://www.flipdish.com/pricing · 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

CLAIM: any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. VERDICT: no, and it is now a first-party statement rather than an inference from the API. EVIDENCE: 'Is there an offline mode on the Flipdish Point of Sale?' (5 Apr 2025) answers in full: 'The Flipdish POS does not support an offline mode. If you encounter persistent internet connectivity issues, it may be advisable to consider setting up a backup hotspot network.' There is no local server to promote, and Flipdish's own documented mitigation for a dead terminal is a CLOUD path, not another till: 'How to keep accepting online orders if your Flipdish terminal is not operational?' (3 Nov 2025) offers exactly two options - the Terminal by Flipdish Android app, or 'Flipdish Portal (web)... From the left panel, select Orders. Click the Live View button at the top to see and accept pending orders' - and closes 'If the terminal issue remains unresolved, please contact Flipdish Support for further assistance.' Consistently, KDS and POS are independent cloud clients ('Can the KDS and POS be set up on different internet networks'), each device is registered and attached to a store from the portal, and printers are addressed by IP from the portal. CONTROLS: `failover` 0 across all 518 articles; `server` scores 13 and every hit is a Lightspeed integration server or a laptop in a label-printer setup, never a Flipdish POS role - a trap for a substring search. Matches the prior pass: no role, master, primary, cluster, election or promotion field exists anywhere in the 1,064-page v1.0 reference, and kiosks and terminals each open their own cloud connection. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-09-17 adversarially verified

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

reliability-cellular-backup

The handheld has built-in SIM connectivity as a documented fallback; automatic cellular failover for fixed terminals is not documented. https://www.flipdish.com/handheld-pos · retrieved 2026-08-01

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 Agreement ... continues for 12 months ... It then auto-renews for 12-month periods.' No month-to-month option is offered publicly. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

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

Termination outside the notice window incurs 'termination compensation of the monthly average of the previous 6 months' fees ... multiplied by the number of months remaining in the Term' — explicit liquidated damages. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

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

Publicly accessible T&Cs state the 12-month initial term, 12-month auto-renewal, and a 3-month written cancellation notice window. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

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

Positive evidence of lock-in from the merchant Terms of Service rather than from silence. 1.3: 'You agree that we will be your exclusive provider of technological solutions similar or equivalent to any of the Services that you use.' 3.7: 'Flipdish may accept orders from End-Users on your behalf via the Services and collect payment from End-Users for such orders.' 4.9 Disbursements: 'we will arrange for the transfer of the total amount of payment card sales processed by us during the relevant sales period, less commission, charges and fees payable to us' - the settlement model presumes Flipdish processes the card sales. 4.5 grants Flipdish a right of setoff 'directly from any sales processed through the Services' and 4.7 makes Flipdish the party that manages Chargebacks. No clause anywhere in the T&Cs contemplates an operator-nominated acquirer or PSP. Corroborated commercially: the one published POS plan on www.flipdish.com/pricing (from EUR 99/month per site) lists 'Transparent transaction fees' and 'Integrated payments' as included, and the add-on list (Kiosks, Managed Marketing, KDS, Uber Direct, Customer Feedback App, Phone Marketing) contains no alternative-processor option; www.flipdish.com/pos-system/payments sells Flipdish Pay as 'one solution for online and in-store payments ... All under one roof. One brand.' and answers 'Do I need any extra software? Nope. Everything you need is built in.'; and www.flipdish.com/integrations has POS, last-mile-delivery and 'other' categories but no payments category and names no third-party processor. Caveat recorded honestly: help.flipdish.com is excluded from this record by policy, so a bespoke Client Agreement variation cannot be ruled out from public sources. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

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

No processing rate of any kind — blended or interchange-plus — is published; only the phrase 'transparent transaction fees'. https://www.flipdish.com/pricing · 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

The opposite is published: 'The Fees may be varied by us at any time (acting reasonably)' plus 'an annual adjustment of up to 5% of your processing rate ... to reflect modest changes in operating costs', with no stated penalty-free exit on increase. https://www.flipdish.com/docs-inner/tac-2 · 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

Per-site subscription tiers are published in EUR and USD (bundle from EUR99/mo; website EUR49/USD119; website+app EUR79/USD199; kiosk EUR59/USD79, all billed annually, with higher monthly rates). Standalone POS pricing, per-additional-terminal pricing and every add-on remain quote-only. https://www.flipdish.com/pricing · retrieved 2026-08-01

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

Online ordering, kiosk, KDS, Managed Marketing, Uber Direct, Customer Feedback App and Phone Marketing are separately packaged (some separately priced) and bundling is discounted — but independent mid-term cancellation is not offered given the 12-month term and 3-month notice. https://www.flipdish.com/pricing · retrieved 2026-08-01

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

Hardware is bought upfront with optional monthly installments per the US pricing FAQ; no prices are published for any SKU, so 'at a published price' fails. https://www.flipdish.com/us/pricing · retrieved 2026-08-01

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

Selling third-party-branded SKUs is not the same as accepting hardware you already own. The hardware page lists 15 SKUs (Epson TM-20III (012A0), Brother QL-800, Artech caller ID, cash drawer, barcode scanner, RFID reader, K2/K2 Mini/D2S kiosks) but every one is a Flipdish-supplied item, and there is no supported-device list, no minimum spec, and no BYO statement anywhere — the researcher concedes this under hardware-commodity-devices and hardware-peripherals but then scores 'not locked' as yes. Specific model/firmware pinning (TM-20III with a part number) cuts the other way. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01 adversarially verified

One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.

commercial-implementation-fee-published

The US pricing FAQ states there 'may be upfront costs for Flipdish hardware and implementation' that vary by need — acknowledged but never quantified, and never stated as $0. https://www.flipdish.com/us/pricing · retrieved 2026-08-01

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

Custom reports and paginated sales APIs (listOrgSales, listPropertySales, getSale) let an operator pull transaction-level data; a documented full self-serve export of orders, line items, payments and labour to CSV is absent, and labour data is not in the public API at all. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-01

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

Guest records are exportable, the other two datasets in this claim are not. The v1.0 Reporting API (OpenAPI 'Flipdish Reporting V1', server https://api.flipdish.co, OAuth2) documents GET /reporting/v1.0/{appNameId}/customermanagement - 'By passing in the appropriate query, you can receive filtered and paginated list of customers' - returning CustomerListItem objects with customerId, phoneNumber, name, totalOrders, totalOrderValue, currency, averageOrderValue, lastOrderDate and optedInForMarketing, filterable by store and currency; /customermanagement/details 'Returns the name, phone number and email' (CustomerDetail: customerId, phoneNumber, name, email) and /customermanagement/orders 'Returns the list of orders for a particular customer'. Named shortfalls: (1) no loyalty balance or point/stamp ledger is exposed in either API version - loyalty appears only as campaign configuration (/api/v1.0/{appId}/campaigns/loyalty and /campaigns/loyalty/{storeId}, LoyaltyCampaign create/read plus a StampLoyaltyCardAgainstCampaignsConfigurations teammate permission), with no per-guest stamp count or points balance object anywhere; (2) there is no gift-card resource at all - 'GiftCard' occurs in the 1,064-page v1.0 reference only as an App Store app-category enum value, so gift-card liability balances cannot be exported. Corpora: the 1,064-page v1.0 API reference and the 99-page v3.0 reference, both pulled from developers.flipdish.com llms.txt indexes on 2026-08-09. Whether the merchant portal offers CSV downloads of the same data is documented on help.flipdish.com, which is excluded from this record by policy, so this is scored on the API surface. https://developers.flipdish.com/v1.0/reference/get_reporting-v1-0-appnameid-customermanagement · retrieved 2026-08-09

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

T&Cs provide that on termination Flipdish will 'at your choice, delete or return all such personal data processed' — a return right, but no defined number of days and no format commitment. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

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

T&Cs state 'You retain ownership of all content and data provided by you', but the privacy policy positions Flipdish as controller of consumer ordering data, processing it 'for its own independent purposes, such as platform security, analytics, and service improvement' — so vendor use is not constrained to aggregated/de-identified purposes. https://www.flipdish.com/privacy-policy · retrieved 2026-08-01

The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).

commercial-source-available-selfhost

Proprietary hosted SaaS; no source availability or self-hosting option anywhere in Flipdish materials. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

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

CLAIM: 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. VERDICT: no. EVIDENCE: the one statement Flipdish makes to merchants about payment compliance is the unversioned bullet 'PCI Compliant' in 'What are the benefits of processing payments through Flipdish's payment technology on the Point of Sale?' (6 Jun 2025), whose sibling bullets are commercial, not technical ('No need for a separate account / No setup or monthly fees / Simple setup'), and whose feature list is 'Card reader configuration setup through the Flipdish portal / Configurable tipping options / Supports split payments across multiple payment options / Refunds can be initiated directly from POS / Payout data will be visible in the Flipdish portal / Single invoice for Flipdish Online and POS orders'. No SAQ type is ever named and no tokenization is ever described. CONTROLS: `P2PE` 0, `SAQ` 0, `tokeniz*` 0 across all 518 help articles and 0 across both API dumps; `encrypt*` scores 1 in the whole help centre and it is the cookie-modal article. POISON: `attestation` 4, all bank-account attestations. The hardware is Stripe Terminal (v1.0 cardreaders DeviceType: CHIPPER_2X, COTS_DEVICE, VERIFONE_P400, WISEPAD_3, WISEPOS_E) and the help centre confirms the dependency operationally - 'Stripe readers cannot process payments independently by manually entering amounts. Transactions must be initiated from the connected POS application' - but Stripe's validation is Stripe's, and Flipdish neither claims it nor tells a merchant what SAQ its estate qualifies for. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585216-what-are-the-benefits-of-processing-payments-through-flipdish-s-payment-technology-on-the-point-of-sale · retrieved 2026-09-17 adversarially verified

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

CLAIM: 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. VERDICT: partial - back-office MFA is documented and MANDATORY; the POS limb and the script-integrity limb are not. EVIDENCE FOR: 'Learn about our Sign in upgrades' (27 Feb 2025) is a first-party, dated description of an enforced control set - 'We have introduced Multi-Factor Authentication, which helps protect our customers' accounts should their email or password be compromised. Multi-factor authentication is required while signing in to systems to enhance security by requiring multiple forms of verification, making unauthorised access of customer accounts and data significantly more difficult' - plus Google ReCaptcha bot detection, Google SSO, an improved password policy ('customers are forced to set secure passwords that are not common or guessable'), and the removal of a weaker method entirely: 'No Longer Supporting Passwordless Access. Previously, some of our customers used a pin code to sign in to the portal... this did not offer Flipdish or our clients sufficient levels of security'. Enrolment is compulsory, not optional: 'Existing customers will also need to set up multi factor authentication via one of the available options. Users will be prompted to set this up automatically when they next sign in.' SHORTFALL (named): (1) it is never framed as PCI DSS - `PCI` scores exactly 1 in the whole 518-article corpus and it is the unversioned 'PCI Compliant' bullet on the payments-benefits page; `6.4.3` 0, `11.6.1` 0, `script integrity` 0. (2) The control covers the PORTAL, not the terminal: front-of-house access to the POS remains single-factor by design - 'Staff typically access the POS via a dedicated pin code. Alternatively, you can have the ability to add RFID card readers to the POS terminal to support staff login' - and every POS workflow article opens 'Log into your Flipdish Point of Sale using your PIN or RFID Card reader', so MFA for ALL CDE access is not met. (3) Nothing documents payment-page script integrity monitoring; the only adjacent mechanism remains the v1.0 POST /api/v1.0/csp/report collector, which is a CSP violation sink, not a change-and-tamper-detection commitment. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9721680-learn-about-our-sign-in-upgrades · retrieved 2026-09-17 adversarially verified

Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.

commercial-soc2-attestation

CLAIM: vendor STATES it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request. VERDICT: no. EVIDENCE: the gap the prior note named - 'a merchant-facing security FAQ making exactly that statement would live on help.flipdish.com' - is now closed, and no such statement exists. CONTROLS: `SOC 2` 0, `SOC2` 0, `ISO 27001` 0, `trust cent*` 0 across all 518 help-centre articles and 0 across the 1,064-page v1.0 and 99-page v3.0 API dumps. POISON: `attestation` does score 4, and all four are BANK-ACCOUNT attestations inside 'Verify Your Bank Account for Payouts (IE)' and '(UK)' - a lexical trap that would have read as a compliance hit. The strongest security material Flipdish publishes to merchants is the sign-in upgrade article (ReCaptcha, mandatory MFA, password policy, Google SSO) and an unversioned 'PCI Compliant' bullet - neither is an audit report, and neither offers one on request. The vendor's own compliance index is still closed at five artefacts (www.flipdish.com/legal: T&Cs, Privacy Policy, Cookie Policy, EU Digital Services Act, EU Accessibility Act); /security and /gdpr 404; trust.flipdish.com and security.flipdish.com are NXDOMAIN; and the merchant T&Cs commit only to 'all security measures required pursuant to Data Protection Laws (including Article 32 of the GDPR)'. BOUND: the gate EVERY one of these notes named is gone. help.flipdish.com/robots.txt re-read with curl 2026-09-17 is `User-agent: *` with Disallow only /not-authorized, /not-found and /[helpCenterIdentifier]/ plus Crawl-delay: 1 - it does NOT name ClaudeBot. The 324th pulled the whole English help centre (Intercom): help.flipdish.com/sitemap.xml lists 517 /en/articles/ URLs, 518 article bodies are held (1.93 MB of extracted text), every article id referenced inside those bodies is held, 0 misses - 100% of the publisher's own manifest. Controls below are tokenised, word-boundary, case-insensitive over those 518 articles, and are read together with the prior pass's 1,064-page developers.flipdish.com v1.0 API reference and 99-page v3.0 dump (27.6 MB). POISON NAMED where it bit: `intercom` scores 518 (the Intercom platform copyright on every page), `retention` 45 (retention MARKETING campaigns, not data retention), `bottle` 11 (Deposit Return Scheme plastic bottles), `restore` 45 (factory-reset articles), `section` 251 (website and report sections), `tab` 281 (UI tabs), `break` (report 'break down'), `up to 12` (12 WEEKS for a dispute reversal). Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585216-what-are-the-benefits-of-processing-payments-through-flipdish-s-payment-technology-on-the-point-of-sale · retrieved 2026-09-17 adversarially verified

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

The DPA half is satisfied: Section 14 of the merchant Terms of Service (www.flipdish.com/docs-inner/tac-2) is a data-processing agreement the operator executes by contracting - it defines Data Protection Laws, binds Flipdish as processor to confidentiality, 'all security measures required pursuant to Data Protection Laws (including Article 32 of the GDPR)', 'reasonable assistance to you, by appropriate technical and organisational measures, to respond to data subject rights exercised pursuant to Data Protection Laws (including Articles 15 to 22 of the GDPR)', breach and DPIA assistance, and 'at your choice, delete or return' of the data; 14.4 then allocates joint-controller responsibilities for the Ordering Process, expressly assigning to Flipdish the duty of 'responding to any data subject requests in accordance with the GDPR (including requests under Articles 15 to 22 GDPR)' for data it collects on the Flipdish Platform. The privacy policy adds standard contractual clauses for EEA transfers, available on request from the data-protection mailbox. The tooling half falls short on three named points. (1) Deletion is guest-initiated, not operator-operated: 'If you order online or via iOS, you can select Delete Account under the About my Data section.' (2) It does not cover every channel - 'Kiosk and Android Apps: please contact Flipdish Support' with a phone number plus either the most recent Order ID or the last four digits of the payment card, i.e. a manual, identity-verified email workflow rather than a self-serve one. (3) Nothing documents an operator-side console to LOCATE or EXPORT one guest's records: the complete 106-entry developers.flipdish.com API manifest exposes no customer or guest resource of any kind, so there is no programmatic access-request path either. Deletion is also global rather than per-merchant - 'an account deletion is irreversible and affects your account across all Flipdish-powered restaurants'. No CCPA/CPRA-specific mechanism (do-not-sell/share, authorised-agent handling) is described anywhere on the permitted hosts. https://www.flipdish.com/consumer-information/data-protection · retrieved 2026-08-09

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

A published accessibility statement targets 'WCAG 2.1 Level AA' across websites, mobile apps, kiosks and the ordering flow and commits to European Accessibility Act conformance, citing keyboard navigation and screen-reader compatibility — but there is no VPAT/ACR, no kiosk tactile/audio mode described, and Flipdish concedes 'Some parts of our products are not yet fully accessible.' https://www.flipdish.com/accessibility-statement · retrieved 2026-08-01

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

CLAIM: 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. VERDICT: no. EVIDENCE: price variation in this product is by DISPATCH TYPE, never by tender - 'How to update prices and apply prices by dispatch type' (https://help.flipdish.com/en/articles/14484417), 'What is a Menu Price Band on the Flipdish Point of Sale' (https://help.flipdish.com/en/articles/9585264) and 'Can I set up order type pricing with the Flipdish Point of Sale' (https://help.flipdish.com/en/articles/9585270). The payments articles - 'What payment types are accepted by the Flipdish Point of Sale' (https://help.flipdish.com/en/articles/9585220), 'Add a custom payment method to your Flipdish POS' (https://help.flipdish.com/en/articles/9619326), 'Configure Service Charges in the Flipdish Portal' and 'What are the benefits of processing payments through Flipdish's payment technology' (https://help.flipdish.com/en/articles/9585216) - enumerate cash, card, custom payment methods, service charges and tipping, and none of them offers a cash/card price differential or a card-type exclusion rule. CONTROLS: 'surcharge' 0, 'cash discount' 0, 'dual pricing' 0, 'non-cash adjustment' 0 across all 518 bodies. BOUND: the help centre's ClaudeBot bar is GONE - help.flipdish.com/robots.txt re-read 2026-09-17 (146 B) is now only 'User-agent: * / Disallow: /not-authorized /not-found /[helpCenterIdentifier]/ / Crawl-delay: 1', with no Cloudflare ClaudeBot block and no Content-Signal, so the 78 flipdish notes that read 'excluded from this sweep by policy' are superseded. CORPUS: all 517 English articles in help.flipdish.com/sitemap.xml (952 locs = 921 article URLs across en/de/es + 31 collections), fetched with curl and a browser UA; an href fixpoint over every /en/articles/<id> link inside those 517 bodies referenced 518 distinct ids, and the one residual (9585411-add-taxes-to-menu-items, absent from the sitemap) was fetched at 200 - so the census is 518/518 with zero misses. Soft-200 control: /en/articles/0000000-zzq-nope-control returns an explicit 404. All controls below are tokenised, word-boundary, case-insensitive over those 518 bodies. Retrieved 2026-09-17. https://help.flipdish.com/en/articles/9585220 · retrieved 2026-09-17 adversarially verified