Vendors / Mainstream commercial restaurant POS

Shift4 SkyTab

Shift4 SkyTab (Shift4 Dine)

dossier live

Claims in scope
278
Scored
278
Assessed
278
Unknown
0
Not applicable
36
Values challenged
36

Identity

Owner
Shift4 Payments, Inc. (NYSE: FOUR)
Parent
Shift4
Founded
Shift4 Payments traces to 1999 (United Bank Card / Harbortouch); SkyTab POS launched 2020-2021 and was renamed Shift4 Dine effective 12 May 2026. The rename is real in the product and the documentation - the help-centre category, article titles and release notes are all 'Shift4 Dine' - but it is not complete in market: shift4dine.com 301-redirects to skytab.com, release-note titles alternate between 'SkyTab POS v1.121' and 'Shift4 Dine v1.126.2', and the Grow My Business hub still sells a 'SkyTab Air' module.
Scale
unknown. No SkyTab/Shift4 Dine installed-base figure is retrievable. Shift4's investor material was not reachable in this session - www.shift4.com returned HTTP 403 and then 429 to every request - so the company-wide merchant count could not be quoted from a primary source either, and no company-wide figure should be attributed to this product in any case.
Who it is for
Independent full-service restaurants and bars, 1-5 locations, sold with hardware, on-site installation and a Shift4-built menu; also the migration destination for Shift4's legacy POSitouch, Restaurant Manager/QSR & Delivery, FuturePOS and Harbortouch estates, which remain documented under a separate Legacy POS Solutions category. Multi-Location Management (Enterprise > Group > Location) and Business Intelligence hierarchies extend it upmarket. Documented geographies are US, Canada, UK, Ireland and Spain, with Spanish fiscalization shipped.
Site
https://www.shift4.com/skytab/

Pricing

transparency: partial · unit: per-terminal · processor lock-in: yes

Software
$29.99 per POS per month for Shift4 Dine, plus a stack of separate recurring first-party fees. Corrected by the 2026-08-03 adversarial pass, which found the figure published on a Shift4 property the previous pass had not searched. The help centre's End-to-End Billing Matrix & Statement Glossary lists 'POS Monthly | PO1, PO2, PO3 | $29.99-$79.99/month - Fee for the POS system, which covers reporting, maintenance, support, and swaps. Charged per POS and based on tier', and defines the tiers as 'PO1: Shift4 Dine POS' and 'PO2: Harbortouch systems, Future POS, Restaurant Manager POS, POSitouch, Focus POS'. The same table publishes Shift4 Dine Customer Hub $20/month, Wireless Data $19.99/month, POS Software (Focus POS only) $19.99 per device, Online Ordering and Delivery Services Enablement $34.99/month effective 7/1/2026, Workforce Management $35/MID, Gift Card Service $25/month, a Monthly Administration Fee of $0-$25 for net-new merchants ('most common rate for existing merchants is $35 per month'), a Monthly Minimum Fee of up to $40, a Monthly Premium Support & Service Fee of $50-$150, and Inactivity at $75 per device. So $29.99 is the terminal software line, NOT the all-in bundled price the third-party roundups report. Marked partial rather than published because these are statement line items explained in a support article, not a pricing page: what a given merchant is actually enrolled in is not published, and the marketing estate that would say so remains bot-blocked - www.shift4.com/skytab/ 403s, and skytab.com and skytab.com/pricing (shift4dine.com 301-redirects there) return 403 then 429 to both the fetch tool and a browser user agent. Source: https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary retrieved 2026-08-03.
Card processing
unknown as a discount rate. No card rate - blended, tiered or interchange-plus - is published in any retrievable Shift4 source, and the Advantage Program articles configure a merchant-chosen Fee Percentage for supplemental fee, dual pricing or cash discount rather than a processing rate. What the 2026-08-03 adversarial pass did recover from the help centre's billing glossary is the per-transaction furniture that sits alongside whatever rate is negotiated: 'Bank Sponsorship Fee: $0.005 Per Transaction', 'Network Transaction Fee: $0.02 Per Transaction', 'Enhanced Security Fee: $0.015 per transaction', 'Batch Header Fee: $0.40 Per Batch', 'Month End Billing: 0.05% per transaction fee for merchants on monthly billing' and 'Incoming Chargebacks: $35 Per Occurrence'. Source: https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary retrieved 2026-08-03.
Contract
30-month Initial Term, then automatic renewal for successive one-year Renewal Terms unless written non-renewal notice is given at least 30 days before expiry, with a 30-calendar-day penalty-free Trial Period from the Effective Date. Source: the SkyTab POS System Service Agreement Terms and Conditions, published at www.shift4.com/pdf/SkyTab-POS-System-Service-Agreement.pdf. Evidence caveat: that URL returns HTTP 403 to this environment; the term, renewal and notice figures were read as indexed text of the vendor PDF by this atlas's 2026-08-01 adversarial pass, and Reforming Retail (2025-12-30) independently quotes the trial clause verbatim - 'Merchant may cancel the Service Agreement without any penalty within thirty (30) calendar days from the Effective Date'. Nobody on this project has rendered the document, so treat as vendor-source at snippet level.
Early termination
Yes, amount unpublished. Reforming Retail documents a merchant invoiced a $45,000 cancellation fee and describes Shift4 computing termination charges from anticipated profit over the remaining term. Grade E - the contract text itself was not readable.

API posture

public API: partner-gated

Cost to integrate
Shift4 states 'Marketplace Cost: Free Shift4 integration! Please contact the third-party integrator for pricing information on the integration' - so Shift4 does not charge for the connection itself, but partner commercial terms and any merchant-side data-access fee are unpublished.
Webhooks
Payments only. The public gateway API exposes an Events resource covering charge, refund, customer, subscription and dispute objects. No POS order, check, menu or labor webhook is documented anywhere, and signing and retry behaviour are not stated in the retrieved pages.
Data export on exit
Partial and manual. Every Customer Hub report downloads as CSV, Excel or PDF and can be scheduled by email; Business Intelligence exports Excel/PDF; Workforce Management exports timecards as CSV including a Paylocity-mapped format. The one genuine exit artifact is the documented Token Migration file (PAN, expiry, cardholder name, street address, postal code) produced on request for handover to another processor or POS/PMS. There is no bulk or API export of the transaction record, and no post-termination retrieval window is published.
Notes
The structural finding is unchanged from the previous pass and now better evidenced: dev.shift4.com is the Shift4 *gateway* API and contains no POS objects - Charges, Refunds, Customers, Cards, Subscriptions, Plans, Payment Methods, Tokens, Payment Links, Disputes, Fraud Warnings, Blacklist, Events, Payouts, Credits, Charge Splits, File Uploads, Checkout - with HTTP Basic auth on a secret key and a documented 429 but no published rate limit. What this pass adds is that a POS integration surface demonstrably exists and is simply unpublished: the Marketplace installation matrix names roughly seventy partners, Loman AI 'pulls your menu directly from Shift4 Dine' and injects phone orders that route to the KDS, Delivery Management reads and writes third-party menus, and the install flow is an operator-granted, per-location, revocable permission grant ('Review the requested permissions and select Allow'). So Shift4 Dine is not closed - it is curated. There is no public reference, no scope list, no self-serve credential and no sandbox for POS data, which is a disclosure choice rather than an architectural limit.

Capabilities

Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.

Order capture & FOH workflow

Partial

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

Real graphical builder: Table Layout Builder in the Customer Hub with named Sections (add/rename/deactivate), round or rectangular tables, per-table Seats maximum, size/rotation/radius controls, snap-to-grid, duplicate, active/inactive, and free-placed Labels for host stand or bar. Shortfall: no documented assignment of a section to a server - Table View colours tables only by who owns a ticket on them - and 'Shift4 Dine is not capable of configuring table layout on the Workstation directly; this must be done via the Customer Hub.' https://shift4.zendesk.com/hc/en-us/articles/360042824993-Configure-Table-Layouts-Sections-and-Labels-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

Items are tagged to a seat/guest at entry and can be reassigned after the fact ('Move an Item Between Guests/Seats'); SPLIT BY SEAT then 'will automatically create separate tickets for all seat guests. It will also split table items on the original ticket evenly across the seats' without re-keying (Split Button Functionality, article 7559924961299). https://shift4.zendesk.com/hc/en-us/articles/13577969885331-Move-an-Item-Between-Guests-Seats-on-Shift4-Dine · retrieved 2026-08-03

B
Yes

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

Courses are first-class objects created in the Customer Hub ('Create or Edit a Course', article 29002588943891) and in Multi-Location Management; Menu Coursing times the kitchen slip per item and Quick Coursing fires a course on demand from the workstation. Send Ticket Options and 'Send a Ticket as a Rush & Continue' control what releases to the KDS. https://shift4.zendesk.com/hc/en-us/articles/48860719056787-Quick-Coursing-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
Yes

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

Four documented methods on Workstation, Tablet and Handheld: Split by Seat, Manual Split (reassign items across checks), Item Split ('Portion amounts and pricing automatically calculate based on how the item is divided') and Split Equally 'e.g., 3-ways, 4-ways'. COMBINE TICKETS merges two or more selected tickets (article 7559924961299) and partial payments are supported on a ticket before splitting. https://shift4.zendesk.com/hc/en-us/articles/45011106030995-Split-Check-Methods-on-Handheld · retrieved 2026-08-03

B
Partial

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

Pre-auth bar tabs ship, with a Standard Pre-auth Amount (min $1.00) and incremental top-up: 'When the ticket exceeds that amount, Shift4 increments the pre-authorization with the credit processor if that is supported by the processor. Otherwise, the system retains the original pre-authorization.' Three named shortfalls: the auth amount 'cannot be modified on a per-ticket or per-tab basis'; 'Tickets with pre-auths on them cannot be split or combined'; and 'No warning is currently provided to the end-user that the preauthorization amount has been exceeded.' No auto-close of stale tabs at end of day is documented. https://shift4.zendesk.com/hc/en-us/articles/6821343653651-Pre-Authorizations-and-Bar-Tabs-on-Shift4-Dine-and-Shift4-Duo · retrieved 2026-08-03

B
Partial

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

Open tickets transfer to another clocked-in employee from the Grid View, and Table View adds a documented 'Transfer a Table' action. Shortfall: no article states that the transfer is written to an audit log naming both the sending and receiving employee; Activity Manager and the Location Activity Reports for Audits are described in terms of ticket, void and discount activity, not transfer attribution. https://shift4.zendesk.com/hc/en-us/articles/46259958684435-Transfer-a-Ticket-to-Another-User-on-Shift4-Dine · retrieved 2026-08-03

B
Yes

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

First-party handheld with its own native app surface (dedicated Create a Ticket, Ticket Functions, Split Check Methods, Table View, Pre-Authorization, QR Pay and printer-setup articles), an integrated reader taking Chip/Swipe/Contactless including Apple Pay, Google Pay and Interac Flash, plus Wi-Fi, Bluetooth and 4G LTE. https://shift4.zendesk.com/hc/en-us/articles/41246927844883-Handheld-Specifications · retrieved 2026-08-03

B
Yes

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

Offline Payments mode is preconfigured on and order entry continues: 'Will my local network, printers, Kitchen Display System, etc., work in Offline Mode? These will work as long as the local network is connected.' The same FAQ publishes the exclusions - pre-authorizations and refunds are disabled, Customer-facing Display cannot take payment, Shift4 Duo does not support offline payments, and menu edits made offline will not sync to other stations. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Partial

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

QR Order lets a guest scan a table QR that 'includes table information', view the menu, add items and send them to the kitchen, with 'SMS click-through authentication to connect customers to the items they ordered properly and to allow them to order multiple rounds'. Shortfall: the documentation describes the guest's own rounds accumulating, and never states that guest-entered items land on a check a server already opened for that table. https://shift4.zendesk.com/hc/en-us/articles/22764853427347-Shift4-Dine-QR-Multi-Round-Ordering-Overview · retrieved 2026-08-03

B
Partial

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 kiosk with documented order flows, admin settings, order numbers, an A35 PIN pad and a merchant dashboard, driven from the same Menu Manager menu. Two shortfalls from Shift4's own FAQ: 'Does Kiosk support Loyalty? Not at this time' and 'the Kiosk terminal is not a Workstation and cannot be assigned or counted towards Revenue Centers'. No ADA/WCAG conformance statement for the kiosk was found anywhere in the help centre. https://shift4.zendesk.com/hc/en-us/articles/47443792410259-Kiosk-FAQs · retrieved 2026-08-03

B
No

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

Across all 2,162 current help-centre articles the only Shift4 Dine (= SkyTab POS, per Release Notes v1.125.2: 'SkyTab POS is now Shift4 Dine') mentions of drive-thru are digital-signage integrations; this 2026-06-02 article's scope is to 'display menu content on drive-thru menu boards, interior displays, and self-order kiosks' -- display only. Anchored searches returned ZERO hits corpus-wide for order confirmation display, OCD, pull-forward, parking spot, tandem, and drive-thru lane. The one drive-thru order-flow article, Service Types Overview in QSR & Delivery (360038373674, updated 2025-09-09), belongs to the separate QSR & Delivery product, and even there drive-thru is only '5 = Drive Thru', a per-station service type, with no window separation or sequencing. The 129 gated ids cluster on offline behaviour and scales, not drive-thru, so the zero-hit is load-bearing here. https://shift4.zendesk.com/hc/en-us/articles/52136495149715-Enable-Clarity-in-the-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
No

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

order-capture-drive-thru-timers

Shift4 Dine's only kitchen timing instrument is forward-looking prep time, not measured speed-of-service segments: 'Prep Times allow you to define how long individual menu items and modifiers take to prepare' and they 'control when items appear on kitchen screens' (updated 2026-05-12). An anchored corpus-wide search for 'Speed of Service' returns seven files; the only actual timer report is on ChefTab, a different Shift4 product, whose article is dated 2023-07-31 and says 'there is a report on the KVS itself that will show the speed of service' broken down 'by Day Part, by Ticket, and by Item' -- no drive-thru order/total/window segments anywhere, and no drive-thru timer in any Shift4 Dine article. https://shift4.zendesk.com/hc/en-us/articles/29683681715731-Configure-Prep-Times-by-Item-and-Modifier-for-the-Kitchen-Display-System · retrieved 2026-09-05 adversarially verified

B
Partial

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

Third-party voice AI is a documented, installable Marketplace integration: Loman AI 'pulls your menu directly from Shift4 Dine', phone orders 'appear in Shift4 Dine as an online order; routes to the correct kitchen display automatically - no manual entry needed'. Shortfall: no first-party voice agent, and the partner path is a curated Marketplace listing rather than a published API partner program - there is no public POS API a voice vendor could build against unaided. https://shift4.zendesk.com/hc/en-us/articles/51910521192979-Enable-Loman-AI-in-the-Customer-Hub · retrieved 2026-08-03

B
Yes

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

Two documented throttles. First-party Online Ordering: 'Restrict number of orders to [ ] every 15 minutes'. Third-party channels via Delivery Management: kitchen capacity in items per prep-time window, with automatic quote extension - 'if capacity is set to 10 items, then items 11-20 will be throttled by an additional 30 minutes, resulting in a 60-minute total prep time.' https://shift4.zendesk.com/hc/en-us/articles/46679956647571-Enable-Kitchen-Capacity-for-Automated-Order-Throttling-on-Delivery-Management · retrieved 2026-08-03 adversarially verified

B
Yes

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

Online Ordering publishes three future-order horizons - 'Same Day: earliest pickup or delivery time = store opening time + prep time' and '1-6 Days Out'. On the POS side, Due Time and Schedule Send hold a ticket and release it to the kitchen at a computed fire time rather than on entry (articles 48881187189011 and 51518556318355). https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Install-and-Configure-Online-Ordering · retrieved 2026-08-03

B
Partial

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

order-capture-catering

The only catering-adjacent capability documented is Online Ordering's '1-6 Days Out' scheduling, which Shift4 itself annotates '(ideal for catering)', plus a Duplicate Ticket button described as useful 'for catering purposes when repeating a specific order'. Shortfall: no catering module - no quotes or proposals, no deposits, no balance-due tracking and no event schedule separate from the standard order queue appear anywhere in the help centre. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Install-and-Configure-Online-Ordering · retrieved 2026-08-03

B
Partial

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

A ready signal does reach the marketplaces and affects courier dispatch - Shift4 publishes an article specifically on how marking an order Ready changes driver assignment across delivery platforms. Shortfall: the documented trigger is an action in the Delivery Management console, not POS or KDS state; no article states that completing the ticket on the workstation or bumping it on the Shift4 KDS emits the order-ready event. https://shift4.zendesk.com/hc/en-us/articles/46805970263315-Impact-of-Marking-an-Order-as-Ready-on-Driver-Assignment-Across-Delivery-Platforms-on-Delivery-Management · retrieved 2026-08-03

B
Yes

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

Voids are taken against configurable Reasons (Manager > Business > Reasons, each carrying a Track Wasted Inventory toggle); job permissions gate void, refund, discount and menu-setup actions individually with PIN override (Change Job Permissions/Settings, article 16082878610323); and Void Reports plus the Business Intelligence Voids/Discounts/Refunds alerts drill from the exception to the ticket and the employee. https://shift4.zendesk.com/hc/en-us/articles/37741650584339-Void-Item-or-Ticket-Counts-as-Inventory-Loss-in-Shift4-Dine · retrieved 2026-08-03

B

Menu, modifiers & pricing engine

Partial

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

Nesting is documented and shipped: a Modifier Set is attached to a Modifier via 'Assigned Nested Modifier Sets', so item > modifier set > nested modifier set works, and the nested set 'appears in a drop-down menu' at order entry. Shortfall: the walkthrough shows exactly one level of nesting and no article documents a third level, nor per-level min/max selection counts; the only forced-selection mechanism described is required modifier sets at the top level. https://shift4.zendesk.com/hc/en-us/articles/360033980194-Set-Up-and-Use-Nested-Modifiers-on-Shift4-Dine · retrieved 2026-08-03

B
No

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

Modifier price in Shift4 Dine is a single scalar on the modifier set: 'enter the required fields for the modifier set name and default price' (updated 2026-05-12). The modifier record itself carries no price field at all -- Create and Manage Modifiers in Multi-Location Management (43088129346323) lists only name, kitchen print name, colour, red/bold, special request, and nested modifier sets. Shift4 Dine does have a matrix construct, but it is an ITEM matrix, not a modifier matrix, and it explicitly excludes modifiers and prices: 'The following fields do not apply to Matrix Items and will not be shown: price, modifier sets, taxes' (Set up Matrix Items in Multi-Location Management, 51336311331475, 2026-05-18). The only true modifier-by-size matrix in the corpus is in QSR & Delivery -- 'Matrix Pricing in QSR & Delivery is used primarily for pizza and allows you to ring in toppings on different-sized portions of a pizza' -- a different Shift4 product. Overrides exist only per location, not per parent item. https://shift4.zendesk.com/hc/en-us/articles/43106955069971-Create-and-Manage-Modifier-Sets-in-Multi-Location-Management · retrieved 2026-09-05 adversarially verified

B
Partial

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

menu-pricing-fractional-placement

Pre-Modifiers give placement prefixes explicitly including 'SIDE, ON THE SIDE, LEFT SIDE, RIGHT SIDE, WHOLE' with a per-pre-modifier price adjustment that is either 'Percentage (%) or Flat ($)' - so a half carries its own price. Shortfalls named by Shift4: 'Currently, only one Pre-Modifier Set is supported. It appears for every item that has at least one modifier set'; halves only, no quarters; and 'Pre-Modifiers are not compatible with: Online Ordering, Third-party delivery platforms (Uber Eats, DoorDash, etc.), Kiosk, Shift4 Duo.' https://shift4.zendesk.com/hc/en-us/articles/46547019716883-Configure-Pre-Modifiers-and-Pre-Modifier-Sets-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Only one of the three pricing models is configurable: charge each topping at a fraction of full price, via a 'Percentage (%) or Flat ($)' adjustment on a placement pre-modifier ('SIDE, ON THE SIDE, LEFT SIDE, RIGHT SIDE, WHOLE'), where negative values reduce the price but cannot take it below $0. Shortfalls: no charge-the-higher-half and no average-the-halves rule exists; the adjustment is a static per-pre-modifier value rather than a rule evaluated across the two halves; and the feature is channel-limited - Shift4 states pre-modifiers are incompatible with 'Online Ordering, Third-party delivery platforms (Uber Eats, DoorDash, etc.), Kiosk, Shift4 Duo', so a half-and-half priced in the dining room cannot be ordered online. https://shift4.zendesk.com/hc/en-us/articles/46547019716883-Configure-Pre-Modifiers-and-Pre-Modifier-Sets-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03 adversarially verified

B
Yes

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

Pre-Modifiers ship quantity prefixes 'LITE, EXTRA' with an independent price multiplier per prefix ('$1 +100% = $2'), which the docs distinguish from adding the modifier twice; nested modifier ordering separately notes 'There is an option to change the quantity of the modifier... If there is a charge for extra items, another modifier needs to be added.' https://shift4.zendesk.com/hc/en-us/articles/46547019716883-Configure-Pre-Modifiers-and-Pre-Modifier-Sets-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Matrix Items are exactly the two-axis grid: a single button (Shift4's own example is 'BYO Pizza') prompts Size then Crust, 'Only values that lead to a valid item given the previous selection are shown', and each cell resolves to a Standard Item with 'its own price, revenue class, and department assignment'. Shortfalls stated by Shift4: 'This feature is currently available only for Pilot users', it can only be configured in Multi-Location Management, 'Matrix Items cannot be used as items within Combo Slots', and 'The Matrix Item prompt flow is only supported on the Workstation for Shift4 Dine and Handheld. Matrix Items are filtered out of menus on other platforms.' https://shift4.zendesk.com/hc/en-us/articles/51336421672211-Use-Matrix-Items-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
No

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

The Menu Viewer article enumerates the modifier-set configuration surface for Shift4 Dine: 'whether the modifier set is required, minimum and maximum modifier selection per modifier set, minimum and maximum modifier quantity per modifier set, if modifier prints in red and bold, and the default modifier price.' Those are hard selection limits, not an included allowance with automatic overage charging. The concept exists elsewhere in the corpus but only under Appetize, a separate Shift4 product: a 'Cross threshold' setting -- 'After selecting the configured number, an additional cost will be added' -- paired with an 'Additional Modifier Charge' that lets you 'Configure the additional cost for each modifier selected past the threshold' (23032951397139). Combos give an 'Upcharge' but only for a premium item inside a slot, not an n-included/overage rule. No substitution credit or substitution-forbid rule found. https://shift4.zendesk.com/hc/en-us/articles/50317440519699-Menu-Viewer-in-Shift4-Dine-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

Combo Builder ships with slots, pre-filled defaults, per-slot swaps and upcharges on premium selections, and reports at child-item level with the base price allocated proportionally to standalone prices. Shortfalls: 'This feature is currently available only for Pilot users' and it is configured only in Multi-Location Management; no automatic detection or conversion of eligible a-la-carte cart items into the combo price is documented; and Shift4 lists live KDS limitations - combos are not grouped in List View, cannot be bumped as a group, and 'Combo item special requests do not appear on KDS.' https://shift4.zendesk.com/hc/en-us/articles/52543226369555-Ring-Up-a-Combo-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
No

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

No per-item, per-channel upsell prompt is configurable in Shift4 Dine itself. Anchored searches for upsell/suggestive/cross-sell over all 2,162 articles hit only: POSitouch (a separate Shift4 product, file-based 'suggestive sell pop-up box'), Appetize ('Upsell Items' tab, again a separate product), digital-signage partners, and this Horago integration, where the upsell is the partner's and lives only in QR ordering -- 'Provide AI-generated upsell recommendations during the ordering process' and 'Review upsell settings and eligible menu categories' (updated 2026-06-02). The 658-line Set Up Online Ordering in Shift4 Dine Customer Hub (1500007486702, updated 2026-08-28) contains no upsell configuration at all, and no attach-rate report exists in the Shift4 Dine Customer Hub Report Guide (46334059307539). https://shift4.zendesk.com/hc/en-us/articles/52146952502547-Enable-Horago-in-the-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

A long press on the item button sets Quantity on Hand, and 'setting an Item to QTY = 0 now automatically means the item is fully 86'd (removed) from Shift4 Dine and Online Ordering.' Shortfall: propagation is documented only to the POS and Shift4's own Online Ordering. Third-party marketplace availability is managed separately in Delivery Management ('Mark Items and Modifiers Unavailable', 'Snooze Items'), the kiosk is not mentioned, and no propagation latency is published anywhere. https://shift4.zendesk.com/hc/en-us/articles/5973606723603-Change-Quantity-on-Hand-Using-Long-Press-for-a-Menu-Item-on-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

menu-pricing-countdown-auto-86

Per-item Quantity on Hand with a Low Stock Indicator at a configurable Alert at Amount, an 'Allow ordering if quantity is zero' toggle that greys the button and shows 'Sold Out', and optional display of remaining counts on the login screen. Shortfall: no scheduled auto-restore - counts are reset manually per item, and the documented bulk behaviour is the reverse (entering 9999 re-enables ordering). https://shift4.zendesk.com/hc/en-us/articles/37736806602899-Item-Inventory-Tracking-Configuration-for-Shift4-Dine · retrieved 2026-08-03

B
Yes

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 is set per Department and overridable per Item across three modes - All Day, Day Parts, or Custom Schedule ('selected days of the week and configured hour blocks') - plus Revenue Centre scoping and specific date ranges. Shift4's worked example: 'Department: Valentine Brunch can be made available only for a custom time schedule, only for the Dining Room RVC, and only on the specifically selected date of 2/14/25.' https://shift4.zendesk.com/hc/en-us/articles/29797791125139-Configure-Menu-Availability-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Channel pricing exists in two places: Menu Manager sets a special online price per item for Online Ordering, and Delivery Management applies third-party price adjustments globally or per item, with bulk price edits by category and a 'Set Pickup Pricing to Match POS Pricing' control. Shortfall: these are separate consoles rather than one price-book model - there is no documented dine-in vs pickup vs delivery vs kiosk price book on the POS menu record, and the percentage-markup rule lives only on the third-party side. https://shift4.zendesk.com/hc/en-us/articles/7817189110163-Set-a-Special-Online-Price-in-Menu-Manager · retrieved 2026-08-03

B
Partial

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 Advantage Program ships three selectable modes - Supplemental Fee, Dual Pricing and Cash Discount - each with a Fee Percentage, a Revenue Class, receipt-appearance customisation and documented ticket-detail, payment-selection and printed-guest-check examples. Shortfall: it is a percentage fee program, not two prices stored per item, so there is no item-level card price used as the displayed base; no article states the program applies to kiosk or Online Ordering; and enrolment 'change[s] your statements from monthly to daily' and locks Supplemental Fee until the 1st of the next month. https://shift4.zendesk.com/hc/en-us/articles/27580032701331-Enroll-and-Set-up-Advantage-Program-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

The item record is enumerated in Menu Items on Shift4 Dine and the only allergen mechanism offered is free text: 'Item Description: General description of the item and allergen information can be added here.' There is no structured allergen flag and no nutrition value field anywhere in the item schema, so nothing can be derived from recipe components or published to third-party menus as structured data. https://shift4.zendesk.com/hc/en-us/articles/25452808313491-Add-and-View-Item-Descriptions-on-Shift4-Dine · retrieved 2026-08-03

B
No

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

Shift4's inventory model is enumerated by the Inventory Detail Report and it is item-level only: Item Name, Item UPC, Quantity on Hand, Alert Threshold, Cost per unit, Total cost, Price, Total Price, Status. There is no ingredient or bill-of-materials entity to link a menu item to, and item cost is typed in manually per menu item (Item Profit Margin article). Recipe costing is delivered by Marketplace partners (MarketMan, Craftable, Orca, Yellow Dog, Restaurant365), not by the POS. https://shift4.zendesk.com/hc/en-us/articles/46477450599059-Inventory-Detail-Report-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

DoorDash, Uber Eats, Grubhub and Deliveroo are certified direct Marketplace integrations with their own installation guides, and menu authoring for those channels runs in Delivery Management - create multiple menus, edit menu hours, remove categories/items, edit modifier rules, bulk-tag, bulk price edits by category, plus alerts and per-channel connection status for rejections and sync errors. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
Partial

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

menu-pricing-dynamic-pricing

Rule-based scheduled pricing with Price Schedule groups assigned to Revenue Centres and Day Parts, Override Dates that suspend and then auto-restore the prior schedule, and rules for forced dollar price, forced percentage up/down and new flat +$/-$ adjustments, inheritable from Department to Item. Shortfalls stated in the article: 'This is currently only available for US merchants' and 'The Dynamic Pricing feature is not available for Online Ordering... currently available only for POS prices.' No demand input and no floor/ceiling guardrails. https://shift4.zendesk.com/hc/en-us/articles/29860071217299-Configure-Dynamic-Pricing-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B

Payments & money movement

No

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

Every payment path in the documentation is Shift4's own gateway: offline mode triggers on 'Gateway unreachable / Processor unreachable' against the Shift4 gateway, QR Pay and the Customer-facing Display 'process payments with Shift4 Gateway', configuration errors resolve to 'Merchant ID Not Found' in Shift4's own system, and the Advantage Program, funding and settlement reporting all run through Shift4 as acquirer. No supported third-party gateway list exists; the Token Migration article exists precisely to hand tokens to a different processor on the way out. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
No

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

payments-published-rates

NOT an absence verdict: Shift4's own current (# updated 2026-07-08) public fee schedule states the card-processing rate is set per merchant in the internal CRM, not published. The Authorization fee row reads 'Per transaction (In Pricing Tab in Titan)/ Per Merchant Account' with previous price 'Increased Bi-Annually', and the Interchange Fee row's Current Price cell holds only 'Per Merchant Account' followed by '(In Pricing Tab in Titan)'. Ancillary fees ARE published here to the cent ($0.40 Per Batch, $35 Per Occurrence chargeback, $0.02 Per Transaction network fee) which makes the per-MID treatment of the discount/auth rate a deliberate contrast, not a documentation gap. A regex for a flat card rate (flat-rate-of, processing-rate-of, 2.xx%, x.xx% + $0.xx) across all 2,192 documents returned 0 files. The record already cites this article (6 rows). Caveat per brief s5: skytab.com/pricing is behind the 429 wall and was not fetched; if it carries a flat rate this verdict falls. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-09-05 adversarially verified

B
Yes

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

'With Dual Pricing, you can offer a simple cash vs. non-cash total on the receipts presented to customers and on the customer-facing displays', and Shift4 separates it from Supplemental Fee precisely on storage: Dual Pricing and Cash Discount require the merchant to maintain two price points per item, one cash and one non-cash, kept in step across the POS, online ordering and printed materials, whereas Supplemental Fee applies a single percentage to every transaction. Enrolment configures the mode, a Fee Percentage and a Revenue Class, and Shift4 publishes worked Ticket Detail, Payment Selection and Printed Guest Check examples for all three modes. https://shift4.zendesk.com/hc/en-us/articles/17140380911379-Advantage-Program-FAQs-United-States · retrieved 2026-08-03 adversarially verified

B
No

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

Explicitly denied by the vendor, not inferred. Article's own banner (# updated 2026-07-16): 'Recent local law changes take effect August 1, 2026 , restricting surcharges on debit card transactions in Louisiana. This impacts a small subset of merchants using Dual Pricing specifically in Louisiana without a manual exclusion for debit, since the Advantage Program does not auto-detect debit BINs.' Prong 1 (automatic debit/prepaid exclusion by BIN/product code) therefore fails on the vendor's own words, and the remedy Shift4 offers is a MANUAL exclusion. Prong 2 (network percentage cap) also fails: 'The default is 4%. The merchant can set a lower customer-facing rate or a higher rate up' to 5% (non-breaking space before 'to' in the source) Prong 3 (per-location enable/disable) is the only one satisfied: https://shift4.zendesk.com/hc/en-us/articles/43164077403923 says 'By default, surcharges are inherited by all locations below this level' and 'You can create overrides to accommodate variations at individual locations.' Conjunctive claim, two prongs dead. Record already cites this article once. https://shift4.zendesk.com/hc/en-us/articles/17140380911379-Advantage-Program-FAQs-United-States · retrieved 2026-09-05 adversarially verified

B
Yes

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

payments-emv-nfc

Published device specs list Chip (EMV dip), Magstripe and Contactless 'including Apple Pay, Google Pay, Interac Flash' on the handheld, and the Customer-Facing Display spec lists 'Chip & PIN, Magnetic Stripe, Contactless, Supports Apple Pay & Google Pay'. PAX PIN pads (A35, Q25) attach to the workstation with Shift4 P2PE remote key injection. https://shift4.zendesk.com/hc/en-us/articles/41246927844883-Handheld-Specifications · retrieved 2026-08-03

B
No

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

Weak proposal killed as the brief asked. Tap-to-Pay, tap to pay, SoftPOS and Tap-on-Phone return ZERO hits across all 2,192 documents INCLUDING the 3M-character dev.shift4.com/docs/api/ reference (grepped separately). The gated-129 title list carries no tap-to-pay/softPOS entry, so this zero-hit is not sitting on the known gap. Positive counter-evidence: SkyTab's actual phone-based contactless story is the guest's phone, not the merchant's - 'The QR Pay feature on Handheld enables guests to complete payments securely and contactlessly using their smartphones' (# updated 2026-05-12). Every merchant-side contactless acceptance path documented is vendor hardware with a built-in reader (SkyTab Air, PAX A6630/IM30, Verifone UX700). Record already cites the QR Pay article once. https://shift4.zendesk.com/hc/en-us/articles/47508407357843-Use-QR-Pay-on-Handheld-for-Secure-Mobile-Payments · retrieved 2026-09-05 adversarially verified

B
Yes

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

The handheld takes full, equal-split and custom-amount payments at the table on its onboard EMV/NFC reader, with tip hints and digital receipt verification documented in its own setup guide, and four split-check methods available before payment. https://shift4.zendesk.com/hc/en-us/articles/41534728316307-Take-Payments-on-Handheld-Full-Equal-Split-and-Custom-Amounts · retrieved 2026-08-03

B
Yes

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

A ticket-specific QR code is shown on the handheld or 'printed on the bottom of the guest check'; the guest pays on their own phone and 'When the full balance is paid through the QR link, the ticket will automatically close on both the Handheld and the Workstation.' Prior partial payments reduce the QR amount to the remaining balance, and an already-paid ticket returns 'Ticket is no longer found' to prevent double charging. https://shift4.zendesk.com/hc/en-us/articles/47508407357843-Use-QR-Pay-on-Handheld-for-Secure-Mobile-Payments · retrieved 2026-08-03

B
Yes

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

Both flows ship: on-device tip prompts (per payment device, receipt tip hints, tip hints on subtotal only, centralized tip configuration in the Customer Hub) and authorise-then-adjust, with End of Day - Adjust Tips, a Finalize Tips Immediately option, a maximum tip limit, and a Transactions Manager tip refund/adjustment path in the Customer Hub when the batch has moved on. https://shift4.zendesk.com/hc/en-us/articles/360057102974-Adjust-Tips-on-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

Tip Share rules are configurable From job / To job with a % Given, calculated on Total, Gross or Net tips and filterable by Revenue Class, with multiple rules allowed. Named shortfall: they are suggestions - Shift4 calls the feature Tip Share Suggestions, the amounts 'appear on Employee End of Shift Reports' and 'Shared amounts can be entered from the Employee Dashboard > Tip Share button', so the allocation is keyed in by a human rather than computed and distributed. Real pooling and payout is left to Marketplace partners (TipHaus, Kickfin, DishOut, GlobalTips). https://shift4.zendesk.com/hc/en-us/articles/29626069064979-Configure-Tip-Share-Suggestions-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

'Shift4 Dine comes preconfigured with Offline Payments mode enabled... You can also configure an Offline Transaction limit to ensure payments do not exceed a set value per transaction.' EMV chip-and-PIN and Apple/Google Pay both keep working offline on PAX devices; stored transactions are retried for up to two days, one every two minutes on reconnect. Only a per-transaction cap is documented - no cumulative offline ceiling is published. https://shift4.zendesk.com/hc/en-us/articles/16079601177747-Configure-Shift4-Dine-for-Offline-Payments-Mode · retrieved 2026-08-03

B
Partial

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

Post-reconnect visibility is genuinely good: pending offline payments older than 24 hours raise a notification on every terminal 'noting the tickets that are pending offline approval, which device is storing them, and the total value', and 'If a transaction cannot be authorized (e.g., insufficient funds), it will require manual intervention.' Shortfall: nowhere does Shift4 state who bears the loss on a declined stored transaction - the FAQ 'I haven't been paid for some of the transactions I processed during the service disruption' routes to Support rather than to a liability statement. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Yes

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

Shift4Gift is first-party: e-gift and physical cards, load/reload/tips on gift cards, manual number entry on the handheld, balance-printing options, real-time Gift Card Balance reports, and a documented multi-location shared program with a Cross-Usage report showing 'who owns the gift cards, the owner of the sale... and where gift cards were used'. Online-ordering redemption is enabled explicitly (Enable Gift Card Payments in Online Ordering). Givex and third-party cards are separately supported. https://shift4.zendesk.com/hc/en-us/articles/7041630069139-Shift4Gift-Reporting-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

payments-house-accounts

House Accounts ship with an enable toggle and a House Account Threshold (credit limit), per-customer account creation, a House Account tender, a Customer House Accounts Balance report in the Customer Hub and a House Account Charges report in Business Intelligence. Loyalty points are explicitly not earned on the House Account tender. https://shift4.zendesk.com/hc/en-us/articles/7979367201555-Use-House-Accounts-on-Shift4-Dine · retrieved 2026-08-03

B
Yes

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

Partial payments against a single ticket are documented, combined with Split by Seat, Item Split, Manual Split and Split Equally 'e.g., 3-ways, 4-ways' with no stated ceiling; each resulting check 'supports multiple payment options' and QR Pay shows only the remaining balance when a prior tender exists. https://shift4.zendesk.com/hc/en-us/articles/13806935386003-Accept-a-Partial-Payment-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
Yes

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

Refund permission is granted per user in the Customer Hub and per job on the workstation; voids require a Reason; Void Reports, Refund Details by Employee and the Business Intelligence Voids/Refunds/Discounts alerts drill from the exception to the ticket, the employee and the ticket detail. Location Activity Reports for Audits give an activity trail in the Customer Hub. https://shift4.zendesk.com/hc/en-us/articles/28706899933459-Enable-Refund-Permissions-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

payments-chargeback-tooling

Shift4 runs the dispute process as acquirer and documents representment, reason codes, arbitration and the inadequate-descriptor fee, and Transaction Manager holds the transaction record. Shortfall: the chargeback material is procedural guidance, not a documented in-product dispute dashboard - no article shows a merchant listing open disputes and uploading evidence assembled from the POS transaction inside the Customer Hub. https://shift4.zendesk.com/hc/en-us/articles/28074632887699-Chargebacks-Representment-Process-Overview · retrieved 2026-08-03

B
Partial

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

Tokenization is real - Shift4 holds tokens mapping to PAN, expiry, cardholder name and address, and will export that token file to a new processor on request - and Payment Links can be reused with 'Allow Multiple Payments'. Shortfall: no documented card-on-file attached to a guest profile that a restaurant can charge again across online, phone and in-store; Online Ordering's customer record saves name, addresses and phone only, and Canadian debit refunds explicitly 'cannot be completed using stored card tokens'. https://shift4.zendesk.com/hc/en-us/articles/43269556571027-Token-Migration · retrieved 2026-08-03

B
Yes

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

payments-payout-timing

Three schedules are published by name: 'Next-Day Funding 24-hour funding: Funds are deposited the next business day', 'Two-Day Funding 48-hour funding', and 'Same-Day Funding: Funds are deposited between 1:00 p.m. ET and 5:00 p.m. ET', with 'Shift4 defaults most merchants to Next-Day 24-hour funding unless requested or changed otherwise.' The Customer Hub adds an Enhanced Estimated Daily Deposit view reconciling tip adjustments that land on a different day, plus Settlement, Batch and Deposit reports. No fee is stated for any schedule. https://shift4.zendesk.com/hc/en-us/articles/30446670804627-Deposit-Schedules-Overview · retrieved 2026-08-03 adversarially verified

B
Partial

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

P2PE is implemented in the hardware path - PAXSTORE pushes a 'Shift4 P2PE' application and a Shift4_P2Pe remote key injection template to each terminal and PIN pad - and Shift4 maintains a Security and Compliance category that states it provides 'our certificate of attestation and other documentation on our PCI compliance'. Shortfall: the attestation articles render as embedded documents with no readable version or date, the only named AoC in the category belongs to SecurionPay, and no PCI DSS 4.x AoC or PCI-listed P2PE solution number for Shift4 Dine was retrievable, nor is the merchant's SAQ type stated. https://shift4.zendesk.com/hc/en-us/articles/4406698996243-PCI-DSS-Requirement-12-8-Service-Provider-Management · retrieved 2026-08-03

B

Kitchen & production

Yes

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

Each Display is configured like a printer with its own Assigned Items and Assigned Modifiers lists ('For prep stations, such as a fryer or grill, it is best practice to select only those items that would be prepared at that station'), plus per-station order-type filtering, order-type colour coding, printer groups, item-to-ticket-printer assignment and modifier-to-different-printer routing - all merchant-configurable, then pushed with Send Config. https://shift4.zendesk.com/hc/en-us/articles/4940365584531-Add-Items-Modifiers-to-Your-Kitchen-Display-System-Station · retrieved 2026-08-03

B
Yes

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

Expo stations take 'all items/mods' while prep stations take their own subset, and Multi Stage Fulfillment chains stations - 'once a ticket is completed at a station, a notification will be sent to the designated Send To station', with a Show Tickets When setting of 'Previous Station' that hides a ticket 'until at least one previous station has fully completed their ticket' and fulfillment notifications withheld 'until the whole ticket is completed'. https://shift4.zendesk.com/hc/en-us/articles/30019010065683-Configure-the-Kitchen-Display-System-Multi-Stage-Fulfillment · retrieved 2026-08-03

B
Yes

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

Courses are defined in the Customer Hub and Multi-Location Management; Menu Coursing and Quick Coursing hold and release courses to the kitchen from the workstation, Send Ticket Options control what is released, and 'Send a Ticket as a Rush & Continue' pushes a ticket ahead on the KDS. The KDS can also Group By course. https://shift4.zendesk.com/hc/en-us/articles/48860719056787-Quick-Coursing-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
Yes

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

Per-item base prep times plus additive per-modifier times ('Base 8 minutes + Extra Crispy 2 + Well Done 3 = 13'), used by the KDS to determine 'When each item should appear on a station's display... How to stagger item firing so the entire order completes together', with Standard and Advanced modes and prep-time schedules. https://shift4.zendesk.com/hc/en-us/articles/29683681715731-Configure-Prep-Times-by-Item-and-Modifier-for-the-Kitchen-Display-System · retrieved 2026-08-03

B
Yes

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

Kitchen capacity is entered as 'the number of items your kitchen can produce within the specified prep time' and orders past it are automatically paced with an extended quote: 'if capacity is set to 10 items, then items 11-20 will be throttled by an additional 30 minutes, resulting in a 60-minute total prep time.' https://shift4.zendesk.com/hc/en-us/articles/46679956647571-Enable-Kitchen-Capacity-for-Automated-Order-Throttling-on-Delivery-Management · retrieved 2026-08-03 adversarially verified

B
Partial

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

Store pause propagates: 'Pause All DSP's or select Pause for the individual DSP', with a duration for automatic reactivation, and items can be snoozed to a preset or custom return time. Shortfall: the action originates in the Delivery Management console in the Customer Hub, not from the POS or KDS - the documented POS-side 86 (Quantity on Hand = 0) is stated to reach 'Shift4 Dine and Online Ordering' only, with no third-party propagation claimed. https://shift4.zendesk.com/hc/en-us/articles/46218051343507-Pause-Delivery-or-Online-Ordering-Channels-on-Delivery-Management · retrieved 2026-08-03

B
Partial

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

Shift4 publishes a dedicated article on how marking an order Ready affects courier assignment across delivery platforms, so a readiness signal does reach the marketplaces. Shortfall: the documented trigger is in Delivery Management, not a KDS bump - no article states that bumping the order complete on the Shift4 KDS emits the order-ready event to DoorDash or Uber Eats. https://shift4.zendesk.com/hc/en-us/articles/46805970263315-Impact-of-Marking-an-Order-as-Ready-on-Driver-Assignment-Across-Delivery-Platforms-on-Delivery-Management · retrieved 2026-08-03

B
Yes

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

kitchen-bump-bar-hardware

A first-party bump bar with published specifications, an installation and setup guide, a usage guide, an ordering path and an Enable Bump Station setting on each Display, alongside touchscreen interaction. https://shift4.zendesk.com/hc/en-us/articles/34204383916947-Bump-Bar-Specifications · retrieved 2026-08-03

B
Yes

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

kitchen-all-day-counts

All Day aggregates outstanding quantities per item across open tickets on the station, with an All Day Item Focus view and a Completed Order Summary (All Day Summary) showing item totals; Group Items and Modifiers on the KDS consolidates the modifier level. https://shift4.zendesk.com/hc/en-us/articles/12800832507667-Use-the-Kitchen-Display-System-All-Day-Feature · retrieved 2026-08-03

B
Yes

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

Per-display Ticket Timers set a 'Warning Timer Status change after' and an 'Alert Timer Status change after' value that recolour the ticket status bar, each enforced only when its checkbox is ticked; sound can be enabled on the Display, and the Kitchen Box Score view shows every station's performance at a glance. https://shift4.zendesk.com/hc/en-us/articles/4940115080083-Set-up-the-Kitchen-Display-System-Ticket-Timer-Settings · retrieved 2026-08-03

B
Partial

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

Printer-to-printer failover is real and is documented on the kitchen-printer settings page itself: the article's 'Remote and Expediter Printers' section -- 'Remote Printers (also called Kitchen Printers) send tickets from the Workstation to locations throughout your business' -- carries on its Advanced tab a 'Failover Printer' field, described as 'Designate a backup printer to print if the primary printer is offline.' (updated 2026-07-24). Partial, not yes, on two counts the corpus does not cover: (a) no KDS-screen failover -- an anchored search for a Kitchen Display going down and tickets rerouting returns nothing, and Configure a Kitchen Display System for the Workstation (4940326008723) has no backup-screen field; (b) no ticket-loss guarantee is stated -- the only recovery article is manual, Resend a Ticket to the Kitchen Printer on Shift4 Dine (29218928656019). https://shift4.zendesk.com/hc/en-us/articles/6878577602451-Hardware-Settings-on-the-Workstation-for-Shift4-Dine · retrieved 2026-09-05 adversarially verified

B
Yes

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

kitchen-offline-operation

'Will my local network, printers, Kitchen Display System, etc., work in Offline Mode? These will work as long as the local network is connected.' The KDS is a LAN peer of the workstation (config is pushed to it by IP on port 9100), so ticket flow survives loss of the internet but not loss of the local network. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03 adversarially verified

B
Partial

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

Stations show full modifier breakout, can group items and modifiers, honour Print Modifiers ordering settings and support ticket size, split views and item focus. Shortfall: no recipe step, portioning or build-instruction display exists - there is no recipe entity in the product at all - so build detail is limited to the modifier text on the line. https://shift4.zendesk.com/hc/en-us/articles/22617155832851-Group-Items-and-Modifiers-on-the-Kitchen-Display-System · retrieved 2026-08-03

B
Partial

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

Placement reaches the kitchen as a prefix: each Pre-Modifier carries an optional 'Kitchen Print Name', a Pre-Modifier Colour and a 'Print Red or Bold' flag, so LEFT SIDE / RIGHT SIDE / WHOLE render distinctly on the slip and the Display. Shortfall: it is a text prefix, not a graphical section rendering, and Pre-Modifiers do not exist on Online Ordering, third-party or kiosk orders at all, so those tickets carry no placement information. https://shift4.zendesk.com/hc/en-us/articles/46547019716883-Configure-Pre-Modifiers-and-Pre-Modifier-Sets-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

kitchen-recall-refire

Bumped tickets are recallable at the station, with Recall Last Ticket, a global Configure Ticket Recall setting, and a POS-side 'Resend a Ticket to the Kitchen Printer' path that reprints without re-entering the order. https://shift4.zendesk.com/hc/en-us/articles/4988714656147-Recall-Tickets-to-the-Kitchen-Display-System-Station · retrieved 2026-08-03

B
Yes

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

The workstation can be configured to notify the Display when an item is voided from an already-sent order, and Real-Time Ticket Header Updates plus Configure Mark Items as Sent keep the live ticket in step with POS edits. https://shift4.zendesk.com/hc/en-us/articles/22227528883859-Configure-the-Workstation-to-Notify-the-Kitchen-Display-System-When-an-Item-is-Voided-From-a-Sent-Order · retrieved 2026-08-03

B
Yes

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

'When an order is completed at the Display station, the system automatically triggers the guest notification you have set up' - notification type is mapped per Order Type under Settings > Hardware > Printers/Kitchen Display System > Guest Notifications, sent by SMS or email to the customer attached to the ticket. QR orders have their own 'Notify Customers When Their QR Order is Ready' path. No separate product purchase is named. https://shift4.zendesk.com/hc/en-us/articles/31427561234067-Guest-Notifications-Overview-on-the-Kitchen-Display-System · retrieved 2026-08-03 adversarially verified

B
Partial

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

kitchen-waste-logging

Void Reasons carry a 'Track Wasted Inventory' toggle so a reason-coded void debits Quantity on Hand. Shortfall: the entry is made at the POS on a void, not at the kitchen or KDS screen, and there is no waste-cost report separate from usage - the article exists to explain how to switch the behaviour off. https://shift4.zendesk.com/hc/en-us/articles/37741650584339-Void-Item-or-Ticket-Counts-as-Inventory-Loss-in-Shift4-Dine · retrieved 2026-08-03

B
Partial

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 Kitchen Box Score shows every station's performance on the Display, and Business Intelligence carries a Long Ticket Times alert that drills to the offending tickets. Shortfall: no report produces average and percentile ticket or station times sliced by daypart, station and order channel, and the Long Ticket Times threshold 'requires a request for support' to set. https://shift4.zendesk.com/hc/en-us/articles/19648514583187-View-the-Overall-Performance-of-Every-Kitchen-Station-at-a-Glance-Kitchen-Box-Score-on-the-Kitchen-Display-System · retrieved 2026-08-03

B
Partial

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

Business Intelligence positions Product Mix drill-down by day part, hour and 15-minute interval as the prep-planning tool - 'This detail is especially helpful for forecasting and prep planning' - and the Trends Daily Sales report computes Projected Sales used to 'Plan prep and inventory'. Shortfall: nothing generates a prep list or predicted prep quantity, and nothing is surfaced to kitchen staff as a task list. https://shift4.zendesk.com/hc/en-us/articles/22524606180755-Run-a-Product-Mix-Report-on-Business-Intelligence · retrieved 2026-08-03

B

Delivery, dispatch & third-party channels

No

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

In-house drivers exist only inside a Marketplace partner. The driver roster ('My drivers > Add driver', driver invited by SMS to a partner mobile app), maximum concurrent deliveries and driver response time are all configured in the InhouseDelivery dashboard, not the POS, and Shift4 states the POS has no delivery concept at all: 'Orders will show as Pickup in the POS, and not as Delivery. The POS does not differentiate between a customer walking in to collect an order and a third-party delivery.' https://shift4.zendesk.com/hc/en-us/articles/50293129762835-InhouseDelivery-and-Online-Integration-and-Setup · retrieved 2026-08-03 adversarially verified

B
No

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

No dispatch or expo screen for deliveries exists in Shift4 Dine. Assignment happens in the InhouseDelivery partner app, and Shift4 documents that even the partner's manual mode is unavailable: 'All orders synced to InhouseDelivery will be automatically dispatched for delivery, regardless of if the auto-dispatch mode is set to Yes or No. This is due to a technical limitation.' Multi-order run batching is not documented anywhere. https://shift4.zendesk.com/hc/en-us/articles/50293129762835-InhouseDelivery-and-Online-Integration-and-Setup · retrieved 2026-08-03 adversarially verified

B
No

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

This URL is already held in the record (4 existing citations in claims.jsonl). SkyTab has no dispatch map of its own; first-party delivery is handed to the InhouseDelivery marketplace app, whose only map is a service-area boundary, not a route: 'Delivery area' is a 'Delivery radius or define a zone on the map. Orders outside this area go to third-party providers (if enabled)' (updated 2026-05-12). Assignment is one order at a time by driver acceptance -- 'Driver response time' is 'Minutes a driver has to accept or reject a delivery before it's offered to another driver' (curly apostrophe in source) -- with 'Maximum deliveries', 'Active orders a driver can handle at one time', as the only multi-order concept. Anchored searches for route optimization, route sequencing and multi-stop return ZERO hits across all 2,162 articles. The only geocoded delivery mapping in the corpus is Mapping Overview in QSR & Delivery (360038045494), a separate Shift4 product. https://shift4.zendesk.com/hc/en-us/articles/50293129762835-InhouseDelivery-and-Online-Integration-and-Setup · retrieved 2026-09-05 adversarially verified

B
No

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

delivery-driver-tracking

This URL is already held in the record. A driver-facing app does exist, but only as the partner's: 'The driver will receive a text message inviting them to download the mobile app and activate their account' (updated 2026-05-12). Nothing in that article, or anywhere in the corpus, surfaces GPS position back to a dispatch screen -- an anchored search for GPS across all 2,162 articles returns three files, all of them GeoTax/tax-rate articles for Appetize. SkyTab itself does not even carry delivery state: 'Why do delivery orders show as Pickup in the POS? Orders will show as Pickup in the POS, and not as Delivery . The POS does not differentiate between a customer walking in to collect an order and a third-party delivery - they are both classified as Pickup .' https://shift4.zendesk.com/hc/en-us/articles/50293129762835-InhouseDelivery-and-Online-Integration-and-Setup · retrieved 2026-09-05 adversarially verified

B
Yes

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

Online Ordering's Delivery Address Validation 'Determines where orders can be delivered. You can set it by zone by drawing a custom area on the map or by driving distance', i.e. arbitrary drawn polygons and drive-distance in addition to a radius; the InhouseDelivery self-delivery settings likewise take a 'Delivery radius or define a zone on the map'. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Install-and-Configure-Online-Ordering · retrieved 2026-08-03 adversarially verified

B
Partial

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

Shift4 documents the delivery fee model as global, not per-zone: 'If delivery is enabled, the following global settings apply to all delivery orders' - one Delivery Surcharge Name with a flat or percentage Type and Amount, one Min/Max Order Amount, one Minimum Delivery Time. Shortfall: a drawn zone controls eligibility only; no independently configurable fee, order minimum or promise time per zone is documented. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Install-and-Configure-Online-Ordering · retrieved 2026-08-03

B
Yes

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

Delivery Address Validation is a first-class setting evaluated at order time, configurable By Driving Distance or by a drawn zone with a Delivery Distance limit, so out-of-area addresses are rejected before acceptance; InhouseDelivery documents the overflow case - 'Orders outside this area go to third-party providers (if enabled)'. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Install-and-Configure-Online-Ordering · retrieved 2026-08-03

B
No

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

This URL is already held in the record. The only driver-money concept in the SkyTab path is the fee the merchant pays the partner -- 'charged per delivery based on your max radius' -- and a tip nudge, 'Orders with higher tips have a greater chance of attracting drivers' (updated 2026-05-12). No mileage capture, no per-delivery reimbursement, and no payroll export line. Every mileage/reimbursement hit in the 2,162-article corpus is in QSR & Delivery, a separate Shift4 product: 'Delivery Zones are used for charging a delivery fee to a customer based on the settings, and they also determine how much the reimbursement to the driver will be' (6885453249683), plus Settle a Driver and Close the Shift on the Driver Summer Screen in QSR & Delivery (360038555733). None of that is Shift4 Dine. https://shift4.zendesk.com/hc/en-us/articles/50293129762835-InhouseDelivery-and-Online-Integration-and-Setup · retrieved 2026-09-05 adversarially verified

B
Partial

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

Shift4 Dine has a full cash-bank and settle-up model - employee banks, cash drawers, till reports, cash over/short and end-of-day drawer counts - but it is per employee, not per driver run, and there is no driver settle-up. Shortfall: cash delivery is in fact excluded from the documented delivery path - 'InhouseDelivery cannot accept orders that are cash on delivery due to the use of third-party delivery partners. Any orders that are received that are cash on delivery will be rejected.' https://shift4.zendesk.com/hc/en-us/articles/50293129762835-InhouseDelivery-and-Online-Integration-and-Setup · retrieved 2026-08-03

B
Partial

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

Courier hand-off is documented three ways: a Dispatch Settings screen in Delivery Management where a provider and per-location reference ID are added, a DoorDash Drive Marketplace integration with its own installation guide, and InhouseDelivery auto-dispatch 'to the cheapest available driver, without the need for manual intervention'. Shortfall: no documented return of the courier quote or live status into the POS order record - the order simply appears in the POS as Pickup. https://shift4.zendesk.com/hc/en-us/articles/46109959336979-Connect-Dispatch-Provider-on-Delivery-Management · retrieved 2026-08-03

B
Partial

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

Hybrid overflow is documented, with three modes - 'Your own drivers: If your drivers are unavailable, third-party drivers will be used as a backup', 'Third-party drivers' and 'Both options: Your drivers will be prioritized, and deliveries will be sent to third-party providers if none of your drivers are online or available', plus out-of-zone overflow. Shortfall: the rules live wholly in the InhouseDelivery Marketplace partner, not in Shift4 Dine, and no wait-threshold overflow rule is documented. https://shift4.zendesk.com/hc/en-us/articles/50293129762835-InhouseDelivery-and-Online-Integration-and-Setup · retrieved 2026-08-03

B
Yes

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

The installation matrix lists DoorDash (US, CA, IE, GB), Uber Eats (US, CA, IE, GB) and Grubhub (US) as first-party Shift4 Marketplace integrations, each with its own Shift4-authored installation guide, alongside Deliveroo and DoorDash Drive. Middleware (Otter, Deliverect and similar) is listed separately and is not required. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03 adversarially verified

B
Yes

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

Marketplace orders land as normal tickets: the POS has a dedicated online-order queue (View Online Orders, Filter Online Orders), Auto-Complete for Online Orders, a dedicated terminal assignment for printing online guest checks, and void/refund handling for online and third-party orders - and a separate article exists for the manual workaround when a merchant does NOT have the Grubhub integration, which confirms the integrated path is automatic. https://shift4.zendesk.com/hc/en-us/articles/22886594992147-DoorDash-Marketplace-Installation-Guide · retrieved 2026-08-03

B
Yes

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

Delivery Management publishes and maintains the third-party menus from one console - create multiple menus, edit menu hours and holiday hours, remove categories, items, modifiers and modifier groups, edit modifier rules, tag alcohol, bulk tag, item-level tax exemptions, bulk price edits by category, global and individual third-party price adjustments, and 'Set Pickup Pricing to Match POS Pricing' - rather than editing each marketplace portal. https://shift4.zendesk.com/hc/en-us/articles/46671194528659-Bulk-Edit-Prices-by-Category-on-Delivery-Management · retrieved 2026-08-03

B
Partial

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

Item-level unavailability on third-party channels is real and time-boxed: Snooze with preset durations, 'next open' or a custom return date/time, plus Mark Items and Modifiers Unavailable. Shortfall: the action must be taken in Delivery Management. The POS-side 86 (Quantity on Hand = 0) is documented to reach 'Shift4 Dine and Online Ordering' only, so a kitchen 86 does not automatically push to DoorDash or Uber Eats. https://shift4.zendesk.com/hc/en-us/articles/46679335039635-Snooze-Items-on-Delivery-Management · retrieved 2026-08-03

B
Yes

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

'Select Pause All DSP's or select Pause for the individual DSP you want to pause. Select the duration for the pause from the dropdown' - one console pauses every connected marketplace with timed auto-reactivation, rather than each marketplace's own tablet. Online Ordering can be disabled separately. https://shift4.zendesk.com/hc/en-us/articles/46218051343507-Pause-Delivery-or-Online-Ordering-Channels-on-Delivery-Management · retrieved 2026-08-03

B
No

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

Re-anchored on audit to the exhaustive report inventory rather than to the settlement guide. The Shift4 Dine Customer Hub Report Guide (# updated 2026-05-12) is self-described as complete -- 'For a full list of reports in this category with descriptions, see the Detailed Report List section' -- and enumerates 32 reports across seven categories: 'Sales Reports', 'Financial and Payment Reports: Tickets, tender types, refunds, voids, and payment activity. Used for reconciliation, researching discrepancies, and validating deposits.', 'Labor Reports', 'Customer Reports', 'Menu and Item Setup Reports', 'Till and Cash Management Reports' and 'Comparison and KPI Reports'. No marketplace-payout, commission, marketing-fee, adjustment or unpaid-order report appears in that inventory; the only third-party-delivery mention in the whole guide is an upcharge example, 'a Delivery surcharge for all Delivery orders'. Corroborating near-miss: the Settlement Report Reconciliation Guide (43788417029907, # updated 2025-12-09) is card-acquiring only -- 'Net Payout = Settled - Refund - Chargeback - Reject' -- and the only third party it accounts for is a card brand, 'For American Express, depending on your account setup, Amex transactions may be funded separately.' Shift4 Dine integrates DoorDash, Uber Eats and Grubhub for order injection and menu sync but publishes no report matching their payout deposits to POS-recorded 3P sales. https://shift4.zendesk.com/hc/en-us/articles/46334059307539-Shift4-Dine-Customer-Hub-Report-Guide · retrieved 2026-09-05 adversarially verified

B
Yes

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

Integration health is exposed to the operator: an alert bell with unread notification counts and a full notifications page, a Troubleshoot Delivery Management Order Errors article, per-location System Monitoring showing 30 days of uptime and downtime 'across your connected 3rd-party channels', configurable member alerts, plus POS-side articles for rejected online orders and expired confirmation windows. https://shift4.zendesk.com/hc/en-us/articles/46684463915795-Locate-and-Understand-Alerts-on-Delivery-Management · retrieved 2026-08-03

B
No

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

This URL is already held in the record (7 existing citations). This 658-line, 2026-08-28 setup guide is the full configuration surface for first-party online ordering, and its notification settings run to the merchant only: 'Adds contacts who receive notifications for new online orders. Leave this setting blank to disable notifications.' No guest-facing status or tracking page appears anywhere in it. Anchored searches across all 2,162 articles for tracking link, track your order and order status page return nothing guest-facing; the only custom-domain capability in the corpus is Website Builder's Connect Domain and Shift4 Checkout payment links ('Checkout Custom Domains. Merchants can use their domain for Payment Links, e.g., pay.nike.com instead of pay.shift4.com'), neither of which is a delivery tracking page. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Set-Up-Online-Ordering-in-Shift4-Dine-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

Quoted times do move with kitchen load on third-party channels: past the configured item capacity the system adds 30 minutes per capacity band automatically, and prep time can be scheduled by time of day. Shortfall: driver availability and zone drive time do not feed the quote - first-party Online Ordering uses a fixed 'Preparation Time (min)' and a single global 'Minimum Delivery Time (min)' per store. https://shift4.zendesk.com/hc/en-us/articles/46679956647571-Enable-Kitchen-Capacity-for-Automated-Order-Throttling-on-Delivery-Management · retrieved 2026-08-03

B
Partial

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

delivery-offline-behavior

Offline behaviour is documented for the POS generally - local network, printers and KDS keep working; pre-auths and refunds do not; menu edits will not sync. Shortfall: nothing addresses delivery specifically - whether online and third-party orders continue to arrive, whether cash delivery orders can be closed, and what happens to driver assignment during an outage are all unstated. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B

Digital ordering & guest-facing channels

Yes

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

Shift4 ships its own Online Ordering storefront, installed from the Customer Hub, with restaurant settings, preparation time, order types, throttling, coupons, closures, late-night scheduling, tip prompts and a previewable site, writing orders straight into the workstation; a first-party Website Builder with free domain management hosts it on the restaurant's own brand. No marketplace commission is charged on these orders. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Install-and-Configure-Online-Ordering · retrieved 2026-08-03

B
Partial

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

Menu Manager imports the POS menu rather than reading it live - the article is literally 'Import Items to Menu Manager From Your POS' - and then holds its own layer of edits: special online prices, different online item names, separate schedules, images, and bulk online menu editing. Shortfall: an item edit on the POS does not automatically become the online item, and Pre-Modifiers, Matrix Items and Dynamic Pricing are all excluded from Online Ordering entirely. https://shift4.zendesk.com/hc/en-us/articles/7816596215699-Import-Items-to-Menu-Manager-From-Your-POS · retrieved 2026-08-03

B
No

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

This URL is already held in the record (13 existing citations). The matrix (updated 2026-06-30) enumerates every Marketplace integration by category and country, one row per partner, plus a separate referral-partner list. The Online Ordering / Online Ordering & Delivery rows are Loman AI, Order with Google, Delivery Management (Stream), Otter, TechRyde Inc, Uber Eats, DoorDash, Brygid Technologies, FOLOS, Menufy, Takeout7, Grubhub, Waitbusters - OLO, Appfront, ChowNow, ToGo Technologies, Real Time Ordering, Eatsy Orders and Delivery Collective Inc (roster corrected on audit; the original note listed only thirteen of these) -- none is described as a branded-app builder, and the claim is about what the vendor offers rather than what a partner redirect might sell. Shift4's own digital ordering products are web: Online Ordering delivers a menu URL you 'add it to your website, social media, or other customer-facing channels' (1500007486702), and Website Builder produces a site. Anchored searches for branded app, native app and white-label across all 2,162 articles return zero; every App Store / Google Play mention in the corpus is for Shift4's own staff apps (InCharge, Workforce Management) or unrelated instructions. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-09-05 adversarially verified

B
Partial

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

A 'Save Customers' toggle stores a record keyed on email address with a list of unique addresses and phone numbers used. Two shortfalls stated by Shift4: 'In a future release, online orders will be automatically linked to customer records. Currently, they are automatically not linked' - so there is no order history to reorder from - and no saved tokenized payment method or guest login is documented for the ordering site. https://shift4.zendesk.com/hc/en-us/articles/26101107824147-Save-and-Sync-Customer-Details-in-Online-Ordering · retrieved 2026-08-03

B
Partial

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

Algorithmic upsell in a digital ordering flow exists, but only through one marketplace partner and only on the QR channel: Horago can 'Provide AI-generated upsell recommendations during the ordering process', and setup includes 'Navigate to AI Settings . Review upsell settings and eligible menu categories' (updated 2026-06-02) -- so it is configurable by category, and it is documented in the vendor's own KB against Shift4 Dine, whose menu it syncs. Partial rather than yes because Shift4's first-party Online Ordering has no upsell surface at all (the 2026-08-28 guide, 1500007486702, contains none), and no attach-rate reporting on suggestions exists anywhere -- the Shift4 Dine Customer Hub Report Guide (46334059307539) has no such measure, and the nearest thing in the corpus is a Business Intelligence server-average report that treats upselling only as a coaching topic. https://shift4.zendesk.com/hc/en-us/articles/52146952502547-Enable-Horago-in-the-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Yes

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

Future orders are supported at three horizons (current hours, Same Day, 1-6 Days Out) and paced by 'Restrict number of orders to [ ] every 15 minutes', set 'based on your location's kitchen capacity'; Late Night Scheduling and Closures further control which slots are offered. https://shift4.zendesk.com/hc/en-us/articles/12776516243475-Set-Online-Order-Throttling-for-Online-Ordering · retrieved 2026-08-03

B
Partial

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

One flow covers takeout and delivery (with mode-specific surcharge, minimums, address validation and prep time), and QR Order/QR Pay covers dine-in at the table. Shortfall: curbside with arrival check-in is not documented anywhere in the help centre - the only alternative to an address is a fixed 'Drop-Off Point'. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Install-and-Configure-Online-Ordering · retrieved 2026-08-03

B
Yes

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

QR Pay is split into two independently toggleable halves - QR Order (scan a table QR carrying table information, browse, add items, send to kitchen, order multiple rounds via SMS click-through authentication) and QR Pay (QR on the guest check, guest pays from their phone, tip configuration, ticket auto-closes in the POS). https://shift4.zendesk.com/hc/en-us/articles/22764853427347-Shift4-Dine-QR-Multi-Round-Ordering-Overview · retrieved 2026-08-03

B
Partial

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

A first-party kiosk with published specifications, an installation guide, an A35 PIN pad for unattended EMV, configurable order flows, tip configuration, order numbers, an Order Again feature and a manager dashboard, running the Menu Manager menu. Shortfalls: no accessibility or ADA conformance statement anywhere, no loyalty support ('Not at this time'), no revenue-centre assignment, and only one form factor is documented. https://shift4.zendesk.com/hc/en-us/articles/45874024285715-Kiosk-Specifications · retrieved 2026-08-03

B
No

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

This URL is already held in the record. The full 2026-08-28 Online Ordering configuration guide covers order settings, order types, throttling, surcharges, notifications, scheduling, delivery zones and menu setup; sharing appears only as 'Share the Online Ordering link on social media', a marketing link, not a per-order shareable cart. Anchored searches across all 2,162 articles for group order, shareable link and spend cap return three files, none of them group ordering: SkyTab POS Winter 2025 Release uses the phrase for in-store 'Auto Split by Seat functionality to simplify handling group orders', Display Groups is menu layout, and Salon & Spa's 'Group order items by product' is cart line consolidation. No participant, per-person cap or split-at-close concept exists. https://shift4.zendesk.com/hc/en-us/articles/1500007486702-Set-Up-Online-Ordering-in-Shift4-Dine-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

Some catering machinery exists and is named as such: 'Future Order can include' both 'Catering orders' and 'Event orders', with lead-time rules ('Shift4 Dine automatically sends the order to the kitchen based on its scheduled fulfillment time and configured preparation lead time'), deposit terms ('Deposit' = 'A partial payment is collected when the order is scheduled') and liability reporting (updated 2026-08-04). But it is not a distinct catering ordering flow: it is a POS/Handheld scheduling feature, 'currently available only for Pilot users using Multi-Location Management (Customer Hub)', and the invoice/house-account half is ruled out in the same article -- 'Payment links and emailed invoices are not supported in the current release.' No separate catering menu or catering minimums, and no quote/proposal step, appears in Online Ordering (1500007486702), which offers only '1-6 Days Out : Customers can schedule orders up to six days in advance (ideal for catering).' Note that the sibling article Schedule a Future Order on Handheld is one of the 129 gated ids, so the handheld half of this feature is a measured floor. https://shift4.zendesk.com/hc/en-us/articles/53574813979027-Future-Orders-Overview · retrieved 2026-09-05 adversarially verified

B
Yes

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

Loman AI is a named certified Marketplace partner installed from the Customer Hub: it answers the restaurant's existing number, 'Loman AI pulls your menu directly from Shift4 Dine', and 'Phone order: Appears in Shift4 Dine as an online order; routes to the correct kitchen display automatically - no manual entry needed', with reservation handling, transfer-to-staff escalation and 30+ languages. Menus are bound to it through a Menu Manager schedule. https://shift4.zendesk.com/hc/en-us/articles/51910521192979-Enable-Loman-AI-in-the-Customer-Hub · retrieved 2026-08-03 adversarially verified

B
No

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

digital-drivethru-ai

This URL is already held in the record (3 existing citations). Shift4 Dine does have an AI voice ordering partner with real POS/menu integration and human handoff -- Loman can 'Take phone orders and route them to your kitchen displays', it 'pulls your menu directly from Shift4 Dine', and it can 'Transfer complex calls to your staff' (updated 2026-06-02) -- but it is a phone product, not a drive-thru lane: 'Loman AI is a phone answering solution built for restaurants and integrated with Shift4 Dine', installed against 'Your existing business phone number'. The Marketplace matrix (48443488325651, 2026-06-30) files it under Online Ordering and lists no drive-thru voice partner. The corpus's other conversational-AI article, Merchant Guide to Conversational Voice Assistant (42022648229267), is Shift4's own support phone line -- 'When you call Shift4, there is no need to navigate a complex phone menu' -- not a guest-facing lane assistant. Zero hits for drive-thru lane, headset or speaker post corpus-wide. https://shift4.zendesk.com/hc/en-us/articles/51910521192979-Enable-Loman-AI-in-the-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
No

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

digital-sms-ordering

Shift4 states the platform has no outbound guest SMS channel to order through: 'Customer Engagement via text messages is not currently available. The only way to set up customer engagement is via Email Campaigns', repeated in the Loyalty FAQs ('Can I send loyalty promotions to my customers via text message? No'). SMS is used only for one-way order-ready notifications and QR click-through authentication. https://shift4.zendesk.com/hc/en-us/articles/360040013233-Set-up-Customer-Engagement-Email-Campaigns-in-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Order with Google is implemented properly - 'Order with Google is automatically enabled when Online Ordering is turned on', with documented steps to add the storefront URL to the Google Business Profile and set 'Preferred for pickup and Preferred for delivery' so the storefront shows at the top of the provider list 'labeled Preferred by this business'. Shortfall: 'This feature is currently available only for Pilot users.' https://shift4.zendesk.com/hc/en-us/articles/50713775950355-Enable-Order-With-Google-for-Online-Ordering · retrieved 2026-08-03

B
No

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

digital-apple-business-connect

The discriminating test is that Shift4 documents the Google analogue in detail and the Apple one not at all. Order with Google gets a dedicated setup article (updated 2026-05-21) -- 'Order with Google (OwG) allows customers to discover your restaurant on Google Search and Google Maps and seamlessly transition into your Online Ordering experience' -- plus a separate FAQ article (51912645715347), a Marketplace matrix row, and a Google Business Profile walkthrough in the InhouseDelivery article ('Select View profile > Food ordering'). Anchored searches for Apple Business Connect, Apple Maps and Order Food return ZERO hits across all 2,162 current articles. The 129 gated ids are internal agent tooling plus an offline/scales cluster; none touches ordering placement channels, so this absence is measured, not merely unread. https://shift4.zendesk.com/hc/en-us/articles/50713775950355-Enable-Order-With-Google-for-Online-Ordering · retrieved 2026-09-05 adversarially verified

B
Partial

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

Shift4 publishes the shortfall itself: 'Online Ordering currently supports partial loyalty functionality: Customers can accrue points on online orders. Rewards can only be applied in-store at this time. Online reward redemption is coming soon!' The same article lists Handheld, Tablet, Kiosk, Duo and Shift4 One as unsupported devices, and the whole Shift4 Loyalty platform is 'currently available only for Pilot users'. https://shift4.zendesk.com/hc/en-us/articles/47976798951571-Shift4-Loyalty-Platform-Limitations-and-Coming-Soon-Features · retrieved 2026-08-03

B
No

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

Shift4 Dine's guest-programme surface is enumerated structurally and contains no paid tier or recurring entitlement: 'Loyalty Programs are the highest level in the loyalty structure. These groups control the following:' followed by exactly three controls - the programme name, 'The custom name of the loyalty points is optional and visible to your members.' and 'The locations included in the loyalty program' - beneath which sit only Discounts and Members (updated 2026-05-12). Corroborated by a closed enumeration of the engagement suite: 'The Customer Hub consists of three key premium features: Customer Engagement, Online Reputation Management, and Social Media Management.' (https://shift4.zendesk.com/hc/en-us/articles/34856371045907-Shift4-Customer-Hub-Basics, updated 2026-08-27). Every 'subscription' hit corpus-wide is a report subscription ('Set up, Edit or Delete a Report Subscription in the Shift4 Customer Hub') or the merchant's own SaaS fee, never a guest entitlement; the dev.shift4.com Plans/Subscriptions objects are the gateway's recurring-billing primitive with no POS-side entitlement. This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/16166684069011-Loyalty-Overview-for-the-Workstation-on-Shift4-Dine · retrieved 2026-09-05 adversarially verified

B
Partial

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

Coupons are defined once in the Customer Hub for Online Ordering and QR Pay, and POS discounts (including Discount Type Purchase Rules for BOGO and spend thresholds) are defined once for the terminal. Shortfall: they are two separate mechanisms with no documented channel-eligibility matrix, the kiosk is not named in either, and loyalty rewards are explicitly in-store only. https://shift4.zendesk.com/hc/en-us/articles/45519296605587-Set-Up-Coupons-for-Online-Ordering-or-QR-Pay-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

The operator can self-serve a Customer Directory, Customer House Accounts Balance and Customer Item Sales report and download it as CSV, Excel or PDF without a support ticket or fee, and loyalty member and redemption reports export the same way. Shortfall: no published contract term states the merchant owns those guest records or constrains Shift4's use of them - the SkyTab POS System Service Agreement PDF returns HTTP 403 to this environment - and marketing consent status is not documented as an exportable field. https://shift4.zendesk.com/hc/en-us/articles/46509565887507-Customer-Reports-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Digital card entry is vendor-hosted: Payment Links are served on shift4.com URLs with the merchant's branding applied, QR Pay opens 'a secure checkout page' on Shift4 infrastructure, and Online Ordering payment configuration is done in the Shift4 console. Shortfall: no PCI DSS 4.0 attestation is readable (the compliance articles are embedded, undated documents), no statement addresses the March 2025 payment-page script-integrity requirements, and 3DS is never mentioned. https://shift4.zendesk.com/hc/en-us/articles/48013714070291-Payment-Links-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

The digital channel does NOT get the same configuration as the POS - the vendor documents it as a manual, merchant-executed price rewrite: for Dual Pricing, 'merchants must update menu prices in the POS system, online ordering platforms, printed menus, and marketing material', and the same instruction repeats verbatim under Cash Discount. Jurisdiction/brand handling fails on the same article's banner: 'the Advantage Program does not auto-detect debit BINs', with Louisiana requiring 'a manual exclusion for debit'. What Online Ordering actually has is order-level service fees with a configurable guest-facing label, not card surcharging - Set Up Online Ordering in Shift4 Dine Customer Hub (# updated 2026-08-28, already cited 7 times by the record) documents an 'Online Order Surcharge Name' field that 'Sets the name customers see when an online order surcharge applies', a Type field that 'Sets a flat-dollar or percentage-based surcharge for online orders', an 'Online Order Surcharge Tax' field, and a parallel 'Delivery Surcharge Name'. So disclosure exists on the digital fee, and parity plus jurisdiction/brand handling do not. https://shift4.zendesk.com/hc/en-us/articles/17140380911379-Advantage-Program-FAQs-United-States · retrieved 2026-09-05 adversarially verified

B

Guest data, loyalty & marketing

Partial

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

There is one customer database, keyed by phone number for loyalty at the POS and by email address for Online Ordering, and the Customer Hub manages members centrally. Shortfall: Shift4 documents that merge behaviour is absent, not automatic - 'Duplicate customer/member records? Due to the nature of this feature, it is possible for duplicate records to happen. Auditing the members for duplicates can help maintain an accurate database' - and online orders are 'automatically not linked' to customer records yet. The kiosk carries no loyalty at all. https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs · retrieved 2026-08-03

B
Partial

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

Shift4 Dine-scoped ('Log in to the Workstation for Shift4 Dine as a manager'). The shipped, present-tense half: 'The first time someone orders in the system, their record will be saved and linked by email address.' and 'It is based on the Email Address - 1 record for each email address.' with 'Addresses: Saves a list of unique addresses used for that email' and 'Phone: Saves a list of phone numbers used for that email' (updated 2026-05-12). The toggle is on the Marketplace tab, and https://shift4.zendesk.com/hc/en-us/articles/360034908934-Configure-Business-Settings-in-Shift4-Dine (updated 2026-08-28) states 'These fields must be filled in before using Online Ordering or any third-party online ordering on the Workstation.', which puts third-party channels in scope. What is NOT shipped, and what blocks a yes, under the heading Previous Orders: 'In a future release, online orders will be automatically linked to customer records. Currently, they are automatically not linked.' Identity is captured and deduplicated; the ticket does not attach to the profile. Hence partial. https://shift4.zendesk.com/hc/en-us/articles/26101107824147-Save-and-Sync-Customer-Details-in-Online-Ordering · retrieved 2026-09-05 adversarially verified

B
No

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

Only one accrual model exists and Shift4 states its limits: 'Loyalty Program points are earned based on points per the whole dollar spent rounded up to the nearest dollar', and 'Can I customize loyalty points earned per dollar? Loyalty does not support loyalty points earned per dollar customization. However, the Loyalty Promotions feature allows loyalty points to be multiplied.' No visit/punch-count and no spend-tier accrual is offered, so the two-of-three threshold is not met. https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs · retrieved 2026-08-03

B
No

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

guest-loyalty-tiers

Shift4 Dine's own loyalty architecture is enumerated top-down and has no status construct: 'Loyalty Programs are the highest level in the loyalty structure. These groups control the following:' - the programme name, the point name, and 'The locations included in the loyalty program' - with the only other objects being Discounts and Members; earn is flat, 'Members can quickly sign up with just their phone number and start earning points based on their transactions.' (updated 2026-05-12). Corroborated by the closed promotion-type enumeration 'Promotion Type: Select from either Sign Up or Multiplier.' (https://shift4.zendesk.com/hc/en-us/articles/16079106442643-Add-a-Loyalty-Promotion-on-the-Shift4-Dine-Customer-Hub) and by Loyalty FAQs: 'Can I customize loyalty points earned per dollar?' - 'Loyalty does not support loyalty points earned per dollar customization.' (https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs). No tier, no status, no promotion or demotion window anywhere in the structure. This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/16166684069011-Loyalty-Overview-for-the-Workstation-on-Shift4-Dine · retrieved 2026-09-05 adversarially verified

B
No

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, queue-and-reconcile versus blocked. VERDICT no. WHAT IS MET: nothing. SkyTab publishes a dedicated, granular offline FAQ and a complete loyalty article set, and neither ever addresses the other. SHORTFALLS. (1) The offline enumeration never mentions loyalty. 'Shift4 Dine Offline Payments Overview and FAQs' (category Shift4 Dine, section Use and Operation, https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs) states 'During Offline Mode, the following Shift4 Dine features are unavailable: Pre-Authorizations / Refunds / Shift4 Dine Customer Hub Data Syncing', and its closing FAQ asks 'Are there any other limitations to offline processing on Shift4 Dine?' and answers only 'While Shift4 Dine is offline, refund and pre-authorization features are disabled.' That is a closed enumeration of offline limitations and loyalty is not in it. The same article is granular enough to answer questions about the local network, printers and the Kitchen Display System ('Your local network, printers, Kitchen Display System, and similar devices work as long as the local network is connected'), about EMV chip and PIN, about Apple Pay and Google Pay, and about editing the menu while offline - and asks nothing about loyalty. (2) The loyalty documentation never mentions connectivity. 'Search for a Loyalty Member on the Workstation for Shift4 Dine' (https://shift4.zendesk.com/hc/en-us/articles/16149428465939-Search-for-a-Loyalty-Member-on-the-Workstation-for-Shift4-Dine) gives only 'Enter the customer's phone number using the keypad and select Lookup' with no statement of what Lookup does without a connection; 'Redeem a Loyalty Reward on the Workstation for Shift4 Dine' (https://shift4.zendesk.com/hc/en-us/articles/16146981088019-Redeem-a-Loyalty-Reward-on-the-Workstation-for-Shift4-Dine) names exactly one constraint, 'Only one Loyalty Reward may be redeemed per ticket'; 'Loyalty Overview for the Workstation on Shift4 Dine' (https://shift4.zendesk.com/hc/en-us/articles/16166684069011-Loyalty-Overview-for-the-Workstation-on-Shift4-Dine) and 'Loyalty FAQs' (https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs) are likewise silent. All five are category Shift4 Dine. (3) The gap is operationally live rather than theoretical, because loyalty is cloud-resident: the Overview places the member record in the Shift4 Dine Customer Hub and pooled across locations, and 'Shift4 Dine Customer Hub Data Syncing' is exactly what the offline FAQ lists as unavailable. The operator cannot determine whether Lookup fails, accrues locally, or blocks the ticket. CONTROLS AND POISON. All searches tokenised with word boundaries over comment-stripped, block-tag-separated text. A loyalty-times-connectivity co-occurrence within a 600-character window, restricted to the 1,031 Shift4 Dine articles, returns exactly ONE document, and it is adjacency not documentation: 'Release Notes - SkyTab POS v1.120' happens to list 'Fixed an issue where a loyalty member who was attached to a ticket and then removed may not have their redeemed loyalty rewards removed' immediately before 'Improved reliability of offline processing when the customer-Facing Display is enabled'. Run over the whole corpus the same probe adds five documents and every one is the sibling-product scope trap: four are Appetize in category Legacy POS Solutions, where a third-party Givex tender carries 'Offline Enabled: Allows the Givex tender to be taken offline if enabled' - that is Appetize, a different acquired product, and importing it would have manufactured a SkyTab capability; the fifth is a Marketplace article about the third-party LoyaltyMatch integration. POISON: the token failover returns exactly 4 documents corpus-wide and every one is a false friend - three are a receipt or kitchen 'FAILOVER PRINTER: Select a backup printer from the dropdown' setting and one is an EMV chip-to-magstripe fallback; standalone returns 8 Shift4 Dine documents and not one concerns offline operation. HARNESS AND POSITIVE CONTROLS: every count below was produced by a script written to disk with the Write tool, never inline in a shell string or a heredoc, because shell quoting collapses a regex word boundary to a literal backspace. HTML comments were stripped BEFORE tags, script and style bodies were removed, and a pilcrow was injected at every closing block and table tag so that tag-stripping cannot weld table cells or bold/anchor spans into a false contiguous quote. Positive controls on every run over the 2,174 bodies: Shift4 = 1,130 documents, order = 761, the = 2,133; negative control zzzqqqnonsense = 0. The corpus contains ZERO HTML comments of any length across all 2,174 bodies, so nothing is commented out. Every asserted zero was run twice, once with both word boundaries and once as a left-boundary stem, and where the two disagree I say so. BOUND CORPUS: the 2,174-article anonymous Zendesk Help Center API dump of shift4.zendesk.com (12,518,321 bytes of bodies), of which category 'Shift4 Dine' is 1,031 articles. SHIFT4 DINE IS SKYTAB, and I established it first-hand rather than inheriting it: the release-note series inside that one category runs SkyTab POS v1.119.6, v1.120, v1.121, v1.121.7, v1.122, v1.123.2, v1.124.2 and then, without a version break, Shift4 Dine v1.124.8, v1.125.2, v1.126.2, v1.127.4, v1.128.0; article 11717296534675 'Find the Release Notes for Shift4 Dine' carries an updated_at of exactly 2026-05-12; a Shift4 Dine article instructs the reader to 'Quickly tap on the SkyTab logo five times' (15674547564819); another says 'Shift4 Dine uses an SNBC thermal printer' under the heading 'SkyTab POS SNBC Receipt Printer' (44476146740883); and a Universal Transaction Gateway article lists the Windows service for Shift4 Dine as 'Shift4 SkyTab Interface Service' (1500010285142). Tokenised, the word SkyTab survives in only 30 of 2,174 bodies (116 as a raw substring, the difference being URLs and image filenames), which is a rename artefact and not a scope signal. I did NOT borrow from Legacy POS Solutions (552 articles, Appetize/Salon & Spa/Hospitality/QSR), Micros Center of Excellence, Restaurant Manager, Shift4 Duo, Shift4 One, Shift4Shop or Microsoft Dynamics 365. FRESHNESS IS NOT EVIDENCE HERE: 108 articles share the minute 2026-05-12T12:03, 107 share 12:12, 80 share 12:00 and 79 share 12:15 - that is the dated rename re-save, explicable rather than random, but it still cannot show that any individual article's CONTENT is current, and no finding below leans on updated_at. CORPUS BOUNDING BY HREF FIXPOINT, RE-RUN BY ME: 1,388 distinct /hc/{locale}/articles/<id> ids are referenced inside the raw bytes of the 2,174 held bodies, 1,193 are held and 195 are absent; I probed all 195 at /api/v2/help_center/en-us/articles/<id>.json and got 0 x HTTP 200, 130 x 401 and 69 x 404, with four fabricated 14-digit ids (99999999999999, 88888888888888, 12345678901234, 55555555555555) all returning 404, so a gated 401 is discriminable from a stale 404. Zero unlisted published articles means the published operator set is complete. I recovered a human-readable label for ALL 130 gated ids by pulling the anchor TEXT out of the referring bodies rather than relying on the URL slug (92 of the 130 are referenced by bare id with no slug, so a slug-only triage would have left 92 unlabelled). VIDEO HOLE, NAMED: 168 of 2,174 bodies contain an <iframe> on raw bytes (136 of them inside Shift4 Dine), 189 of the embeds are player.vimeo.com, and the KB's own Lighthouse 2025w49 release notes speak of 'unlocking the full value of our SkyTab video library'. Video-bearing articles carry MORE text than average (median 2,231 characters against 1,594 corpus-wide) and only 17 articles corpus-wide are near-textless, so video supplements the prose rather than replacing it - but no text-only zero over this KB is complete, and I name the in-area video articles per cell below. ATTACHMENTS were censused at /api/v2/help_center/articles/<id>/attachments.json. HOLES SPECIFIC TO THIS CELL, STATED PLAINLY: (a) two gated 401 articles are SkyTab offline material - 8153331764243 'Shift4 Dine Offline Mode Issue Troubleshooting' and 24300353919123 'Shift4 Dine Offline Processing Transaction Issue Troubleshooting' - and both are listed in 'Shift4 Dine Offline Resources' (https://shift4.zendesk.com/hc/en-us/articles/36289244948627-Shift4-Dine-Offline-Resources) underneath an explicit 'Internal:' heading, i.e. Shift4 support-agent material, and both are titled to payment-transaction faults; (b) four offline-titled Shift4 Dine articles embed Vimeo video I cannot read. Neither hole touches the loyalty side of the conjunction: not one of the 130 gated ids bears a loyalty, member, reward, marketing or engagement label under anchor-text recovery, and ZERO loyalty-titled Shift4 Dine articles carry a video embed. The verdict is a verdict about the published operator documentation, which is what the claim asks about. ATTACHMENTS: all 2,174 articles probed at 200, 15,527 attachments of which only 20 are non-image; the sole Shift4 Dine PDFs are 'Manager End of Day QRG.pdf' and 'Employee End of Day QRG.pdf', procedural end-of-shift checklists that duplicate their articles and mention neither loyalty nor offline loyalty. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-09-15 adversarially verified

B
Partial

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

guest-loyalty-offer-stacking-rules

Shift4 Dine-scoped by title and body. A published precedence ladder exists: 'Discount Stacking and Order of Application' - 'Multiple discounts can apply to the same ticket or item. Shift4 Dine applies discounts automatically in this order:' then 'Standard Discounts with Force Price as the Discount Type', 'Item-level Discount Type Purchase Rules', 'Item-level Standard Discounts', 'Ticket-level Discount Type Purchase Rules', 'Ticket-level Standard Discounts' (updated 2026-05-12). That is fixed system behaviour, not operator configuration: the configurable 'Additional Criteria' are enumerated in full as 'Include modifier values', 'Require reason', 'Automatic Application', 'Effective dates and times' and 'Eligible order types' - no exclusive-versus-combinable toggle and no per-offer stacking flag. Loyalty discounts sit outside the ladder entirely: 'These discounts work outside the standard discounts and won't appear in the regular discount sections.' (https://shift4.zendesk.com/hc/en-us/articles/16166684069011-Loyalty-Overview-for-the-Workstation-on-Shift4-Dine). Hence partial: order-of-application is documented, stacking-as-configuration is not. This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/44242422566035-Configure-Discount-Type-Purchase-Rules-Using-Shift4-Dine-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

Audiences can be narrowed: campaign Sending Rules offer 'All Customers' or 'Custom List', and the 'Invite to visit again' type is 'Sent to customers based on criteria you enter to encourage them to return'. Shortfall: there is no general rules builder over recency, frequency, spend or items purchased - the only criteria-driven type is the win-back template, and everything else is a broadcast or a hand-built list. https://shift4.zendesk.com/hc/en-us/articles/360040013233-Set-up-Customer-Engagement-Email-Campaigns-in-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

Two independent closed enumerations, both with room, both silent. Targeting: the audience selector is enumerated exhaustively as 'All Customers : Send to all customers.' and 'Custom List : Choose specific customers to send to.', and the campaign types are 'Holidays and promotions', 'Welcome new customer', 'Invite to visit again: Sent to customers based on criteria you enter to encourage them to return.' and 'Survey email' - criteria the operator enters, never a system-derived segment (updated 2026-05-12). Reporting: the Customer Directory report carries the raw RFM dimensions but no segmentation over them - 'Customer Directory' is 'Listed alphabetically by customer name' with columns 'Name, Email Address, Phone Number(s), Address, Average Spent, Total Spent, Last Visit' (https://shift4.zendesk.com/hc/en-us/articles/46509565887507-Customer-Reports-on-the-Shift4-Dine-Customer-Hub, updated 2026-05-18); the grouping-and-sorting column is enumerated for all three customer reports and offers only alphabetical order. SevenRooms does advertise 'Create guest tags and segments based on guest behavior (VIP, Regular, Big Spender)' but is a third-party Marketplace partner and its tags are operator-created. https://shift4.zendesk.com/hc/en-us/articles/360040013233-Set-up-Customer-Engagement-Email-Campaigns-in-Shift4-Dine-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Yes

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

Customer Engagement ships triggered campaign types as always-on configurations, not one-off sends: 'Welcome new customer: Sends an email to newly added customers once their first ticket is closed at your location', 'Invite to visit again: Sent to customers based on criteria you enter', plus Survey email and Holidays and promotions, each with a Sending Rules frequency and Draft/Active/Complete/Inactive states. https://shift4.zendesk.com/hc/en-us/articles/360040013233-Set-up-Customer-Engagement-Email-Campaigns-in-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

Email only, stated twice by Shift4: 'Customer Engagement via text messages is not currently available. The only way to set up customer engagement is via Email Campaigns', and in the Loyalty FAQs 'Can I send loyalty promotions to my customers via text message? No, the loyalty promotion via text messages feature is not available at this moment.' SMS marketing is available only by installing a Marketplace partner such as Textmunication or Mailchimp. https://shift4.zendesk.com/hc/en-us/articles/360040013233-Set-up-Customer-Engagement-Email-Campaigns-in-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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, on the documentation limb, with the handling limb expressly unresolved and that stated below rather than hidden. WHAT IS MET: nothing that the claim can score. The vendor twice states, in its own words, that the operator cannot send text marketing at all. 'Loyalty FAQs' (category Shift4 Dine, section Use and Operation, https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs): 'Can I send loyalty promotions to my customers via text message? No, the loyalty promotion via text messages feature is not available at this moment. The only way to set up customer promotions is via email.' Independently, 'Set up Customer Engagement / Email Campaigns in Shift4 Dine Customer Hub' (category Shift4 Dine, https://shift4.zendesk.com/hc/en-us/articles/360040013233-Set-up-Customer-Engagement-Email-Campaigns-in-Shift4-Dine-Customer-Hub) carries a heading 'Customer Engagement via Text Messages' whose entire body reads 'Customer Engagement via text messages is not currently available. The only way to set up customer engagement is via Email Campaigns.' SHORTFALLS. (1) The regulatory vocabulary is wholly absent. Tokenised over all 2,174 bodies: 10DLC = 0 documents, 10-DLC = 0, A2P = 0, 'brand registration' = 0, 'campaign registration' = 0, 'The Campaign Registry' = 0, CTIA = 0, TCPA = 0, 'short code' = 0, shortcode = 0, 'toll-free' = 0, Twilio = 0. The same twelve terms are 0 across my own extractions of the Merchant Processing Agreement, the Shift4 Dine POS System Service Agreement, the Shift4 Customer Hub Terms and Conditions, the Gateway Terms and Conditions and the Workforce Terms of Use. (2) The zero is about the regulatory concept and not about my choice of word, because the vendor's own messaging vocabulary is present in quantity: SMS = 32 documents corpus-wide and 16 within Shift4 Dine, 'text message' = 21 and 9, messaging = 27 and 19. (3) A2P traffic really does flow on the operator's behalf, so the silence has a consequence. SkyTab sends loyalty phone-verification and marketing opt-in texts ('As part of our loyalty program, we send a text message to the member's provided phone number to confirm its validity. By agreeing to receive text messages, the member is also opting in to receive text marketing communications from us', https://shift4.zendesk.com/hc/en-us/articles/16166684069011-Loyalty-Overview-for-the-Workstation-on-Shift4-Dine); digital receipts by SMS link ('Digital Receipts Overview for Shift4 Dine', https://shift4.zendesk.com/hc/en-us/articles/51205071457171-Digital-Receipts-Overview-for-Shift4-Dine); QR Multi-Round Ordering authentication ('QR Order will use SMS click-through authentication', https://shift4.zendesk.com/hc/en-us/articles/34391318109075-Configure-QR-Multi-Round-Ordering); kitchen-display guest-ready notifications ('The notification type (e.g., SMS, email, etc.) assigned to the order type will be sent to the guest', https://shift4.zendesk.com/hc/en-us/articles/31427561234067-Guest-Notifications-Overview-on-the-Kitchen-Display-System); kiosk 'SMS on Done'; Payment Links; and Workforce employee invitations. Not one article says who registers the brand or the campaign, what throughput applies, or what to do when a guest notification is filtered. THE INVERSE TEST, RUN AND REPORTED HONESTLY: A2P 10DLC registration is normally performed by the messaging provider rather than by the POS reseller, and every SMS surface above is sent by Shift4's infrastructure on Shift4's own brand - the loyalty text is expressly marketing 'from us'. The one place the operator's own identity is the sender is explicitly NOT platform A2P: 'Send a Receipt to a Customer Using InCharge' (https://shift4.zendesk.com/hc/en-us/articles/15645722634771-Send-a-Receipt-to-a-Customer-Using-InCharge) tells the user to use the device's own SMS app and warns 'When sending via SMS, remember that the recipient will see your phone number as the sender', which is person-to-person messaging from the handset. So this no is a finding about the published documentation and about the absence of any operator-facing registration flow; it is NOT a finding that no 10DLC registration exists upstream at Shift4, and a reader must not take it as one. The claim is scored no because neither limb is evidenced: registration is nowhere documented, and no published source states that Shift4 handles it. CONTROLS AND POISON. MY OWN CONTROL CARRIED THE TRAP AND I REPRODUCED IT: an untokenised raw-byte probe for (10\s*DLC|A2P|Box\s*12|W-?2) returns 21 documents where the tokenised clean-text probe returns 0, and all 21 are 'W2' inside Zendesk ULID heading anchors such as id="h_01H2RBZ2WSRDK4BJHYYMSBTW2F", inside styled-component CSS class hashes such as 'sc-1fkmqhw-2', and inside base64 inline image payloads. Publishing the raw count would have asserted a 21-document hit rate that does not exist. Further poison: the token carrier returns only 3 documents and none is an SMS carrier (a telephone-line carrier in an escalation script, an 'SMS Carrier' free-text admin profile field, and the consumer 'Carrier charges may apply' receipt disclaimer); 'opt-in' returns 3 and all concern email or push consent. HARNESS AND POSITIVE CONTROLS: every count below was produced by a script written to disk with the Write tool, never inline in a shell string or a heredoc, because shell quoting collapses a regex word boundary to a literal backspace. HTML comments were stripped BEFORE tags, script and style bodies were removed, and a pilcrow was injected at every closing block and table tag so that tag-stripping cannot weld table cells or bold/anchor spans into a false contiguous quote. Positive controls on every run over the 2,174 bodies: Shift4 = 1,130 documents, order = 761, the = 2,133; negative control zzzqqqnonsense = 0. The corpus contains ZERO HTML comments of any length across all 2,174 bodies, so nothing is commented out. Every asserted zero was run twice, once with both word boundaries and once as a left-boundary stem, and where the two disagree I say so. BOUND CORPUS: the 2,174-article anonymous Zendesk Help Center API dump of shift4.zendesk.com (12,518,321 bytes of bodies), of which category 'Shift4 Dine' is 1,031 articles. SHIFT4 DINE IS SKYTAB, and I established it first-hand rather than inheriting it: the release-note series inside that one category runs SkyTab POS v1.119.6, v1.120, v1.121, v1.121.7, v1.122, v1.123.2, v1.124.2 and then, without a version break, Shift4 Dine v1.124.8, v1.125.2, v1.126.2, v1.127.4, v1.128.0; article 11717296534675 'Find the Release Notes for Shift4 Dine' carries an updated_at of exactly 2026-05-12; a Shift4 Dine article instructs the reader to 'Quickly tap on the SkyTab logo five times' (15674547564819); another says 'Shift4 Dine uses an SNBC thermal printer' under the heading 'SkyTab POS SNBC Receipt Printer' (44476146740883); and a Universal Transaction Gateway article lists the Windows service for Shift4 Dine as 'Shift4 SkyTab Interface Service' (1500010285142). Tokenised, the word SkyTab survives in only 30 of 2,174 bodies (116 as a raw substring, the difference being URLs and image filenames), which is a rename artefact and not a scope signal. I did NOT borrow from Legacy POS Solutions (552 articles, Appetize/Salon & Spa/Hospitality/QSR), Micros Center of Excellence, Restaurant Manager, Shift4 Duo, Shift4 One, Shift4Shop or Microsoft Dynamics 365. FRESHNESS IS NOT EVIDENCE HERE: 108 articles share the minute 2026-05-12T12:03, 107 share 12:12, 80 share 12:00 and 79 share 12:15 - that is the dated rename re-save, explicable rather than random, but it still cannot show that any individual article's CONTENT is current, and no finding below leans on updated_at. CORPUS BOUNDING BY HREF FIXPOINT, RE-RUN BY ME: 1,388 distinct /hc/{locale}/articles/<id> ids are referenced inside the raw bytes of the 2,174 held bodies, 1,193 are held and 195 are absent; I probed all 195 at /api/v2/help_center/en-us/articles/<id>.json and got 0 x HTTP 200, 130 x 401 and 69 x 404, with four fabricated 14-digit ids (99999999999999, 88888888888888, 12345678901234, 55555555555555) all returning 404, so a gated 401 is discriminable from a stale 404. Zero unlisted published articles means the published operator set is complete. I recovered a human-readable label for ALL 130 gated ids by pulling the anchor TEXT out of the referring bodies rather than relying on the URL slug (92 of the 130 are referenced by bare id with no slug, so a slug-only triage would have left 92 unlabelled). VIDEO HOLE, NAMED: 168 of 2,174 bodies contain an <iframe> on raw bytes (136 of them inside Shift4 Dine), 189 of the embeds are player.vimeo.com, and the KB's own Lighthouse 2025w49 release notes speak of 'unlocking the full value of our SkyTab video library'. Video-bearing articles carry MORE text than average (median 2,231 characters against 1,594 corpus-wide) and only 17 articles corpus-wide are near-textless, so video supplements the prose rather than replacing it - but no text-only zero over this KB is complete, and I name the in-area video articles per cell below. ATTACHMENTS were censused at /api/v2/help_center/articles/<id>/attachments.json. HOLES SPECIFIC TO THIS CELL: under anchor-text recovery none of the 130 gated 401 ids bears an SMS, messaging, campaign, registration or marketing label - the four that match the messaging pattern are a gateway database-offline error, a merchant welcome-email issue, a Legacy 'Email Report' and a Mailchimp recipient-status article - and ZERO SMS- or message-titled Shift4 Dine articles carry a video embed, so the video hole does not touch this cell. NOTE ON WEIGHT: this claim is table-stakes weight, so the differentiator grade floor does not bind; the citations are first-party vendor product documentation and grade B. https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs · retrieved 2026-09-15 adversarially verified

B
Partial

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

guest-loyalty-campaign-attribution

Loyalty reporting includes a Loyalty Redemption by Location report showing 'redeemed loyalty discount activities', exportable to CSV/Excel/PDF, so redemptions are traceable to the discount. Shortfall: nothing ties a redemption back to the email campaign that drove it, and no incremental-sales or campaign-attribution reporting exists in Customer Engagement. https://shift4.zendesk.com/hc/en-us/articles/38825545487635-Locate-Loyalty-Reports-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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 operator self-serves a Customer Directory with contact information and visit history, Customer Item Sales, Customer House Accounts Balance, loyalty member and redemption reports and gift-card balance reports, each downloadable as CSV, Excel or PDF from the Customer Hub with no fee or support ticket documented. https://shift4.zendesk.com/hc/en-us/articles/46509565887507-Customer-Reports-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03 adversarially verified

B
Partial

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

Both halves exist separately: Customer Engagement can send a Survey email 'to gain feedback and ratings from your customers based on the criteria you select', and Reputation Management connects Facebook, Google and Yelp accounts to read ratings and respond in-product with Complete / In Progress / Do Not Respond statuses. Shortfall: no score-based routing - low scores are not diverted to private service recovery and high scores are not steered toward public review sites. https://shift4.zendesk.com/hc/en-us/articles/360042822653-Use-Reputation-Management-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

Shift4 Dine-scoped ('Shift4 Loyalty is available to eligible merchants using Shift4 Dine and Shift4 Dine Customer Hub.', updated 2026-05-12). The FAQ devotes an enumerated section to Customer Enrollment and Accounts and the mechanic it describes is one shared link with no per-guest code and no attribution: 'Customers enroll using a customer-facing enrollment URL or QR code generated during setup.' and 'Can a customer have multiple loyalty accounts?' - 'No. Each customer can have only one loyalty account per merchant.' The bonus-award construct in the GA programme is a closed two-option enumeration with room for a referral type and without one: 'Promotion Type: Select from either Sign Up or Multiplier.' (https://shift4.zendesk.com/hc/en-us/articles/16079106442643-Add-a-Loyalty-Promotion-on-the-Shift4-Dine-Customer-Hub, updated 2026-05-12) - a signup bonus with no referrer side is not the two-sided reward this cell requires. This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/48082498087827-Shift4-Loyalty-FAQs · retrieved 2026-09-05 adversarially verified

B
No

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

Shift4 Dine-scoped, updated 2026-05-12. The member-side artefacts are enumerated where a wallet pass would have to appear and it is absent: 'How do customers check their points balance?' - 'Customers can log into their loyalty dashboard anytime using the enrollment link, or staff can look up their account at the Workstation to show their current points balance.', and the lookup keys are a closed list - 'Staff can add a loyalty member by selecting the Loyalty button on the order screen and searching by phone number, email, QR code, or loyalty card number.' A web dashboard plus a merchant loyalty card is not a wallet pass. The only 'Apple Wallet|Google Wallet|pkpass|wallet pass' hits corpus-wide are two payment-acceptance settings - 'an integrated contactless reader for NFC (Apple Pay / Google Wallet) payments' in Hardware Settings on the Workstation for Shift4 Dine, and an Ingenico Telium contactless toggle - neither of which is a loyalty credential. This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/48082498087827-Shift4-Loyalty-FAQs · retrieved 2026-09-05 adversarially verified

B
Partial

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

Partial deletion tooling exists: a member's status can be changed in the Customer Hub so 'they will no longer be able to access loyalty using their phone number. The phone number is treated as if they were a new member', and customer records can be deleted in the Customer Hub. Shortfalls: deactivation retains the points balance rather than erasing data, deleted online-ordering customers are silently restored on their next order, and no DSAR workflow or executable DPA is documented. https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs · retrieved 2026-08-03

B
Partial

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

Manual point adjustments require a typed reason and the permission model gates who can perform them, and Business Intelligence alerts flag discount, void and excess-tip patterns by employee. Shortfall: no redemption velocity limit, no manager-approval gate specific to point adjustment, and no employee self-redemption flag are documented. https://shift4.zendesk.com/hc/en-us/articles/4406379330707-Loyalty-Points-Overview · retrieved 2026-08-03

B
No

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

guest-loyalty-ai-offer-recommendation

The offer-and-campaign engine is enumerated end to end and every decision in it is the operator's. Content: four campaign types, 'Holidays and promotions', 'Welcome new customer', 'Invite to visit again' and 'Survey email'. Audience: 'All Customers : Send to all customers.' or 'Custom List : Choose specific customers to send to.' Send time: 'The Review tab allows you to take a look at the final design for the campaign and determine the Date & Time that the email will be sent out.' (updated 2026-05-12). No model-chosen offer, audience or timing at any step. The vendor demonstrably labels AI where it exists - 'the information that you add to the form is used to generate AI content for the website' in Get Started With Website Builder - so silence here is informative rather than merely lexical. Loman AI, clickBACON and Barlytics are third-party Marketplace partners, not Shift4 Dine features. https://shift4.zendesk.com/hc/en-us/articles/360040013233-Set-up-Customer-Engagement-Email-Campaigns-in-Shift4-Dine-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Yes

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

Shift4Gift is native stored value with balance tracking, reload, e-gift and physical cards, and a documented multi-location shared program: 'This allows you to use one central gift card website where customers can purchase gift cards that are redeemable across all participating locations', with a Cross-Usage report allocating funds between owner locations. https://shift4.zendesk.com/hc/en-us/articles/48794084293011-Shift4-Gift-Card-Onboarding-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B

Labor & workforce

Yes

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

Employees log in and clock in at the workstation with no separate time clock; break in/out, clock-out restrictions per job, magnetic server/manager cards and employee ID cards are all supported, and punches feed Timeclock Management and the payroll reports. https://shift4.zendesk.com/hc/en-us/articles/9810544211219-Timeclock-Overview-on-Shift4-Dine · retrieved 2026-08-03

B
No

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

The clock-in identity model for Shift4 Dine is enumerated per employee and is credential-based, never photographic: the Employee Labor Settings are 'Health Card Exp', 'Liquor Card Exp', 'Dates', 'Track Labor', 'Paid Hourly', 'Record Breaks' and 'Card Only Access: If a Mag Card was set up on the General tab for this employee, it determines if a user is required to log in to the system using their assigned Mag card.' (updated 2026-05-12). The integrity controls that do exist are manager-side and after the fact: 'Future date shift validation prevents manually adding a future date to shift start time or end time' and 'Concurrent shift validation prevents adding a concurrent shift for an employee.' (https://shift4.zendesk.com/hc/en-us/articles/9810544211219-Timeclock-Overview-on-Shift4-Dine). The only biometric punch in the corpus, 'Fingerprint Guide in POSitouch', is a sibling product, and a fingerprint is neither a photo nor a photo-only mode. This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/360035408973-Labor-Time-Clock-Settings-on-the-Workstation-for-Shift4-Dine · retrieved 2026-09-05 adversarially verified

B
Partial

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

CLAIM: records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behaviour documented. VERDICT partial. WHAT IS MET, AND IT IS SUBSTANTIVE. SkyTab documents a named, automatic reconciliation mechanism for punches taken while a device is out of communication. 'Automatic Shift Merge Overview' (category Shift4 Dine, section Use and Operation, https://shift4.zendesk.com/hc/en-us/articles/31953171912211-Automatic-Shift-Merge-Overview): 'As a part of Shift4 Dine's local sync capabilities, Shift Merge will automatically detect any overlapping shifts an employee may have and merge these to a single timeclock record to reduce labor reporting issues. Overlapping shifts can occur in various ways but generally, happen when an employee attempts to clock in on more than one Shift4 Dine device where at least one of those devices is not communicating properly.' The reconciliation rule is stated precisely: 'When duplicate, overlapping shifts are detected, Shift4 Dine will merge these records to a new single timeclock record using the earliest clock in time and latest clock out time.' Surfacing is documented: 'Users will be prompted from the Manager > Timeclock screen if there have been any merged shifts ... The new merged shift record will be shown in the timeclock record next to the employee name with the Shift Merge icon.' So punches taken on a device that is out of communication survive and are later reconciled automatically, and the behaviour is written down. This is corroborated architecturally: the offline FAQ enumerates what IS unavailable offline - 'Pre-Authorizations / Refunds / Shift4 Dine Customer Hub Data Syncing' - and the time clock is not in that list, while 'Your local network, printers, Kitchen Display System, and similar devices work as long as the local network is connected' (https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs). SHORTFALLS. (1) The mechanism is not generally available: the article's first line is 'Note: This feature is currently in pilot and is not available for all merchants.' A capability the operator may not be able to switch on cannot carry a yes on a differentiator-weight claim. (2) The vendor's own account is that duplicates ARE created and then merged by a heuristic that needs human checking, which is not 'without loss or duplicate entries': 'If a merged record is created, the clock in and out times should be reviewed for accuracy and adjusted as needed. Users can tap on the merge icon in the timeclock to note that this record was reviewed.' An earliest-in, latest-out merge can overstate a shift. (3) The single-device case is undocumented: nothing in the corpus says what a clock-in does on one terminal that has itself lost connectivity, or whether that punch queues and replays. Only the multi-device overlap case is addressed. CONTROLS AND POISON, PUBLISHED. THE VOCABULARY TRAP IS PRESENT AND I MEASURED IT: 'time punch' as a phrase is 0 documents corpus-wide and the token punch is only 7 documents (1 inside Shift4 Dine), so a punch-based zero would have been a reader artefact; the vendor's words return 'time clock' 39, timeclock 18, 'clock in' 33, 'clock out' 43 and 'shift merge' 2. SECOND TRAP: in this KB offline overwhelmingly means the CARD-PAYMENT path and not the labour path - the token offline returns 117 documents corpus-wide and 42 inside Shift4 Dine, and of the nine Shift4 Dine articles with Offline in the title, eight are payment articles (Offline Payments Mode Overview and Capabilities, Use Offline Payments Mode, Offline Payments Mode Recovery, Offline Payments Mode Checklist, Configure Shift4 Dine for Offline Payments Mode, Offline Payments Overview and FAQs, Offline Resources, and the Customer-facing Display guidance) and the ninth is Spanish fiscalisation. A pass that read offline as an operating mode of the whole POS would have scored this cell off card-authorisation queueing, a different proposition. THIRD: a clock-vocabulary times connectivity co-occurrence inside Shift4 Dine returns 3 documents and Shift Merge is the only substantive one - the other two are 'you can download a PDF version of the End of Day procedures below for quick reference and offline access', which is a PDF and not the POS. HARNESS AND POSITIVE CONTROLS: every count below was produced by a script written to disk with the Write tool, never inline in a shell string or a heredoc, because shell quoting collapses a regex word boundary to a literal backspace. HTML comments were stripped BEFORE tags, script and style bodies were removed, and a pilcrow was injected at every closing block and table tag so that tag-stripping cannot weld table cells or bold/anchor spans into a false contiguous quote. Positive controls on every run over the 2,174 bodies: Shift4 = 1,130 documents, order = 761, the = 2,133; negative control zzzqqqnonsense = 0. The corpus contains ZERO HTML comments of any length across all 2,174 bodies, so nothing is commented out. Every asserted zero was run twice, once with both word boundaries and once as a left-boundary stem, and where the two disagree I say so. BOUND CORPUS: the 2,174-article anonymous Zendesk Help Center API dump of shift4.zendesk.com (12,518,321 bytes of bodies), of which category 'Shift4 Dine' is 1,031 articles. SHIFT4 DINE IS SKYTAB, and I established it first-hand rather than inheriting it: the release-note series inside that one category runs SkyTab POS v1.119.6, v1.120, v1.121, v1.121.7, v1.122, v1.123.2, v1.124.2 and then, without a version break, Shift4 Dine v1.124.8, v1.125.2, v1.126.2, v1.127.4, v1.128.0; article 11717296534675 'Find the Release Notes for Shift4 Dine' carries an updated_at of exactly 2026-05-12; a Shift4 Dine article instructs the reader to 'Quickly tap on the SkyTab logo five times' (15674547564819); another says 'Shift4 Dine uses an SNBC thermal printer' under the heading 'SkyTab POS SNBC Receipt Printer' (44476146740883); and a Universal Transaction Gateway article lists the Windows service for Shift4 Dine as 'Shift4 SkyTab Interface Service' (1500010285142). Tokenised, the word SkyTab survives in only 30 of 2,174 bodies (116 as a raw substring, the difference being URLs and image filenames), which is a rename artefact and not a scope signal. I did NOT borrow from Legacy POS Solutions (552 articles, Appetize/Salon & Spa/Hospitality/QSR), Micros Center of Excellence, Restaurant Manager, Shift4 Duo, Shift4 One, Shift4Shop or Microsoft Dynamics 365. FRESHNESS IS NOT EVIDENCE HERE: 108 articles share the minute 2026-05-12T12:03, 107 share 12:12, 80 share 12:00 and 79 share 12:15 - that is the dated rename re-save, explicable rather than random, but it still cannot show that any individual article's CONTENT is current, and no finding below leans on updated_at. CORPUS BOUNDING BY HREF FIXPOINT, RE-RUN BY ME: 1,388 distinct /hc/{locale}/articles/<id> ids are referenced inside the raw bytes of the 2,174 held bodies, 1,193 are held and 195 are absent; I probed all 195 at /api/v2/help_center/en-us/articles/<id>.json and got 0 x HTTP 200, 130 x 401 and 69 x 404, with four fabricated 14-digit ids (99999999999999, 88888888888888, 12345678901234, 55555555555555) all returning 404, so a gated 401 is discriminable from a stale 404. Zero unlisted published articles means the published operator set is complete. I recovered a human-readable label for ALL 130 gated ids by pulling the anchor TEXT out of the referring bodies rather than relying on the URL slug (92 of the 130 are referenced by bare id with no slug, so a slug-only triage would have left 92 unlabelled). VIDEO HOLE, NAMED: 168 of 2,174 bodies contain an <iframe> on raw bytes (136 of them inside Shift4 Dine), 189 of the embeds are player.vimeo.com, and the KB's own Lighthouse 2025w49 release notes speak of 'unlocking the full value of our SkyTab video library'. Video-bearing articles carry MORE text than average (median 2,231 characters against 1,594 corpus-wide) and only 17 articles corpus-wide are near-textless, so video supplements the prose rather than replacing it - but no text-only zero over this KB is complete, and I name the in-area video articles per cell below. ATTACHMENTS were censused at /api/v2/help_center/articles/<id>/attachments.json. HOLES SPECIFIC TO THIS CELL: two timeclock-titled Shift4 Dine articles embed Vimeo video I cannot read ('Timeclock Overview on Shift4 Dine' and 'Add a New Shift Using Timeclock Management in Shift4 Dine Customer Hub'), which bears directly on shortfall (3); and three of the 130 gated 401 ids are time-clock adjacent under anchor-text recovery - 360037037413 'Employee Time Clock', 360043203193 'Time clock .' and 360038045614 'QSR Labor & Overtime Settings' - but all three are referenced only from Legacy POS Solutions, the retired and acquired product line, and so cannot bear on SkyTab. Attachment census: 2,174 of 2,174 probed at 200, 15,527 attachments, 20 non-image; the one labour PDF, 'Labor_Report_Example.pdf', hangs off a Legacy POS Solutions article. https://shift4.zendesk.com/hc/en-us/articles/31953171912211-Automatic-Shift-Merge-Overview · retrieved 2026-09-15 adversarially verified

B
Yes

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

Permissions are per job and per discrete action rather than fixed tiers - documented examples include Access to all Tickets, Access Menu Setup (with PIN override), manage/split tickets, refund permission (granted separately per user in the Customer Hub), cash-handling and employee-bank permissions, clock-out restrictions, ticket payment mode by job and default menu type by job. Multi-Location Management adds its own users-and-permissions layer per location. https://shift4.zendesk.com/hc/en-us/articles/16082878610323-Change-Job-Permissions-Settings-on-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

Activity Manager on the workstation and Location Activity Reports for Audits in the Customer Hub provide an activity trail, and exception reports (Void, Refund Details by Employee, BI Discounts/Voids/Refunds alerts) attribute the action to an employee. Shortfall: no article documents that the approving manager on a PIN override is recorded separately from the acting employee, nor that the trail is immutable. https://shift4.zendesk.com/hc/en-us/articles/360035971713-Activity-Manager-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

Workforce Management is Shift4's own scheduling and employee-management product, not a third-party app: departments and sections, schedule templates, split shifts, availability, time-off requests, public holidays, shift opportunities, published schedules and manager/employee mobile apps. Shortfall: it is a separately priced module and a separate application, so scheduling does not sit inside the timekeeping store. Shift4's billing glossary lists 'Workforce Management Fee | STW | $35/MID', the Customer Hub menu 'will open up the new Workforce application', and timekeeping stays on the POS and is copied in - 'Timecards from the Workstation are synced to Workforce Management on a regular basis (approx. every 15 minutes).' https://shift4.zendesk.com/hc/en-us/articles/16039662717331-Workforce-Management-Merchant-FAQs · retrieved 2026-08-03 adversarially verified

B
Partial

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

Sales history feeds scheduling: 'employee, job, and sales data (sales forecasting for scheduling) will automatically sync into Workforce', and Scheduled vs Actual and Sales vs Labor Cost reports close the loop. Shortfall: no article shows recommended staffing levels or labor hours generated by daypart - the forecast is an input to the scheduler's judgement, not a generated staffing recommendation. https://shift4.zendesk.com/hc/en-us/articles/25280976133011-Workforce-Management-Partner-FAQs · retrieved 2026-08-03

B
Partial

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 Attendance shows who is clocked in during service, and the Shift4 InCharge mobile app gives managers live sales off-premise. Shortfall: the labor-cost-as-percentage-of-sales figures live in the Sales vs Labor Cost and Labor Productivity reports, which are run for a period; no article documents a live labor-percentage figure on a manager view during the shift. https://shift4.zendesk.com/hc/en-us/articles/16068840827795-Use-the-Live-Attendance-Feature-in-Workforce-Management · retrieved 2026-08-03

B
Partial

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

Overtime rules are configurable (including Ontario-specific rules and overtime calculation configuration), Workforce Management surfaces Compliance Warnings while building the schedule, and Business Intelligence carries an Overtime Hours alert. Shortfall: the documented enforcement point is scheduling and reporting - no article describes a warning or block presented to the employee at clock-in before the overtime is incurred. https://shift4.zendesk.com/hc/en-us/articles/16167853279635-Set-Overtime-Rules-in-Workforce-Management · retrieved 2026-08-03

B
Partial

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

One jurisdiction is genuinely shipped: Workforce Management 'automatically identifies when a meal break has been missed and applies the extra one hour of pay to the relevant timecard' for California, and Ontario overtime rules have their own configuration article. Break definitions, break pay, penalty hours and a Break Punctuality report all exist. Shortfalls: the rule library is not per-state - the Custom Compliance Rule Groups article documents only how to create a group and assign employees, never tying a group to a jurisdiction or enumerating the available rules - and no break attestation prompt to the employee is documented anywhere. https://shift4.zendesk.com/hc/en-us/articles/12518532550547-California-Missed-Meal-Break-Compliance-on-Workforce-Management · retrieved 2026-08-03 adversarially verified

B
No

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

labor-minor-labor-rules

The Business Labor settings screen is introduced as the jurisdictional-compliance surface - 'The labor settings of the business depend on the employer's state.' - and is then enumerated in full with no age dimension: 'Pay Period (Start of Week)', 'Pay Period Type: Weekly, Biweekly, or Monthly', 'Breaks: Determine if breaks are paid or unpaid', 'Minimum Wage: Set the minimum wage rate', 'Overtime Rules: Determine how to calculate overtime', 'Daily Overtime Thresholds (Hours)', 'Weekly Overtime Thresholds (Hours)' and 'Overtime Multipliers' (updated 2026-05-12). The employee-level fields are likewise enumerated and include no date of birth and no minor flag. Workforce Management's compliance module is break-scoped by its own navigation: 'Select Main Menu > Compliance > Breaks > Custom Rule Groups.', with assignment via 'Navigate to the employee profile at Employees > Employee Name > Compliance' - different break rules per employee group, with no age-based hour cap, prohibited window, school-day limit or clock-in enforcement stated (https://shift4.zendesk.com/hc/en-us/articles/12520941831315-Custom-Compliance-Rule-Groups-on-Workforce-Management, updated 2026-05-21). This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/360035408973-Labor-Time-Clock-Settings-on-the-Workstation-for-Shift4-Dine · retrieved 2026-09-05 adversarially verified

B
Partial

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

Rules are configurable From job to To job with a % Given, computed on Total, Gross or Net tips and filterable by Revenue Class, with multiple rules supported and results shown on the Employee End of Shift Report. Shortfall: the output is a suggestion that a person must key in from the Employee Dashboard Tip Share button, so it does not compute and apply the tip-out by itself; Shift4 lists five Marketplace partners for actual tip pooling and payout. https://shift4.zendesk.com/hc/en-us/articles/29626069064979-Configure-Tip-Share-Suggestions-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Per-shift, per-employee tip records exist - Employee Tip Totals, Employee Shift Summary, Tip Share Suggestions reporting where shared amounts are 'recorded as a reduction of Gross Tips to Net Tips', declared cash tips are editable with a record, and Business Intelligence has Tip Reporting - all exportable. Shortfall: because distribution is entered by hand, the trail records the amounts keyed rather than a pool-in/pool-out ledger. https://shift4.zendesk.com/hc/en-us/articles/29625033253523-Shift4-Dine-Tip-Share-Suggestions-Reporting · retrieved 2026-08-03

B
Partial

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, THREE CONJUNCTS: the payroll export (1) separates cash from charged qualified tips, (2) carries a Treasury tipped-occupation code, and (3) supports W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. VERDICT partial - conjunct one is met and documented, conjuncts two and three are wholly absent, so the verdict is not self-refuting. WHAT IS MET. 'Run Tip Reporting on Business Intelligence' (category Shift4 Dine, section Reports, https://shift4.zendesk.com/hc/en-us/articles/21539348610707-Run-Tip-Reporting-on-Business-Intelligence): 'To access this report, log in to Business Intelligence and select Labor/Payroll > Payroll > Tip Reporting ... The report displays: Cash Sales and reported cash tips / Charge Sales and reported charge tips / Tip percentages for both payment types.' It is framed as a tax instrument - 'This report is a valuable tool for: Payroll accuracy / Tax compliance / Identifying tip-reporting inconsistencies / Reducing financial risk' - with a computed potential-unreported-tips column ('If an employee's cash tip percentage is significantly lower than their charge tip percentage, it may indicate underreporting'). So the cash-versus-charge split is a first-class, documented reporting distinction and not an inference. A dedicated payroll export exists alongside it: 'Reporting Overview in Shift4 Dine' (https://shift4.zendesk.com/hc/en-us/articles/18053470233107-Reporting-Overview-in-Shift4-Dine) enumerates 'Payroll by Employee', 'Payroll by Employee - New', 'Payroll by Employee by Job', 'Payroll Export', 'Employee Tip Totals' and 'Employee Tip Totals - New', and 'Run an Employee Wage Report on Business Intelligence' (https://shift4.zendesk.com/hc/en-us/articles/21925680215187-Run-an-Employee-Wage-Report-on-Business-Intelligence) documents scheduled delivery to 'A payroll service / An accountant / Corporate payroll' with per-employee regular hours, overtime hours, sales totals and tips. The POS also distinguishes declared cash tips at source ('Edit Declared Cash Tips on Shift4 Dine'; the Report Guide's rule that when 'Non-cash Tips Paid as Wages' is on, those tips are excluded from the Cash Expected calculation). SHORTFALLS. (1) No Treasury tipped-occupation code exists anywhere: tokenised over all 2,174 bodies, 'tipped occupation' = 0 documents, 'occupation code' = 0, Treasury = 0. (2) No W-2 field mapping exists: 'W-2' = 0, W2 = 0, 'Box 12' = 0, 'Box 14' = 0. (3) The surrounding statutory vocabulary is equally absent: 'qualified tips' = 0, '4137' = 0, '8027' = 0, 'allocated tips' = 0, FICA = 0, 'tip credit' = 0. (4) The same absence holds in the contracts: tokenised over my own extractions of the Merchant Processing Agreement, the Shift4 Dine POS System Service Agreement, the Shift4 Customer Hub Terms and Conditions, the Gateway Terms and Conditions and the Workforce Terms of Use, tip, tips, gratuity, 'W-2', '8027' and FICA are all 0, and payroll appears only in disclaimers placing payroll and taxes on the merchant. (5) The single 1099 hit in the KB is the Customer Hub's 'Form 1099k' link, which is Shift4's own merchant-level card-settlement reporting and not employee wage reporting. THE ZEROS ARE ABOUT THE STATUTORY CONCEPTS AND NOT ABOUT MY WORDING, because the vendor's adjacent vocabulary is plentiful in the same corpus: payroll = 37 documents, 'cash tips' = 23, 'declared tips' = 6, 'payroll export' = 6, tips = 228. CONTROLS AND POISON, PUBLISHED. THE DECISIVE POISON IS THE RAW-BYTE TRAP AND I REPRODUCED IT ON MY OWN HARNESS: an untokenised regex (10\s*DLC|A2P|Box\s*12|W-?2) over the raw bytes returns 21 documents where the tokenised clean-text probe returns 0. All 21 are false - 'W2' inside Zendesk ULID heading anchors (id="h_01H2RBZ2WSRDK4BJHYYMSBTW2F", id="h_01H034N06DWCYW2ZWSC8FAQ0PD"), inside styled-component CSS class hashes ('sc-1fkmqhw-2'), and inside base64 inline image payloads. Publishing a raw count would have asserted 21 W-2 hits where there are none. SECOND POISON, from the contract side: a whitespace-squashed substring probe reports FICA at 20 hits in the MPA, 9 in the Dine POS SSA and 6 in the Customer Hub terms against a true tokenised count of 0 in all three, matching inside 'specifically', 'identification' and 'notification'; the same probe falsely reports tip 3 times in the MPA. Only tokenised counts are reportable. HARNESS AND POSITIVE CONTROLS: every count below was produced by a script written to disk with the Write tool, never inline in a shell string or a heredoc, because shell quoting collapses a regex word boundary to a literal backspace. HTML comments were stripped BEFORE tags, script and style bodies were removed, and a pilcrow was injected at every closing block and table tag so that tag-stripping cannot weld table cells or bold/anchor spans into a false contiguous quote. Positive controls on every run over the 2,174 bodies: Shift4 = 1,130 documents, order = 761, the = 2,133; negative control zzzqqqnonsense = 0. The corpus contains ZERO HTML comments of any length across all 2,174 bodies, so nothing is commented out. Every asserted zero was run twice, once with both word boundaries and once as a left-boundary stem, and where the two disagree I say so. PDF THREE-INSTRUMENT INVARIANCE, MEASURED BY ME PER DOCUMENT ON 2026-09-15: I re-fetched every contract myself (www.shift4.com answers 429 with a 'Vercel Security Checkpoint' HTML interstitial to a short User-Agent and 200 application/pdf to a full browser UA with Accept, Accept-Language and a Referer of https://www.shift4.com/legal - a bot heuristic, not a bar; note that a naive crawler WRITES THAT INTERSTITIAL TO DISK AS A .pdf, which is a corpus hole, and a fabricated path under /pdf/ returns 404 while a 429 is returned even for fabricated paths, so a 429 discriminates nothing). The ?refresh= query string is a cache-buster only: the MPA fetched with refresh=20260810, with a bogus refresh=19990101 and with no query at all are md5-identical (71bf4fd984f004a58ed62c59a855ca8b), so the cited URL and the bare URL are the same document. I then extracted each PDF with BOTH `pdftotext` and `pdftotext -layout` and compared tokenised counts for 29 terms across eight documents: plain and layout agree EXACTLY on every term in every document, and each quote below was confirmed present under BOTH modes. The known intra-word-space fault is ABSENT from these files (the single-letter-fragment signature is 246 under layout against 254 under plain on the MPA, i.e. layout splits fewer words, not more). POISON PUBLISHED: a whitespace-squashed substring probe, which the brief warns about, is worthless on these contracts - it returns FICA at 20/9/6 across MPA/Customer Hub/Dine POS SSA against a true tokenised count of 0 in all three (it is matching inside 'specifically', 'identification' and 'notification'), 'own' at 19 against a true 3 (inside 'download' and 'known'), and 'cap' at 3/4/5 against a true 0 (inside 'capacity' and 'capital'). Only the tokenised counts are reportable. A second instrument artefact worth recording: a `grep -c` run over a `tr`-flattened layout extraction reported 0 for a phrase that is plainly present in both modes, because form-feed page breaks resplit the stream - the phrase check must be done on the normalised text, not on a shell pipeline. BOUND CORPUS: the 2,174-article anonymous Zendesk Help Center API dump of shift4.zendesk.com (12,518,321 bytes of bodies), of which category 'Shift4 Dine' is 1,031 articles. SHIFT4 DINE IS SKYTAB, and I established it first-hand rather than inheriting it: the release-note series inside that one category runs SkyTab POS v1.119.6, v1.120, v1.121, v1.121.7, v1.122, v1.123.2, v1.124.2 and then, without a version break, Shift4 Dine v1.124.8, v1.125.2, v1.126.2, v1.127.4, v1.128.0; article 11717296534675 'Find the Release Notes for Shift4 Dine' carries an updated_at of exactly 2026-05-12; a Shift4 Dine article instructs the reader to 'Quickly tap on the SkyTab logo five times' (15674547564819); another says 'Shift4 Dine uses an SNBC thermal printer' under the heading 'SkyTab POS SNBC Receipt Printer' (44476146740883); and a Universal Transaction Gateway article lists the Windows service for Shift4 Dine as 'Shift4 SkyTab Interface Service' (1500010285142). Tokenised, the word SkyTab survives in only 30 of 2,174 bodies (116 as a raw substring, the difference being URLs and image filenames), which is a rename artefact and not a scope signal. I did NOT borrow from Legacy POS Solutions (552 articles, Appetize/Salon & Spa/Hospitality/QSR), Micros Center of Excellence, Restaurant Manager, Shift4 Duo, Shift4 One, Shift4Shop or Microsoft Dynamics 365. FRESHNESS IS NOT EVIDENCE HERE: 108 articles share the minute 2026-05-12T12:03, 107 share 12:12, 80 share 12:00 and 79 share 12:15 - that is the dated rename re-save, explicable rather than random, but it still cannot show that any individual article's CONTENT is current, and no finding below leans on updated_at. CORPUS BOUNDING BY HREF FIXPOINT, RE-RUN BY ME: 1,388 distinct /hc/{locale}/articles/<id> ids are referenced inside the raw bytes of the 2,174 held bodies, 1,193 are held and 195 are absent; I probed all 195 at /api/v2/help_center/en-us/articles/<id>.json and got 0 x HTTP 200, 130 x 401 and 69 x 404, with four fabricated 14-digit ids (99999999999999, 88888888888888, 12345678901234, 55555555555555) all returning 404, so a gated 401 is discriminable from a stale 404. Zero unlisted published articles means the published operator set is complete. I recovered a human-readable label for ALL 130 gated ids by pulling the anchor TEXT out of the referring bodies rather than relying on the URL slug (92 of the 130 are referenced by bare id with no slug, so a slug-only triage would have left 92 unlabelled). VIDEO HOLE, NAMED: 168 of 2,174 bodies contain an <iframe> on raw bytes (136 of them inside Shift4 Dine), 189 of the embeds are player.vimeo.com, and the KB's own Lighthouse 2025w49 release notes speak of 'unlocking the full value of our SkyTab video library'. Video-bearing articles carry MORE text than average (median 2,231 characters against 1,594 corpus-wide) and only 17 articles corpus-wide are near-textless, so video supplements the prose rather than replacing it - but no text-only zero over this KB is complete, and I name the in-area video articles per cell below. ATTACHMENTS were censused at /api/v2/help_center/articles/<id>/attachments.json. HOLES SPECIFIC TO THIS CELL: under anchor-text recovery no gated 401 id bears a W-2, tax, payroll or tip-reporting label (the tip-labelled gated ids are PAX SP30 tip-hint configuration and Salon & Spa tips, both outside SkyTab); the attachment census found no payroll or tax PDF for SkyTab among 15,527 attachments, of which only 20 are non-image; and twelve report-titled Shift4 Dine articles embed Vimeo video, so a text-only reading of the reporting suite is not complete. https://shift4.zendesk.com/hc/en-us/articles/21539348610707-Run-Tip-Reporting-on-Business-Intelligence · retrieved 2026-09-15 adversarially verified

B
No

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

Shift4 positions itself as an exporter, not a payroll processor: Workforce Management exports timecards to payroll systems and Shift4 documents a mapping-and-CSV path to Paylocity specifically, while payroll partners (TipHaus, Flexspring, Nory) are listed in the Marketplace under a Payroll category. No tax filing or direct deposit product appears anywhere in the documentation. https://shift4.zendesk.com/hc/en-us/articles/16112010342035-Export-Timecards-to-Payroll-Systems-in-Workforce-Management · retrieved 2026-08-03

B
Partial

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

One named provider is documented end to end - 'Workforce Management allows you to map timecard data to Paylocity payroll codes... export timecards as a CSV file formatted for direct import into Paylocity' - alongside a generic Export Timecards to Payroll Systems article and Payroll by Employee reports. Shortfall: only one payroll provider is named with a documented format; ADP, Gusto, Paychex and QuickBooks are not, and the Marketplace routes payroll to partners instead. https://shift4.zendesk.com/hc/en-us/articles/26650252331923-Export-Workforce-Management-Timecards-to-Paylocity · retrieved 2026-08-03

B
Partial

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

Self-service and approval are both documented: swaps and drops are enabled per department, employees claim open Shift Opportunities from the mobile app, and manager approval is the default with an explicit opt-out - 'use the Auto approve checkbox to allow shift swaps to occur without a manager's approval.' Shortfall: no eligibility enforcement is documented. Nothing states that a swap or claim is blocked or flagged when it would put the employee into overtime, and nothing validates that the claiming employee holds the job or role the shift is scheduled for. https://shift4.zendesk.com/hc/en-us/articles/15938531764115-Enable-Shift-Swaps-Drops-for-a-Department-in-Workforce-Management-United-States · retrieved 2026-08-03 adversarially verified

B
Yes

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

Business Intelligence ships a Server Productivity report plus Employee Cashout, Employee Wage and Tips vs Sales reports, and Product Mix drills to employee to show who sold the most of a given item; the Discounts, Voids and Excess Tips alerts break down by employee for void and comp rates. https://shift4.zendesk.com/hc/en-us/articles/21968263833235-Run-a-Server-Productivity-Report-on-Business-Intelligence · retrieved 2026-08-03

B

Inventory, purchasing & cost control

No

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

The inventory model is enumerated and contains no recipe entity: the Inventory Detail Report's fields are Item Name, Item UPC, Quantity on Hand, Alert Threshold, Cost, Total cost, Price, Total Price and Status, and cost is typed per menu item in the Item Cost field. There is no sub-recipe, prep item or component, so nothing can recalculate a plate cost when an ingredient price moves. https://shift4.zendesk.com/hc/en-us/articles/46477450599059-Inventory-Detail-Report-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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 is counted in menu-item units only (Quantity on Hand against the sellable item, with a single Cost per unit). No purchase unit, recipe unit, count unit or conversion factor field exists in the documented item record, and no yield or waste percentage is applied anywhere. https://shift4.zendesk.com/hc/en-us/articles/46477450599059-Inventory-Detail-Report-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

The Inventory Detail Report 'reflects current inventory levels at the time of generation' and takes no date range at all - 'No date range selection is required for this report'. There is no count period, no receipts ledger and no recipe-derived theoretical usage, so a theoretical-vs-actual variance cannot be produced; Shift4 routes this to Marketplace inventory partners. https://shift4.zendesk.com/hc/en-us/articles/46477450599059-Inventory-Detail-Report-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Quantity on Hand tracks live against sales - the item button greys to Sold Out at zero when 'Allow ordering if quantity is zero' is off, a Low Stock Indicator fires at a configured threshold, counts can display on the login screen, and a reason-coded void can debit stock. Shortfall: depletion is at the sellable-item level only; there are no ingredients, so modifier selections do not deplete anything. https://shift4.zendesk.com/hc/en-us/articles/37736806602899-Item-Inventory-Tracking-Configuration-for-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

Hitting zero does 86 automatically: 'setting an Item to QTY = 0 now automatically means the item is fully 86'd (removed) from Shift4 Dine and Online Ordering.' Shortfalls: the trigger is the sellable item's own count, not a component ingredient, and connected third-party delivery menus are not included - those are snoozed separately in Delivery Management. https://shift4.zendesk.com/hc/en-us/articles/5973606723603-Change-Quantity-on-Hand-Using-Long-Press-for-a-Menu-Item-on-Shift4-Dine · retrieved 2026-08-03

B
No

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

Counting is documented as typing a new Quantity on Hand into the item record on the workstation, the Customer Hub, or via long press at order entry. No full physical count, spot count or scheduled cycle count workflow exists, and no count history is retained - a new value overwrites the old one, which is exactly the correction procedure Shift4 gives for inventory errors. https://shift4.zendesk.com/hc/en-us/articles/37736806602899-Item-Inventory-Tracking-Configuration-for-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

Counts can be adjusted on any terminal or tablet by long-pressing the item at order entry, and a barcode scanner is a supported peripheral with item BIN/search configuration. Shortfall: there is no dedicated counting app, no scan-to-count workflow, and Shift4 warns that configuration changes made while offline will not sync to other stations and may create duplicate records. https://shift4.zendesk.com/hc/en-us/articles/5973606723603-Change-Quantity-on-Hand-Using-Long-Press-for-a-Menu-Item-on-Shift4-Dine · retrieved 2026-08-03

B
No

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

Shift4 Dine has no purchasing module at all - no vendor, purchase order or receiving entity appears in any article - and no broadline distributor is listed. The Marketplace routes procurement to inventory partners (MarketMan, Craftable, Orca, Yellow Dog, Backbar, Restoke AI, BeerBoard, Ideal, Nory, Restaurant365). https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
No

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

No invoice ingestion of any kind exists in Shift4 Dine; the product has no accounts-payable or invoice object. Invoice capture is a Marketplace partner function (MarginEdge, Craftable, Restaurant365, Back Office by Buyers Edge). https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
No

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

Item Cost is a single manually entered figure per menu item with no purchase history behind it - 'each item must be configured with its specific Item Cost. Without these cost settings, the software cannot calculate or report true profitability'. With no invoices and no received prices, there is nothing to compare against a prior or contracted price. https://shift4.zendesk.com/hc/en-us/articles/50322302475923-Item-Profit-Margin-Configuration-and-Report-for-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

A per-item Alert at Amount acts as a minimum threshold and surfaces in the Inventory Detail Report next to Quantity on Hand. Shortfall: it only raises a low-stock indicator - there is no suggested order quantity, no purchase order to generate, and no forecast-driven par mode. https://shift4.zendesk.com/hc/en-us/articles/37736806602899-Item-Inventory-Tracking-Configuration-for-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

inventory-waste-logging

A Void Reason with 'Track Wasted Inventory' enabled debits Quantity on Hand, so waste is captured with a reason code. Shortfall: it is a by-product of voiding a sale rather than a waste workflow, there is no standalone spoilage entry, and no report separates waste cost from usage - Shift4's article exists to help merchants turn the behaviour off after unwanted depletion. https://shift4.zendesk.com/hc/en-us/articles/37741650584339-Void-Item-or-Ticket-Counts-as-Inventory-Loss-in-Shift4-Dine · retrieved 2026-08-03

B
No

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

The inventory record is fully enumerated by the Inventory Detail Report and contains no date field of any kind - no received date, no use-by, no expiry - and there is no receiving workflow in which one could be captured. https://shift4.zendesk.com/hc/en-us/articles/46477450599059-Inventory-Detail-Report-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

inventory-bar-partial-bottle

Scales are supported for selling items by weight at the POS (CAS PD-II, Mettler Toledo Viva, NTEP-certified scales), not for weighing liquor. Beverage control is a distinct Marketplace category Shift4 fills with partners - Barlytics, BarVision, Bevchek, BeerBoard, Pour Controls, US BeerSAVER, Backbar, Craftable - which is positive evidence that partial-bottle counting is not native. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
No

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

There is no period COGS calculation to export - no recipes, no receipts, no count periods - and no GL account mapping exists in the Accounting Overview or the report catalogue. Accounting posting is a Marketplace partner function (Shogo, DAVO, Back Office by Buyers Edge, Restaurant365, Wenodo). https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
No

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

Native inventory is a single Quantity on Hand and a manually typed Item Cost per menu item. Everything the claim describes - recipes, costing, counts, purchasing, variance - is delivered by separately contracted Marketplace partners, of which the installation matrix names eleven in the Inventory or Beverage Control categories including MarketMan, Craftable, Orca, Yellow Dog and Restaurant365. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
Partial

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

The Profit Margin report joins Item Cost to actual sales and gives 'a granular breakdown of your item-level profitability, comparing individual costs against actual sales performance... average sale price and profit margin percentage', explicitly flagging 'where heavy discounting might be eroding your gains'. Shortfalls: the cost is a manually maintained number rather than a recipe roll-up, so it does not move when an ingredient price changes, and no configurable margin threshold raises an alert. https://shift4.zendesk.com/hc/en-us/articles/50322302475923-Item-Profit-Margin-Configuration-and-Report-for-Shift4-Dine · retrieved 2026-08-03

B

Reporting, BI & data access

Yes

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

Two live surfaces: the Customer Hub dashboard with configurable widgets and a Real-Time Transaction Manager, and the Shift4 InCharge mobile app for off-premise managers with ticket search, discounts applied, voids, sales by order type, customer reviews, trend calculations and a Resync InCharge Data action. https://shift4.zendesk.com/hc/en-us/articles/4412936491283-Shift4-InCharge-Mobile-App · retrieved 2026-08-03

B
Yes

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

A full documented EOD sequence - close tickets, adjust tips, count and close drawers/banks, print the Activity and Drawer/Bank Summary, clock out - with published Activity Summary equations, plus End of Day Batch Totals, Settlement, Settlement Detail, Deposit and Till reports in the Customer Hub reconciling sales, tips, tenders and expected deposit. https://shift4.zendesk.com/hc/en-us/articles/47942516286611-End-of-Day-Batch-Totals-Report-on-the-Shift4-Dine-Customer-Hub-United-States-Europe · retrieved 2026-08-03

B
Yes

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

Business Intelligence ships both a Product Mix report and a separate Modifiers Mix report, with Group By and Drill To across departments, menu items, day parts (down to hour and 15-minute intervals), stores and employees; the Customer Hub adds Menu Item Detail and Product Mix Percentage. Revenue centres are a first-class reporting dimension. https://shift4.zendesk.com/hc/en-us/articles/30121981096339-Run-a-Modifiers-Mix-Report-on-Business-Intelligence · retrieved 2026-08-03

B
Yes

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

Void Reports, Discount Details and Discount Summary, Refund Details by Employee, plus Business Intelligence alerts for Discounts, Voids and Refunds that drill from the exception to the ticket detail and the employee, with reason codes configured under Manager > Business > Reasons and timestamps on the ticket record. https://shift4.zendesk.com/hc/en-us/articles/46473145255059-Void-Reports-on-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

Till reports cover till activity, cash in/out and starting and ending balances by employee, alongside Cash Out Details by Employee, the Employee Cashout report in Business Intelligence, employee banks versus cash drawers, and the End of Day count-and-close-drawers flow that produces the over/short figure. https://shift4.zendesk.com/hc/en-us/articles/46406309034387-Till-Reports-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

Business Intelligence ships Labor Productivity and Labor Analysis reports and a Trends - Daily Labor report; Workforce Management adds Sales vs Labor Cost and Scheduled vs Actual; the Customer Hub carries Employee Labor Detail and Payroll by Employee by Job - all driven by the POS time clock. https://shift4.zendesk.com/hc/en-us/articles/21924801791507-Run-a-Labor-Productivity-Report-on-Business-Intelligence · retrieved 2026-08-03

B
Yes

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

Server Productivity plus Tips vs Sales, Employee Tip Totals and Employee Shift Summary give per-server sales, tips as a percentage of sales and shift detail; Product Mix drills to employee for category attachment, and the BI alerts expose void, discount and excess-tip behaviour by server. https://shift4.zendesk.com/hc/en-us/articles/21968263833235-Run-a-Server-Productivity-Report-on-Business-Intelligence · retrieved 2026-08-03

B
Partial

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

Revenue is sliceable by channel: order types are first-class reporting dimensions, InCharge shows Sales by Order Type, revenue centres and revenue classes segment further, and completed online orders have their own Customer Hub report. Shortfall: nothing nets marketplace commission or marketing fees out of third-party revenue, so margin by marketplace cannot be produced. https://shift4.zendesk.com/hc/en-us/articles/42500578746643-View-Item-Count-for-Departments-Revenue-Classes-and-Order-Types-on-Reports · retrieved 2026-08-03

B
Yes

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

Any Customer Hub report can be subscribed with locations, recipient email list, Frequency (Monthly with day, Weekly with day, Daily with Last Day or Current Day), send time, Export Type of CSV, PDF or XLS and a custom subject line; Business Intelligence has its own Schedule a Report function. https://shift4.zendesk.com/hc/en-us/articles/16081142713619-Run-Subscribe-to-Reports-in-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

Shift4's only public API is the gateway API, and its object list is exhaustively payments: Charges, Refunds, Customers, Cards, Subscriptions, Plans, Payment Methods, Tokens, Payment Links, Disputes, Fraud Warnings, Blacklist, Events, Payouts, Credits, Charge Splits, File Uploads, Checkout. There is no order, check, menu, item or employee resource, so POS data is not reachable; auth is HTTP Basic with a secret key rather than scoped credentials. https://dev.shift4.com/docs/api · retrieved 2026-08-03 adversarially verified

A
Partial

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

Scored from the webhooks feature page, not the API index. Webhook URLs are configured in account settings, each pinned to live or test mode, and Shift4 POSTs the event as JSON to that URL. Retry IS documented: 'Failed webhook requests are resent with an increasing delay between each attempt', with strict in-order delivery so a failing event blocks every later event for that URL until it succeeds. Shortfalls: no payload signature or shared-secret verification is offered anywhere - the page instead instructs you to use only the event identifier from the request and re-fetch the object from the API, and to record processed event ids yourself against replay; and there are no order lifecycle events, because the complete Types of Events list in the reference (CHARGE_*, REFUND_UPDATED, CUSTOMER_*, PLAN_*, CREDIT_*, FRAUD_WARNING_*, PAYOUT_*, PAYMENT_METHOD_*, PAYMENT_LINK_*, CHARGE_SPLIT_*) contains no order, check or ticket object. https://dev.shift4.com/docs/webhooks · retrieved 2026-08-09

A
Partial

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

URL NOT previously held. Same evidence base as extensibility-api-access-cost, and partial for the same reason. Included-by-default signals: API credentials are one ordinary Customer Hub role permission - 'Manage Developer Settings', described as 'Access and configure developer-facing settings, such as API credentials or webhook configuration' - and raw-data access is documented as a standard reporting-surface action, with a published field-level spec (Settlement Report CSV Extract Specification, # updated 2026-07-06) and portal exports 'Download .CSV or Download .XLSX' from Transaction Manager and the Reports tab. Neither exhaustive fee schedule carries an API, data-export or reporting-access line item. Against a full yes: no document states inclusion affirmatively; a $20 Shift4 Dine Customer Hub Fee exists for 'premium Shift4 Dine Customer Hub features'; and the background Download Center is still gated - 'This feature is currently available only for Pilot users.' Grade B, not A: this is vendor product documentation, and the fee question is properly answered by the merchant agreement behind the 429 wall. https://shift4.zendesk.com/hc/en-us/articles/43022018641043-User-Permissions-in-the-Shift4-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

Core reports - EOD, PMIX at item level, voids/discounts, till, labor detail, payroll - are in the Customer Hub report set available to every merchant. Shortfall: the deep analytics layer is a separately sold module. Business Intelligence has its own onboarding, its own users and permissions, and appears as a purchasable service in the Grow My Business hub alongside Website, SkyTab Air and other add-ons, and it is where PMIX drill-down, hierarchies, labor analysis and the alerting live. https://shift4.zendesk.com/hc/en-us/articles/42615093852051-Use-Grow-My-Business-to-Add-Services-to-the-Shift4-Customer-Hub · retrieved 2026-08-03

B
Partial

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 partial. WHAT IS MET. A 24-month rolling retention window for transaction-level financial reporting data is expressly published, and the truncation is documented rather than silent. Shift4 Gateway Terms and Conditions section 24.23, 'Transaction History Retention Period' (https://www.shift4.com/pdf/Gateway-Terms-and-Conditions.pdf?refresh=20241101, re-fetched by me 2026-09-15 at HTTP 200 application/pdf): 'Subject to Section 18 (Data in SHIFT4's Care), SHIFT4 will store Merchant's financial reporting data for a maximum of twenty-four (24) months post-settlement; this will be a rolling period where the most recent months will be maintained and the data for any month earlier than twenty-four (24) will be deleted.' Section 24.27 'Transaction Data Retention' repeats it: 'SHIFT4 will store Merchant's Transaction data based on a rolling calendar, which means that Transaction data will be purged after the period stated.' The same figure is corroborated independently inside the Help Center from the query side: 'Find Missing Transactions in Transaction Manager (United States)' (category Transaction Manager, https://shift4.zendesk.com/hc/en-us/articles/1500010168641-Find-Missing-Transactions-in-Transaction-Manager-United-States) tells the operator that on Advanced Search 'leave this blank, and it will look back through two years (to date) of transactions', and that a transaction absent from Transaction Manager 'Is deleted after two years'. That is transaction-level detail, queryable, at exactly the 24 months the claim names, and the deletion is stated rather than silent. SCOPE, JUSTIFIED RATHER THAN ASSUMED: both instruments are Shift4 platform-wide rather than SkyTab-branded, and I rely on them because SkyTab ships them - 'Shift4 Dine Customer Hub Real-Time Transaction Manager' (category Shift4 Dine, https://shift4.zendesk.com/hc/en-us/articles/27781412213779-Shift4-Dine-Customer-Hub-Real-Time-Transaction-Manager) says 'Transaction Manager is a comprehensive tool in Shift4 Dine Customer Hub that enables merchants to effortlessly locate, analyze, and compare' transactions, and 33 Shift4 Dine articles route the operator into Transaction Manager for refunds, tip adjustments, split-check adjustments and online-order voids. SHORTFALLS. (1) THE ARCHIVE FEE THE CLAIM EXPRESSLY DISQUALIFIES IS PRESENT. Section 24.23 continues: 'If Merchant wishes to increase or decrease its Transaction History Retention Period, Merchant may ask to do so at an additional fee, but the ability to do so is subject to Merchant's particular Integration and business requirements and may not be practicable.' Section 24.24 adds 'SHIFT4 will retain historical data for a limited time only and has no obligation to retain historical data without compensation.' (2) It is a maximum, not a floor: 'a maximum of twenty-four (24) months' with monthly purging, so the claim's 'at least 24 months' is met only at the boundary and only while the merchant keeps settling. (3) SkyTab's own reporting documentation states no window anywhere. 'Reporting Overview in Shift4 Dine' (category Shift4 Dine, https://shift4.zendesk.com/hc/en-us/articles/18053470233107-Reporting-Overview-in-Shift4-Dine) enumerates the whole report set - Financial Overview, Cash Out Details by Employee, Customer Directory, Day to Day Comparison, Discount Details, Employee Labor Detail, Employee Shift Detail, Employee Tip Totals, Hourly Sales, Inventory Detail, Menu Item Detail, Net Tender Type Summary, Payroll by Employee, Payroll Export, Profit Margin, Refund Details by Employee, seven Sales Summary variants, Tax Detail, Ticket Summary and Till Detail - and says only 'Select a report that you'd like to generate, adjust the date and times as needed, then select Generate Report.' The 'Shift4 Dine Customer Hub Report Guide' (https://shift4.zendesk.com/hc/en-us/articles/46334059307539-Shift4-Dine-Customer-Hub-Report-Guide) and 'Shift4 Dine Customer Hub Reports Overview' (https://shift4.zendesk.com/hc/en-us/articles/360042964093-Shift4-Dine-Customer-Hub-Reports-Overview) are equally silent. (4) The windows SkyTab DOES surface are much shorter and are not reconciled with the 24 months: the Business Intelligence date selector offers a closed list topping out at 'Last Year' ('Yesterday / This Week / Last Week / Live / Month to Date / Last Month / Year to Date / Last Year'); the Customer Hub Location Overview shows only 'Past 7 Days of Batches' (https://shift4.zendesk.com/hc/en-us/articles/36286134504851-View-Batch-and-Processing-Reports-in-the-Shift4-Dine-Customer-Hub); Transaction Manager Quick Search states 'Only the previous seven days are searched'; and Customer Hub exports expire ('Files remain available for 7 days', 'Use the Download Center in the Shift4 Customer Hub'). (5) A genuine silent-truncation behaviour of another kind is documented: 'Day Part reporting is only available for sales generated AFTER Day Parts were created for the reporting location (MID). Day Parts assignments are NOT retroactive for historical sale data' (Day Parts Reporting and Revenue Center Reporting, both category Shift4 Dine). (6) The other contracts undercut the commitment: the Shift4 Customer Hub Terms and Conditions promise only 'a reasonable period of time' to extract Account Data, the Privacy Policy (effective 2026-07-22) says 'We generally retain your information as long as reasonably necessary', and the Workforce Terms of Use disclaim retention in capitals - 'ANY DATA, INCLUDING ACCOUNT HISTORY AND USER CONTENT RESIDING ON OUR SERVERS, MAY BE DELETED, ALTERED, MOVED OR TRANSFERRED AT ANY TIME FOR ANY REASON IN OUR SOLE DISCRETION, WITH OR WITHOUT NOTICE AND WITH NO LIABILITY OF ANY KIND.' CONTROLS AND POISON, INCLUDING A CORRECTION OF THE PRIOR PASS. The prior proposal published 'two years = 0' and '24 months = 0'; those figures were computed inside the Shift4 Dine category and are FALSE corpus-wide - tokenised over all 2,174 bodies 'two years' is 2 documents, and one of them is the Transaction Manager article that resolves this cell. Tokenised retention is 6 documents corpus-wide and NOT ONE concerns data retention: three are Salon & Spa and Appetize booking software in category Legacy POS Solutions where 'Retention Type' is a guest-acquisition UI field, one is loyalty-points copy ('Points can be added or subtracted ... including ... retention purposes'), and one is PHYSICAL HARDWARE - 'Bump Bar Installation and Setup' instructs 'Route the cable under the retention clip.' A published count on the word retention would have been meaningless in both directions. Vendor-vocabulary counts instead: 'date range' = 92 documents corpus-wide and 46 in Shift4 Dine, history = 71/20, historical = 19/12, archived = 13/4, retained = 9/7, purge = 3/2 - and every purge hit in Shift4 Dine is a POWER purge (hold the power button for 30 seconds), not a data purge. '12 months' = 2 documents, both other products (an Appetize statements page and a Transaction Manager fraud-scan window). HARNESS AND POSITIVE CONTROLS: every count below was produced by a script written to disk with the Write tool, never inline in a shell string or a heredoc, because shell quoting collapses a regex word boundary to a literal backspace. HTML comments were stripped BEFORE tags, script and style bodies were removed, and a pilcrow was injected at every closing block and table tag so that tag-stripping cannot weld table cells or bold/anchor spans into a false contiguous quote. Positive controls on every run over the 2,174 bodies: Shift4 = 1,130 documents, order = 761, the = 2,133; negative control zzzqqqnonsense = 0. The corpus contains ZERO HTML comments of any length across all 2,174 bodies, so nothing is commented out. Every asserted zero was run twice, once with both word boundaries and once as a left-boundary stem, and where the two disagree I say so. PDF THREE-INSTRUMENT INVARIANCE, MEASURED BY ME PER DOCUMENT ON 2026-09-15: I re-fetched every contract myself (www.shift4.com answers 429 with a 'Vercel Security Checkpoint' HTML interstitial to a short User-Agent and 200 application/pdf to a full browser UA with Accept, Accept-Language and a Referer of https://www.shift4.com/legal - a bot heuristic, not a bar; note that a naive crawler WRITES THAT INTERSTITIAL TO DISK AS A .pdf, which is a corpus hole, and a fabricated path under /pdf/ returns 404 while a 429 is returned even for fabricated paths, so a 429 discriminates nothing). The ?refresh= query string is a cache-buster only: the MPA fetched with refresh=20260810, with a bogus refresh=19990101 and with no query at all are md5-identical (71bf4fd984f004a58ed62c59a855ca8b), so the cited URL and the bare URL are the same document. I then extracted each PDF with BOTH `pdftotext` and `pdftotext -layout` and compared tokenised counts for 29 terms across eight documents: plain and layout agree EXACTLY on every term in every document, and each quote below was confirmed present under BOTH modes. The known intra-word-space fault is ABSENT from these files (the single-letter-fragment signature is 246 under layout against 254 under plain on the MPA, i.e. layout splits fewer words, not more). POISON PUBLISHED: a whitespace-squashed substring probe, which the brief warns about, is worthless on these contracts - it returns FICA at 20/9/6 across MPA/Customer Hub/Dine POS SSA against a true tokenised count of 0 in all three (it is matching inside 'specifically', 'identification' and 'notification'), 'own' at 19 against a true 3 (inside 'download' and 'known'), and 'cap' at 3/4/5 against a true 0 (inside 'capacity' and 'capital'). Only the tokenised counts are reportable. A second instrument artefact worth recording: a `grep -c` run over a `tr`-flattened layout extraction reported 0 for a phrase that is plainly present in both modes, because form-feed page breaks resplit the stream - the phrase check must be done on the normalised text, not on a shell pipeline. BOUND CORPUS: the 2,174-article anonymous Zendesk Help Center API dump of shift4.zendesk.com (12,518,321 bytes of bodies), of which category 'Shift4 Dine' is 1,031 articles. SHIFT4 DINE IS SKYTAB, and I established it first-hand rather than inheriting it: the release-note series inside that one category runs SkyTab POS v1.119.6, v1.120, v1.121, v1.121.7, v1.122, v1.123.2, v1.124.2 and then, without a version break, Shift4 Dine v1.124.8, v1.125.2, v1.126.2, v1.127.4, v1.128.0; article 11717296534675 'Find the Release Notes for Shift4 Dine' carries an updated_at of exactly 2026-05-12; a Shift4 Dine article instructs the reader to 'Quickly tap on the SkyTab logo five times' (15674547564819); another says 'Shift4 Dine uses an SNBC thermal printer' under the heading 'SkyTab POS SNBC Receipt Printer' (44476146740883); and a Universal Transaction Gateway article lists the Windows service for Shift4 Dine as 'Shift4 SkyTab Interface Service' (1500010285142). Tokenised, the word SkyTab survives in only 30 of 2,174 bodies (116 as a raw substring, the difference being URLs and image filenames), which is a rename artefact and not a scope signal. I did NOT borrow from Legacy POS Solutions (552 articles, Appetize/Salon & Spa/Hospitality/QSR), Micros Center of Excellence, Restaurant Manager, Shift4 Duo, Shift4 One, Shift4Shop or Microsoft Dynamics 365. FRESHNESS IS NOT EVIDENCE HERE: 108 articles share the minute 2026-05-12T12:03, 107 share 12:12, 80 share 12:00 and 79 share 12:15 - that is the dated rename re-save, explicable rather than random, but it still cannot show that any individual article's CONTENT is current, and no finding below leans on updated_at. CORPUS BOUNDING BY HREF FIXPOINT, RE-RUN BY ME: 1,388 distinct /hc/{locale}/articles/<id> ids are referenced inside the raw bytes of the 2,174 held bodies, 1,193 are held and 195 are absent; I probed all 195 at /api/v2/help_center/en-us/articles/<id>.json and got 0 x HTTP 200, 130 x 401 and 69 x 404, with four fabricated 14-digit ids (99999999999999, 88888888888888, 12345678901234, 55555555555555) all returning 404, so a gated 401 is discriminable from a stale 404. Zero unlisted published articles means the published operator set is complete. I recovered a human-readable label for ALL 130 gated ids by pulling the anchor TEXT out of the referring bodies rather than relying on the URL slug (92 of the 130 are referenced by bare id with no slug, so a slug-only triage would have left 92 unlabelled). VIDEO HOLE, NAMED: 168 of 2,174 bodies contain an <iframe> on raw bytes (136 of them inside Shift4 Dine), 189 of the embeds are player.vimeo.com, and the KB's own Lighthouse 2025w49 release notes speak of 'unlocking the full value of our SkyTab video library'. Video-bearing articles carry MORE text than average (median 2,231 characters against 1,594 corpus-wide) and only 17 articles corpus-wide are near-textless, so video supplements the prose rather than replacing it - but no text-only zero over this KB is complete, and I name the in-area video articles per cell below. ATTACHMENTS were censused at /api/v2/help_center/articles/<id>/attachments.json. HOLES SPECIFIC TO THIS CELL: 'Reporting Overview in Shift4 Dine' itself embeds Vimeo video, as do 11 other report-titled Shift4 Dine articles, so a text-only reading of the reporting suite is incomplete; and under anchor-text recovery the only reporting-labelled gated 401 ids are 'Reporting Overview | Report' and 'Email Report', both referenced solely from Legacy POS Solutions, plus two Transaction Manager mReports articles. https://www.shift4.com/pdf/Gateway-Terms-and-Conditions.pdf?refresh=20241101 · retrieved 2026-09-15 adversarially verified

B
Partial

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

Business Intelligence has a dedicated Alerts section covering 'Discounts, Voids, Refunds, Long Ticket Times, Excess Tips, High Ticket Amount, and Overtime hours', each drilling to the ticket and employee, with a tip-percentage threshold held in the database. Shortfalls: they are screens the operator must open rather than proactive push or email, and the Long Ticket Times threshold is not self-serve - 'To set the long ticket time, a request for support is required.' https://shift4.zendesk.com/hc/en-us/articles/21688656732947-View-Alerts-on-Business-Intelligence · retrieved 2026-08-03

B
No

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

Shift4's restaurant analytics product describes its own interaction model as structured drill-down, in a promotional feature article dated 2026-04-17 that would have every reason to advertise an assistant: 'Business Intelligence integrates all aspects of your business intelligence, allowing you to access any data point from yesterday using our Group By and Drill To features.', 'Pivot Tables for Smarter Prep' and 'Custom Charts, Reports & Dashboards' - 'Create and save your own reports in the Favorites Section'. Two near-misses rejected. 'Merchant Guide to Conversational Voice Assistant' is genuinely natural-language but is Shift4's support phone router - 'just speak naturally and tell us what you need in your own words. Our system will analyze your request and automatically route your call to the department best equipped to handle your needs' - and returns no figure or chart against the operator's own data. 'Query Builder Overview in Harbortouch Retail' is a structured builder in a sibling product and is excluded on both counts. This URL is not currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/38852779680531-Business-Intelligence-Key-Features · retrieved 2026-09-05 adversarially verified

C
Partial

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

Customer Reports give a Customer Directory with 'contact information and visit history' and Customer Item Sales for per-guest purchasing analysis, and Business Intelligence has a Sales/Guests section. Shortfall: no new-versus-returning counts, no visit-frequency distribution and no lifetime-spend cohorts are produced - the operator gets the underlying rows, not the cohort analysis. https://shift4.zendesk.com/hc/en-us/articles/46509565887507-Customer-Reports-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

The Trends - Daily Sales report computes Projected Sales from the location's own history using a published formula (a five-period average) and Shift4 positions it to 'Schedule labor appropriately... Plan prep and inventory', with the forecast consumable by Workforce Management scheduling. Shortfall: the granularity is a day, not a daypart or hour, and the method is a moving average rather than a model. https://shift4.zendesk.com/hc/en-us/articles/21968656710547-Run-a-Trends-Daily-Sales-Report-on-Business-Intelligence · retrieved 2026-08-03

B
Yes

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

Declared cash tips are editable and recorded, charged tips are reported separately, Tip Share amounts show as the reduction from Gross to Net tips per employee, Employee Tip Totals and Payroll by Employee carry the figures into payroll, and Business Intelligence Tip Reporting plus the Tips vs Sales report cover the shift-level detail. https://shift4.zendesk.com/hc/en-us/articles/21539348610707-Run-Tip-Reporting-on-Business-Intelligence · retrieved 2026-08-03

B

Multi-location, franchise & enterprise governance

Yes

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

Multi-Location Management is a true three-level object model - Enterprise, Group and Location - where selecting a level sets the Current Level context for viewing, creating and editing, with an Ownership column governing edit rights per row and an Overrides Only filter. Business Intelligence carries its own three-level reporting hierarchy (e.g. District Manager, Regional Manager, Director of Operations) that reports group and drill to. https://shift4.zendesk.com/hc/en-us/articles/37651000033427-Navigate-Multi-Location-Management-Hierarchy · retrieved 2026-08-03

B
Yes

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

multi-location-central-menu-publish

'menu data is created at the enterprise level and automatically shared across all locations', with an explicit publish action to the workstation, documented data inheritance and override rules, location-level override visibility (a blue dot on overridden fields, an override count per row at Enterprise level) and enterprise authoring of items, modifiers, modifier sets, pre-modifiers, departments, courses, order types, tenders, discounts, taxes, surcharges, gratuities and revenue classes. https://shift4.zendesk.com/hc/en-us/articles/37651549332627-Publish-Changes-From-Multi-Location-Management-to-the-Workstation · retrieved 2026-08-03

B
Partial

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

One item record can carry different prices per location through the Enterprise/Location override model, and Dynamic Pricing in Multi-Location Management adds day-part and revenue-centre price schedules without duplicating the item. Shortfall: there is no named price tier or zone object applied to a location group, and channel pricing is not part of it - online and third-party prices are maintained in Menu Manager and Delivery Management separately. https://shift4.zendesk.com/hc/en-us/articles/43076584598419-Configure-Dynamic-Pricing-and-Menu-Availability-and-Dynamic-Pricing-in-Multi-Location-Management · retrieved 2026-08-03

B
Yes

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

Customer Hub reports accept multiple locations in one run ('You can select multiple locations for this report'), and Business Intelligence groups by hierarchy level and drills to the locations beneath it - 'Select the row for Fisher and drill to locations' - with Locations setup, account switching and Comparison and KPI reports for store-versus-store. https://shift4.zendesk.com/hc/en-us/articles/22904914748307-Set-up-or-Delete-Hierarchies-on-Business-Intelligence · retrieved 2026-08-03

B
Yes

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

Multi-location gift programs are set up explicitly at onboarding ('one central gift card website where customers can purchase gift cards that are redeemable across all participating locations') and the Cross-Usage report exists precisely for settlement: 'who owns the gift cards, the owner of the sale of gift cards, and where gift cards were used... allows your accounting department to allocate the funds correctly for each participating location.' Outstanding balances come from the Gift Card Balance report. https://shift4.zendesk.com/hc/en-us/articles/7041630069139-Shift4Gift-Reporting-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

First-party and Shift4 Dine-scoped ('Loyalty is exclusively available on Shift4 Dine'). The cross-location half is stated outright rather than inferred: 'As part of our loyalty program, we have a separate loyalty record from their customer record, which will be pooled across all our locations. This allows us to offer program-specific benefits and rewards and gather more detailed information about member behavior and preferences across different locations.' and 'The landing page for members displays key points of data for each member gathered from all locations in the program.' (updated 2026-05-12). The programme-spans-locations half: 'The locations included in the loyalty program' is one of the three things a Loyalty Program controls, and 'If the user has multiple locations, programs can be made for each location, or they can be part of a single program.', corroborated in https://shift4.zendesk.com/hc/en-us/articles/16075743302547-Add-a-Loyalty-Program-on-the-Shift4-Dine-Customer-Hub - 'If your Shift4 Dine Customer Hub account is tied to more than one location, select the location or locations for your program.' Membership is programme-scoped, not location-scoped: 'The name of the loyalty program for this member. If the member is in multiple programs, a new record will be shown for each program.' (https://shift4.zendesk.com/hc/en-us/articles/16076256115859-View-and-Add-Loyalty-Members-on-Shift4-Dine-Customer-Hub) Constraint noted, not disqualifying: 'Each location can only be assigned to one program'. Neither URL is currently in claims.jsonl. https://shift4.zendesk.com/hc/en-us/articles/16166684069011-Loyalty-Overview-for-the-Workstation-on-Shift4-Dine · retrieved 2026-09-05 adversarially verified

B
Partial

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

Shift4 Dine-scoped: step one is 'Log in to the Shift4 Dine Customer Hub and select' the 'Delivery Management' module, and it is the freshest article in this batch at 2026-07-07. Virtual brands on shared hardware are a named, documented capability: 'Learn to add virtual or ghost kitchen concepts to your account on Delivery Management by creating additional merchants and configuring each with its own name, settings, and POS connection.', with the flow 'Type in the Virtual Location name.', 'Select your POS locations using the checkboxes, then select Continue' and 'The POS will resync the menu to the new virtual (ghost) location. From here, configure the menu for your new location.' That is a separate merchant identity and a separate menu against the same physical POS location. Partial rather than yes because the documentation stops there: no per-brand receipt branding and no per-brand revenue segregation is stated anywhere, and the eleven-step flow contains no such step. https://shift4.zendesk.com/hc/en-us/articles/46678091259923-Add-a-Virtual-Location-on-Delivery-Management · retrieved 2026-09-05 adversarially verified

B
Yes

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

Taxes are created and managed per location in Multi-Location Management, with hidden (inclusive) tax setup, filter taxes by order type, separate tax line printing, item-level tax exemptions on delivery menus, documented Canadian tax requirements and VAT handling, and full Spanish fiscalization including consumer receipt QR verification and fiscal reporting. https://shift4.zendesk.com/hc/en-us/articles/42239518027667-Configure-Tax-Settings-in-Multi-Location-Management · retrieved 2026-08-03

B
Partial

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

Workforce Management holds Custom Compliance Rule Groups, per-department break and overtime rules, holiday rates and penalty hours, and 'automatically configures a merchant's Compliance Rules based on their location'. Shortfall: rules are organised by department within a location rather than by location group from an above-store console, and enforcement is documented at scheduling and reporting rather than at the terminal. https://shift4.zendesk.com/hc/en-us/articles/12520941831315-Custom-Compliance-Rule-Groups-on-Workforce-Management · retrieved 2026-08-03

B

Hardware & physical footprint

No

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

Every documented client device is a Shift4-supplied unit identified by model - the Elys L1400 workstation, the M8 tablet, the named handheld, the A3700 customer-facing display, PAX A35/Q25 PIN pads and the Shift4 Duo A800/A930 - provisioned through PAXSTORE with Shift4 P2PE and remote key injection pushed by Shift4. No article contemplates installing the POS app on an operator-purchased iPad or Android tablet. https://shift4.zendesk.com/hc/en-us/articles/45643837558163-Shift4-Dine-Hardware-Glossary-and-Identification-Guide · retrieved 2026-08-03

B
Partial

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

Device specifications are published per model (workstation, handheld, tablet, customer-facing display, kiosk, bump bar, charging station) with dimensions, displays, connectivity and environmental ratings, and the platform is evidently Android (PAXSTORE, Android Settings, 'Allow Install Unknown Apps', 'Display Over Other Apps'). Shortfall: no article names the client operating system or a minimum OS version - the OS is implied by troubleshooting steps rather than stated, and no supported-version matrix exists. https://shift4.zendesk.com/hc/en-us/articles/4410565401747-Shift4-Dine-Device-Specifications · retrieved 2026-08-03

B
Yes

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 device with an integrated reader and published specs: 173.8 x 80.2 x 17.4 mm, 305 g, 6.5-inch 1600x720 touchscreen, EMV dip, magstripe and contactless including Apple Pay, Google Pay and Interac Flash, dual-band Wi-Fi, Bluetooth, 4G LTE, fast charging and a documented operating range of -10C to 50C. A grab-and-go charging station has its own specification and FAQ articles. https://shift4.zendesk.com/hc/en-us/articles/41246927844883-Handheld-Specifications · retrieved 2026-08-03

B
Partial

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

Shift4 publishes a shift-life claim - 'Long-lasting, all-day battery life (no mid-day recharges needed)' - and ships a grab-and-go bay charging station with its own specifications. Shortfall: the claim is qualitative rather than a rated hours figure, and no hot-swappable or field-replaceable battery is documented (the published dimensions are quoted as including the battery). https://shift4.zendesk.com/hc/en-us/articles/41246927844883-Handheld-Specifications · retrieved 2026-08-03

B
Yes

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

hardware-handheld-lte

The published handheld specification lists Connectivity Options of 'Wi-Fi (2.4GHz and 5GHz), Bluetooth, 4G LTE (Supports bands compatible with Canadian carriers)' - cellular is built into the device rather than a separate failover appliance. https://shift4.zendesk.com/hc/en-us/articles/41246927844883-Handheld-Specifications · retrieved 2026-08-03

B
Yes

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

Terminals keep trading with the internet down - card payments store and forward, cash and printing continue, 'local network, printers, Kitchen Display System... will work as long as the local network is connected' - and Shift4 publishes the degradations explicitly: pre-authorizations and refunds disabled, Customer-facing Display cannot take payment, Shift4 Duo unsupported, Customer Hub may show unauthorised payments as approved, and cross-station config sync stops. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Yes

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

A first-party KDS with its own hardware packing list, versioned release notes through v1.33, bump bar, station routing by assigned items and modifiers, multi-stage fulfillment, prep-time pacing, ticket timers, all-day views, split views, guest notifications and a Spanish UI - not an integration dependency. https://shift4.zendesk.com/hc/en-us/articles/4940326008723-Configure-a-Kitchen-Display-System-for-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

First-party kiosk with published specifications, installation guide, A35 PIN pad for unattended EMV, configurable order flows and tips, order numbers, an Order Again feature and a merchant dashboard, running the same Menu Manager menu. Shortfalls: only one form factor is documented (no countertop versus freestanding split), no ADA or accessibility conformance is published, and Shift4 states the kiosk does not support loyalty and cannot be assigned to revenue centres. https://shift4.zendesk.com/hc/en-us/articles/45874024285715-Kiosk-Specifications · retrieved 2026-08-03

B
Partial

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

One of the three named hardware classes is documented, and only through a marketplace partner: Clarity from Creative Realities gives 'Centralized control over drive-thru boards, interior displays, and self-order kiosks' with menu data synced from Shift4 Dine (updated 2026-06-02); the Marketplace Integration Partner Installation Matrix (48443488325651, updated 2026-06-30) lists CRI, Evergreen and DsMenu (MoogX) under 'Digital Menu Boards'. The other two fail outright: an anchored corpus-wide search for headset, speaker post and intercom returns ZERO hits in 2,162 articles, as does order confirmation display / OCD. No speed-of-service or drive-thru timer measurement exists for Shift4 Dine. Menu boards yes; order confirmation displays, headsets and timers no. https://shift4.zendesk.com/hc/en-us/articles/52136495149715-Enable-Clarity-in-the-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

Third-party printers from more than one class are documented by model: the Epson TM-L100 label printer with its own install and configuration articles, the Epson U220 impact printer down to DIP switch settings, plus a Shift4 S80 receipt printer, network kitchen printers, printer groups, per-item printer assignment and margin and character-per-line settings. Shortfall: there is no published compatibility list of supported ESC/POS models, and the receipt and kitchen printers shipped with the system are Shift4-supplied units ordered through the Customer Hub. https://shift4.zendesk.com/hc/en-us/articles/28300946989715-Install-and-Connect-the-Epson-TM-L100-Label-Printer-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
Yes

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

The full peripheral set is documented with install and configure articles each: cash drawers (with additional-key ordering and per-job cash handling), barcode scanners (including discount-by-barcode scan), scales for by-weight items (CAS PD-II, Mettler Toledo Viva, NTEP-certified models, plus manual weight entry without a scale), customer-facing displays, label printers, caller ID and TP-Link networking gear. https://shift4.zendesk.com/hc/en-us/articles/46050806655123-Use-Scales-Weighted-Items-on-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

Card entry happens on PAX PTS devices running a Shift4 P2PE application with remote key injection pushed from PAXSTORE using the Shift4_P2Pe template, so the encryption boundary is in the reader. Shortfall: Shift4 never states the merchant's resulting SAQ type in the merchant-facing documentation, and no PCI-listed P2PE solution reference was retrievable. https://shift4.zendesk.com/hc/en-us/articles/17273697856019-Download-Apps-From-PAXSTORE-for-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
No

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

Same test and same result as payments-softpos-tap-to-pay; the two cells are near-duplicates. No Tap-to-Pay-on-iPhone, Tap-to-Pay-on-Android, SoftPOS or Tap-on-Phone string exists in the 2,162-article help centre or in any of the 30 dev.shift4.com pages. The documented phone-based flow is the reverse direction: 'enables guests to complete payments securely and contactlessly using their smartphones' by scanning a QR code. Commodity-phone acceptance would be a hardware/marketing claim and skytab.com is walled (429), but the help centre documents every other acceptance mode in device-level detail (contactless EMV sale procedures, PIN pad markings 'Card/Chip/Contactless'), so its silence here is meaningful rather than merely a floor. https://shift4.zendesk.com/hc/en-us/articles/47508407357843-Use-QR-Pay-on-Handheld-for-Secure-Mobile-Payments · retrieved 2026-09-05 adversarially verified

B
No

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

hardware-pricing-transparency

URL NOT previously held by the record. Hardware ordering (# updated 2026-08-11) runs entirely inside the authenticated merchant portal and the price is never shown publicly: 'Select Orders > Hardware from the left navigation menu (located near the bottom)' ... 'It will be charged to your account and reflected on your monthly statement.' The internal branch is explicit that the price list is an internal artefact: 'please refer to the pricing matrices in the form and ensure the merchant is aware of the fee being incurred.' What IS published is not a per-SKU purchase price but a recurring tiered device fee - 'PA1: $9.99 PA2: $19.99 PA3: $39.99 PA4: $29.99/$35.99*' and 'PO1: $29.99 PO2: $49.99 PO3: $79.99' - where PA4 covers KDS, Customer-facing Display, Kiosk, Handheld and Tablet indiscriminately. skytab.com is unreachable (429) and was not fetched; the verdict rests on the vendor's own documented ordering flow, not on that wall. https://shift4.zendesk.com/hc/en-us/articles/15046423648147-Order-Hardware-for-Shift4-Dine-and-Employee-ID-Cards-Using-the-Shift4-Dine-Customer-Hub-United-States · retrieved 2026-09-05 adversarially verified

B
Partial

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

The billing glossary describes an equipment model built on recurring fees rather than purchase: the Annual Service & Maintenance Fee 'covers the lifetime replacement of your credit card processing devices... This fee is nominal for covering upfront equipment with lifetime no-cost replacements compared to purchasing equipment.' Shortfall: no article states whether outright purchase is available as an alternative, and the SkyTab POS System Service Agreement, which would settle it, returns HTTP 403. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-08-03

B
Partial

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

Shift4 documents no post-cancellation hardware policy at all. What is documented cuts the other way: terminals are provisioned and controlled through Shift4's PAXSTORE tenancy with Shift4 P2PE keys remotely injected, app updates pushed by Shift4, remote support access and device deactivation (e.g. 'Manually Deactivate Kiosk'), and the equipment fee model is framed around Shift4 replacing devices rather than the merchant owning them. https://shift4.zendesk.com/hc/en-us/articles/17273697856019-Download-Apps-From-PAXSTORE-for-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

Shift4's own billing glossary states the program: 'The Annual Service & Maintenance Fee covers the lifetime replacement of your credit card processing devices if they malfunction or need upgrading to the latest model, including overnight shipping.' Shortfall: it is a fee-funded replacement program with a shipping method rather than a published warranty term and a stated advance-exchange turnaround SLA, and it is scoped to card-processing devices. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-08-03

B
No

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

hardware-byod

Staff-facing ordering and payment runs only on enumerated Shift4 devices - workstation, tablet, handheld, Duo - all provisioned via PAXSTORE with injected P2PE keys. The only app documented for a personal phone is the Workforce Management employee app for schedules and timecards, which takes no orders and no payments. https://shift4.zendesk.com/hc/en-us/articles/45643837558163-Shift4-Dine-Hardware-Glossary-and-Identification-Guide · retrieved 2026-08-03

B
Partial

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

Real capability exists: the Notification Center reports operational status per subsystem including local network state, Shift4 pushes app updates to workstations, PAXSTORE handles remote key injection and push history, Remote Support Access and AirViewer allow remote control of a terminal, and a Gold Standard article publishes the current version of every Shift4 product. Shortfall: this is assembled from several tools, most of them Shift4-operated, rather than one merchant-facing console listing every terminal, printer and KDS as online or offline with remote reboot and staged rollout. https://shift4.zendesk.com/hc/en-us/articles/28924051492883-Notification-Center-Operational-Status-Feature-for-Shift4-Dine · retrieved 2026-08-03

B
No

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

Scale support is for selling items by weight at the POS, not for beverage pouring. Shift4 fills the beverage category entirely with Marketplace partners - Barlytics, BarVision, Bevchek, BeerBoard, Pour Controls, US BeerSAVER - which is positive evidence that flow meters, tap walls and pour spouts posting to a tab are not native. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
Yes

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 supported peripheral with install, connect and configure articles for the workstation and a 'Utilize Caller ID in Shift4 Dine' usage article, working against the POS customer database that also holds order history and the Duplicate Ticket reorder path. https://shift4.zendesk.com/hc/en-us/articles/18236480278675-Install-and-Connect-Caller-ID-on-the-Workstation-for-Shift4-Dine · retrieved 2026-08-03

B

Integrations, API & extensibility

Partial

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

extensibility-public-api-docs

dev.shift4.com is fully public, readable without an NDA or sales call, and documents authentication, test and live keys, error handling and every gateway object. Shortfall: it is the payments gateway only. No POS API reference exists publicly - Marketplace partners such as Loman AI, Otter, MarketMan and Delivery Management plainly read orders and menus, but that interface has no published documentation, so a developer cannot read how POS data is accessed. https://dev.shift4.com/docs/api · retrieved 2026-08-03

A
Partial

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

extensibility-api-access-cost

URL NOT previously held. Partial, not yes: API credentials are an ordinary role permission inside the standard Customer Hub, not a plan upgrade - the Developers permission group carries exactly one entry, 'Manage Developer Settings', described as 'Access and configure developer-facing settings, such as API credentials or webhook configuration' (# updated 2026-08-20). dev.shift4.com is open self-signup ('Log in to Dev Sign up') and the API reference says only 'Once logged in, you can find your API keys in your account settings', naming no fee. Both exhaustive published fee schedules - End-to-End (2026-07-08) and Gateway Only (2026-07-31), which itemise fees down to $0.005 per transaction - contain NO API-access line item. But no document AFFIRMATIVELY states API access is included at no additional per-location fee, and the same schedule does show a $20 Shift4 Dine Customer Hub Fee whose own note says it is for 'premium Shift4 Dine Customer Hub features', so a premium gate on adjacent surfaces exists. This is an absence inside an exhaustive fee schedule, which supports partial and not yes. The merchant service agreement (www.shift4.com/pdf/SkyTab-POS-System-Service-Agreement.pdf) would settle it and is behind the 429 wall. https://shift4.zendesk.com/hc/en-us/articles/43022018641043-User-Permissions-in-the-Shift4-Customer-Hub · retrieved 2026-09-05 adversarially verified

B
Partial

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

extensibility-free-sandbox

Payments side: 'each account has two modes: test mode and live mode. Each mode has its own set of public and secret keys', and the Testing page supplies a full bank of test values - 20 success cards, validation-error and processing-error cards, dispute cards (4242000000000018 chargeback), fraud-check cards and 3D Secure cards - so a payment integration can be exercised end to end. Shortfalls: those are test inputs, not a seeded environment, and the keys come from an account's settings, with dev.shift4.com/signup returning a 403 Cloudflare interstitial so self-serve account creation could not be confirmed. On the POS side there is no self-serve sandbox at all - the demo MID is partner-gated, 'Authorized Shift4 Dine Partners (SP Office Codes only) will have a Demo MID automatically created when their sales office is onboarded', additional MIDs go through the Partner Demo MID form after a BlueStacks/MuMu Player emulator install and require a terminal serial number, and seeded content is a favour ('You can also request the Product Demo menu copied to your MID'). https://dev.shift4.com/docs/testing · retrieved 2026-08-09

A
Partial

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

The install flow behaves like an operator-granted authorization: the merchant is redirected to the Customer Hub, logs in, and is told to 'Review the requested permissions and select Allow to grant InhouseDelivery access to Online delivery orders', selecting the specific location; each integration has a documented Uninstall that revokes it. Shortfall: no OAuth 2.0 specification, scope list, token model or revocation endpoint is published anywhere, and the gateway API itself uses HTTP Basic with a shared secret key rather than OAuth. https://shift4.zendesk.com/hc/en-us/articles/48279511185299-Install-a-Marketplace-Integration-Directly-in-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
No

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

extensibility-webhooks-push

Order lifecycle webhooks cannot exist because the public API has no order object: its resources are Charges, Refunds, Customers, Cards, Subscriptions, Plans, Payment Methods, Tokens, Payment Links, Disputes, Fraud Warnings, Blacklist, Events, Payouts, Credits, Charge Splits and File Uploads. Events cover payment objects only, and no POS-side webhook documentation exists in any Shift4 source. https://dev.shift4.com/docs/api · retrieved 2026-08-03

A
Partial

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

Weak proposal killed: the page exists but the cell is conjunctive and one prong is affirmatively absent. Retry WITH backoff: satisfied verbatim - 'Failed webhook requests are resent with an increasing delay between each attempt.' Replayable event log: satisfied - the API reference documents 'List Events' at 'GET https://api.shift4.com/events' with created gt/gte/lt/lte filters and startingAfterId/endingBeforeId cursors, plus 'Retrieves an existing event object' at GET /events/{EVENT_ID}. Cryptographic signature: NOT satisfied. There is no HMAC, no signing secret and no signature header for webhooks anywhere on the page or in the 3M-character API reference; grepping the reference for signature/HMAC/signing returns hits only for Checkout Request signing ('Checkout Request signature is created using HMAC with SHA256') and for a customerSignature dispute file-upload field. Shift4 documents an explicit ALTERNATIVE to signing: 'For security reasons, you should only use the event identifier from the webhook request and obtain the remaining data by making a direct request to the Shift4 API', and handles replay by merchant-side bookkeeping - 'it is advised to record which events were processed and never process the same event twice.' Note also a reliability liability the cell does not ask about but an operator should know: 'when event delivery fails for a given webhook URL, then delivery of all other events for that webhook URL will be blocked until that failed delivery is successfully retried.' Record already cites dev.shift4.com/docs/webhooks (no trailing slash); re-fetched live at 200 on 2026-09-05. https://dev.shift4.com/docs/webhooks/ · retrieved 2026-09-05 adversarially verified

A
Partial

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

Externally originated orders demonstrably become first-class tickets - Loman AI phone orders 'Appear in Shift4 Dine as an online order; route to the correct kitchen display automatically', and DoorDash, Uber Eats and Grubhub orders inject the same way and land in reporting. Shortfall: there is no public write API. The path exists only for approved Marketplace partners; a merchant or an unlisted developer has no documented way to post an order. https://shift4.zendesk.com/hc/en-us/articles/51910521192979-Enable-Loman-AI-in-the-Customer-Hub · retrieved 2026-08-03

B
Partial

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

extensibility-menu-write-api

Menus are demonstrably writable by partners - Delivery Management creates and edits Marketplace menus, items and modifiers, Menu Manager imports from the POS and pushes to channels, and Loman AI keeps a live copy in sync. Shortfall: no menu write API is published; every documented path is a Shift4-operated console or an approved partner integration. https://shift4.zendesk.com/hc/en-us/articles/53429637702803-Create-a-Marketplace-Menu · retrieved 2026-08-03

B
Yes

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 features-completed count against the eight high-quality features the program requires. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is the instrument the program page points to when it says the roster is tracked in real time, and it 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, not a ceiling. In that registry this vendor is the entry `shift4`, rendered as 'Shift4', with qualityStatus PREFERRED and 8 of the 8 high-quality features built. TWO Shift4 entries exist and they are different SKUs: this one is PROVIDER_AGGREGATION_TYPE_POS, 8 of 8 features, and its own providerPortalLink is https://www.skytab.com/ — which is what settles that the PREFERRED entry is SkyTab. The other, `xdine_production` ('Shift4/XDine'), is a MIDDLEWARE_AGGREGATOR at 3 of 8 features and only CERTIFIED, and its portal link is shift4.com. 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

B
Yes

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

DoorDash (US, CA, IE, GB), Uber Eats (US, CA, IE, GB) and Grubhub (US) are each listed as direct Marketplace integrations with Shift4-authored installation guides, plus Deliveroo and DoorDash Drive. Middleware is optional and listed separately, so none of the three requires a paid aggregation layer. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03 adversarially verified

B
Yes

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

extensibility-middleware-compatibility

Shift4 Dine is a supported endpoint for multiple aggregators: Deliverect has its own Enable Deliverect in the Customer Hub article, and Otter is listed in the installation matrix under Online Ordering & Delivery (Partner Redirect, US and CA), alongside TechRyde, Appfront, Delivery Collective and others. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
Partial

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

Multiple accounting destinations are reachable and installable from the Customer Hub - Shogo, DAVO Automated Sales Tax, Back Office by Buyers Edge, Restaurant365, Wenodo - so posting to QuickBooks and others is a solved problem in practice. Shortfall: none is a Shift4-built, Shift4-maintained connector with mapped journal entries; QuickBooks is reached through the third-party Shogo layer, and the native Accounting Overview in the Customer Hub is a reporting view rather than a GL integration. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
Partial

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

extensibility-payroll-export

Paylocity is documented natively with payroll-code mapping and a direct-import CSV, and TipHaus and Flexspring appear in the Marketplace under Payroll. Shortfall: only one payroll provider has a documented native export format; the generic 'Export Timecards to Payroll Systems' article does not name a second provider with a mapped format. https://shift4.zendesk.com/hc/en-us/articles/26650252331923-Export-Workforce-Management-Timecards-to-Paylocity · retrieved 2026-08-03

B
Yes

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

extensibility-app-marketplace

A public integrations marketplace at shift4.com/marketplace, browsable and self-installable from the Customer Hub, with roughly seventy named partners across Online Ordering, Delivery, Inventory, Beverage Control, Labor, Payroll, Accounting, Marketing, Reservations, Digital Menu Boards, Security, Business Intelligence and Kiosk, plus a documented install/uninstall flow and a named set of referral-only partners. Shift4 states 'Marketplace Cost: Free Shift4 integration!' https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
Partial

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

Third-party front ends do drive the Shift4 transaction record in practice: Pye Kiosk is a listed Marketplace kiosk partner, and multiple third-party online-ordering partners (ChowNow, Menufy, Appfront, ToGo Technologies, Brygid, FOLOS) inject orders into the POS. Shortfall: there is no documented headless or embedded mode, no published API for it, and no article describing a third-party UI driving the POS transaction engine directly. https://shift4.zendesk.com/hc/en-us/articles/48443488325651-Marketplace-Integration-Partner-Installation-Matrix · retrieved 2026-08-03

B
Partial

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

One genuine exit artifact is documented: on request Shift4 produces a token export file carrying PAN, expiry, cardholder name, street address and postal code for handover to a new processor or POS/PMS, initiated through Support or an Enterprise Account Manager. Shortfall: it covers card tokens only. Orders, menu and customers leave as per-report CSV/Excel/PDF downloads, there is no bulk or API export, and no contract term establishing an on-demand complete export at contract end is readable - the service agreement PDF returns HTTP 403. https://shift4.zendesk.com/hc/en-us/articles/43269556571027-Token-Migration · retrieved 2026-08-03

B

Reliability, offline & operations

Yes

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

reliability-offline-order-entry

'Will my local network, printers, Kitchen Display System, etc., work in Offline Mode? These will work as long as the local network is connected.' Order entry, kitchen routing and check printing are local-network operations on the workstation, and Offline Payments mode is designed to keep service running with minimal user interaction. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Yes

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

reliability-offline-card-auth

Store-and-forward is documented in detail: transactions 'are stored on the device until the connection is re-established', EMV chip and PIN 'will continue to function as it is in online mode' on PAX devices, digital wallets work offline, storage is good for up to two days, and the queue drains one transaction every two minutes on reconnect. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03 adversarially verified

B
Partial

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

A per-transaction cap is configurable (Offline Transaction limit) and failures surface - pending items older than 24 hours raise a cross-terminal notification naming the storing device and total value, and unauthorised transactions 'require manual intervention'. Shortfall: no cumulative offline cap is published, and Shift4 never states who absorbs the loss when a stored transaction declines; the corresponding FAQ directs the merchant to Support instead. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Partial

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

Terminals share ticket state over the LAN - 'Open tickets made in the last 3 days populate on the Open Tickets screen and will sync to the other Shift4 Dine Workstation' - and printers and KDS keep working while the internet is down. Shortfall: Shift4 warns that offline configuration edits do not propagate and 'creating multiple duplicate records across stations may cause issues when normal syncing resumes', and offline card payments are advised to be closed on the terminal that took the original authorization. https://shift4.zendesk.com/hc/en-us/articles/360033804054-Manage-Tickets-on-Shift4-Dine · retrieved 2026-08-03

B
Partial

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

There is clearly local state - each device stores its own offline transactions and retries them, tickets sync station to station over the LAN, and the KDS holds a database that can be backed up and restored to 'the Server' on the Display. Shortfall: no article documents an on-premise transaction engine or edge server as an architectural component, names it, or states which station holds the authoritative record. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Yes

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

reliability-offline-kds-printing

Stated directly in the offline FAQ: local network, printers and the Kitchen Display System 'will work as long as the local network is connected', with the Notification Center exposing local network status so staff can tell the difference between an internet outage and a LAN failure. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Partial

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

The automatic half is documented verbatim: 'FAILOVER PRINTER : Select a backup printer from the dropdown. If the primary printer is unavailable, the failover printer will automatically handle print jobs' (updated 2026-06-16); Manage Printers and Kitchen Displays in Multi-Location Management (46609843289875, 2026-05-12) confirms 'Failover printer assignment' is a live Workstation setting. The alert half fails: no Shift4 Dine article documents any notification when a printer is unreachable. The only printer-failure alerting in the whole corpus is ChefTab, a different product, dated 2023, which offers a 'Printer Error Notification' that will 'Notify the user when printer errors are encountered.' Shift4 Dine's own printer-failure article is a manual troubleshooting flow -- 'send a receipt printer test print. If the test print fails, reseat the receipt printer USB cable' (38745992918547). https://shift4.zendesk.com/hc/en-us/articles/34668850853139-Shift4-Dine-Printer-and-Receipt-Settings · retrieved 2026-09-05 adversarially verified

B
Partial

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

Shift4 does document the partition risk and gives operational guidance: offline configuration edits 'will be saved on the POS where they were made... no other stations will have these changes synced, and creating multiple duplicate records across stations may cause issues when normal syncing resumes.' Shortfall: that is a warning, not a stated resolution policy - no last-write-wins, merge or operator-prompt behaviour is defined, and a separate article exists for resolving locked tickets. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Yes

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

An explicit exclusion list is published: 'During Offline Mode, the following features are unavailable: Pre-Authorizations, Refunds, Shift4 Dine Customer Hub Data Syncing', plus Shift4 Duo devices unsupported, Customer-facing Display payments unavailable ('use the onboard reader instead'), unsynced menu edits, and a caution that Customer Hub reports may show unauthorised offline payments as approved. There is a whole Shift4 Dine Offline Resources index and an offline checklist. https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs · retrieved 2026-08-03

B
Yes

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

reliability-public-status-page

A public, no-login status page listing 70+ components including Shift4 Dine (with regional and per-feature sub-components), Cloud POS Services, API, Payments Platform, Card Processing, kiosk, mobile ordering, gift (Givex) and named upstream processors (TSYS, First Data, Elavon, Worldpay, Chase, Heartland, Moneris), with email, SMS, Slack and RSS subscription for incidents and maintenance. https://status.shift4.com/ · retrieved 2026-08-03

B
Partial

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

24/7 live support exists - Workforce Management's FAQ says 'Our dedicated support team is available 24/7... via phone, email, or live chat', and articles route merchants to Shift4 Support by phone or chat throughout. Shortfall: Shift4's own billing glossary lists it as a chargeable line, not a base inclusion: 'Monthly Premium Support & Service Fee - Fee covering a large scope of support and service-related functions including 24/7 phone-based support, local on-site technical support.' Account Maintenance support is separately documented as Monday-Friday 8am-8pm EST. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-08-03

B
Yes

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

On-site installation is a documented part of the model: a Customer Site Readiness Guide prepares the venue for the install visit, the Shift4 Dine Installation and Configuration Guide and initialization steps are written for an installer, and the billing glossary names 'local on-site technical support' as a covered service. https://shift4.zendesk.com/hc/en-us/articles/19349224790675-Shift4-Customer-Site-Readiness-Guide · retrieved 2026-08-03

B
Yes

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

reliability-menu-build-service

Shift4's programming team performs the build: 'Once you submit your menu, we'll email you when it's built. Most menu builds take about a week, but programming also works orders by install date', and a Pre-Launch Specialist will gather the data for merchants who cannot upload it themselves. The Menu Submission Guide sets the input format - full food and alcohol menus as .pdf, .doc, .png or .jpeg with 'All item prices and descriptions... visible', or an Excel/Word listing - and quotes a 2-3 week turnaround for a new concept requiring a new MID. https://shift4.zendesk.com/hc/en-us/articles/31810517896851-Launch-Control-FAQs · retrieved 2026-08-03 adversarially verified

B
Partial

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

reliability-hardware-replacement-sla

'The Annual Service & Maintenance Fee covers the lifetime replacement of your credit card processing devices if they malfunction or need upgrading to the latest model, including overnight shipping.' Shortfall: overnight shipping is a method, not a stated end-to-end turnaround, no advance-exchange process is described, and the coverage is written around card-processing devices rather than every terminal, KDS screen and printer. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-08-03

B
Partial

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

Shift4 maintains a Security and Compliance category whose stated purpose is 'This page will provide our certificate of attestation and other documentation on our PCI compliance', alongside PCI DSS Roles and Responsibilities and a merchant-facing PCI programme. Shortfall: the attestation articles render as embedded documents with no readable text, version or date; the only named AoC in the category belongs to SecurionPay; and nothing states PCI DSS v4.0/4.0.1 or the post-March-2025 future-dated requirements. https://shift4.zendesk.com/hc/en-us/articles/4406698996243-PCI-DSS-Requirement-12-8-Service-Provider-Management · retrieved 2026-08-03

B
Yes

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

reliability-mfa-role-based-access

Two-factor authentication is enabled from Customer Hub Profile & Settings, sensitive account maintenance (bank account, profile, contacts) forces a one-time-password verification with a three-attempt lockout, and role-based permissions run per user in the Customer Hub, per job on the workstation and per user in Multi-Location Management. Screen lock and auto-logout are configurable per station. https://shift4.zendesk.com/hc/en-us/articles/360040643034-Set-up-and-Use-Two-Factor-Authentication-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

reliability-self-serve-training

A large free public training library: Merchant Training Quick Reference Guides for every module (POS, Customer Hub, KDS, handheld, kiosk, CFD, Business Intelligence, Website Builder, Online Ordering, Workforce, Multi-Location) localised for US, Canada, UK, Ireland and Spain, Employee and Manager Essentials collections, and a video section linked from most articles. A practice mode exists too - Demo Mode on the KDS and InCharge, and a documented demo MID with a MuMu Player emulator. https://shift4.zendesk.com/hc/en-us/articles/32113692677907-Merchant-Training-Quick-Reference-Guides · retrieved 2026-08-03

B
No

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 or server role automatically if the designated primary terminal or local server fails. VERDICT no. WHAT IS MET: nothing, because SkyTab documents no master terminal, no designated primary and no on-premise POS server, and therefore documents no mechanism by which a role could be assumed. WHAT THE DOCUMENTATION DOES DESCRIBE, stated neutrally rather than as a defence: every Workstation is documented as an independent peer behind a router, synchronising over a message bus and against the cloud. 'Merchant Network Troubleshooting Guide on the Workstation for Shift4 Dine' (category Shift4 Dine, section Errors and Troubleshooting, https://shift4.zendesk.com/hc/en-us/articles/38741077173267-Merchant-Network-Troubleshooting-Guide-on-the-Workstation-for-Shift4-Dine) branches its remediation as 'Red Bar on All Workstations' versus 'One or More Workstations Have a Red Bar' and 'Yellow Bar on All Workstations' versus 'One or More Workstations Have a Yellow Bar', and its port table names the synchronisation transport as '5672 / RabbitMQ / Synchronization'; the LAN diagram runs ISP modem to router to switch to POS hub to Workstations, with no node identified as a server. 'Configure Cloud and Local Settings in Manager Settings' (category Shift4 Dine, https://shift4.zendesk.com/hc/en-us/articles/55395971270547-Configure-Cloud-and-Local-Settings-in-Manager-Settings) states the propagation model: 'Cloud Settings in Manager Settings are accessible through the web and the Workstation. Changes apply to all stations once they are published', and 'Local Settings in Manager Settings automatically sync to all stations at the location in the background.' The offline FAQ states per-station independence: 'Individual devices or stations can go offline while others remain connected' (https://shift4.zendesk.com/hc/en-us/articles/4416200518931-Shift4-Dine-Offline-Payments-Overview-and-FAQs). 'Notification Center Operational Status Feature for Shift4 Dine' (https://shift4.zendesk.com/hc/en-us/articles/28924051492883-Notification-Center-Operational-Status-Feature-for-Shift4-Dine) enumerates the connections the product itself treats as critical - 'Local Network / Internet Connection / Lighthouse Connect / Payments' - and a primary terminal is not among them. SHORTFALLS. (1) No role, and so no role assumption. Tokenised word-boundary counts across the 1,031 Shift4 Dine articles: master = 0, 'primary terminal' = 0, 'main terminal' = 0, 'lead terminal' = 0, 'local server' = 0, 'back office server' = 0, 'file server' = 0, 'main station' = 0, 'primary station' = 0, 'main POS' = 0, node = 0, quorum = 0, takeover = 0, 'take over' = 0, redundancy = 0, 'high availability' = 0. (2) The word primary DOES occur 28 times in Shift4 Dine and I read every hit: they are a primary reporting LOCATION for time-zone purposes, a primary recipient email, a primary transaction amount, primary table statuses, primary filters on reports, and a 'FAILOVER PRINTER ... if the primary printer is unavailable' - not one is a primary terminal. Likewise designated = 11 and every hit is a designated backup printer or a designated primary location. (3) Nothing states what happens to shared state if the peer holding an open ticket is lost, so the claim's underlying question is not answered in either direction by any published article. CONTROLS AND POISON, PUBLISHED. The token failover returns exactly 4 documents corpus-wide and EVERY ONE would have inverted this cell if counted rather than read: 'FAILOVER PRINTER: Select a backup printer from the dropdown. If the primary printer is unavailable, the failover printer will automatically handle print jobs' (Shift4 Dine Printer and Receipt Settings), 'Failover Printer: Designate a backup printer to print if the primary printer is offline' (Hardware Settings on the Workstation), 'Failover printer assignment' (Manage Printers and Kitchen Displays in Multi-Location Management), and an EMV fallback - 'If inserted incorrectly 3 times, the Tablet will failover to use the Magnetic Strip on the card.' A hit count scores this claim yes off a receipt printer. SECOND: the zero on master is bounded, not an artefact - master returns 15 documents across the whole corpus (a 'Hardware Master List' category and a Gold Standard Matrix guide), and the LEFT-BOUNDARY STEM of master returns 7 documents inside Shift4 Dine where the both-boundaries token returns 0, and all 7 are Mastercard; Workstation returns 354 Shift4 Dine documents, which proves I am searching the right product with the right noun. THIRD: standalone and stand-alone return 8 Shift4 Dine documents and none is architectural (the Standalone terminals product line, the standalone Workforce app, a '3DS Standalone' event status, check presenters not sold 'as a standalone add-on', Handheld's planned 'additional standalone functionality', and combo children's 'individual standalone prices'). FOURTH: 'peer to peer' returns 1 document and it is a Kitchen Display System release-note performance item, and 'local sync' returns 2, one being a 'Local sync server' setting that belongs to Salon and Spa in category Legacy POS Solutions - a different, retired product, and precisely the sibling-product trap. I deliberately imported nothing from Legacy POS Solutions, Micros Center of Excellence, Restaurant Manager, Shift4 Duo or Shift4 One, several of which DO describe local sync servers and terminal roles. HARNESS AND POSITIVE CONTROLS: every count below was produced by a script written to disk with the Write tool, never inline in a shell string or a heredoc, because shell quoting collapses a regex word boundary to a literal backspace. HTML comments were stripped BEFORE tags, script and style bodies were removed, and a pilcrow was injected at every closing block and table tag so that tag-stripping cannot weld table cells or bold/anchor spans into a false contiguous quote. Positive controls on every run over the 2,174 bodies: Shift4 = 1,130 documents, order = 761, the = 2,133; negative control zzzqqqnonsense = 0. The corpus contains ZERO HTML comments of any length across all 2,174 bodies, so nothing is commented out. Every asserted zero was run twice, once with both word boundaries and once as a left-boundary stem, and where the two disagree I say so. BOUND CORPUS: the 2,174-article anonymous Zendesk Help Center API dump of shift4.zendesk.com (12,518,321 bytes of bodies), of which category 'Shift4 Dine' is 1,031 articles. SHIFT4 DINE IS SKYTAB, and I established it first-hand rather than inheriting it: the release-note series inside that one category runs SkyTab POS v1.119.6, v1.120, v1.121, v1.121.7, v1.122, v1.123.2, v1.124.2 and then, without a version break, Shift4 Dine v1.124.8, v1.125.2, v1.126.2, v1.127.4, v1.128.0; article 11717296534675 'Find the Release Notes for Shift4 Dine' carries an updated_at of exactly 2026-05-12; a Shift4 Dine article instructs the reader to 'Quickly tap on the SkyTab logo five times' (15674547564819); another says 'Shift4 Dine uses an SNBC thermal printer' under the heading 'SkyTab POS SNBC Receipt Printer' (44476146740883); and a Universal Transaction Gateway article lists the Windows service for Shift4 Dine as 'Shift4 SkyTab Interface Service' (1500010285142). Tokenised, the word SkyTab survives in only 30 of 2,174 bodies (116 as a raw substring, the difference being URLs and image filenames), which is a rename artefact and not a scope signal. I did NOT borrow from Legacy POS Solutions (552 articles, Appetize/Salon & Spa/Hospitality/QSR), Micros Center of Excellence, Restaurant Manager, Shift4 Duo, Shift4 One, Shift4Shop or Microsoft Dynamics 365. FRESHNESS IS NOT EVIDENCE HERE: 108 articles share the minute 2026-05-12T12:03, 107 share 12:12, 80 share 12:00 and 79 share 12:15 - that is the dated rename re-save, explicable rather than random, but it still cannot show that any individual article's CONTENT is current, and no finding below leans on updated_at. CORPUS BOUNDING BY HREF FIXPOINT, RE-RUN BY ME: 1,388 distinct /hc/{locale}/articles/<id> ids are referenced inside the raw bytes of the 2,174 held bodies, 1,193 are held and 195 are absent; I probed all 195 at /api/v2/help_center/en-us/articles/<id>.json and got 0 x HTTP 200, 130 x 401 and 69 x 404, with four fabricated 14-digit ids (99999999999999, 88888888888888, 12345678901234, 55555555555555) all returning 404, so a gated 401 is discriminable from a stale 404. Zero unlisted published articles means the published operator set is complete. I recovered a human-readable label for ALL 130 gated ids by pulling the anchor TEXT out of the referring bodies rather than relying on the URL slug (92 of the 130 are referenced by bare id with no slug, so a slug-only triage would have left 92 unlabelled). VIDEO HOLE, NAMED: 168 of 2,174 bodies contain an <iframe> on raw bytes (136 of them inside Shift4 Dine), 189 of the embeds are player.vimeo.com, and the KB's own Lighthouse 2025w49 release notes speak of 'unlocking the full value of our SkyTab video library'. Video-bearing articles carry MORE text than average (median 2,231 characters against 1,594 corpus-wide) and only 17 articles corpus-wide are near-textless, so video supplements the prose rather than replacing it - but no text-only zero over this KB is complete, and I name the in-area video articles per cell below. ATTACHMENTS were censused at /api/v2/help_center/articles/<id>/attachments.json. HOLES SPECIFIC TO THIS CELL, AND WHY THE CELL IS STILL no RATHER THAN unknown: one gated 401 id is in this subject area - 360042707254, anchored as 'Sync Troubleshooting' and referenced from Shift4 Dine - and one absent id that returns 404, 17636025574803 'Resolve POS Terminal is Not on Correct Subnet', is also network material from Shift4 Dine. I have not dropped the cell to unknown for these because this no does not rest on silence: it rests on a sixteen-term vocabulary census over 1,031 articles PLUS the vendor positively naming a different mechanism (a RabbitMQ bus, cloud-published settings, per-station independence, and a closed enumeration of critical connections that omits any terminal role), and a single support-agent troubleshooting article cannot reverse that. ZERO network-, server- or architecture-titled Shift4 Dine articles carry a video embed, so the video hole does not reach this cell. Attachment census: 15,527 attachments, 20 non-image, no SkyTab architecture or deployment document among them. https://shift4.zendesk.com/hc/en-us/articles/38741077173267-Merchant-Network-Troubleshooting-Guide-on-the-Workstation-for-Shift4-Dine · retrieved 2026-09-15 adversarially verified

B
Partial

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

reliability-cellular-backup

The handheld ships 4G LTE alongside dual-band Wi-Fi in its published specification. Shortfall: no cellular failover is documented for the workstation, tablet, KDS or customer-facing display - the networking guidance is Wi-Fi best practices, a TP-Link router, switch and Omada access point - and no automatic failover behaviour is described even for the handheld. https://shift4.zendesk.com/hc/en-us/articles/41246927844883-Handheld-Specifications · retrieved 2026-08-03

B

Commercial, compliance & data ownership

No

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

Shift4's SkyTab POS System Service Agreement is a multi-year term, not month-to-month. Reforming Retail quotes the agreement's 30-day trial provision - 'Merchant may cancel the Service Agreement without any penalty within thirty (30) calendar days from the Effective Date' - and describes the underlying term as 'typically three years or longer' with early termination priced on anticipated future profits. Shift4's own PDF at www.shift4.com/pdf/SkyTab-POS-System-Service-Agreement.pdf returns HTTP 403 to this environment, so the vendor-primary text could not be read directly. https://reformingretail.com/index.php/2025/12/30/to-catch-a-predator-shift4-termination-fees/ · retrieved 2026-08-03

E
No

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

commercial-no-early-termination-fee

An early termination charge plainly exists. Reforming Retail documents a merchant invoiced a $45,000 cancellation fee after attempting to cancel, and describes Shift4 computing termination fees from anticipated profits over the remaining term. This is third-party reporting, not the contract text: the SkyTab POS System Service Agreement PDF 403s to this environment, so the liquidated-damages clause itself was not read first-hand. https://reformingretail.com/index.php/2025/12/30/to-catch-a-predator-shift4-termination-fees/ · retrieved 2026-08-03

E
Yes

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

The terms are genuinely published: the SkyTab POS System Service Agreement Terms and Conditions is a public PDF on shift4.com, and it states a 30-month Initial Term, automatic renewal for successive one-year Renewal Terms absent written non-renewal notice at least 30 days before expiry, and a 30-calendar-day penalty-free Trial Period from the Effective Date. Evidence caveat: www.shift4.com/pdf/SkyTab-POS-System-Service-Agreement.pdf returns HTTP 403 to this environment, so the term/renewal/notice figures come from this atlas's 2026-08-01 adversarial pass reading indexed text of that PDF, and the trial clause is independently quoted verbatim by Reforming Retail (cited). Graded E rather than A because no one on this project has rendered the document. https://reformingretail.com/index.php/2025/12/30/to-catch-a-predator-shift4-termination-fees/ · retrieved 2026-08-03

E
No

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

Shift4 is the acquirer and the gateway throughout: the offline logic is written against the Shift4 gateway and processor, QR Pay and the customer-facing display 'process payments with Shift4 Gateway', the Advantage Program, settlement, funding, statements and chargebacks are all Shift4's, and the documented reason to export card tokens is that the merchant is leaving for another processor. No supported third-party processor list exists anywhere in the documentation. https://shift4.zendesk.com/hc/en-us/articles/43269556571027-Token-Migration · retrieved 2026-08-03

B
No

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

Interchange-plus EXISTS as a named plan - the Advantage Program FAQs say a merchant may switch 'to their prior pricing plan or a new pricing plan, such as Interchange+' - but the markup is never published. In the current (2026-07-08) fee schedule the Interchange Fee row's Current Price cell holds only 'Per Merchant Account' followed by '(In Pricing Tab in Titan)' and the Authorization fee row is 'Per transaction (In Pricing Tab in Titan)/ Per Merchant Account': the bps/per-transaction markup lives in Shift4's internal CRM, per MID. A regex for an interchange-plus markup expressed as bps or x.xx% + $0.xx matched 0 of 2,192 documents; the only interchange-plus string in the entire corpus is the plan-name mention above. Record already cites this article. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-09-05 adversarially verified

B
No

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

CLAIM: the processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange or network changes, or grants penalty-free exit on any increase. VERDICT no, on express adverse language rather than on silence. WHAT IS MET: nothing; the published agreements do the opposite on the cover page, in the amendment clause, in a dedicated escalator clause and in the termination clause. WHERE THESE DOCUMENTS LIVE AND WHY THEY ARE SKYTAB'S: skytab.com redirects to dine.shift4.com, whose /legal 404s, and the SkyTab footer points to https://www.shift4.com/legal, so the shift4.com legal index IS SkyTab's contract corpus; the product-specific instrument is the Shift4 Dine POS System Service Agreement, Shift4 Dine being SkyTab. SHORTFALLS. (1) The MPA cover page, in capitals as published: 'SECTION 10 REQUIRES ALL DISPUTES WITH BANK OR COMPANY TO BE RESOLVED IN BINDING INDIVIDUAL ARBITRATION ... SECTION 9 LIMITS BANK AND COMPANY'S LIABILITY AND MERCHANT'S REMEDIES. BANK OR COMPANY CAN CHANGE THE FEES AT ANY TIME, INCLUDING IN CONNECTION WITH THE RIGHTS IN SECTION 12.7.' (https://www.shift4.com/pdf/Merchant-Processing-Agreement-Terms-and-Conditions.pdf?refresh=20260810, re-fetched by me 2026-09-15, HTTP 200 application/pdf.) (2) MPA section 12.7 Amendments: 'Bank or Company may amend this Agreement, including by adding new terms or fees or increasing fees, at any time. Company may substitute Bank with another bank at any time. Amendments due to changes in Card Brand fees, interchange, assessments, Rules, or any Laws or judicial decision may become immediately and notice may follow such effectiveness.' (The third sentence is ungrammatical exactly as published, identically in both extraction modes.) The pass-through carve-out the claim contemplates exists only as a carve-out for IMMEDIATE effect, sitting inside an otherwise unlimited at-any-time right. (3) MPA section 12.15 Other Rights is an escalator FLOOR, not a cap: 'Without limiting any other rights of Company, beginning on the one year anniversary following the earlier of the signature date or the Effective Date, Company shall have a right to increase the aggregate fees payable by Merchant by an amount equal to the greater of (i) the average annual change (expressed as a percentage) for the prior calendar year in the Consumer Price Index for All Urban Consumers - All Items (seasonally unadjusted) (collectively the "CPI-U") plus 1%, or (ii) 7%. Specific to 12.7 and 12.15, Merchants continued use 30 days after notice under Section 12.5 constitutes acceptance.' The opening words 'Without limiting any other rights of Company' are decisive, and the second sentence converts an increase into deemed acceptance rather than a right to leave. Section 12.5 permits that notice to be given merely by 'the posting of such information by Bank or Company at one or more of their sponsored websites or customer service merchant portal'. (4) The SkyTab product contract repeats both mechanisms with a lower floor. Shift4 Dine POS System Service Agreement section 3.e (https://www.shift4.com/pdf/Shift4-Dine-POS-System-Service-Agreement.pdf?refresh=20260904): 'Shift4 may change any terms, conditions, rates, fees, expenses, or charges incurred under this Service Agreement upon 30 days' written notice to Merchant. Using the Equipment or Service after a change takes effect constitutes acceptance of the change.' Section 3.g: 'Without limiting any other rights of Shift4 ... Shift4 shall have a right to increase the aggregate fees payable by Merchant by an amount equal to the greater of (i) ... CPI-U plus 1%, or (ii) 4%.' (5) The exit limb is foreclosed. The merchant's only termination right is for Shift4's uncured material breach (MPA section 8.1), and any other exit is liquidated: section 8.5.5, 'If this Agreement terminates during the Term for any reason other than as a result of an uncured breach by Company, Merchant shall be liable to Company for liquidated damages in the amount equal to the base monthly termination fee amount, as determined by the table in the section below, multiplied by the number of terminal IDs. This new amount will then be multiplied by the number of months then remaining in the Term of the Agreement.' I quote that clause's PROSE and deliberately do not transcribe its tier TABLE, which renders correctly only under -layout. The Dine POS agreement section 2.d.ii makes any other merchant termination 'a material breach'. The only change-rejection right anywhere in the corpus is for the arbitration clause (Dine POS SSA section 11.e.ix). A fee increase is nowhere a trigger for penalty-free exit. APPLICABILITY: these are the operative commercial terms of the processing agreement and the POS service agreement that a SkyTab merchant signs, not a data-processing addendum settling rights only, so the clause reaches the claim directly. CONTROLS AND POISON, TOKENISED PER DOCUMENT over my own extractions of the MPA, the Shift4 Dine POS System Service Agreement and the Shift4 Customer Hub Terms and Conditions: cap = 0/0/0, capped = 0/0/0; interchange = 4 in the MPA and 0 in the two POS-side documents; CPI-U = 1/0/1 and also 1 in the Gateway Terms and Conditions. Positive controls in the same pass: MPA Merchant = 456, Agreement = 211, Shift4 = 26; Dine Shift4 = 171, Merchant = 203; Hub Shift4 = 156. PDF THREE-INSTRUMENT INVARIANCE, MEASURED BY ME PER DOCUMENT ON 2026-09-15: I re-fetched every contract myself (www.shift4.com answers 429 with a 'Vercel Security Checkpoint' HTML interstitial to a short User-Agent and 200 application/pdf to a full browser UA with Accept, Accept-Language and a Referer of https://www.shift4.com/legal - a bot heuristic, not a bar; note that a naive crawler WRITES THAT INTERSTITIAL TO DISK AS A .pdf, which is a corpus hole, and a fabricated path under /pdf/ returns 404 while a 429 is returned even for fabricated paths, so a 429 discriminates nothing). The ?refresh= query string is a cache-buster only: the MPA fetched with refresh=20260810, with a bogus refresh=19990101 and with no query at all are md5-identical (71bf4fd984f004a58ed62c59a855ca8b), so the cited URL and the bare URL are the same document. I then extracted each PDF with BOTH `pdftotext` and `pdftotext -layout` and compared tokenised counts for 29 terms across eight documents: plain and layout agree EXACTLY on every term in every document, and each quote below was confirmed present under BOTH modes. The known intra-word-space fault is ABSENT from these files (the single-letter-fragment signature is 246 under layout against 254 under plain on the MPA, i.e. layout splits fewer words, not more). POISON PUBLISHED: a whitespace-squashed substring probe, which the brief warns about, is worthless on these contracts - it returns FICA at 20/9/6 across MPA/Customer Hub/Dine POS SSA against a true tokenised count of 0 in all three (it is matching inside 'specifically', 'identification' and 'notification'), 'own' at 19 against a true 3 (inside 'download' and 'known'), and 'cap' at 3/4/5 against a true 0 (inside 'capacity' and 'capital'). Only the tokenised counts are reportable. A second instrument artefact worth recording: a `grep -c` run over a `tr`-flattened layout extraction reported 0 for a phrase that is plainly present in both modes, because form-feed page breaks resplit the stream - the phrase check must be done on the normalised text, not on a shell pipeline. CORPUS BOUNDING: the https://www.shift4.com/legal index is server-rendered and I enumerated 25 distinct English terms PDFs from its own hrefs, including a generic POS System Service Agreement, a Simphony/Oracle variant, Gateway Terms and Conditions, Online Ordering Service Agreement and Workforce Terms of Use, all of which I fetched and searched; the index self-limits, displaying only 'current terms and conditions' and directing anyone seeking archived versions to customer service, so this verdict is bounded to the live text as of 2026-09-15 and prior revisions are unmeasured. Both POS service agreements contain zero occurrences of the token SkyTab - the rebrand is complete in the contract text. https://www.shift4.com/pdf/Merchant-Processing-Agreement-Terms-and-Conditions.pdf?refresh=20260810 · retrieved 2026-09-15 adversarially verified

B
Yes

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

Published on Shift4's public help centre with no login, though in a billing-statement glossary rather than on a pricing page: 'POS Monthly | PO1, PO2, PO3 | $29.99-$79.99/month - Fee for the POS system, which covers reporting, maintenance, support, and swaps. Charged per POS and based on tier', with 'PO1: Shift4 Dine POS' defined in the same article. Shift4 Dine is therefore $29.99 per POS per month, i.e. per terminal. The same table publishes the recurring fees stacked above it - Customer Hub $20, Wireless Data $19.99, Online Ordering and Delivery Services Enablement $34.99 (effective 7/1/2026), Workforce Management $35/MID, Gift Card Service $25 - which is why the circulated '$29.99 all-in' figure is misleading. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-08-03 adversarially verified

B
Yes

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

Shift4 publishes a per-module fee schedule with independent statement codes: Workforce Management STW $35/MID, Gift Card Service GCM $25, Online Ordering & Delivery Services Enablement OLO $34.99, Shift4 Dine Customer Hub $20, Wireless Data WIS $19.99 - each a separate line from the base POS Monthly charge, PO1 $29.99 per POS. Cancellation independence is stated for the largest module: 'This service can be cancelled after initial onboarding.' Because the base charge is a flat per-terminal tier fee rather than a bundle, there is no bundle for a module cancellation to reprice, and Marketplace apps install and uninstall individually. https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-08-03 adversarially verified

B
No

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

Both prongs fail. No published outright price (see hardware-pricing-transparency: ordering is portal-only and the price list is an internal 'pricing matrices in the form'). And the documented billing model is recurring per-device SaaS, not purchase: 'Please be advised that for POS SaaS (Software as a Service) setups, POS Fees are billed as long as the equipment is on the account. Includes Seasonal accounts during their off-seasons.' Devices carry standing monthly fees by tier (PA1-PA4 covering KDS, Customer-facing Display, Kiosk, Handheld, Tablet; PO1-PO3 covering the POS itself), plus an Inactivity fee of $75 Per Device, defined as a 'Fee applied to all “software-as-a-service” billing models per device for every 30 days you do not actively process credit card payments', a 'Lane SaaS Fee' priced at '$10 per device on Free Lane Placements', and an 'FuturePOS Equipment Rental Fee' code. The Annual Service & Maintenance Fee row frames the equipment as supplied rather than sold: it 'is assessed on any account with provided credit card processing equipment' and is described as 'nominal for covering upfront equipment with lifetime no-cost replacements compared to purchasing equipment that may cost thousands of dollars.' https://shift4.zendesk.com/hc/en-us/articles/14382700830739-End-to-End-Billing-Matrix-Statement-Glossary · retrieved 2026-09-05 adversarially verified

B
Partial

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

Some non-proprietary peripherals are documented by model: Epson TM-L100 label printer, Epson U220 impact printer down to DIP switches, CAS PD-II and Mettler Toledo Viva scales, NTEP-certified scales, TP-Link networking. Shortfall: the transaction path is locked to Shift4-supplied devices - workstation, tablet, handheld, Duo, PAX A35/Q25 PIN pads, A3700 display - provisioned through Shift4's PAXSTORE with injected P2PE keys, and no commodity tablet or PC option is documented. https://shift4.zendesk.com/hc/en-us/articles/28253527021843-Change-Epson-U220-Impact-Printer-Dip-Switch · retrieved 2026-08-03

B
Partial

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

Self-serve export is real and broad: any Customer Hub report downloads as CSV, Excel or PDF and can be scheduled by email, Business Intelligence exports to Excel or PDF, Workforce Management exports timecards to CSV, and Ticket Detail (Open and Closed), Menu, Customer, Inventory, Till, Void and Refund reports are all included. Shortfall: it is report-by-report rather than a full transactional export - there is no bulk dump and no API, since the public API has no order object. https://shift4.zendesk.com/hc/en-us/articles/16081142713619-Run-Subscribe-to-Reports-in-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Yes

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

All three categories export in machine-readable form from the Customer Hub without a support ticket: the Customer Directory with contact details and visit history and Customer House Accounts Balance (Customer Reports), loyalty member and Loyalty Redemption by Location reports ('The Customer Hub allows exporting reports in various formats (CSV, Excel, PDF)'), and the gift card Balance report with outstanding liability. https://shift4.zendesk.com/hc/en-us/articles/38825545487635-Locate-Loyalty-Reports-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03 adversarially verified

B
Partial

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

CLAIM: 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. VERDICT partial. WHAT IS MET, ON TWO INSTRUMENTS. (1) The SkyTab back office contract grants an express post-termination extraction right, which is materially better than silence or a lockout. Shift4 Customer Hub Terms and Conditions section 10.3 - the Customer Hub being SkyTab's back office, documented throughout the KB as 'Shift4 Dine Customer Hub' - (https://www.shift4.com/pdf/Shift4-Customer-Hub-Terms-and-Conditions.pdf?refresh=20260512, re-fetched by me 2026-09-15 at HTTP 200 application/pdf, quote confirmed under both pdftotext and pdftotext -layout): 'Upon termination of these Terms for any reason, you must immediately stop using the Services and your license to use the Services provided under these Terms shall end. Upon your termination of these Terms, Shift4 will provide you with a reasonable period of time to allow you to extract your Account Data (defined below) that Shift4 has stored on its servers as of the termination date.' The identical sentence appears at section 10.3 of the Lighthouse Terms and Conditions, Lighthouse being the predecessor back office. (2) A DEFINED window does exist, on the gateway instrument, and it is 24 months. Gateway Terms and Conditions section 24.24 'Transition Assistance' (https://www.shift4.com/pdf/Gateway-Terms-and-Conditions.pdf?refresh=20241101): 'Upon termination of this Gateway Services Agreement by Merchant, SHIFT4 shall, upon Merchant's reasonable request, allow access to your GATEWAY accounts and TrueTokens for the Transaction History Retention Period at a reasonable Transition Assistance Fee to be negotiated.' Section 24.23 defines that period as 'a maximum of twenty-four (24) months post-settlement' on a rolling basis. So the claim's 'rather than immediate cutoff' limb is met twice over, and its 'defined number of days' limb is met on the gateway agreement. SCOPE, STATED: the Customer Hub terms are SkyTab-specific; the Gateway Terms and Conditions are a platform-wide Shift4 instrument, and I rely on it because the SkyTab Customer Hub ships Transaction Manager and SkyTab processes through the Shift4 gateway, but whether a given SkyTab merchant executes the Gateway Services Agreement alongside the Merchant Processing Agreement is not established from the published index, which is part of why this is a partial and not a yes. SHORTFALLS. (1) THE WINDOW IS FEE-GATED, AND THE SAME CLAUSE SAYS SO IN TERMS: 'For avoidance of doubt, upon termination of this Gateway Services Agreement Merchant shall have no right to, and SHIFT4 shall have no obligation to provide, your Transaction History or TrueTokens unless Merchant pays the Transition Assistance Fee.' The fee is 'to be negotiated' and is nowhere quantified, and section 24.24 adds 'SHIFT4 will not develop any software to facilitate the transfer of CHD or data to any Direct Competitor.' Section 24.23 likewise makes any change to the retention period 'an additional fee'. (2) The SkyTab-specific instrument supplies no number at all: 'a reasonable period of time' is the entire specification in the Customer Hub terms. (3) The trigger is asymmetric on both instruments. The Customer Hub's first sentence covers 'termination of these Terms for any reason' but the extraction sentence is conditioned on 'Upon YOUR termination of these Terms', while section 10.2 permits Shift4 to terminate 'without any notice and liability for any reason'; the Gateway clause likewise runs only on 'termination of this Gateway Services Agreement by Merchant'. An operator terminated by Shift4 has no stated extraction right. (4) The SkyTab POS contract is silent. The Shift4 Dine POS System Service Agreement (https://www.shift4.com/pdf/Shift4-Dine-POS-System-Service-Agreement.pdf?refresh=20260904) contains no data-retrieval clause; its only post-termination window is for hardware, 'All Equipment must be returned to Shift4 within 60 days following termination' (section 2.d.i); its section 6 licence 'shall immediately terminate upon expiration or termination of this Service Agreement'; and section 4.g puts preservation on the merchant - 'Merchant shall be solely responsible for storing and backing up Merchant's data stored on the Equipment. Shift4 shall have no liability to Merchant for loss or destruction of Merchant's data.' The Merchant Processing Agreement is silent on data return; its section 8.6 'Discontinuation of Services' concerns withholding funds. (5) The only other numeric window in the corpus runs to the wrong party: the Workforce Terms of Use (https://www.shift4.com/pdf/Workforce-Terms-of-Use.pdf?refresh=20260512) provide that on cancellation 'historic data relating to scheduling activities on worker accounts will be retained and made available to Workers for a minimum of 90 days (unless such records are deleted by your Company). After such period, you will no longer have access to your User Content or other account information after cancellation.' That is 90 days of scheduling data made available to WORKERS, defeasible by the merchant's own deletion, and the same document disclaims retention generally in capitals: 'ANY DATA, INCLUDING ACCOUNT HISTORY AND USER CONTENT RESIDING ON OUR SERVERS, MAY BE DELETED, ALTERED, MOVED OR TRANSFERRED AT ANY TIME FOR ANY REASON IN OUR SOLE DISCRETION, WITH OR WITHOUT NOTICE AND WITH NO LIABILITY OF ANY KIND.' I could not verify the existence of a separately published 'SkyTab Workforce Terms of Use': the legal index publishes one Workforce Terms of Use and the token SkyTab does not occur in it. (6) No US DPA exists to supply a figure - /legal/dpa, /data-processing-addendum, /pdf/Data-Processing-Addendum.pdf and /pdf/DPA.pdf all 404, the published DPAs are EU/UK-scoped, and their section 4.7 is day-less ('Processor shall cease to use Personal Data and shall arrange for its safe return or destruction as shall be required by Client'). APPLICABILITY: I rely on the Customer Hub terms and the Gateway agreement as operative commercial terms of the services the operator buys, not as a DPA settling rights only, and I say for each which entity and product it governs. CONTROLS AND POISON, TOKENISED PER DOCUMENT (MPA / Dine POS SSA / Customer Hub T&C): export = 0/0/0; extract = 0/0/1, that single hit being the section 10.3 sentence quoted above; retrieval = 1 in the MPA (a chargeback retrieval request, an unrelated homonym) and 0 elsewhere; 'reasonable period' = 1/0/1; terminate = 9/7/5. In the Gateway Terms and Conditions retention = 4 and every hit is a genuine data-retention clause, which is the opposite of the KB where retention never means data retention. Positive controls in the same pass: MPA Merchant 456, Agreement 211; Dine Shift4 171; Hub Shift4 156. PDF THREE-INSTRUMENT INVARIANCE, MEASURED BY ME PER DOCUMENT ON 2026-09-15: I re-fetched every contract myself (www.shift4.com answers 429 with a 'Vercel Security Checkpoint' HTML interstitial to a short User-Agent and 200 application/pdf to a full browser UA with Accept, Accept-Language and a Referer of https://www.shift4.com/legal - a bot heuristic, not a bar; note that a naive crawler WRITES THAT INTERSTITIAL TO DISK AS A .pdf, which is a corpus hole, and a fabricated path under /pdf/ returns 404 while a 429 is returned even for fabricated paths, so a 429 discriminates nothing). The ?refresh= query string is a cache-buster only: the MPA fetched with refresh=20260810, with a bogus refresh=19990101 and with no query at all are md5-identical (71bf4fd984f004a58ed62c59a855ca8b), so the cited URL and the bare URL are the same document. I then extracted each PDF with BOTH `pdftotext` and `pdftotext -layout` and compared tokenised counts for 29 terms across eight documents: plain and layout agree EXACTLY on every term in every document, and each quote below was confirmed present under BOTH modes. The known intra-word-space fault is ABSENT from these files (the single-letter-fragment signature is 246 under layout against 254 under plain on the MPA, i.e. layout splits fewer words, not more). POISON PUBLISHED: a whitespace-squashed substring probe, which the brief warns about, is worthless on these contracts - it returns FICA at 20/9/6 across MPA/Customer Hub/Dine POS SSA against a true tokenised count of 0 in all three (it is matching inside 'specifically', 'identification' and 'notification'), 'own' at 19 against a true 3 (inside 'download' and 'known'), and 'cap' at 3/4/5 against a true 0 (inside 'capacity' and 'capital'). Only the tokenised counts are reportable. A second instrument artefact worth recording: a `grep -c` run over a `tr`-flattened layout extraction reported 0 for a phrase that is plainly present in both modes, because form-feed page breaks resplit the stream - the phrase check must be done on the normalised text, not on a shell pipeline. CORPUS BOUNDING: 25 distinct English terms PDFs enumerated from the server-rendered https://www.shift4.com/legal index, eight fetched and searched in full; the index displays only current terms and refers archived versions to customer service, so this is bounded to the live text of 2026-09-15. The Zendesk KB adds nothing: tokenised over all 2,174 bodies, 'post-termination' = 0 documents, 'export your data' = 0, 'merchant agreement' = 0, 'data processing addendum' = 0. https://www.shift4.com/pdf/Shift4-Customer-Hub-Terms-and-Conditions.pdf?refresh=20260512 · retrieved 2026-09-15 adversarially verified

B
No

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

CLAIM: 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 or de-identified use for its own products or marketing. VERDICT no, on express adverse language: the published terms state the reverse of both limbs. WHAT IS MET: nothing on limb one. On limb two there is exactly one genuine constraint in the whole contract corpus and it is narrow, recorded below rather than suppressed. THE CENTRAL CLAUSE, VERBATIM - Merchant Processing Agreement section 11.3 'Title to the Services' (https://www.shift4.com/pdf/Merchant-Processing-Agreement-Terms-and-Conditions.pdf?refresh=20260810, re-fetched by me 2026-09-15, HTTP 200 application/pdf, quote confirmed under both pdftotext and pdftotext -layout): 'The Services are licensed and not sold. As a result, Merchant acquires only a nontransferable, revocable, non-exclusive right to use the Services during the term ... Company retains all right, title, and interest in and to the Services, and anything arising in connection with the Services, including any materials provided to Merchant, feedback related to the Services, products or services developed in connection with the Services, and any data of any kind derived from Transactions, which Company can use, share, sell, and/or otherwise disclose for any purpose not prohibited by Laws, including in furtherance of providing any Services. Notwithstanding anything to the contrary any Privacy Policy or notice or in this Agreement, we have the right to use, disclose, share, and retain any information you provide or that arises out of the Services in this Agreement, during the term and thereafter: ... (vi) with our affiliates, business partners and agents; ... (x) to perform analytic services for you, us, and/or others, including analyzing, tracking, and comparing transaction and other data to develop and provide insights for those parties as well as for developing, marketing, maintaining and/or improving our products and services.' SHORTFALLS. (1) Ownership of transaction-derived data is vested in Company, not the merchant. (2) The verb 'sell' is express; I read all three tokenised occurrences of sell in the MPA and the other two are a sales-draft endorsement and a change-of-control notice, so this is the only one that reaches data. (3) The grant is NOT confined to aggregated or de-identified data - the tokens aggregated, de-identified and anonymized are 0 in the MPA, 0 in the Shift4 Dine POS System Service Agreement and 0 in the Shift4 Customer Hub Terms and Conditions. (4) Limb (x) is exactly the own-products-and-marketing use the claim asks to see constrained, stated as permitted. (5) It survives termination ('during the term and thereafter') and is drafted to override the Privacy Policy. CORROBORATION ON THE SKYTAB SIDE. Shift4 Dine POS System Service Agreement section 11.h (https://www.shift4.com/pdf/Shift4-Dine-POS-System-Service-Agreement.pdf?refresh=20260904): 'For avoidance of doubt, you give Shift4 the permission to, but not limited to, collect and allow third parties to utilize: User-Provided Information, Service Information, Third-Party Software Information, and Transaction Data.' Shift4 Customer Hub Terms and Conditions section 11, the SkyTab back office: 'All data collected via the Shift4 interface or in connection with your use of the Services, including customer information and information about your business and employees used with or stored in or by the Services, is collected by Shift4.' The only definition of 'Account Data' makes it the merchant's RESPONSIBILITY rather than its property: 'You must prevent unauthorized access to and use of any of your information or data used with or stored in or by the Services (collectively, "Account Data").' Dine POS SSA section 4.g puts preservation on the merchant: 'Merchant shall be solely responsible for storing and backing up Merchant's data stored on the Equipment. Shift4 shall have no liability to Merchant for loss or destruction of Merchant's data.' THE ONE COUNTERVAILING CLAUSE, RECORDED RATHER THAN SUPPRESSED: Gateway Terms and Conditions section 18.1 'Data in SHIFT4's Care' (https://www.shift4.com/pdf/Gateway-Terms-and-Conditions.pdf?refresh=20241101) is a real purpose limitation - 'SHIFT4 agrees that Cardholder Information will not be used for any other purpose than to support (i) SHIFT4 in its general business requirements and support of GATEWAY, and (ii) Merchant in the activities contemplated by its and other merchants' use of GATEWAY' - but it is scoped to Cardholder Information under the gateway agreement, it says nothing about ownership, and MPA 11.3 operates 'notwithstanding anything to the contrary'. THE CONTRAST THAT SHOWS THE DRAFTING IS DELIBERATE: the aggregation-limited shape the claim describes exists elsewhere in the Shift4 family but not in SkyTab's contract - POS System Service Agreement (Simphony and Oracle) section 6.6 (https://www.shift4.com/pdf/POS-System-Service-Agreement_Simphony-Oracle.pdf?refresh=20251120): 'Company may (a) compile statistical and other information related to the performance, operation and use of the Services, and (b) use data from the Services in aggregated form ... Company retains all intellectual property rights in Service Analyses.' The token aggregated is 1 in that document and 0 in all of the SkyTab-side ones. A TENSION TO RECORD RATHER THAN RESOLVE: the Privacy Policy (effective 2026-07-22, https://www.shift4.com/privacy-policy) says 'No Sale of Data: Shift4 does not sell your Personal Information to third parties', which is a narrower category than 'any data of any kind derived from Transactions', and 11.3 expressly beats the Privacy Policy; the two reconcile only if transaction-derived data is not Personal Information. ABSENCE CONTROLS, TOKENISED PER DOCUMENT (MPA / Dine POS SSA / Customer Hub T&C): aggregated 0/0/0, de-identified 0/0/0, anonymized 0/0/0, owns 0/0/0, export 0/0/0. ownership = 4/2/2 and I read all eight: in the MPA they are a Beneficial Ownership Addendum, two change-of-control covenants and an indemnity for actions taken in connection with a Change in Ownership; in the Dine POS SSA one is a tax on 'the ownership, possession, or use of the Equipment' and the other runs AGAINST the merchant - 'Nothing contained in this Service Agreement shall give Merchant any ownership interest, or title to, the Software'; in the Customer Hub terms both protect Shift4's title. own = 3/2/2 and every hit is boilerplate ('at its own cost and expense', 'its own internal business purposes'). Positive controls in the same pass: MPA Merchant 456, Agreement 211, Shift4 26; Dine Shift4 171, Merchant 203, Agreement 106; Hub Shift4 156. PDF THREE-INSTRUMENT INVARIANCE, MEASURED BY ME PER DOCUMENT ON 2026-09-15: I re-fetched every contract myself (www.shift4.com answers 429 with a 'Vercel Security Checkpoint' HTML interstitial to a short User-Agent and 200 application/pdf to a full browser UA with Accept, Accept-Language and a Referer of https://www.shift4.com/legal - a bot heuristic, not a bar; note that a naive crawler WRITES THAT INTERSTITIAL TO DISK AS A .pdf, which is a corpus hole, and a fabricated path under /pdf/ returns 404 while a 429 is returned even for fabricated paths, so a 429 discriminates nothing). The ?refresh= query string is a cache-buster only: the MPA fetched with refresh=20260810, with a bogus refresh=19990101 and with no query at all are md5-identical (71bf4fd984f004a58ed62c59a855ca8b), so the cited URL and the bare URL are the same document. I then extracted each PDF with BOTH `pdftotext` and `pdftotext -layout` and compared tokenised counts for 29 terms across eight documents: plain and layout agree EXACTLY on every term in every document, and each quote below was confirmed present under BOTH modes. The known intra-word-space fault is ABSENT from these files (the single-letter-fragment signature is 246 under layout against 254 under plain on the MPA, i.e. layout splits fewer words, not more). POISON PUBLISHED: a whitespace-squashed substring probe, which the brief warns about, is worthless on these contracts - it returns FICA at 20/9/6 across MPA/Customer Hub/Dine POS SSA against a true tokenised count of 0 in all three (it is matching inside 'specifically', 'identification' and 'notification'), 'own' at 19 against a true 3 (inside 'download' and 'known'), and 'cap' at 3/4/5 against a true 0 (inside 'capacity' and 'capital'). Only the tokenised counts are reportable. A second instrument artefact worth recording: a `grep -c` run over a `tr`-flattened layout extraction reported 0 for a phrase that is plainly present in both modes, because form-feed page breaks resplit the stream - the phrase check must be done on the normalised text, not on a shell pipeline. CORPUS BOUNDING: 25 distinct English terms PDFs enumerated from the server-rendered https://www.shift4.com/legal index, of which I fetched and searched eight in full; the index displays only current terms and refers archived versions to customer service, so this is bounded to the live text of 2026-09-15. There is no US DPA - /legal/dpa, /data-processing-addendum, /pdf/Data-Processing-Addendum.pdf and /pdf/DPA.pdf all 404 - and the published DPAs are EU/UK-scoped. The Zendesk KB adds nothing: tokenised over all 2,174 bodies, 'data ownership' = 0 documents, 'own your data' = 0, 'de-identified' = 0. https://www.shift4.com/pdf/Merchant-Processing-Agreement-Terms-and-Conditions.pdf?refresh=20260810 · retrieved 2026-09-15 adversarially verified

B
Partial

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

Both halves are documented in substance: card entry runs on PAX PTS devices carrying a Shift4 P2PE application with remote key injection from PAXSTORE, and Shift4 holds tokens mapping to PAN and cardholder data on the merchant's behalf, exportable on request. Shortfall: Shift4's merchant-facing documentation never names the resulting SAQ type (SAQ A or SAQ P2PE-HW) and no PCI-listed P2PE validation reference was retrievable. https://shift4.zendesk.com/hc/en-us/articles/43269556571027-Token-Migration · retrieved 2026-08-03

B
Partial

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

MFA is available on back-office access (Customer Hub two-factor authentication, plus forced OTP with lockout on account maintenance) and a Security/PCI category exists with roles and responsibilities. Shortfalls: MFA is documented as opt-in configuration rather than enforced for all cardholder-data-environment access, no article addresses PCI DSS v4.0.1 by name, and nothing addresses payment-page script integrity monitoring under Req 6.4.3/11.6.1 for the hosted ordering and Payment Links pages. https://shift4.zendesk.com/hc/en-us/articles/360040643034-Set-up-and-Use-Two-Factor-Authentication-in-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B
Partial

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

Locating and exporting an individual guest is straightforward (Customer Directory search and export, ticket-level customer lookup) and a form of deletion exists - a loyalty member can be deactivated so 'they will no longer be able to access loyalty using their phone number', and customer records can be deleted in the Customer Hub. Shortfalls: deactivation preserves the point balance rather than erasing the record, a deleted online-ordering customer 'will be restored in the system' on their next order, no DSAR workflow is documented, and no executable DPA is published in the help centre. https://shift4.zendesk.com/hc/en-us/articles/4406373525907-Loyalty-FAQs · retrieved 2026-08-03

B
No

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

Re-anchored on audit from the Lighthouse release notes to the SkyTab kiosk configuration surface. The claim is conjunctive: a published VPAT/ACR claiming WCAG 2.1 AA AND a documented tactile/audio non-visual access mode on kiosks. The second conjunct fails against a matched comparator. Shift4 Dine's kiosk has sixteen dedicated articles -- 'Configure Kiosk Admin Settings' (# updated 2026-05-12), 'Kiosk Specifications', 'Kiosk Installation Guide', 'Configure Kiosk Order Flows', 'Navigate the Kiosk User Interface' and 'Kiosk FAQs' among them -- and no ADA mode, audio jack, headphone, screen-reader or tactile-navigation setting appears in any of them. The sibling Appetize Interact X kiosk, a different Shift4 SKU, documents exactly that feature where it exists: 'Enable ADA Mode: Enable/Disable the ability to put a kiosk in ADA Mode', 'Plugging in headphones into a storm audio jack or tapping any key on the storm navigation bar engages ADA mode as well.', a 'Default ADA Theme' and per-image 'Alternate Text: this is the text that will read aloud when a user uses ADA with headphones'. So Shift4 documents kiosk non-visual access where it exists, and the SkyTab kiosk configuration surface, which had room for it, does not carry it. On the conformance-report conjunct: anchored regexes for WCAG, VPAT, accessibility-conformance, Section 508 and ACR return zero across all 2,192 documents, and Shift4's own web-accessibility answer is to outsource -- 'Yes. Currently, we support a couple of industry-standard ADA solutions for the websites.', with 'you would need to sign up for an account with the individual ADA provider'. Caveat retained: a corporate VPAT would live on www.shift4.com, which returns HTTP 429 on robots.txt and was not fetched; this verdict rests on the kiosk conjunct, not on that wall. https://shift4.zendesk.com/hc/en-us/articles/30548852009363-Configure-Kiosk-Admin-Settings · retrieved 2026-09-05 adversarially verified

B
Partial

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

Disclosure is handled deliberately: enrolment requires accepting an Advantage Program Disclosure Agreement and then a second program-specific disclosure, the fee's appearance on the receipt is customisable, and Shift4 publishes ticket-detail, payment-selection and printed-guest-check examples for Supplemental Fee, Dual Pricing and Cash Discount. Shortfall: no documentation states that debit and prepaid cards are automatically excluded by BIN or product code, nor that the network percentage cap is enforced - both are the controls that make a surcharge compliant. https://shift4.zendesk.com/hc/en-us/articles/27580032701331-Enroll-and-Set-up-Advantage-Program-on-the-Shift4-Dine-Customer-Hub · retrieved 2026-08-03

B

Adversarial verification

An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 36 values — 30 upheld, 3 downgraded, 3 upgraded. It separately resolved 55 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.

Pricing and identity

FieldVerdictWhat the verifier found
pricing.softwareupgrade-to-yesThe researcher's conclusion followed from searching only shift4.com and skytab.com, both of which return 403/429. The figure is published on a third Shift4 property they were already reading for 200 other cells. The help centre's billing glossary lists 'POS Monthly | PO1, PO2, PO3 | $29.99-$79.99/month... Charged per POS and based on tier' and defines 'PO1: Shift4 Dine POS'. Shift4 Dine is therefore $29.99 per POS per month at list, before the $20 Customer Hub fee, $19.99 wireless data, $34.99 online-ordering enablement and $35 Workforce module. Note what this also refutes: the popular claim that $29.99 is an all-in bundled price. It is the terminal software line only, and at least four other recurring first-party fees sit above it. pricing.software rewritten accordingly. source

Capability claims

ClaimAs first scoredVerdictWhat the verifier found
labor-native-schedulingyes / B, cites Manage Shifts in Workforce Management; note says Workforce 'is Shift4's own scheduling product sharing the timekeeping data'downgrade-to-partialWorkforce Management is Shift4's own product, but it is neither included nor the same platform. Shift4's own billing glossary prices it as a separate line item - 'Workforce Management Fee | STW | $35/MID | Scheduling and employee management tool for Shift4 Dine POS Software. This service can be cancelled after initial onboarding.' The merchant FAQ confirms it 'will open up the new Workforce application' as a distinct app with its own mobile client, and that timekeeping lives on the POS and is copied across: 'Timecards from the Workstation are synced to Workforce Management on a regular basis (approx. every 15 minutes).' Scheduling therefore sits beside the timekeeping store behind a paid subscription and a 15-minute sync, not inside it. Named shortfall recorded. source
labor-break-compliance-by-stateyes / B, cites California Missed Meal Break Compliance; note asserts Custom Compliance Rule Groups and per-location auto-configurationdowngrade-to-partialI retrieved both articles the note leans on. The California page delivers only the penalty half: the system 'automatically identifies when a meal break has been missed and applies the extra one hour of pay to the relevant timecard', and is framed throughout as 'Stay compliant with California legislation in relation to missed breaks' with no other jurisdiction named. The Custom Compliance Rule Groups article is purely mechanical - how to create a group and assign employees - and never ties a rule group to a state or enumerates what rules exist. No article anywhere prompts an employee to attest that a break was taken or waived, which is a third of what the claim asks for. Documented: missed-meal-break detection and premium pay in California, plus Ontario overtime rules. Not documented: a per-jurisdiction rule library or break attestation. source
labor-shift-swap-workflowyes / B, cites Enable Shift Swaps/Drops for a Department; note claims Compliance Warnings surface against the resulting scheduledowngrade-to-partialThe self-service and approval halves check out - swaps and drops are enabled per department and manager approval is the default, with an explicit opt-out: 'use the Auto approve checkbox to allow shift swaps to occur without a manager's approval.' What I could not find in this article or in the swap/drop approval articles is the eligibility half the claim requires: nothing states that a claim or swap is blocked or flagged when it would push the employee into overtime, and nothing checks that the claiming employee holds the job/role the shift is scheduled for. The note's Compliance Warnings link points at the California meal-break feature, which is evaluated against worked timecards, not against a proposed swap. Partial with the shortfall named. source
commercial-pricing-publishedunknown / F - 'Widely reported as $29.99/month with bundled hardware, but I could not read it on a Shift4 property'resolve-to-yesThe researcher looked only at the bot-blocked marketing estate and concluded nothing is published. Shift4 publishes a full itemised fee schedule inside its own public help centre, no login required: 'POS Monthly | PO1, PO2, PO3 | $29.99-$79.99/month - Fee for the POS system, which covers reporting, maintenance, support, and swaps. Charged per POS and based on tier', with the tiers defined in the same article as 'PO1: Shift4 Dine POS'. So the Shift4 Dine rate is $29.99 per POS per month - per-terminal, as the claim asks - and the same table publishes 'Shift4 Dine Customer Hub Fee: $20', 'Wireless Data: $19.99', 'Online Ordering and Delivery Services Enablement Fee: $34.99 (effective 7/1/2026)', 'Batch Header Fee: $0.40 Per Batch', 'Network Transaction Fee: $0.02 Per Transaction' and 'Bank Sponsorship Fee: $0.005 Per Transaction'. This is a first-party document carrying specific dollar figures, which is what the cell asks for, and it independently corroborates the $29.99 the record refused to record from third parties. source
commercial-module-unbundlingpartial / B - shortfall stated as 'no module price list exists beyond gift cards'upgrade-to-yesThe named shortfall is factually wrong and I can retract it with the vendor's own document. The End-to-End Billing Matrix is exactly a module price list: each module carries its own statement code and monthly figure - Workforce Management STW $35/MID, Gift Card Service GCM $25, Online Ordering & Delivery Services Enablement OLO $34.99, Shift4 Dine Customer Hub $20, Wireless Data WIS $19.99 - all separate from the base POS Monthly line PO1 $29.99. The Workforce row states cancellation independence in terms: 'This service can be cancelled after initial onboarding.' Because the base POS charge is a flat per-terminal tier fee rather than a bundle, there is nothing for a module cancellation to reprice. Upgraded to yes on that document. source
payments-dual-pricingyes / B, cites the Advantage Program enrolment articleupheldI challenged this expecting a surcharge dressed as dual pricing, because the enrolment article the researcher cited configures nothing but a 'Fee Percentage', which is a register-time markup and not two stored prices. The US Advantage Program FAQ resolves it against the researcher's reasoning but in favour of their answer: 'With Dual Pricing, you can offer a simple cash vs. non-cash total on the receipts presented to customers and on the customer-facing displays', and Shift4 distinguishes it from Supplemental Fee precisely on storage - Dual Pricing and Cash Discount require the merchant to maintain two price points per item, one cash and one non-cash, updated in the POS, online and on printed materials, while Supplemental Fee applies one percentage across all transactions. Two prices per item plus both totals on the check is what the claim asks for. Yes stands; evidence re-pointed at the FAQ, which is where the mechanism is actually stated. source
payments-payout-timingyes / B - note quotes only the next-day defaultupheldRetrieved the Deposit Schedules article. It publishes three named schedules, not one: 'Next-Day Funding 24-hour funding: Funds are deposited the next business day', 'Two-Day Funding 48-hour funding', and 'Same-Day Funding: Funds are deposited between 1:00 p.m. ET and 5:00 p.m. ET', with 'Shift4 defaults most merchants to Next-Day 24-hour funding unless requested or changed otherwise.' The claim asks for a published schedule plus a next-day or same-day option and both exist. No fee for any schedule is stated, which is a gap worth flagging but not one that moves the cell. Note corrected to include same-day. source
reliability-offline-card-authyes / B, cites the Offline Payments Overview and FAQsupheldRead the FAQ myself. Store-and-forward is documented, not implied: on a PAX device 'transactions in Offline Mode will continue to function as it is in online mode', including chip-and-PIN; 'Transactions can be stored for up to two days without any implications'; and on reconnect 'the system will automatically process pending transactions one at a time, sending a transaction every two minutes until the queue is cleared', with a stated allowance of one hour per 30 pending transactions. Shift4 is also candid about the risk this carries, which is a mark in favour of the source: stored transactions that fail authorisation 'will require manual intervention', and the article warns against clearing data on a device holding a pending queue. Card payments while offline, not a cash-only fallback. Upheld. source
kitchen-offline-operationyes / B, cites the Offline Payments Overview and FAQsupheldSame article, and the qualification the researcher wrote into the note is the article's own: 'Will my local network, printers, Kitchen Display System, etc., work in Offline Mode? These will work as long as the local network is connected.' So the failure mode covered is loss of internet, not loss of the LAN, and the record says exactly that. The cell is scored on what the source supports. source
delivery-driver-rosterno / B, cites InhouseDelivery and Online Integration and SetupupheldA `no` against a named business needs positive evidence of absence, so I went at this one hardest. The InhouseDelivery guide supplies it twice over. The driver model - 'Your own drivers', 'Third-party drivers' or 'Both options', with the priority rule that 'Your drivers will be prioritized, and deliveries will be sent to third-party providers if none of your drivers are online or available' - lives entirely in the partner's dashboard, reached after creating a separate account with that partner. And Shift4 states the POS has no delivery entity at all: 'Orders will show as Pickup in the POS, and not as Delivery. The POS does not differentiate between a customer walking in to collect an order and a third-party delivery - they are both classified as Pickup.' A product that cannot distinguish a delivery from a walk-in cannot hold a driver roster. Upheld. source
delivery-dispatch-boardno / B, cites InhouseDelivery and Online Integration and SetupupheldConfirmed from the same guide plus the Delivery Management article index, which I enumerated through the help centre's search API. The only dispatch surface Shift4 documents is 'Connect Dispatch Provider on Delivery Management' - a handoff to a delivery-as-a-service provider, not an operator-facing board - and assignment otherwise happens inside the InhouseDelivery partner app. No expo, map, driver-assignment or run-batching screen appears in the Shift4 Dine corpus. Combined with the POS classifying every delivery as Pickup, this is a documented absence rather than an unfound feature. source
order-capture-throttlingyes / B, cites Enable Kitchen Capacity for Automated Order ThrottlingupheldI challenged this because the cited evidence lives in Delivery Management, which the record's own product.yaml calls a Marketplace integration - if throttling only existed there, the cell would be a partner capability. It exists on both sides. The first-party Online Ordering configuration carries its own throttle: 'Limit how many orders can be fulfilled every 15 minutes to prevent overwhelming the kitchen.' And Delivery Management is Shift4-operated rather than a redirect - it installs from the Shift4 Dine Customer Hub, 'the system will connect to your Workstation and begin menu synchronization', and Shift4 authors the whole article set. Its throttle is capacity-with-quote-extension as the claim requires: 'if capacity is set to 10 items, then items 11-20 will be throttled by an additional 30 minutes, resulting in a 60-minute total prep time.' Per-channel limits per time slot on both first-party and third-party ordering. Upheld. source
kitchen-order-throttlingyes / B, cites Enable Kitchen Capacity for Automated Order ThrottlingupheldRetrieved the article. Capacity is entered as the number of items the kitchen can produce within a specified prep-time window, and excess volume is automatically paced by extending the quote rather than by rejecting orders - 'if capacity is set to 10 items, then items 11-20 will be throttled by an additional 30 minutes, resulting in a 60-minute total prep time.' The onboarding guide confirms this runs on Shift4-operated infrastructure installed from the Customer Hub with menus synced from the Workstation, and no separate fee is named in either article. Automatic pacing on a configurable volume threshold is what the claim asks for. source
delivery-zones-polygonyes / B, cites Install and Configure Online OrderingupheldRetrieved the Online Ordering configuration article. Delivery Address Validation 'Determines where orders can be delivered. You can set it by zone by drawing a custom area on the map or by driving distance', with a maximum delivery distance in miles alongside. Drawn map areas and drive-distance are exactly the two mechanisms the claim distinguishes from a bare radius or ZIP list, and notably the article does not offer a ZIP-code mode at all. Upheld on first-party Online Ordering, which is firmer footing than the InhouseDelivery corroboration the researcher also cited. source
delivery-3p-direct-integrationyes / B, cites the Marketplace Integration Partner Installation MatrixupheldRead the matrix. DoorDash and Uber Eats each have a dedicated Shift4-authored connection guide ('Connect DoorDash to Delivery Management', 'Connect Uber Eats to Delivery Management', plus 'Sign Up for DoorDash Through Delivery Management'), and Grubhub is listed as a direct Customer Hub integration under 'Online Ordering, Delivery'. The matrix separates these from a partner-redirect column containing Otter, Menufy, TechRyde and others - so the aggregators are present as alternatives, not as a required layer. Deliverect, Chowly and ItsaCheckmate do not appear at all. All three named marketplaces are first-party. Upheld. source
extensibility-first-party-delivery-integrationsyes / B, cites the Marketplace Integration Partner Installation MatrixupheldSame document, checked against the specific question of whether a paid middleware layer is required. It is not: DoorDash and Uber Eats connect through Shift4's own Delivery Management with Shift4-written guides, Grubhub is a direct Customer Hub integration, and Otter appears only in the separate partner-redirect list. Shift4's marketplace terms state 'Marketplace Cost: Free Shift4 integration', so Shift4 charges nothing for the connection itself - though the $34.99 per month Online Ordering and Delivery Services Enablement Fee in the billing glossary is a first-party cost a reader should weigh alongside this cell. source
digital-voice-ai-phoneyes / B, cites Enable Loman AI in the Customer HubupheldChallenged on the standard partner-versus-native objection, which does not apply here: this claim's own wording admits 'native or a named certified partner'. Loman AI is named, installs from the Customer Hub, and the injection path is the operative test - 'Appears in Shift4 Dine as an online order; routes to the correct kitchen display automatically - no manual entry needed', with the menu pulled directly from Shift4 Dine. That is a completed order reaching the KDS without staff transcription. Two caveats I would not leave implied: the article never uses the word 'certified', and it publishes no price, so the merchant's cost of Loman is unknown. source
kitchen-guest-ready-notificationyes / B, cites Guest Notifications Overview on the Kitchen Display SystemupheldRetrieved the article. Completion on the Display is the trigger and the notification is mapped per order type - 'The notification type (e.g., SMS, email, etc.) assigned to the order type will be sent to the guest' - with the order type having to be pre-defined in Guest Notification settings and a workstation-side enablement article as prerequisite. No separate product, add-on or fee is named anywhere in the setup chain, which is the condition the claim attaches. Worth noting against the record's own digital-sms-ordering `no`: outbound SMS exists here as a one-way transactional notification while Shift4 states plainly that SMS marketing does not, and both readings are consistent. source
menu-pricing-half-and-half-rulepartial / B, cites Configure Pre-Modifiers and Pre-Modifier SetsupheldRetrieved the Pre-Modifiers article. The researcher's finding is right - placement prefixes 'SIDE, ON THE SIDE, LEFT SIDE, RIGHT SIDE, WHOLE' and quantity prefixes 'LITE, EXTRA' with a 'Percentage (%) or Flat ($)' price adjustment that may be negative but not below $0 - and the article contains no charge-the-higher-half and no average-the-halves rule, so one of the three models the claim enumerates is met and partial is correct. The shortfall the record names is understated, though, and I have added the article's own exclusion list: pre-modifiers work on the workstation and handheld only and are explicitly incompatible with 'Online Ordering, Third-party delivery platforms (Uber Eats, DoorDash, etc.), Kiosk, Shift4 Duo'. A half-and-half priced in the dining room cannot be ordered online at all. source
reliability-menu-build-serviceyes / B, cites the Shift4 Dine Menu Submission GuideupheldThe cited guide is a submission guide and on its own it only proves the operator hands material over - it even offers a POS Menu Import Template the operator fills in, which pointed towards a downgrade. The Launch Control FAQs close it in the vendor's favour and state who does the work: 'Once you submit your menu, we'll email you when it's built. Most menu builds take about a week, but programming also works orders by install date', with a Pre-Launch Specialist available to gather the data for merchants who cannot upload it themselves. Shift4's programming team performs the build. Yes stands; evidence re-pointed at Launch Control, which is where the statement actually lives. source
reporting-public-apino / A, cites dev.shift4.com/docs/apiupheldEnumerated the API reference myself rather than trusting the researcher's list. Every documented top-level resource is a payments object: Charges, Refunds, Customers, Cards, Subscriptions, Plans, Payment Methods, Tokens, Payment Links, Disputes, Fraud Warnings, Blacklist, Events, Payouts, Credits, Charge Splits, File Uploads, Checkout. There is no order, check, ticket, menu, item or employee resource, and no separate POS API is referenced from the gateway docs. Auth is HTTP Basic with the secret key as username and an empty password - an account-wide credential, not a scoped one. POS data is not reachable from Shift4's public API. Upheld. source
commercial-export-customer-and-loyaltyyes / B, cites Locate Loyalty Reports in the Shift4 Dine Customer HubupheldRetrieved the loyalty reports article and checked the field lists rather than the report names. Loyalty Member Activity by Location carries 'customer information (Name, Phone #, Email), visits, lifetime earnings, redeemed points, points adjustments, and current loyalty members' point balances' - contact PII and the point ledger in one export - alongside Loyalty Points Adjustment and Loyalty Redemption by Location, all available as 'CSV, Excel, PDF'. Self-serve from Reporting > Reports > Loyalty with no fee or ticket named. With the Customer Hub's gift-card Balance report covering outstanding liability, all three categories the claim lists are machine-readable and operator-reachable. source
guest-loyalty-data-export-portabilityyes / B, cites Customer Reports on the Shift4 Dine Customer HubupheldChecked the same evidence against the harder half of this claim, which is contact PII plus transaction history with no vendor fee or support ticket. The loyalty report set exports 'Name, Phone #, Email', visits and lifetime earnings to CSV or Excel directly from the Customer Hub, and the Customer Reports set adds the Customer Directory with visit history and Customer Item Sales. The claim allows 'CSV or API' and the CSV half is satisfied. One honest limit the note should carry: this is report-by-report and there is no API path, because Shift4's public API has no order object - so a guest list is portable but a full guest transaction ledger has to be assembled from several separate reports. source
commercial-hardware-purchase-outrightunknown / F - 'Hardware is ordered through the Customer Hub with no price shown'upheldRe-checked against the billing glossary that resolved the software-pricing cell, on the theory that it might carry equipment prices too. It does not. Equipment appears only as an 'Annual Service & Maintenance Fee' covering 'lifetime replacement of your credit card processing devices if they malfunction or need upgrading to the latest model, including overnight shipping', plus 'Inactivity: $75 Per Device' and a 'Handheld Support fee: $26 Per Device for sites boarded prior 01/01/25'. Every one of those is a recurring service charge on equipment the merchant holds, and none is a purchase price. That is suggestive of a rental posture but it is not evidence that outright purchase is unavailable, so unknown is the correct answer and stands. source
reporting-webhookspartial / A, cites dev.shift4.com/docs/api - 'the public docs as retrieved do not state retry behaviour or payload signature ver'upheldValue upheld, reasoning corrected. The first pass scored this from the single-page API reference and concluded retry behaviour was undocumented; the dedicated feature page at /docs/webhooks, linked from the reference's Events section, documents it in terms: 'Failed webhook requests are resent with an increasing delay between each attempt', and 'when event delivery fails for a given webhook URL, then delivery of all other events for that webhook URL will be blocked until that failed delivery is successfully retried'. The signature half of the claim genuinely fails, and now on positive evidence rather than absence of mention: the page's security guidance is to 'only use the event identifier from the webhook request and obtain the remaining data by making a direct request to the Shift4 API', with merchant-side de-duplication offered as the replay defence - which is what a vendor writes when there is no signed payload to verify. Order lifecycle events remain absent against the complete Types of Events enumeration. Partial stands with the shortfall restated. source
extensibility-free-sandboxpartial / A, cites dev.shift4.com/docs/api - 'on the POS side the equivalent is a demo MID that must be requested from Shift4 pl'upheldValue upheld, both legs re-grounded off the index page. The payments sandbox is real and is documented at /docs/testing, which the first pass did not cite: test-mode and live-mode key pairs plus an enumerated bank of test cards for success, validation errors, processing errors, disputes, fraud check and 3D Secure. The POS leg is stronger against the claim than recorded - Shift4's own article 'Request a Shift4 Dine Demo MID' restricts the demo environment to Authorized Shift4 Dine Partners with SP Office Codes and routes extra MIDs through a partner form requiring an emulator install and a terminal serial number, which is a dealer enablement path, not a developer sandbox. I could not test self-serve signup on the payments side because dev.shift4.com/signup serves a 403 Cloudflare interstitial to every user agent I tried, so I did not upgrade on that half either. Partial stands. source
payments-published-ratesunknown / F - No card-processing rate is published in any retrievable Shift4 source. skytab.com (the live marketinresolve-to-noPOSITIVE CONTROL, not a bare zero-hit. Re-read article 14382700830739 (# updated 2026-07-08): the fee schedule publishes ancillary fees to the cent yet leaves exactly two rows -- Authorization fee (line 274 'Per transaction (In Pricing Tab in Titan)/ Per Merchant Account', previous price line 276 'Increased Bi-Annually') and Interchange Fee (lines 952-959 'Per Merchant Account' / '(In Pricing Tab in Titan)') -- as per-MID. The enumeration HAD ROOM for a rate and the vendor's own published answer is 'quote-only', which answers the claim ('publishes ... rather than quote-only') directly rather than merely meaning we cannot see the rate. I re-ran the flat-rate regex myself over all 2,192 docs (/[0-9]\.[0-9]{2}% ?\+ ?\$?0?\.[0-9]{2}|flat rate of|processing rate of/): zero files. SUBJECT SCOPING CHECKED: the End-to-End Billing Matrix is Shift4-the-processor's, not a sibling POS SKU, and it carries Shift4 Dine POS/accessory fee codes (PO1-PO3, PA1-PA4, 'Non-Shift4 Dine' exclusions), so it is legitimate for a payments/commercial cell on a Shift4 record. Precedent 76% no. Upheld B. source
payments-surcharge-guardrailsunknown / F - The Advantage Program articles set a single Fee Percentage per location and never describe BIN or prresolve-to-noBoth killing quotes byte-verified in 17140380911379: the debit-BIN banner at line 8 and 'The default is 4%. The merchant can set a lower customer-facing rate or a higher rate up to 5%.' at line 231. The 5% ceiling is ABOVE the Visa/Mastercard 4% cap, so prong 2 (engine enforces the network cap) fails affirmatively, not by absence. Per-location prong verified in 43164077403923, 'Create and Manage Surcharges in Multi-Location Management' -- a Shift4 Dine surface, in subject -- line 28. A conjunctive claim with two prongs affirmatively dead on the vendor's own words is a no, not an unknown. Upheld B. source
payments-softpos-tap-to-payunknown / F - No Tap to Pay on iPhone or Android tap-to-phone acceptance is documented for Shift4 Dine; every docuresolve-to-noRan the zero-hit myself with my own regexes over all 2,192 docs: /[Tt]ap.?to.?[Pp]ay/, /SoftPOS|Soft POS/, /Tap on Phone|Tap.?to.?Phone/ -- ZERO files each, including the 3,021,495-character dev.shift4.com/docs/api/ reference (grade A, complete, re-fetched 200 today). Checked the gated-129 title list: no tap-to-pay/softPOS entry, so this does not sit on the measured gap. The QR Pay quote is byte-present. Not a bare zero-hit: the corpus documents every other acceptance mode at device level, and a grade-A payments API reference that would have to carry a SoftPOS SDK carries none. Upheld B. source
hardware-tap-to-phoneunknown / F - No Tap to Pay on iPhone or Tap to Pay on Android capability is documented for any Shift4 Dine surfacresolve-to-noSame tests as payments-softpos-tap-to-pay, re-run independently, same zero result. The two cells are near-duplicates and are consistent. The residual 429 risk is honestly stated in the analyst's own note. Upheld B. source
hardware-pricing-transparencyunknown / F - Hardware is ordered through the Customer Hub ('Order Hardware for Shift4 Dine and Employee ID Cards'resolve-to-noWEAKEST SURVIVING no IN BATCH F, and I nearly overturned it: the claim names 'the vendor's public site', which is skytab.com, behind the 429 wall. It survives because the vendor's own documentation affirmatively describes an internal, non-public price list rather than merely failing to show one -- 'please refer to the pricing matrices in the form' and 'It will be charged to your account and reflected on your monthly statement', both byte-verified in 15046423648147 (# updated 2026-08-11) -- and what IS published in the fee schedule is a recurring tiered device fee (PA1 $9.99 through PO3 $79.99, byte-verified) rather than any per-SKU purchase price. A vendor that publishes SKU prices does not tell its agents to consult an internal pricing matrix. Precedent 76% no, 3% unknown. Upheld B with the 429 caveat retained. source
extensibility-api-access-costunknown / F - Marketplace Overview states integrations are a 'Free Shift4 integration' and directs the merchant toresolve-to-partialVerified 43022018641043 is a genuine enumeration -- 'Learn what each Customer Hub permission controls', a full permission inventory -- and that 'Manage Developer Settings' / 'Access and configure developer-facing settings, such as API credentials or webhook configuration' is byte-present (# updated 2026-08-20). Confirmed the URL was NOT previously in claims.jsonl (0 hits). Scoping: the article is the Shift4 Customer Hub, the vendor's own merchant portal, not a sibling POS SKU. The refusal to go to yes is correct -- an absence inside a fee schedule plus a live $20 premium-Hub fee is partial, and the settling instrument (the MSA) is behind the 429 wall. Upheld partial/B. source
extensibility-webhook-reliabilityunknown / F - The gateway API exposes an Events resource, but the retrieved documentation pages do not state HMAC resolve-to-partialGRADE A CLASS CONFIRMED AND VALUE CHECKED, which is what I was asked to do. I read dev.shift4.com/docs/webhooks/ end to end: 'Failed webhook requests are resent with an increasing delay between each attempt.' is byte-present, so retry-with-backoff is real and not inferred from the page merely existing. I then grepped all 2,192 docs for /signing secret|X-Signature|webhook signature|HMAC/ -- ONE file, the API reference, and its HMAC use is Checkout Request signing, not webhook signing. The signature prong is therefore affirmatively absent and Shift4 documents an explicit substitute ('you should only use the event identifier from the webhook request and obtain the remaining data by making a direct request to the Shift4 API'). Conjunctive claim, one prong dead and two live -> partial is the honest read. Upheld partial/A. source
extensibility-doordash-preferredunknown / F - Shift4 documents a direct DoorDash Marketplace integration, DoorDash Drive, a Find Your DoorDash Storesolve-to-noFETCHED THE CITED URL LIVE MYSELF ON 2026-09-05. It resolves and the 2026 roster reads 'Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, and UrbanPiper'; Shift4 and SkyTab appear nowhere on the page. The instrument is correct in kind -- this is a DoorDash-published designation, so the vendor corpus is the wrong place to look and its silence is not the evidence, the roster is. The same URL is the cited instrument on 20+ other atlas records; precedent 79% no. Upheld B. source
commercial-interchange-plus-publishedunknown / F - No processing rate of any kind is published in a retrievable Shift4 source - neither a blended flat resolve-to-noSame positive control as payments-published-rates and the discrimination is sharper: Interchange+ is named as an available plan in 17140380911379 line 48 ('their prior pricing plan or a new pricing plan, such as Interchange+') while the Interchange Fee row of the published fee schedule carries only 'Per Merchant Account' plus '(In Pricing Tab in Titan)'. The plan exists; the bps-plus-per-transaction markup the claim requires is affirmatively not published. My own regex for a percent-plus-cents markup across 2,192 docs returned zero. Precedent 98% no (46 of 47). Upheld B. source
commercial-rate-increase-clauseunknown / F - Whether the processing agreement caps unilateral rate increases or grants penalty-free exit on one cupheldOVERTURNED. This was the auditor's first suspicion and it was RIGHT for this cell specifically. The claim is explicitly about what the PROCESSING AGREEMENT provides -- 'caps or prohibits unilateral vendor-initiated rate increases ... or grants penalty-free exit'. Every quote in the analyst's note is byte-verified (I read lines 274-276, 409 and 428 of 14382700830739 myself) but every one documents Shift4's PRACTICE, not its contractual permissions. A fee schedule showing repeated increases is fully compatible with an MSA that caps them, requires notice, or grants exit; caps constrain magnitude, and none of the cited increases states a ceiling either way. The second disjunct, penalty-free exit on any increase, is not addressed by a single word of evidence in the batch. The settling instrument, www.shift4.com/pdf/SkyTab-POS-System-Service-Agreement.pdf, is behind the 429 wall, and the brief predicted this cell would stay unknown. Scoring no converts 'we cannot read the contract' into 'the contract lacks the clause'. Downgraded to unknown/F. Note this analyst applied the correct standard two rows later on commercial-post-termination-export-window and commercial-data-ownership-clause; this row is inconsistent with their own discipline.
commercial-hardware-purchase-outrightunknown / F - Hardware is ordered through the Customer Hub with no price shown, and the billing glossary frames eqresolve-to-noAttacked as one of the four billing-matrix commercial no's and it SURVIVES where commercial-rate-increase-clause did not, because the fee schedule is a positive control for THIS claim rather than a proxy for an unread contract. It enumerates the billing model directly and the model is rental/SaaS: 'POS Fees are billed as long as the equipment is on the account', a $75 per-device Inactivity fee applied to 'software-as-a-service' billing models, a 'Lane SaaS Fee', an 'FuturePOS Equipment Rental Fee' code, and decisively the vendor contrasting its own model against purchase -- 'lifetime no-cost replacements compared to purchasing equipment that may cost thousands of dollars'. All byte-verified. That is Shift4 affirmatively stating equipment is supplied, not sold. Precedent is only 18% no on this cell, but that reflects vendors that DO sell hardware. Upheld B. source
commercial-post-termination-export-windowunknown / F - No post-termination data retrieval window is documented. The Token Migration article shows Shift4 wiupheldCorrectly left unknown. I confirmed the corpus carries no post-termination retrieval language and that the analyst did not stretch the Download Center's 7-day export-artefact expiry into one. This is the right handling of the 429 wall, and it is the standard against which commercial-rate-increase-clause fails. Upheld unknown/F.
commercial-data-ownership-clauseunknown / F - No readable published term states that the merchant owns its transaction and customer data or construpheldCorrectly left unknown, same reasoning, and the analyst explicitly refused to stretch the integration consent mechanic ('Select Allow to provide the integration with access to your POS data') into an ownership clause. Upheld unknown/F.
digital-surcharge-transparencyunknown / F - The Advantage Program (Supplemental Fee, Dual Pricing, Cash Discount) is documented as a POS-side prresolve-to-noBORDERLINE -- precedent is 61% partial, 0% yes, 27% no, and I tested whether this should move to partial. It should not. The head of the claim is PARITY ('Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS'), and parity fails affirmatively rather than by absence: 17140380911379 lines 127 and 143 both read 'merchants must update menu prices in the POS system, online ordering platforms, printed menus, and marketing material' -- the digital channel is a manual price rewrite, not a configuration. The jurisdiction/brand prong also fails affirmatively ('the Advantage Program does not auto-detect debit BINs'). The Online Ordering surcharge fields the analyst found are an order-level service fee with a guest-facing label, which satisfies the disclosure prong only. Head clause dead -> no. Upheld B. source
reporting-api-not-upchargedunknown / F - Marketplace Overview states 'Marketplace Cost: Free Shift4 integration! Please contact the third-parresolve-to-partialSame evidence base as extensibility-api-access-cost and consistently scored. Verified the permission enumeration and the byte-presence of the Settlement Report CSV Extract Specification and the Customer Hub export actions. The refusal to reach yes on an absence-inside-a-fee-schedule is correct, as is grade B rather than A. Upheld partial/B. source
reporting-history-retentionunknown / F - No retention window is published for transaction-level detail in the Customer Hub or Business IntellupheldOVERTURNED. The auditor's third suspicion, and RIGHT. I read 1500012366501 in full: it is 'Void Transactions in Transaction Manager', it does NOT enumerate retention at all, and its six-month figure is scoped to voided transactions moved into Archives after batch close -- 'The voided transactions will stay in Archives for six months, after which they are pruned from the system.' That is an archive-purge rule for one transaction state in the gateway back office, not the reporting UI's history window, and Transaction Manager is Shift4's cross-product gateway console rather than a Shift4 Dine reporting surface. So the row's own url does not support the words credited to it. I then looked for a real positive control and there is none: my own regex /retained for|retention period|months of (data|history)|data retention/ over all 2,192 docs returns two irrelevant hits (a session filter and a payroll mapping), and the actual reporting enumeration, the Shift4 Dine Customer Hub Report Guide (46334059307539, 32 reports, # updated 2026-05-12), says only 'The Customer Hub reports support flexible date ranges' with no stated limit. A claim of the form 'documents a window of at least 24 months' cannot be closed by a corpus that documents no window at all, over a floor 129 gated articles deep. Precedent: 46% unknown, only 15% no. Downgraded to unknown/F.
delivery-3p-reconciliationunknown / F - Delivery Management's Analytics section is documented for store uptime/downtime monitoring only. No resolve-to-noVerdict SURVIVES but the anchor was wrong-shaped, so I replaced it. The Settlement Report guide is a near-miss demonstration (and the oldest citation in batch F, # updated 2025-12-09); it shows what card-acquiring settlement is, not that marketplace reconciliation is absent. The real positive control is the Shift4 Dine Customer Hub Report Guide (# updated 2026-05-12), which is self-described as the exhaustive report inventory -- 'For a full list of reports in this category with descriptions, see the Detailed Report List section' -- across seven named categories, with 32 reports enumerated. I read the whole list: no marketplace, third-party, payout-matching, commission or unpaid-order report exists in it, and my own grep of that article for /Third.?Party|DoorDash|Uber|Grubhub/ returns one line, about a delivery SURCHARGE. An enumeration that had room and does not contain the answer is a legitimate no; a settlement guide alone is not. Re-cited, no/B. source
commercial-wcag-kiosk-accessibilityunknown / F - No VPAT, accessibility conformance report or WCAG claim was found for the Shift4 kiosk or for Onlineresolve-to-noThe auditor's second suspicion, PARTLY RIGHT: the release-notes anchor is indefensible for a conformance claim and I replaced it, but the verdict survives on different evidence. Lighthouse itself is IN SUBJECT -- the 2026w9 notes cover Multi-Location Management, Online Ordering, Kiosk and QR Pay and name 'SkyTab users in the UK and Ireland' -- so the scoping objection fails; the problem is instrument class, not subject. I confirmed independently that /WCAG|VPAT|Section 508|conformance report/ returns ZERO files across all 2,192 documents, and I agree a VPAT would normally live on a corporate trust page behind the 429 wall, so that prong alone would support only unknown. The verdict is rescued by the other conjunct, which fails affirmatively against a matched comparator: SkyTab's own kiosk has sixteen dedicated articles including 'Configure Kiosk Admin Settings' (# updated 2026-05-12), 'Kiosk Specifications', 'Kiosk FAQs' and 'Navigate the Kiosk User Interface', and my grep of that set for /ADA|accessib|audio|headphone|screen reader|tactile|braille/ returns nothing -- while the sibling Appetize Interact X kiosk documents 'Enable ADA Mode' and a headphone jack explicitly. Shift4 documents a kiosk non-visual mode where one exists; on the SkyTab kiosk configuration surface, which had room, it does not. Conjunctive claim, one prong affirmatively dead. Re-cited, no/B. source
order-capture-drive-thruunknown / F - No drive-thru order flow, order-point/window separation, lane sequencing or pull-forward article exiresolve-to-noCONSISTENCY TEST vs hardware-drive-thru (the auditor's fifth suspicion) -- they ARE consistent; see that row. I re-ran the drive-thru search myself: only six files in 2,192 contain drive-thru/drive-through and I opened every one. Two are Appetize Retail UI examples, one is 'Service Types Overview in QSR & Delivery' (sibling SKU), two are ChefTab/OASys KVS -- and I caught one the analyst missed, 'BumpBar Functions for the Kitchen Video System' (360037515054, # updated 2026-01-07), which DOES document a pull-forward-shaped feature: 'If the system is set to be a drive-thru, the PARK button sends selected orders to another screen in ROD Maintenance.' I checked its subject: it is the OASys iPad bumpbar for the ChefTab KVS line, not Shift4 Dine, so it is a sibling product and out of subject for this record. That leaves the Clarity digital-signage article as the only Shift4 Dine drive-thru mention, and it is display-only. Order types in Shift4 Dine are merchant-created free text (360042824953), so there is no fixed service-type enumeration to point at, but a conjunctive claim needing window separation, lane sequencing and pull-forward has zero prongs documented in a current, device-level-detailed KB whose gated cluster does not touch drive-thru. Upheld no/B, with the PARK near-miss now on the record. source
order-capture-drive-thru-timersunknown / F - No drive-thru timing or segment (order/total/window) measurement is documented in any Shift4 Dine orresolve-to-noVerified: /Speed of Service/ and timer reporting appear only on ChefTab, a sibling KVS SKU, and the prep-time article is Shift4 Dine's only kitchen timing instrument, byte-checked ('Prep Times allow you to define how long individual menu items and modifiers take to prepare'). Second positive control on the reporting side: the Shift4 Dine Customer Hub Report Guide enumerates 32 reports across seven categories and contains no speed-of-service or drive-thru timing report. Since Shift4 Dine documents no drive-thru at all, segmented order/total/window timers cannot exist; consistent with order-capture-drive-thru. Upheld no/B. source
menu-pricing-modifier-price-by-parent-sizeunknown / F - Modifier pricing is documented as a base price on the modifier, adjusted by Pre-Modifier percentage resolve-to-noPositive control confirmed and byte-verified. 'enter the required fields for the modifier set name and default price' is present in 43106955069971 (# updated 2026-05-12); the modifier record enumeration carries no price field; and the Matrix Items article states affirmatively 'The following fields do not apply to Matrix Items and will not be shown: price, modifier sets, taxes' (51336311331475, 2026-05-18) -- the matrix construct exists and explicitly excludes the thing the claim needs. The true modifier-by-size matrix is in QSR & Delivery, correctly excluded as a sibling SKU. This is an enumeration with room, not a zero-hit. Upheld no/B. source
menu-pricing-included-allowanceunknown / F - No article describes an included-modifier allowance (n toppings included, charge only for overage, sresolve-to-noPositive control confirmed. The Menu Viewer article enumerates the complete modifier-set field list -- 'whether the modifier set is required, minimum and maximum modifier selection per modifier set, minimum and maximum modifier quantity per modifier set, if modifier prints in red and bold, and the default modifier price' (byte-verified) -- and contains no threshold or overage field, while the sibling Appetize product documents exactly that ('Cross threshold', 'Additional Modifier Charge'). Matched comparator plus an enumeration with room. Upheld no/B. source
menu-pricing-upsell-promptsunknown / F - No suggestive-sell or upsell prompt configuration was found for POS, kiosk or Online Ordering, and nresolve-to-noVerdict upheld, one factual correction to the note. I re-ran /upsell|suggestive sell/ over all 2,192 docs: nine files, and every in-subject one is a partner integration (Horago QR, Evergreen digital menu boards); POSitouch and Appetize are sibling SKUs; Business Intelligence treats upselling only as a coaching topic. Shift4 Dine's own configuration surfaces that had room -- 'Configure Kiosk Order Flows', 'Configure Kiosk Admin Settings' and the 658-line Online Ordering guide -- carry no upsell prompt setting at all, so the head conjunct ('configured per item and per channel') is affirmatively dead. CORRECTION: the note's claim that no attach-rate report exists is wrong. 'Use the Modifier Mix Report in the Shift4 Dine Customer Hub' (51644639809427, # updated 2026-08-05) publishes an 'Attach Rate' column, 'Percentage indicating how often the modifier is attached to an item'. That measures modifiers, not prompts, so it does not revive the claim, but the note overstated. Precedent is 76% partial and 0% yes; partial there reflects vendors whose own POS has suggestive-sell, which Shift4 Dine's does not. Upheld no/B. source
kitchen-printer-fallbackunknown / F - Fulfillment printers can be assigned to a KDS station and printers can be grouped, but no article deresolve-to-partialQuote byte-verified in 6878577602451 (# updated 2026-07-24): 'Failover Printer: Designate a backup printer to print if the primary printer is offline.' at line 209, inside the article whose Remote/Expediter Printers section reads 'Remote Printers (also called Kitchen Printers) send tickets from the Workstation to locations throughout your business' at line 90. In subject (Shift4 Dine Workstation). I confirmed the KDS side independently: 'Configure a Kitchen Display System for the Workstation for Shift4 Dine' (4940326008723, # updated 2026-07-10) has no backup-screen or failover field. Printer-to-printer yes; screen failover and the no-ticket-loss guarantee absent -> partial. Upheld partial/B. source
reliability-printer-fallbackunknown / F - Printers can be grouped, items assigned to specific ticket printers, a modifier printed to a differeresolve-to-partialTHE AUDITOR'S SEVENTH SUSPICION WAS WRONG, and here is the test. ChefTab is indeed out of subject for a SkyTab record -- 'ChefTab Kitchen Video System Preferences Overview' (360038007933) is the sole home of 'Printer Error Notification: Notify the user when printer errors are encountered.' in the entire 2,192-document corpus, and it is a sibling KVS SKU. But the analyst never CREDITED ChefTab; they cited it as a near-miss to show why the alert prong is not met for Shift4 Dine. Deleting ChefTab from the record entirely leaves exactly the same arithmetic: automatic failover documented verbatim for Shift4 Dine ('FAILOVER PRINTER : Select a backup printer from the dropdown. If the primary printer is unavailable, the failover printer will automatically handle print jobs', byte-verified, # updated 2026-06-16), alert prong undocumented. Partial either way. Precedent is 51% no, but those records have no failover at all; this one has it verbatim. Upheld partial/B. source
reliability-failover-terminal-roleunknown / F - No article describes a master or primary terminal role, nor automatic promotion of another terminal upheldCorrectly declined. This is the textbook case of a zero-hit that is worse than it looks: the brief's gated-129 list IS the resilience cluster (Offline Mode, Shift4 Dine Offline Mode Issue Troubleshooting, Commerce Engine Offline Stand-In Overview and Configuration, Restaurant Manager UTG Setup for Offline Mode), all returning 401 at 37 bytes. The analyst identified that and refused a no. Exactly right. Upheld unknown/F.
hardware-drive-thruunknown / F - No outdoor menu board, order confirmation display, speaker or headset integration appears in the Harresolve-to-partialConsistency with order-capture-drive-thru CHECKED, and they are consistent rather than contradictory: hardware-drive-thru has one of four prongs documented (outdoor menu boards, via the Clarity/CRI/Evergreen/DsMenu Marketplace rows, which I verified by reading the Marketplace matrix myself -- 'Digital Menu Boards' is a real category with four partner rows), while order-capture-drive-thru has zero prongs documented. One prong met is partial; zero prongs met is no. I re-ran /[Hh]eadset|[Ii]ntercom|speaker post|order confirmation display/ across all 2,192 documents: ZERO files each. Upheld partial/B. source
delivery-route-mapunknown / F - No route sequencing or live map view for multi-stop delivery runs is documented in any Shift4 Dine aresolve-to-noPositive control: the InhouseDelivery article is the whole of Shift4 Dine's first-party delivery configuration surface, and its map field is a boundary, not a route -- byte-verified 'Orders outside this area go to third-party providers (if enabled)'. I re-ran /route optimi|multi-stop/ over all 2,192 docs: ZERO files. The only geocoded delivery mapping is in QSR & Delivery, a sibling SKU. Upheld no/B. source
delivery-driver-trackingunknown / F - Live driver GPS surfaced back to a dispatch screen is not documented in the Shift4 Dine help centre;resolve-to-noVerified independently: /GPS/ returns exactly three files corpus-wide and I opened all three -- 'Enterprise Tax Rates and Tax Groups in Appetize', 'Tax Rates and Tax Groups in Appetize' and 'GeoTax in Appetize'. All sibling-SKU tax articles; none is driver tracking. The driver-app quote is byte-present and describes the partner's app. The positive control is the same InhouseDelivery configuration enumeration. Upheld no/B. source
delivery-driver-compunknown / F - No mileage capture, per-delivery reimbursement or driver-retained tip accounting is documented in Shresolve-to-noTwo positive controls, both checked. The InhouseDelivery configuration surface carries no mileage or reimbursement field, and the Shift4 Dine Customer Hub Report Guide's Labor Reports category -- 'Employee hours, labor cost, payroll exports, overtime, and job assignments' -- enumerates no reimbursement or per-delivery driver-pay line among its 32 reports. Every mileage/reimbursement hit belongs to QSR & Delivery, a sibling SKU, correctly excluded. Upheld no/B. source
delivery-tracking-pageunknown / F - Guest-facing order status for first-party delivery is documented only as a completion notification (resolve-to-noPrecedent is 61% partial and only 15% no, so I tested this hardest of the delivery four and it holds. I read the notification block of 1500007486702 (# updated 2026-08-28) myself: the only notification setting is 'Email/SMS Notifications', described as 'Adds contacts who receive notifications for new online orders. Leave this setting blank to disable notifications.' -- merchant-facing contacts, not guests. That is a settings enumeration WITH ROOM for a guest status link that does not contain one, which is a positive control rather than a bare zero-hit. Upheld no/B. source
digital-native-appunknown / F - No branded consumer iOS/Android ordering app published under the restaurant's own name is documentedresolve-to-noTHE AUDITOR'S SIXTH SUSPICION WAS WRONG on the verdict but RIGHT that the note was loose, so I corrected the roster. I read all 74 rows of the Marketplace Integration Partner Installation Matrix myself: it is a genuine enumeration, one row per partner with Category, Installation Method and Countries, plus a separate 'Referral Partners (No Customer Hub Integration)' list. It is NOT partial and NOT country-scoped (country is a per-row field), so the four digital no's that lean on it do rest on a real enumeration. The analyst's Online Ordering roster was INCOMPLETE: it omitted Appfront, ChowNow, ToGo Technologies, Real Time Ordering, Eatsy Orders, Delivery Collective Inc and SWIPEBY. Corrected in the note. The verdict is unaffected, because no row is described as a branded-app builder and the claim is about what the VENDOR offers rather than what a partner redirect might sell: my own grep for /branded (mobile )?app|native app|white.?label/ over all 2,192 documents returns zero, and every App Store / Google Play mention is a Shift4 staff app (InCharge, Workforce Management, Authenticator) or an unrelated instruction. Shift4's own digital ordering is a menu URL plus Website Builder. Upheld no/B with corrected roster. source
digital-upsell-engineunknown / F - No upsell, cross-sell or recommendation configuration is documented for Online Ordering, the kiosk oresolve-to-partialByte-verified 'Provide AI-generated upsell recommendations during the ordering process' and the AI Settings step in 52146952502547 (# updated 2026-06-02), and confirmed Horago is documented in Shift4's own KB against Shift4 Dine, whose menu it syncs -- in subject. Confirmed the refusal to reach yes: Shift4 Dine's first-party Online Ordering guide has no upsell surface. One correction that does not change the verdict: an attach-rate measure does exist in Shift4 Dine, the Modifier Mix Report's 'Attach Rate' column (51644639809427, # updated 2026-08-05), but it measures modifier attachment generally, not attachment on suggested items, so the reporting prong of this claim is still unmet. Partial stands. Upheld partial/B. source
digital-group-orderingunknown / F - No shareable group-order link, per-person spend cap or multi-participant cart is documented for Onliresolve-to-noPositive control confirmed: the 658-line, # updated 2026-08-28 Online Ordering configuration guide is the full first-party digital ordering surface and its only sharing concept is 'Share the Online Ordering link on social media' (byte-verified). I re-ran /group order|spend cap/ myself: 'spend cap' zero files; 'group order' three files, and I opened all three -- Salon & Spa cart consolidation (sibling SKU), Shift4 Dine Display Groups (menu layout) and the SkyTab POS Winter 2025 Release's in-store 'Auto Split by Seat'. None is a shareable multi-participant cart. Upheld no/B. source
digital-catering-portalunknown / F - No distinct catering ordering flow, catering menu with minimums, lead-time rules, quotes, deposits oresolve-to-partialByte-verified the load-bearing negative, 'Payment links and emailed invoices are not supported in the current release.' in 53574813979027 (# updated 2026-08-04), and the pilot-only scoping. The analyst also correctly flagged that the sibling article 'Schedule a Future Order on Handheld' is one of the 129 gated ids -- an honest use of the measured floor, and the reason this is partial rather than a firmer verdict in either direction. Upheld partial/B. source
digital-drivethru-aiunknown / F - Loman AI is documented for inbound phone calls only. No drive-thru lane voice ordering is documentedresolve-to-noVerified: 'Loman AI is a phone answering solution built for restaurants and integrated with Shift4 Dine' is byte-present (# updated 2026-06-02), and the Marketplace matrix -- which I read in full -- files Loman AI under 'Online Ordering' and lists no drive-thru voice partner in any of its 74 rows. That is an enumeration with room. Combined with the corpus-wide zero for headset/intercom/speaker post (re-run by me: zero files each) and no drive-thru order flow at all, the claim's premise is absent. Upheld no/B. source
digital-apple-business-connectunknown / F - No Apple Business Connect placement or Apple Maps 'Order Food' custom action is mentioned anywhere iresolve-to-noPrecedent is 64% unknown, so I tested whether this is a bare zero-hit. It is not, and the discriminator is the analyst's own: Shift4 documents the exact analogue in depth -- Order with Google gets a dedicated setup article (# updated 2026-05-21), a separate FAQ article, a Google Business Profile walkthrough and its own row in the Marketplace matrix -- while /Apple Business Connect/ and /Apple Maps/ return ZERO files across all 2,192 documents on my own re-run. The Marketplace matrix is an enumeration of ordering-placement channels that had room for an Apple row and does not carry one. Asymmetric documentation against a matched comparator is a positive control. Upheld no/B. source
digital-subscriptionsunknown / F - No guest subscription or membership product (recurring billing for a fee waiver, entitlement or paidresolve-to-noThe analyst's carrier was the Shift4 Loyalty limitations article, which is marked 'Note: This feature is currently available only for Pilot users.' and enumerates only REWARD TYPES - a pilot product's coming-soon list is a thin positive control for a membership programme. Replaced with the GA native loyalty structure enumeration plus the closed Customer Hub feature list, both of which have room for a guest subscription and contain none. All quotes verified byte-present. Verdict survives on stronger evidence. source
guest-loyalty-thirdparty-identity-attachunknown / F - Nothing documents what guest identity, if any, arrives with a DoorDash, Uber Eats or Grubhub order aresolve-to-partialSuspicion tested: that the partial rested on the roadmap sentence 'In a future release...'. It does not. I re-read the article: the roadmap sentence is the DISQUALIFIER that keeps the cell off yes, while the partial rests on the present-tense 'their record will be saved and linked by email address' plus the field-by-field sync table. Both quotes byte-present in the cited file; the Business Settings quotes byte-present at lines 222 and 224 of that article's text. Third-party scope confirmed by the Business Settings sentence, not inferred. Upheld unchanged. source
guest-loyalty-tiersunknown / F - No status tier, automatic promotion or demotion mechanism is documented in either the established loresolve-to-noConsistency test against guest-loyalty-offer-stacking-rules = partial: the two rest on DIFFERENT subsystems and do not contradict. Stacking is documented in the Discount Type Purchase Rules engine, and the corpus explicitly segregates the two - 'These discounts work outside the standard discounts and won't appear in the regular discount sections.' A discount precedence ladder implies nothing about loyalty status tiers. Evidence replaced because the analyst's carrier (Shift4 Loyalty Limitations) is a PILOT product ('Note: This feature is currently available only for Pilot users.') enumerating reward types, which is not where a tier would live; the GA structural enumeration is the real positive control. Value unchanged. source
guest-loyalty-offline-behaviorunknown / F - The offline FAQ enumerates what breaks offline (pre-auths, refunds, Customer-facing Display payment,upheldChecked that the analyst applied the protection rather than smuggling in a no. They did: value unknown, grade F, rationale naming the gated cluster. I re-read all three public offline articles and confirmed loyalty is absent from them, and found one strengthening fact the analyst missed - the offline unavailability list names Customer Hub data syncing, which is the very channel loyalty balances traverse. Upheld.
guest-loyalty-offer-stacking-rulesunknown / F - Discount Type Purchase Rules document qualifying conditions and a floor of $0, and loyalty discountsresolve-to-partialRead the whole article. Every quoted string is byte-present, including the full five-rung ladder and the complete Additional Criteria list, and that list is a genuine closed enumeration with room for a combinability toggle - so the shortfall half of the partial is itself a positive control, not a zero-hit. The only exclusivity construct corpus-wide, 'Enterprise Exclusivity Groups for Appetize', is correctly excluded as a sibling product under the Shift4-Dine subject boundary. Upheld unchanged. source
guest-loyalty-rfm-segmentationunknown / F - No automatic lifecycle segmentation (new, regular, at-risk, lapsed, VIP) is documented. The Customerresolve-to-noI attacked the weakest seam myself: 'Invite to visit again: Sent to customers based on criteria you enter' leaves its criteria unenumerated, so a recency trigger could have hidden there. Test: searched all 2,192 docs for 'days since|last visit|have not visited|visit frequency|total spend' - five files, of which the only Shift4 Dine one is the Customer Directory report, whose sort order is alphabetical and which offers no filter. The recency dimension is displayed but never segmented on. Two enumerations with room beat a bare zero-hit; this is a positive control, not a floor artefact. Upheld. source
guest-loyalty-10dlc-registrationunknown / F - A2P 10DLC brand or campaign registration is never mentioned. Shift4 states outbound marketing SMS isupheldFound independently while auditing the cross-location cell: the loyalty overview's SMS opt-in paragraph directly falsifies the 'no SMS at all' premise the no was built on. Re-ran the analyst's own regexes and confirmed the zero-hit is real - but a real zero-hit is exactly what must be downgraded once the positive control evaporates. Overturned to unknown.
guest-loyalty-referral-programunknown / F - No native guest referral mechanic with per-guest codes, first-order attribution or two-sided rewardsresolve-to-noRan the search myself: '[Rr]efer(ral|-a-friend| a friend)' returns 8 files corpus-wide and every hit is 'Voice Referral' card-authorization handling in Transaction Manager or Dynamics 365 - the analyst's characterisation is exact. The verdict does not rest on that zero-hit alone: the Add a Loyalty Promotion article is a true positive control, an enumerated promotion-type picker with exactly two members. Kept at B. source
guest-loyalty-wallet-passunknown / F - No Apple Wallet or Google Wallet loyalty pass is documented. Loyalty identity is a phone number lookresolve-to-noRe-ran the wallet regex: exactly 2 files, both as described, so the near-miss handling is honest. Grade held at B rather than downgraded because the FAQ's enrolment-and-accounts section is a real enumeration of member-side access channels with room for a pass, not a bare zero-hit. Noted but not disqualifying: Shift4 Loyalty carries 'Note: This feature is currently available only for Pilot users.', so this is a positive control over a pilot product; the GA Customer Hub loyalty documentation (16166684069011) likewise enumerates Programs, Discounts and Members with no pass artefact. Upheld. source
guest-loyalty-ai-offer-recommendationunknown / F - No AI or ML generation of offer content, target audience or send timing is documented in Customer Enresolve-to-noThe analyst's carrier was the Shift4 Loyalty limitations article - a pilot product's coming-soon list, which is not an enumeration with room for AI targeting. Replaced with the campaign engine's own step-by-step enumeration, which covers exactly the three decisions this cell asks about (offer content, audience, send time) and assigns all three to the operator. Added the discriminating control the analyst only half-used: the corpus advertises AI by name in Website Builder, so the vendor's own naming convention would have surfaced an AI recommender had one shipped. Value unchanged, evidence strengthened from a zero-hit to a positive control. source
labor-photo-punch-verificationunknown / F - No photo capture or facial verification at punch is documented for the workstation or the Workforce resolve-to-noRead both articles in full. Every quoted setting is byte-present and the Employee Labor Settings list is genuinely closed - it is the screen a photo-punch toggle would live on, and it enumerates seven controls of which exactly one is the identity control (Mag card). That is a positive control, not a zero-hit. The coordinator's 'a device has a camera' proposal is correctly killed. Precedent is 0% yes across 41 records. Upheld. source
labor-offline-time-punchunknown / F - The offline FAQ covers payments, printing and KDS but never states whether clock-in/clock-out is recupheldChecked that the protection was applied and not smuggled past: value unknown, grade F, rationale naming the gated titles. Independently confirmed the two timeclock articles are silent on connectivity by reading both in full, and confirmed the sibling attribution of the two offline-clock hits. Upheld.
labor-minor-labor-rulesunknown / F - Custom Compliance Rule Groups exist and could plausibly express minor-labor limits, but no article dresolve-to-noRead both articles in full. The strongest element is the framing sentence the analyst did not quote - 'The labor settings of the business depend on the employer's state' - which establishes that this screen IS where a jurisdictional minor rule would live, making its eight-item enumeration a proper positive control rather than an incidental list. The one plausible alternative home, Workforce Management compliance, is confirmed break-only from its own navigation path. Upheld; note strengthened. source
labor-qualified-tips-w2-reportingunknown / F - No article addresses the 2026 W-2 Box 12 code TP or Box 14b qualified-tips requirements, nor a TreasupheldTest: I read the whole of 360035408973 looking for a field list. There is none - the payroll section is five report names, and the only field-level enumerations in the article are the Business Labor settings and the Employee Labor settings, neither of which is a payroll export. Also checked line 2 of the text file: '# updated 2026-05-12T12:03:26Z', which predates any plausible TY2026 W-2 documentation. Overturned to unknown.
reporting-nl-queryunknown / F - No natural-language query or AI analytics assistant is documented for Business Intelligence or the Cresolve-to-noBoth limbs of the suspicion failed. Limb one, that the no rests on a sibling product: it does not - the carrier is the Business Intelligence Key Features article, and Harbortouch Retail's Query Builder appears in the analyst's note only as a named-and-rejected near-miss, which is correct handling. Limb two, that a Query Builder is not the same thing as an NL assistant: the analyst says exactly that and rejects it. What I did change is the GRADE. This article is marketing copy hosted on the help centre - 'The Future of Restaurant Analytics is Here', 'cutting-edge', 'Reach out today to see how Business Intelligence can take your restaurant's performance to the next level' - so it is a vendor marketing source, grade C, not product documentation at B. The verdict survives on it because a 2026 promotional feature reel is precisely where an AI assistant would be advertised, and the corpus proves Shift4 names AI when it has it (Website Builder). Value upheld, grade downgraded B to C. source
multi-location-cross-location-loyaltyunknown / F - Loyalty is configured per location in the Customer Hub and lookup is by phone number, but no articleresolve-to-yesThe suspicion asked whether a member's balance genuinely spans LOCATIONS or whether only one program exists in one account, and demanded the multi-location part be quoted. Test: ran 'loyalt.*(multiple locations|all locations|across locations|other locations|each location)' over all 2,192 held docs - two files, one a sibling gift-card portal, the other article 16166684069011, which the analyst never cited. It contains the exact sentence the suspicion asked for: the loyalty record 'will be pooled across all our locations', and the member landing page shows data 'gathered from all locations in the program'. So the yes is right but was under-evidenced - the analyst chained three inferences (program spans locations, member belongs to program, therefore balance spans) where one first-party sentence says it. Evidence replaced. On precedent this yes is not unusual: multi-location-cross-location-loyalty runs 31% yes across 45 records, the highest yes rate of any cell in this batch. Grade B, vendor product documentation. source
multi-location-multi-brandunknown / F - Delivery Management supports adding a Virtual Location and Uber Eats virtual restaurants are referenresolve-to-partialThe suspicion was that the partial rested on 'Configure Revenue Classes', a reporting construct that cannot reach multi-brand. Test: I read the cited article in full. The partial rests entirely on the virtual-location flow; revenue classes appear in the analyst's note only as the nearest reporting construct, explicitly REJECTED as gratuity-and-tax scoped rather than brand-scoped, which is the correct call. The virtual-location flow does reach multi-brand on the identity and menu axes while stopping short of brand-level receipts and reporting, which is what partial means. Subject boundary checked: Delivery Management is reached from the Shift4 Dine Customer Hub, not a sibling product. Upheld unchanged. source
extensibility-doordash-preferredno/B, cited to DoorDash's 2026 announcement post, on the ground that Shift4/SkyTab was not among the ten names it lists.upgrade-to-yesFetched DoorDash's own provider registry at https://merchants.doordash.com/api/partner-integrations on 2026-09-11 (robots.txt read first: Allow: / with only /cdn-cgi/ and /monitoring barred). It returns 64 providers each carrying a qualityStatus of PREFERRED, CERTIFIED or AT_RISK_OF_SUSPENSION - a census, not a floor, and the instrument the program page means when it says the roster is tracked in real time. The 2026 announcement post this corpus cited introduces its ten names with the word 'include', so it was never a ceiling. The registry carries TWO Shift4 entries and they are different SKUs. `shift4` is PREFERRED, PROVIDER_AGGREGATION_TYPE_POS, 8 of 8 high-quality features, and its own providerPortalLink is https://www.skytab.com/ - that link is what settles which SKU the preferred entry covers. `xdine_production` ('Shift4/XDine') is a MIDDLEWARE_AGGREGATOR at 3 of 8 features and only CERTIFIED, portal link shift4.com. The prior verdict was reading a floor as a ceiling. source
guest-loyalty-offline-behaviorunknown (F) — never examinedresolve-to-noUpheld at no/B on my own re-reading. The coordinator's inverted scope warning did NOT change this cell: I re-derived the Shift4 Dine = SkyTab identity first-hand from the unbroken release-note version series and from three articles that name both brands in one sentence, so the cited articles are SkyTab's own documentation, not a sibling product's. Every quote was verified verbatim inside the article actually cited, and every cited article is in category Shift4 Dine. I re-ran the fixpoint (1,388 referenced / 195 absent / 0 x 200 / 130 x 401 / 69 x 404, four fabricated controls all 404) and reproduced the proposer's shape. What I added and the proposer did not: the video hole (four offline-titled Shift4 Dine articles carry Vimeo embeds I cannot read), and a recovery of anchor text for all 130 gated ids rather than the 38 that carry a URL slug. The two gated SkyTab offline articles are in-area on the offline axis, which is why the note now names them rather than burying them; the cell survives because the LOYALTY side of the conjunction is fully readable, carries no video at all, and is completely silent about connectivity.
guest-loyalty-10dlc-registrationunknown (F) — never examinedresolve-to-noValue held at no/B but the note is substantially rewritten and the proposer's framing of this as 'the strongest of the nine' is withdrawn. I ran the inverse test the brief asked for and it partly succeeded: every SMS surface in this KB is sent by Shift4's own platform on Shift4's own brand - the Loyalty Overview says in terms that by opting in the member agrees to receive text marketing 'from us' - so A2P 10DLC brand and campaign registration for that traffic sits with Shift4 as the sender, exactly where a messaging aggregator would silently handle it, and the documentation's silence is therefore informative about DOCUMENTATION and not proof that registration is unperformed. I nearly moved this to partial on that reasoning and did not, because a partial needs a MET conjunct that is actually documented and nothing here documents handling; inferring registration from the mere existence of SMS traffic would be the inference-for-evidence trap. The zeros themselves reproduce exactly on my own harness (12 registration terms at 0 against SMS = 32 documents and 'text message' = 21), and the raw-byte W-2 trap reproduces. The coordinator's inverted scope warning did not change this cell.
reporting-history-retentionunknown (F) — never examinedresolve-to-partialOVERTURNED from no to partial. The proposal's central sentence - that 'SkyTab's reporting documentation nowhere states any retention period at all, and the published contracts that do address retention set no queryable window' - is false, and so is its published control figure 'two years = 0'. Shift4's Gateway Terms and Conditions section 24.23 is headed 'Transaction History Retention Period' and commits to a rolling maximum of twenty-four (24) months of the merchant's financial reporting data; the Zendesk KB independently corroborates the same figure from the other side, where Transaction Manager's Advanced Search 'will look back through two years (to date) of transactions' and a transaction 'Is deleted after two years'. The proposer's numeric-window zeros were computed inside the Shift4 Dine category and then published as flat corpus-wide zeros: corpus-wide 'two years' is 2 documents, and one of the two is the article that bears on this cell. Two independent instruments agreeing on 24 months is exactly what the claim asks to see, so a no cannot stand. It is not a yes because the contract makes any change to that window, and any post-termination access to it, a fee, which is the claim's own disqualifier. Scope is stated in the note: the Gateway agreement and Transaction Manager are platform-wide Shift4 instruments that the SkyTab back office ships and inherits, and I justify that rather than assuming it.
reliability-failover-terminal-roleunknown (F) — never examinedresolve-to-noValue held at no/B; the note's advocacy is removed. I pushed on the brief's specific challenge - a no whose note argues the absence is a strength is suspicious - and the challenge is fair about the WORDING but not about the VALUE. I have deleted the sentence instructing the reader not to mistake this for a weakness and replaced it with a neutral statement of the architecture and its limits. The value survives because the claim as worded asks for automatic assumption of a master or server role, and SkyTab documents no such role in a nine-term vocabulary census across all 1,031 Shift4 Dine articles, while positively documenting a different mechanism (a RabbitMQ synchronisation bus, cloud-published settings, per-station independence, and a closed enumeration of the connections the system believes can break) - which is the shape of no that survives audit. Corpus consistency supports it: this claim runs no 24 / partial 9 / unknown 12 / yes 2 across the atlas. I did NOT drop it to unknown for the one in-area gated article, and I say why in the note.
commercial-rate-increase-clauseunknown (F) — never examinedresolve-to-noUpheld at no/B. I re-fetched the PDF myself and confirmed it is the same document with or without the ?refresh= query string (md5-identical across the cited value, a bogus value and no query at all), extracted it both ways, and verified every quoted clause under BOTH pdftotext modes. This is the strongest of the nine: the verdict rests on express adverse contract language, not on an absence, so the PDF extraction hazards could only have damaged it by hiding a cap, and the tokenised zero on cap and capped is invariant across plain and layout in all three contracts while the squashed probe's 3/4/5 for cap is pure noise from 'capacity' and 'capital'. The applicability rule is satisfied: this is the operative fee clause of the processing agreement, not a DPA settling rights only. I added the Gateway Terms and Conditions to the checked set and it carries the same CPI-U escalator shape.
commercial-data-ownership-clauseunknown (F) — never examinedresolve-to-noValue held at no/B; note amended to add a countervailing clause the proposer missed and to correct a misquote. The MPA section 11.3 quote verifies verbatim under both pdftotext modes and is express adverse language on both limbs, so the applicability rule is satisfied and this no does not rest on my failing to find a clause. What I added: Gateway Terms and Conditions section 18.1 IS a genuine purpose limitation on Shift4's use of data, scoped to Cardholder Information, and the record should carry it rather than only the adverse clauses; it does not rescue the cell because the claim's first limb - the merchant owns its transaction and customer data - is expressly contradicted. I also corrected the proposer's quotation of Dine POS SSA section 4.g, which reads 'Merchant shall be solely responsible', not 'Merchant is solely responsible'.
labor-offline-time-punchunknown (F) — never examinedresolve-to-partialUpheld at partial/B. I verified all four load-bearing quotes verbatim inside the cited article, which is category Shift4 Dine section Use and Operation, so it is SkyTab's own documentation. The partial is NOT self-refuting: a named, automatic, documented on-reconnect reconciliation mechanism genuinely exists, which is more than silence, while the pilot restriction and the vendor's own instruction to review merged times for accuracy defeat the claim's 'without loss or duplicate entries'. I reproduced the vocabulary trap independently - 'time punch' is 0 documents and punch is 7 (1 in Shift4 Dine), while the vendor's words time clock, timeclock, clock in and clock out return 39, 18, 33 and 43 - so a punch-based zero would have been a pure reader artefact. Added: two timeclock-titled Shift4 Dine articles carry video, which is a hole on the shortfall I list third.
labor-qualified-tips-w2-reportingunknown (F) — never examinedresolve-to-partialUpheld at partial/B. I checked the self-refutation risk the brief named and the partial is safe: of the claim's three conjuncts, conjunct one is genuinely met and I verified both halves of the quote verbatim inside the cited article, which is category Shift4 Dine section Reports. Conjuncts two and three are absent on thirteen tokenised zeros that I reproduced independently, and those zeros are bounded by a live vendor vocabulary in the same field - payroll 37 documents, 'cash tips' 23, 'declared tips' 6, 'payroll export' 6. The raw-byte W-2 trap reproduces exactly on my harness and is published. The differentiator grade floor does not bite because the value is not a yes.
commercial-post-termination-export-windowunknown (F) — never examinedresolve-to-partialValue held at partial/B, note materially strengthened and corrected. The proposer's first shortfall - 'there is no defined number of days' - is only half true: I found Gateway Terms and Conditions section 24.24, which the proposer never read, and it ties post-termination access to the Transaction History Retention Period, which section 24.23 defines as twenty-four months. That makes the partial stronger, not weaker, so the value is unchanged but the reasoning had to be rebuilt. The fee gate in the same clause is what keeps it off a yes. I also verified the Customer Hub section 10.3 quote under both pdftotext modes, confirmed the ?refresh= query string is a cache-buster (md5-identical documents), corrected the proposer's misquote of Dine POS SSA section 4.g, and could NOT verify the existence of a separate 'SkyTab Workforce Terms of Use' - the legal index publishes one Workforce Terms of Use and the token SkyTab does not occur in it - so that attribution is dropped.

Sources

Every URL this record cites. 117 in total.