Punchh

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

UPHELD, now cited, and settled on the vendor's own exclusion rather than on a keyword count. Punchh does not author modifiers; it receives them, one level deep, and its own document says so in the negative. Modifier structure is carried in a flat `menu_items` array where the only expression of parenthood is the `serial_number` string: "The purpose of this field is to identify which items on the check are base items and which items are modifiers to the base items... If you have an item with serial number 3.0, any items with serial number 3.x will modify the 3.0 item." Then the exclusion, verbatim: "Serialization is limited to one decimal point, so you can only modify the base item. You cannot modify a modifier with 1.x.x, and so on." The claim asks for at least three levels; the publisher states that the second level is the last one representable. There is no modifier group construct anywhere -- "modifier group" reads 0 across the 228 pages, the 15 specs and the 2,586 KB titles, as do min/max selection counts and any forced-selection flag -- and the word "modifier" occurs on only 6 pages and 9 KB titles, every one of them the offer-qualification sense ("How to set up a Line Item Selector to include Modifiers for Offers", "What does Maximum Discounted Modifiers referes [sic] to while creating a LIS"): selecting against modifiers a POS reported, never defining them. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/menu-items · retrieved 2026-09-08

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

UPHELD, now cited. There is no size dimension and no modifier price to vary. The menu item object is published as an exhaustive field table -- "The following table describes the fields that comprise the menu items object" -- and its whole field set is `item_name`, `item_qty`, `item_amount`, `menu_item_type`, `menu_item_id`, `menu_family`, `menu_major_group`, `serial_number`. No size, no unit price, no parent reference beyond the one-decimal serial number, no matrix construct. `item_amount` is not a price at all in the configurable sense: "The total price of the line item... If you have three items with the same ID on the check, this amount should represent the total amount for the three items, not the unit price." The stored side is narrower still. The KB's Product Catalog article states what Punchh keeps: "our database imports data for the following fields", and lists five: Item Name, Menu Item ID, Menu Item Type, Item Family, Item Major Group. No price among them. Price reaches Punchh only as a per-transaction amount, so there is no item record for a price matrix to hang on. "price by size", "size price", "price tier" and "price zone" each read 0 across the whole corpus and all 2,586 KB titles. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/menu-items · retrieved 2026-09-08

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

menu-pricing-fractional-placement

Not scored by this record.

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

Not scored by this record.

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

UPHELD, now cited. A topping is representable in Punchh and a tier of one is not. The vendor's own worked example carries a topping as an ordinary flat-priced line -- a "Beef Cotto Salame" at serial_number 1.1 modifying a Muffuletta at 1.0, and the pizza illustration is Punchh's own: "The pizza has an add-on topping modifier... Pizza - 1.0; Add-on topping - 1.1; Salad - 2.0." The quantity field is a plain integer with an aggregation instruction that forecloses tiering: "The quantity of the item on the check. If you have more than one of the same item on the check, include the items in one menu item object and reflect the total quantity in this field." Light/regular/extra/double and a per-tier price multiplier have nowhere to live: there is no tier field, no multiplier field and no unit price on the line. "quantity tier" and "topping" each read 0 across the 2,586 KB titles; "multiplier" reads 3 there and all 3 are the loyalty point multiplier ("How do point multipliers work", "How do we apply a point multiplier to menu items in the QC"), which multiplies points earned, not the price of a modifier. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/menu-items · retrieved 2026-09-08

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

menu-pricing-versioning-effective-dates

Not scored by this record.

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

menu-pricing-franchise-hierarchy

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

menu-pricing-dynamic-pricing

Not scored by this record.

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

Not scored by this record.

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

payments-published-rates

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

payments-emv-nfc

UPHELD, now cited, and this is the cell where the vocabulary is present and the thing is not. Punchh ships no payment terminal, so there is no first-party terminal for the claim to be true of. NFC does appear -- 3 pages -- but every occurrence is a loyalty pass being read by somebody else's reader: the prerequisite Punchh publishes is an "Apple VAS-certified payment terminal with NFC capabilities (terminal with the ability to read the pass from the user's device on the tap...)", and the data path is "The POS system collects Apple NFC data (apple_nfc_data) sent by the payment terminal and uses this information to query the" Punchh User Look-up API. The tap identifies the guest; the card is authorised by a terminal Punchh neither sells nor certifies, and the merchant must obtain the NFC certificate from Apple themselves. The Google Wallet page is the same shape, requiring the operator's own Google Pay & Wallet Console issuer account. "apple pay" and "google pay" likewise attach only to pass enrolment ("initiate only if a user who does not have a pass opted to pay via Apple Pay"). "contactless", "card present" and "tokeniz" read 0 across the corpus, and "emv" reads 0 in the EMV sense -- its 2 substring hits are the identifier "shl1s59zemvqd" and an iOS `systemVersion` snippet, both read and both noise. EMV and NFC read 0 across all 2,586 KB titles. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/applepassintegrationwithpos · retrieved 2026-09-08

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

RESOLVED from unknown. The placeholder marked an unexamined cell, and it was badly wrong: Punchh runs a full first-party gift card program, not an integration stub. The Mobile API publishes 17 gift card operations (15 under /api2/mobile/gift_cards, plus Create Gift Card Claim Token and Transfer a Gift Card Using Invitation Claim Token) -- Purchase, Reload, Import Physical Gift Card, Fetch Gift Card Balance, Fetch Gift Card Transaction History, Gift, Share, Revoke Sharing, Transfer, Consolidate, Tip via Gift Card, Get EPIN -- against 40 property names beginning `gift_card` including `enable_gift_card_auto_reload`, `gift_card_auto_reload_threshold`, `max_gift_card_balance` and `require_passcode_for_gift_card`, and the webhook manager ships 14 dedicated gift-card event pages (purchased, reloaded, redeemed, gifted, received, shared, transferred, auto-reload enabled/disabled/reminder/payment-error). Balance is real-time and per-card: `GET /api2/mobile/gift_cards/{uuid}/balance`, and the Gift Card Redeemed event carries `gift_card_balance` at the moment of payment. Redemption at the register is documented through Single Scan Flow: "Punchh single scan flow allows a user to earn points for purchases, redeem rewards, and pay using a gift card, credit card, or saved credit card ... all in one scan", with `payment_type` = `GiftCard`, and the redeemed event fires "when a guest redeems a gift card by making a payment using the gift card at the POS". PARTIAL rather than yes on the claim's last clause only: the online-ordering channel is not shown. The gift card resource exists in the Mobile API (131 `gift_card` occurrences) and the Platform Functions API (8); the Online Ordering and SSO API spec contains the string zero times, and its only "gift" tokens are `gifted_tier` and `gift_reason`, which are loyalty-tier gifting and a support field, not a stored-value instrument. 43 of the 2,586 KB titles concern gift cards and none of them places one in an online order. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/single-scan-flow · retrieved 2026-09-08

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

payments-house-accounts

Not scored by this record.

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

Not scored by this record.

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

Punchh has no register, and its own POS docs place the transaction at the integrating POS: 'the POS operator... first identifies the user by performing a user look-up... and then creates a check-in', with the POS sending order details to Punchh via API. The only refund/void surface Punchh itself ships is the POS Payments API for its Single Scan Flow — 'After a payment is accepted/processed, you can use the Refund Payment API to refund the payment', and the Void/Cancel Payment API is 'most commonly used when the POS has issues such as timeout or connectivity'. Those endpoints authenticate as the machine, not the employee ('Authorization: Token token=LOCATION_KEY_GOES_HERE, btoken=BUSINESS_KEY_GOES_HERE') — there is no per-employee or role credential in the POS API scheme, no manager-PIN or approval step anywhere in the payment operation docs, and the published webhook event list has no voided or refunded event. Role-gated void/refund authorization with an approver-identifying audit trail is a control of the third-party POS Punchh integrates with, not of Punchh. https://developers.partech.com/docs/dev-portal-pos/additional-topics/pos-payments · retrieved 2026-08-04

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

payments-chargeback-tooling

Not scored by this record.

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

Not scored by this record.

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

payments-payout-timing

Not scored by this record.

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

payments-multi-entity-routing

Not scored by this record.

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

Not scored by this record.

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

UPHELD, now cited. Punchh has no driver entity of any kind. Across 228 developer pages, 15 specs (292 operations, 1,129 property names) and 2,586 KB titles there is no driver object, no assignment state, no clock-in/out and no run history: "courier", "in-house driver", "driver roster", "driver assignment" and "run history" all read 0, and no property name contains "driver". The two substring hits were read and are homonyms -- a guest survey option coded `truck_driver` ("Are you a professional truck driver?"), and a KB article titled "What are Dumpster drivers", which is Punchh's fraud vocabulary for guests who scan receipts retrieved from the bin. Delivery reaches Punchh only as money already collected by somebody else: the check details guide classifies it under line type S, "Any item representing money received that is not a sale. For example: service charges, delivery fees, tips, purchase of gift cards/certificates". The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/poscheckdetailsguide · retrieved 2026-09-08

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

UPHELD, now cited. There is no dispatch surface because there is nothing to dispatch -- Punchh never holds an open order. Its POS contract is post-transaction: the integrating POS "must call the" Create Check-in "API endpoint for every loyalty guest at the end of a transaction". "expo screen", "undispatched", "multi-order run" and "driver availability" read 0 across the corpus and all 2,586 KB titles. "dispatch" reads 2 pages and both are the webhook sense of the word -- a field "will be dispatched via functional mapping for `guest_create` and `guest_update` events" -- which is message delivery to Braze or mParticle, not order dispatch to a driver. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/poscheckdetailsguide · retrieved 2026-09-08

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

Not scored by this record.

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

delivery-driver-tracking

Not scored by this record.

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

Not scored by this record.

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

UPHELD, now cited, and the near-miss was checked rather than assumed. "delivery fee" does occur -- 7 pages, 9 specs -- but always as a line item Punchh is TOLD about after the fact, never one it computes: line type S covers "service charges, delivery fees, tips, purchase of gift cards/certificates", money received that is not a sale, sent in so that earning rules can exclude it. A zone would need a zone record, a fee, an order minimum and a promise time; Punchh publishes none of the four. "delivery zone", "order minimum" and "promise time" read 0 across the corpus and all 2,586 KB titles, and the 8 delivery-titled KB articles are about third-party delivery services (barcode suppression for Toast and Aloha third-party orders, a pick-up-versus-delivery flag on an online order) plus, twice, e-mail and App Store delivery errors. Punchh does not validate a customer address for fee purposes at all -- its one address article is an online-ordering geocoding error. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/poscheckdetailsguide · retrieved 2026-09-08

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

delivery-offline-behavior

Not scored by this record.

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

PAR Engagement bundles ordering with loyalty and marketing; ordering is a sibling module rather than Punchh itself. https://punchh.com/ · retrieved 2026-08-01

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

digital-menu-single-source

Punchh itself owns no menu record: menu items enter Punchh only as reference data the POS or ordering system sends with check-ins and redemptions, used to decide 'whether the offer is valid given the current cart items' and 'how many points a guest should earn', and the Online Ordering docs exist to 'Integrate Punchh Loyalty with your online ordering system' — the ordering channel is someone else's. Within the PAR Engagement bundle the first-party ordering channel is the sibling PAR Ordering product, whose page on punchh.com markets exactly this capability: 'Import menus directly from your POS, push updates instantly, and roll out changes in minutes not hours' and 'Control every menu across every channel from a single interface'. Shortfall: single-source menus require buying the sibling PAR Ordering product plus a supported POS menu import — Punchh alone has no digital menu — and the propagation claim rests on feature-page marketing, not admin-guide documentation. https://punchh.com/solutions/ordering/ · retrieved 2026-08-04

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

Not scored by this record.

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

"One-Tap Loyalty" is marketed when the products integrate; saved tokenized cards and one-tap reorder are not separately documented. https://punchh.com/ · retrieved 2026-08-01

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

digital-upsell-engine

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

digital-drivethru-ai

Not scored by this record.

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

digital-sms-ordering

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Guest360 builds rich profiles combining loyalty, ordering and marketing behaviour across touchpoints, including pre-enrolment; merge rules not published. https://punchh.com/ · retrieved 2026-08-01

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

guest-loyalty-thirdparty-identity-attach

Not scored by this record.

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

Tiers and personalized rewards are documented; points-per-dollar versus visit/punch accrual is not separately enumerated publicly. https://punchh.com/ · retrieved 2026-08-01

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

guest-loyalty-tiers

Not scored by this record.

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

guest-loyalty-offline-behavior

Not scored by this record.

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

guest-loyalty-offer-stacking-rules

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Segmentation plus real-time personalized offers across email, SMS, app and web; named always-on birthday/win-back templates not published. https://punchh.com/ · retrieved 2026-08-01

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

guest-loyalty-native-email-sms

Not scored by this record.

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

guest-loyalty-consent-management

Not scored by this record.

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

guest-loyalty-10dlc-registration

Not scored by this record.

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

guest-loyalty-campaign-attribution

Not scored by this record.

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

Not scored by this record.

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

guest-loyalty-cdp-event-api

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

UPHELD, now cited. Punchh knows an employee only as two strings on a redemption payload. `employee_id` and `employee_name` are the sole employee-shaped properties in 1,129, and they arrive inside the check body ("employee_id": "7") for attribution of a discount, not as a record Punchh maintains. Nor could a terminal authenticate a person against Punchh if it wanted to: POS API auth is machine-level, "Authorization: Token token=LOCATION_KEY_GOES_HERE, btoken=BUSINESS_KEY_GOES_HERE", a location key and a business key with no per-employee or role credential anywhere in the scheme. "clock in", "clock out", "timecard", "time clock", "punch in" and "payroll" read 0 across 228 pages, 15 specs and all 2,586 KB titles; the corpus-wide "punch" count is Punchh's own name and its `punch_cards` loyalty construct, and the 3 "badge" titles are gamification badges a GUEST earns, not an employee credential. The one "labor" substring in the specs is the word "collaborate". The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/make-first-pos-call · retrieved 2026-09-08

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

Not scored by this record.

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

labor-geofenced-mobile-punch

Not scored by this record.

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

Not scored by this record.

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

Punchh roles are built from individually toggled permissions under Settings > Admin Users > Roles > [role] — the help centre names discrete toggles such as 'Roles and Permissions Management', 'Settings Read Only', 'Settings Advanced' and 'Allow Access to Report Section' — and admins are separately scoped to locations, store numbers or location groups (Create Business Admin accepts location_ids, store_numbers, location_group_ids and role_id). Shortfall: some capabilities are hard-wired to the three built-in tiers and cannot be granted a la carte. Punchh states 'there is no a-la-carte permission that can be enabled for a role to allow access to all location data. An admin user's role must be granted at least Business Manager permissions', and building or modifying location groups 'is restricted to the Business Owner and Business Manager only. Thus, any other role will not be able to add or edit any location group by enabling any specific permission.' https://support.punchh.com/s/article/What-roles-in-Punchh-can-see-all-location-data-from-the-Dashboard · retrieved 2026-08-04

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

Punchh keeps per-object Audit Logs used 'to determine who made changes to a user, setting or campaign' — reachable from the top right of an individual admin user, role, guest or campaign, and addressable by object type (dashboard.punchh.com/businesses/###/audit?item_type=AppMessage) — plus a Reports > Admin Activity report that 'pulls in all historical data around Admin gifting activity' and 'shows all admin activity since the inception of the business's Punchh platform'. Shortfall: this covers configuration changes and discretionary gifting, not an override-approval workflow — Punchh documents no second-approver override flow, and no page asserts the log is immutable or tamper-evident. Coverage is also uneven by the vendor's own account: the log is absent from section landing pages and a guest's audit log is blank unless the profile was changed manually. https://support.punchh.com/s/article/Why-does-the-Audit-Log-not-appear-as-expected-for-certain-sections-of-Punchh · retrieved 2026-08-04

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

labor-fair-workweek-support

Not scored by this record.

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

labor-minor-labor-rules

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

labor-digital-onboarding-i9

Not scored by this record.

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

Not scored by this record.

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

UPHELD, now cited. Punchh has no ingredient, so it can have no recipe. The only record it keeps of a sellable item is the Product Catalog, and the KB states both its contents and its origin: "our database imports data for the following fields" -- Item Name, Menu Item ID, Menu Item Type, Item Family, Item Major Group -- added "automatically when we receive a transaction and there's no way to manually add or remove Menu Items." Five fields, no cost, no components, no sub-recipes. "recipe", "bill of material", "plate cost", "costing" and "ingredient" read 0 across 228 pages, 15 specs and all 2,586 KB titles. The word "inventory" occurs, and it is a homonym that was opened: it is SWAG inventory, the merchandise a guest buys with saved points, where "The API handles the full redemption flow end-to-end - including eligibility checks, point deduction, inventory decrement, reward creation, and optional shipping detail capture." Branded merchandise stock is not food cost. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/How-does-Punchh-import-Menu-Items-from-our-POS · retrieved 2026-09-08

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

UPHELD, now cited. There is no unit to convert. The Product Catalog Punchh maintains holds Item Name, Menu Item ID, Menu Item Type, Item Family and Item Major Group and nothing else, and on the wire an item carries `item_qty`, documented only as "The quantity of the item on the check" -- a count of things sold, with no unit attached and no second unit to relate it to. "conversion factor", "purchase unit", "recipe unit", "yield" and "waste" read 0 across 228 pages, 15 specs and all 2,586 KB titles. The single "unit of measure" substring in the specs was read and belongs to the swag-redemption merchandise flow, which is Punchh's own points-for-goods feature and not a raw-to-usable conversion. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/How-does-Punchh-import-Menu-Items-from-our-POS · retrieved 2026-09-08

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

UPHELD, now cited. Punchh runs no count of any kind, because it holds no stock position to count against: its item record is a transaction-derived mirror -- "Menu Items are created automatically as entries in your POS system sync with Punchh... after a transaction is performed that includes the new menu items" -- with no quantity-on-hand field. "physical inventory", "spot count", "cycle count", "stock count", "par level" and "depletion" read 0 across 228 pages, 15 specs and all 2,586 KB titles. The swag inventory homonym was opened and does not rescue the cell: its stock is set by configuration through a Punchh representative ("Contact your Punchh representative to update this Punchh platform configuration"), decremented by redemption, and never counted, varianced or historised by an operator. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/How-does-Punchh-import-Menu-Items-from-our-POS · retrieved 2026-09-08

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

inventory-waste-logging

Not scored by this record.

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

inventory-transfers

Not scored by this record.

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

inventory-commissary

Not scored by this record.

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

inventory-lot-traceability

Not scored by this record.

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

Not scored by this record.

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

inventory-bar-partial-bottle

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

RESOLVED from unknown, and resolved on the vendor's own number rather than on an absence. Punchh does ship an operator dashboard at dashboard.punchh.com with a landing page showing sales -- the KB states that it "displays the net sales of the business", which "can be thought of as" qualifying spend, "or spending that can be earned on". What it is not is live. The KB publishes the refresh schedule in full: "If you do not have a specific location selected - at 3 am PST, 7 am PST, 11 am PST, 3 pm PST, 7 pm PST, and 11 pm PST. Essentially, every 4 hours... there can be a 30-45 minute window for the refresh to complete and... the 7 am PST refresh can take up to 2 hours to complete. If you have a specific location selected - once a day at 7 am PST." The claim asks for transactions reflected within minutes of the sale; the publisher documents four hours at best and twenty-four for the single-location view an operator would actually use, and the page itself carries the admission in its chrome ("Data on this page was last refreshed on [date]"). The claim's second half fails independently: the dashboard is a browser portal, and no operator-facing mobile app is documented -- the Punchh mobile app in this corpus is the GUEST app. Note also that "net sales" here is loyalty-attributed spend only, since Punchh sees a check solely when a POS posts one to it. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/How-often-does-the-Dashboard-refresh · retrieved 2026-09-08

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

UPHELD, now cited, and the two traps under this cell were both opened. Punchh publishes 89 report-titled KB articles and not one is a daily close: they are Business Liability, Lift, Location, Redemption, Coupon, Admin Activity, Week-on-Week and Payments. The nearest-named, Payments Report, is Punchh's own stored-value ledger, not a tender reconciliation -- "a breakdown of spending (including virtual gift cards, providing general information about purchases, refunds, and any failures)" -- and covers only transactions settled through Punchh's Single Scan Flow. The second trap is the phrase "End Of Day", which does occur: "Configurable POS End Of Day" is a time-of-day setting "beyond which pending points from all check-ins of the day will be automatically, finally approved", a loyalty points cutoff carrying no money at all. The claim wants gross sales, net sales, tax, tips, discounts, refunds, tender types and expected cash deposit in one document; Punchh never sees a cash drawer, and "closeout", "close out", "z report", "daily close", "cash deposit" and "tender type" read 0 across 228 pages, 15 specs and all 2,586 KB titles. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/What-is-the-Payments-Report · retrieved 2026-09-08

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

UPHELD, now cited. "product mix", "pmix", "item mix", "daypart" and "revenue center" read 0 across the 2,586 KB titles, and Punchh could not produce the report if it were named: its item record is the five-field Product Catalog (Item Name, Menu Item ID, Menu Item Type, Item Family, Item Major Group), which carries neither a price nor a modifier relationship, so there is no basis for gross and net sales at modifier level. Item-level questions Punchh does answer are offer-shaped, not mix-shaped -- "How can I find the menu item that is discounted most often by a certain redeemable", "Can I track the sale of menu items through the app with receipt tags" -- and both are scoped to checks that reached Punchh through a loyalty check-in, which is a subset of sales, not the mix. The 5 "revenue center" substring hits were read: all are the phrase in prose about a POS's own configuration, none a filter Punchh offers. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/How-does-Punchh-import-Menu-Items-from-our-POS · retrieved 2026-09-08

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

reporting-multiloc-drilldown

Not scored by this record.

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

reporting-custom-report-builder

Not scored by this record.

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

Not scored by this record.

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

reporting-raw-warehouse-export

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Operates across 275+ brands and 89k+ locations, so grouping exists; a named hierarchy object is not documented publicly. https://punchh.com/ · retrieved 2026-08-01

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

multi-location-central-menu-publish

UPHELD, now cited, and the vendor states the exclusion in one sentence: "Currently, menu items may only be added or deleted from your POS system. Once added or removed, the new data will be reflected the next time Punchh syncs with your POS." The Product Catalog article says it again from the other side -- "there's no way to manually add or remove Menu Items" -- and the developer portal agrees on direction of flow: the section is titled "How To Send Menu Items to Punchh", and the menu data exists so "Punchh can determine whether the offer is valid given the current cart items". Authoring, versioning and publishing to a chosen set of locations are all absent because the first of them is: "menu publish", "publish menu", "central menu", "push menu" and "menu version" read 0 across 228 pages, 15 specs and all 2,586 KB titles. NOTE ON SCOPE, because a sibling product could easily be mistaken for this one: PAR Ordering does publish menus ("Import menus directly from your POS, push updates instantly"), and PAR Ordering is a different product on the same portal. Punchh is the loyalty layer, and this record is Punchh. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/How-can-I-add-or-delete-Menu-Items · retrieved 2026-09-08

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

multi-location-local-override-policy

Not scored by this record.

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

UPHELD, now cited. A price zone needs an item record with a price on it, and Punchh's item record has no price field: "our database imports data for the following fields", and the five it lists are Item Name, Menu Item ID, Menu Item Type, Item Family and Item Major Group. Price exists only as `item_amount` on a transaction line, described as "The total price of the line item... not the unit price", which is a historical fact about one check rather than a configurable attribute. "price zone", "price tier", "pricing tier", "price group" and "daypart" read 0 across 228 pages, 15 specs and all 2,586 KB titles. Punchh does model location groups -- 6 operations under /api2/dashboard/location_groups -- but they scope admin permissions, campaigns and offers, never prices; the 8 price-titled KB articles are all offer processing functions ("Hit Target Menu Item Price", "Target Price for a Bundle", "Maximum Unit Price function under Line Item Filters"), which set a DISCOUNT target against a price the POS supplied. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://support.punchh.com/s/article/How-does-Punchh-import-Menu-Items-from-our-POS · retrieved 2026-09-08

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

multi-location-scheduled-publish

Not scored by this record.

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

multi-location-new-store-template

Not scored by this record.

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

multi-location-corp-vs-franchisee-roles

Not scored by this record.

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

multi-location-royalty-calculation

Not scored by this record.

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

multi-location-royalty-collection

Not scored by this record.

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

Not scored by this record.

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

multi-location-normalized-item-rollup

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

Supports locations operating in different currencies and languages within one enterprise account, with consolidated reporting converted to a reporting currency.

multi-location-multi-currency-locale

Not scored by this record.

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

multi-location-config-audit-log

Not scored by this record.

Supports SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. differentiator

multi-location-enterprise-sso

Not scored by this record.

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

multi-location-enterprise-api

Not scored by this record.

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

Not scored by this record.

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

extensibility-public-api-docs

REPLACES an undated first-pass placeholder that said 'developer.punchh.com did not resolve at check time; API access appears partner-gated' -- while this same record has cited developers.partech.com since 2026-08-09 at grade A for extensibility-oauth-partner-apps and grade B for extensibility-webhooks-push. PAR Technology owns Punchh, so that portal is the first-party developer surface under the parent's name; searching for it under the acquired brand's own subdomain is what produced the absence. Re-established anonymously 2026-09-01 under our own UA: robots.txt is 76 bytes, one `User-agent: *` group whose only rule is `Allow: /`, plus a Sitemap line, and the paths below were matched mechanically against it rather than by eye. The site publishes a machine-readable manifest at /llms.txt (HTTP 200, 142,405 b, read whole) enumerating 531 pages across Commerce Engines (PAR Ordering, PAR POS), Engagement Tools (PAR Punchh), Operations Tools and a Scalar-rendered Docs tree. The Punchh material alone runs to nine API certification feature matrices (Kiosk, Loyalty Pay, Mobile SSO, Offers Ingestion, Online Ordering, Pay-on-the-Go, POS, Single Scan Flow, SMS), an 'Overview of Punchh API Integrations' getting-started page, 'Punchh API Security Guidelines' covering partner onboarding, 'Punchh API and Product FAQs', a 'Punchh Base URIs - Overview' naming sandbox and production environments, developer guides for Advanced Authentication, Offers Ingestion and Redemptions 2.0 basket locking, and a per-endpoint OpenAPI reference (for example the Online Ordering and SSO API's POST /oauth/token 'Get SSO Token' operation). Nothing on the route required an agreement, a login or a sales call. SPOT-CHECKED RATHER THAN ASSUMED, since a landing page is not the reference: /docs/dev-portal-webhooks-manager returned 200 with 45,981 b titled 'Events Framework - Overview of Webhooks Manager', and /docs/dev-portal-platform-functions returned 200 with 38,097 b titled 'Getting Started With Platform Functions API Integrations'. Note for anyone re-walking this host: /docs by itself is a 404 that renders about 30 KB of full site navigation. https://developers.partech.com/llms.txt · retrieved 2026-09-01

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

extensibility-api-access-cost

Not scored by this record.

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

extensibility-partner-revshare

Not scored by this record.

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

extensibility-free-sandbox

Not scored by this record.

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

Punchh publishes two credential schemes and neither is an OAuth 2.0 scoped grant. Platform Functions: 'All platform APIs require an admin key as a part of the authentication, which can be generated from the Punchh platform' and 'Once regenerated, the old admin key expires and cannot be used for any platform-level functions' — the OpenAPI parameter is a flat 'Authorization: Bearer BUSINESS_ADMIN_KEY_GOES_HERE'. Mobile and Online Ordering: a client id/secret pair that PAR's own sample app calls PUNCHH_OAUTH_CLIENT_ID / PUNCHH_OAUTH_SECRET, used to compute an x-pch-digest request header, and 'given to you by your PAR Punchh representative when you get access to a test environment'. Shortfall: revocation exists only as regenerating one business-wide admin key, there are no per-app scopes documented anywhere in the spec, and integration credentials are issued by PAR rather than granted and revoked by the operator. https://developers.partech.com/docs/dev-portal-platform-functions · retrieved 2026-08-04

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

extensibility-webhooks-push

Punchh ships a Webhooks Manager that 'allows brands to get information about events happening in real-time so that action can be taken within the same application or a different application', with configuration and audit logs under Platform > Settings > Webhooks Manager. Shortfall: the documented event set is loyalty-domain only — 'Users, Loyalty check-ins, Gift check-ins, Redemptions, Rewards, Redeemables, Marketing notifications, Transactional notifications, Coupons'. No order lifecycle events are subscribable: a paid transaction surfaces only as a loyalty or gift check-in, and there is no modified, voided or refunded event in the published list. https://developers.partech.com/docs/dev-portal-webhooks-manager · retrieved 2026-08-04

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

Not scored by this record.

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

Not scored by this record.

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

extensibility-menu-write-api

Not scored by this record.

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

extensibility-data-symmetry

Not scored by this record.

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

extensibility-published-rate-limits

Not scored by this record.

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

extensibility-doordash-preferred

Not scored by this record.

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

Not scored by this record.

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

extensibility-middleware-compatibility

Not scored by this record.

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

Not scored by this record.

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

extensibility-payroll-export

Not scored by this record.

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

extensibility-bi-data-warehouse

Not scored by this record.

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

extensibility-app-marketplace

Not scored by this record.

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

extensibility-custom-fields-scripting

Not scored by this record.

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

Not scored by this record.

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

extensibility-api-versioning-deprecation

Not scored by this record.

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

Not scored by this record.

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

reliability-offline-order-entry

UPHELD, now cited, and this is the sharpest vocabulary-without-the-thing case in the record: Punchh publishes an entire module titled "Handling POS Disconnections", and every offline requirement in it is levied on somebody else. Punchh is the server that becomes unreachable. Its own words: "When the POS cannot reach the Punchh server, the POS will queue all transactions until the connectivity is restored"; "Ensure that enough disk space is available on the POS for storing the offline transactions for a maximum of 30 days"; "the POS handles the network outage or server errors at the store level by queueing and storing transactions." The claim is that order entry, ticket routing and check printing continue on-terminal without WAN -- Punchh has no order entry to continue. It never holds an open check: the integrating POS "must call the" Create Check-in "API endpoint for every loyalty guest at the end of a transaction", and what degrades in an outage is loyalty, stated plainly: "In cases when the connectivity to Punchh is down, the POS will be unable to perform loyalty user look-up or check-in, and therefore loyalty users will not be able to earn." The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/tutorials/modules/10-handling-pos-disconnections · retrieved 2026-09-08

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

reliability-offline-card-auth

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

reliability-offline-kds-printing

UPHELD, now cited. Punchh has no kitchen surface at all, online or off. "kitchen display", "kitchen printer", "ticket routing", "prep station" and "bump screen" read 0 across 228 developer pages, 15 specs (292 operations, 1,129 property names) and all 2,586 KB titles; the one "kds" substring in the specs is the identifier "myq9wo2kds83u" and was read. What Punchh does specify for an outage is a guest-facing consolation on the check, not a kitchen path: "the POS generates a unique barcode or QR code so the guest can earn points" later, printed "ONLY when a loyalty user look-up was not done... OR when the POS is offline." That is deferred loyalty accrual; the food still reaches the line by whatever means the POS provides. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/tutorials/modules/10-handling-pos-disconnections · retrieved 2026-09-08

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

UPHELD, now cited. Punchh configures no printer, so it cannot fail over between two. The word "printer" occurs on 4 pages and every occurrence was read: two are a hardware checklist for certification ("Working system with a printer and scanner, etc., sent to the Punchh office in Austin, Texas"), and two are a capability caveat pointing the other way -- "Punchh recommends printing QR codes instead of barcodes because QR codes support more store locations than the EAN 13 barcode limit of 8192 locations. However, some POS printers do not support QR codes." Punchh's remedy there is to fall back to a barcode FORMAT, not to a backup device. "backup printer", "printer fallback", "failover" and "unreachable printer" read 0 across the corpus and all 2,586 KB titles, and there is no alerting construct: the published webhook event list has no device, printer or hardware event of any kind. The scope sentence is Punchh's own, from the KB: "Currently, menu items may only be added or deleted from your POS system." Punchh is the loyalty and offers layer behind somebody else's register; its Product Catalog is a read-only mirror populated by observed transactions. Measured over the PAR Punchh corpus frozen 2026-09-08: 228 developer-portal pages (1,710,047 chars, every page also served as Markdown by appending .md) across the six dev-portal sections that are the Punchh developer portal, plus the 15 OpenAPI specs those sections publish (3,413,139 chars, 292 operations, 139 named schemas, 1,129 distinct property names), plus the 2,586 support.punchh.com articles enumerated by the publisher's own /s/sitemap-topicarticle-1.xml. Two census notes. The root sitemap.xml and root llms.txt are the same 531 locs to the URL, and neither lists a single OpenAPI spec: the specs and 8 further pages appear only in the per-section llms.txt files, which emit them at a base URL that drops the /docs/<section>/ prefix (so the advertised developers.partech.com/meta-fields/index.md 404s while /docs/dev-portal-webhooks-manager/meta-fields/index.md is 200). And llms-full.txt is NOT the corpus here -- it is 5,729 bytes, the home page alone. Absence is measurable on every host in scope: developers.partech.com robots.txt is 76 b, one `User-agent: *` group whose only rule is `Allow: /`, and a fabricated path answers 404 at 854 stripped chars at /docs/ and 612 inside a doc tree, against 3,373 for the live POS Payments page; punchh.com and partech.com 404 a fabricated path at 60 stripped chars. support.punchh.com is the exception and was read through the Aura endpoint rather than its HTML: its Salesforce shell is 190,217 b / 71 stripped chars for a real slug and for a fabricated one alike, so the page fetch cannot discriminate and never bounded anything here. Nothing in this corpus carries `additionalProperties: false` -- 0 of 139 named schemas and 0 nodes anywhere in the 15 spec trees -- so every ceiling below is the DOCUMENTED ceiling, not a logical one, and none of these verdicts is graded above B. https://developers.partech.com/docs/dev-portal-pos/additional-topics/punchhbarcodealgorithm · retrieved 2026-09-08

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

Not scored by this record.

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

Not scored by this record.

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

reliability-public-status-page

Not scored by this record.

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

reliability-contractual-uptime-sla

Not scored by this record.

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

reliability-incident-postmortems

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

reliability-menu-build-service

Not scored by this record.

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

reliability-hardware-replacement-sla

Not scored by this record.

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

reliability-backup-restore

Not scored by this record.

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

Not scored by this record.

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

reliability-mfa-role-based-access

Not scored by this record.

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

reliability-self-serve-training

Not scored by this record.

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

reliability-failover-terminal-role

Not scored by this record.

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

reliability-cellular-backup

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

PAR publishes the consolidated Master Agreement (dated 11.14.25, v2.0) covering all PAR services, expressly including 'PAR Punchh Services'. Section 3(b): 'each Subscription Order shall automatically renew for successive (i) one-year periods at the end of the Initial Subscription Term, or (ii) if no Initial Subscription Term is set forth in the applicable Subscription Order, periods equal to and aligned with the Term of this Agreement (each a Renewal Subscription Term) at the end of the Initial Subscription Term, unless either Party provides the other party with at least sixty (60) days' notice of its intent not to renew the applicable Subscription Order.' Both the renewal term and the notice window are therefore public rather than quote-only. https://partech.com/doc/01-par-master-agreement-consolidated-all-par-services_website/?v=2 · retrieved 2026-08-04

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

No pricing shown on the Punchh homepage or PAR's Punchh product page; demo/contact only. https://punchh.com/ · retrieved 2026-08-01

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

commercial-module-unbundling

Not scored by this record.

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

Software-only loyalty layer; no proprietary hardware requirement. https://punchh.com/ · retrieved 2026-08-01

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

commercial-hardware-not-locked

Not scored by this record.

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

commercial-implementation-fee-published

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

commercial-source-available-selfhost

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

commercial-soc2-attestation

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.

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

Not scored by this record.