PAR POS / Brink POS

order-capture-floor-plan-editor

Brink models tables and sections but not a floor plan. Settings2's Table Type carries exactly four fields - Id, Name, "Capacity: Allowed number of seats for this Table", IsActive - and Settings.svc's Section Type carries only Id and Name (brinkapiportal.parpos.com/settings#SectionTypeTable). Ordering.svc's GetParty is "to retrieve an open Party at the location" keyed on TableId, and NewOrder carries a SectionId, so tables and sections are live operational objects. Shortfall: across all 659 documented operations and types there is no table shape, no x/y coordinate, no saved-layout object and no field assigning a section to an employee - and the schema does model geometry where it exists (DestinationDeliveryZoneCoordinates carries Latitude and Longitude). Nothing on cdn.parpos.com's published document index, the 5.16/5.16r2 release notes or the Features QRGs mentions a floor-plan or table-layout editor. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#TableTypeTable · retrieved 2026-08-08

order-capture-seat-level

The 5.16r2 Admin Portal Config Guide documents seat-level order capture end to end: the Table Service job option "Group Items by Seat: Order items displayed on the Order List control are grouped by Seat Number. Pressing the 'Next Person' button on the register advances to the next seat"; a register "Change Seat" button behavior that "Changes the seat of the select items in the order list" (unsent items only); "Show Seat Information: Displays table and seat numbers"; and "Show Sub-Total by Seat" on checkout. The Split Order screen additionally supports "moving items between the orders, splitting individual items" so a check can be split by seat after entry. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

order-capture-coursing-hold-fire

Hold and on-demand release exist as register button behaviors; a course model does not. The 5.16r2 Admin Portal Config Guide's register behavior table documents Hold - "Places selected order items on hold, to be sent at a later time" - with Clusivity ("Inclusive of the order items selected, or Exclusive of the order items selected") and Release Type ("Manual: Order items will be held until employee explicitly releases", "Prompt: Employee must enter hold minutes", "Specific: Predefined hold minutes"); Release - "Releases selected items that are currently being held so that they can be manually sent to the kitchen"; and Send Order Items - "Sends to the kitchen selected unsent order items, which are not being held, on the current order". The KDS renders the state: Kitchen View Format has "Held Items: Color of order items that are currently being held". Shortfall: there is no course entity. Items are held by ad-hoc selection or a hold-minutes timer, not assigned to a named course, and there is no fire-next-course action that releases one course; "course" occurs zero times in both the 8,425-line guide and the 1.75MB / 659-anchor API portal dump, and the Order and OrderItem types carry no course or fire-group field. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

order-capture-split-merge

The Admin Portal guide documents "Split Order": "Opens 'Split Order' screen, which allows for adding new orders to the current party, moving items between the orders, splitting individual items, and combining (un-splitting) split items," gated behind a "Split Check" security-level permission. Shortfall: even N-way split, arbitrary dollar/percentage-amount split, and merge behavior after a partial payment has been taken are not itemized anywhere in the guide — only free-form item-level splitting/combining is described. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

order-capture-bar-tab-preauth differentiator

Card pre-authorisation with a configured amount is documented. The Integration Settings Portal User Guide (cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf), under Payment Device Configuration > ParPay Settings (5.0i+, updated 5.0L & 5.0m), lists "Enable Pre-Authorization (5.0m+) - Enables the server to initiate a pre-authorized [transaction]. If selected, a [default amount] must be entered. For detailed information, please see the 5.0m Release Notes (MH1-792)." The PAR Pay API (developers.partech.com/docs/par-pay/) backs this with POST /creditcard/v1/preauth ("Preauthorize a credit card transaction without capturing funds"), POST /creditcard/v1/capture and POST /creditcard/v1/void. Shortfall: none of the 26 PAR Pay operations is an incremental or top-up authorisation, and no PAR document describes re-authorising a growing tab or auto-closing stale tabs at end of day - the only tab-related item in the Admin Portal guide remains the "Can Access any Tab" permission. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

order-capture-transfer-audit

The Admin Portal guide documents a "Transfer Items"/"Transfer Party" register behavior: "Opens the Transfer Party window that allows the current employee to select tables or tabs to transfer to another employee." Shortfall: no dedicated audit report or log entry naming both the transferring and receiving employee for a transfer action was found — the guide's audit reports (Manager Override Detail, Void Details, etc.) cover void/discount/promotion/surcharge approvals, not table/tab transfers. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

order-capture-native-handheld

PAR Tablet: rugged Gorilla Glass, sealed, NFC/RFID for card processing, 10-hour battery; runs PAR POS natively. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

order-capture-offline-order-entry

PAR's In-Store Resilience release notes (Rev 05, June 2025) document offline order entry and enumerate the exceptions. Validation procedure: "Turn off the internet connection... The primary and all secondary registers will continue to function but in offline mode, just as they currently do"; with the primary register's cable pulled, "the backup primary swiftly assumes control and continues operating in offline mode. The remaining secondary registers subsequently recover and also operate in offline mode." FAQ: "What occurs if the location completely loses its internet connection? A: If internet connectivity is lost, offline mode operates normally with the primary register acting as the host as it does today." What does NOT work offline is published in the same FAQ: online ordering ("online orders will still fail"), changeset publishing, End of Day, and synchronising historical data to the cloud; guardrails also block Clocking Out, Checking Out and Cash Drawer Assignment on a backup primary for a default 15 minutes. Single-register locations "cannot implement this feature - the primary register transitions to offline mode after a connection loss, as it currently does." This supersedes the earlier reading of the API FAQ's "Accept Orders When Master Offline", which is a cloud-side setting about inbound API orders only. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

order-capture-qr-same-check differentiator

Assessed 2026-08-08. Re-checked the basis for the prior `no`: Ordering.svc's twelve operations and the NewOrder type, which indeed has no TableId, no PartyId and no parent order id, so a third-party QR product integrating through the published API cannot append to a server-opened check. That is an enumeration of the public integration surface only. The claim asks what the product does, and PAR sells its own QR guest-ordering front end (PARk it, announced March 2020, marketed as turning Brink into a self-order channel via QR code), for which PAR publishes no documentation - cdn.parpos.com/Documentation.html lists no guest-ordering user guide, and the only first-party QR document is CheckPleaseQRCGuide.pdf, which is pay-at-table. A first-party front end need not use the public API, so the API's shape is not positive evidence about it. The register behavior table shows no QR join-check control either, but that is again absence of evidence. Unknown until PAR documents the guest ordering path.

order-capture-kiosk-first-party differentiator

First-party kiosk with real-time POS menu sync claimed; no ADA/accessibility conformance documentation published. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

order-capture-drive-thru

"Drive Thru Mode" plus a drive-thru solution suite; G5 drive-thru audio and order confirmation boards. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

order-capture-drive-thru-timers

PAR sells a first-party Drive-Thru Timer product for monitoring wait times. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

order-capture-voice-ai differentiator

Assessed 2026-08-08. Checked partech.com/solutions/, /solutions/cloud-pos/ and /solutions/pos-hardware/drive-thru/ - the drive-thru line is headsets and timers (PAR G5 headset, Drive Thru Timer), with no voice-AI ordering agent named. developers.partech.com's sitemap has five URLs (/, /commerce-engines/par-pos/, /commerce-engines/par-ordering/, /engagement-tools/par-punchh/, /operations-tools/par-ops/) and its two rendered references (/docs/par-pay/, 26 operations; /docs/identity-service/, 23) carry nothing voice-related. The legacy API portal's 659 operations expose generic order injection (Ordering.svc SubmitOrder) but no voice-specific certification, and parpospartners.partech.com is an integration directory, which is not enumeration evidence. The previously cited SYNQ3 press release is dead evidence (SYNQ3 was acquired by SoundHound in Jan 2024). Unresolved because a general ordering API is neither a first-party voice agent nor a documented voice-AI partner programme, and PAR publishes no page that would settle it.

order-capture-throttling differentiator

Brink publishes channel-scoped lead- and prep-time control but not capacity throttling. Settings2's FutureOrderingOptions type enumerates AllowFutureDateOrdering, Destinations ("Destinations that future ordering can be directed to" - the per-channel axis), IsEnabled, LeadTimeThresholds, MaximumDaysInAdvance, MinimumLeadMinutes ("Minimum amount of time that the order pickup time needs to be from placement time"), MinimumPrepMinutes ("Minimum amount of time before the order pickup time allocated at which the order is open on the register and sent to the kitchen"), PrepTimeThresholds and RequiredDepositPercent. Shortfall: LeadTimeThreshold and PrepTimeThreshold each carry a single integer of minutes (LeadMinutes / PrepMinutes) and nothing else - there is no order-count or capacity limit per time slot, and no field that extends the quote when kitchen load crosses a threshold. The word "throttl" does not appear anywhere in the 1.75MB portal dump, the 5.16/5.16r2 release notes or the Features QRGs; 5.16r2's only related addition is manual - "Operators can manually set a custom prep time on any future order, replacing the default calculated prep time" (NUC-2117). Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#FutureOrderingOptionsTypeTable · retrieved 2026-08-08

order-capture-scheduled-orders

The cited page's only supporting word is "preordering" in a list of conversion tools. That is thin for a 'yes' on scheduled orders, and fire-time injection is admittedly undocumented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01 adversarially verified

order-capture-catering

Catering appears only as a destination in the menu-sync channel list, and "PAR Catering" is a separate offering whose Learn More links off to punchh.com — i.e. a distinct product, not a documented capability of PAR Ordering. No catering order-management functionality is described. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01 adversarially verified

order-capture-order-ready-signal differentiator

Verified. DoorDash's DPIP requirement list expressly includes "Order Ready Signal" as one of eight mandatory high-quality features, and PAR is named in the 2026 roster alongside Checkmate, Chowly, Deliverect, Otter, Qu, Square, Stream, Toast and UrbanPiper. Scope caveat: this evidences the DoorDash-channel signal only, not a guest-facing or in-store ready notification. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01 adversarially verified

order-capture-void-comp-controls

The Admin Portal guide documents the full chain: a Void Reasons list ("Refund reasons are listed for the employee to choose when the 'Refund' button behavior is executed"; five default reasons include 86'd Item, Kitchen Error, Server Error, Test Order, Waste); role-gated SecurityLevel permissions (VoidItems, ApproveDiscounts, already cited elsewhere in this record); and an exception-report trio — "Void Details" (grouped by employee, sorted by void time), "Void Summary" (totals by void reason), and "Manager Override Detail" ("Lists details regarding all manager override actions, including: Approval Time, Login User, Button Name, Button Action, Approval User, and Approval Method"). https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

menu-pricing-nested-modifiers

Settings2 exposes ModifierGroups with ItemPrice/ModifierPrice pricing methods; nesting depth and min/max/forced flags not documented publicly. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01

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

Positive absence on the same exhaustive Settings2 menu-model enumeration this record already accepted for the fractional-placement 'no': ModifierGroupItem carries only Price and PriceMethod (ItemPrice | ModifierPrice); the only other modifier pricing mechanism is ItemModifierCodePricing (price by modifier code); PriceLevel is item-scoped ("Price level that is to override the item price") with no modifier linkage; and no size dimension exists anywhere in the menu model. Per-parent, per-size modifier pricing is achievable only by duplicating modifier groups — exactly the duplication the claim's matrix requirement excludes. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03

menu-pricing-fractional-placement differentiator

Half portions exist as a modifier-code concept, not as a placement dimension. The guide's kitchen options document "Consolidate Like Modifier Codes: Consolidate modifiers into groups based on the modifier code (ADD, NO, HALF, etc.) on both kitchen displays and printed kitchen chits" - HALF is one of PAR's own worked examples of a modifier code - and the Modifier Code Pricing page exists so that "if a modifier does not have a price defined on a code, the user can add or remove a price as needed", backed in the API by ItemModifierCodePricing {ModifierCodeId, Price}. So a half topping can be ordered, routed to the kitchen and charged at its own price. What is missing is the section: a modifier code has Name, Abbreviation, Applies To, Charge Type and a Type drawn from a closed enum of Normal, No, Sub, For and On Side - there is no left/right, no quarters, and nothing that records which half a modifier sits on, so two halves of one pizza are indistinguishable to the system and cannot be priced against each other. Any left/right modelling is operator naming convention, not a documented product capability. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read adversarially verified

menu-pricing-half-and-half-rule differentiator

The modifier pricing surface is enumerated and closed, and contains exactly one lever. A modifier code's Charge Type is drawn from Always Unless Limited By Item, Never, Charge for Non-Ingredients, and - in the API's ModCodeChargeType - UseModifierTiers or ModifierCodePricing. ModifierCodePricing is a flat amount per modifier per code (ItemModifierCodePricing carries only ModifierCodeId and Price), and Modifier Tiers are explicitly for substitutions: "Modifier tiers are used to determine if a substituted item should carry a charge. Substituting a modifier for another of equal or lesser modifier tier level does not carry a charge", with only Name and Level. So an operator can set what a HALF-coded modifier costs, but there is no percentage or multiplier, no rule that charges the higher-priced half, and no rule that averages the halves - one of the three behaviours the claim requires, not the two it asks for. This is enumeration of the alternatives, not absence of mention. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read adversarially verified

menu-pricing-topping-quantity-tiers

Also missed. Settings2 documents ItemModifierCodePricing (Id, ModifierCodeId, Price) with the note that "valid modifier codes are the ones that have charge type as 'Modifier Code Pricing'" — i.e. a modifier's price varies by its preparation code (the NO/LIGHT/EXTRA/SIDE family). That is a documented differential-price-by-quantity-code mechanism. Caveat: PAR does not publish the modifier-code enumeration itself, so if the rubric demands named light/regular/extra tiers, score partial. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01 adversarially verified

menu-pricing-size-style-matrix differentiator

Brink's item pricing model has no variant grid. The Settings2 Items type - the complete item record, read by GetItems and written by SaveItems - carries roughly fifty fields including Price, PriceLevelId, PricePer, ModifierCodesPricing, ItemPriceChanges, Components and Skus, and none of them is a two-axis variant matrix. PriceLevel is a flat single value ("Id, Name, Price: Price assigned to items of this price level"), ItemModifierCodePricing is one price per modifier code (ModifierCodeId + Price), and PriceChange is a day/time-scoped price override. Nothing models size as one axis and crust/preparation as another with a per-cell price - size and style variants have to be separate Items or modifiers. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#ItemsTypeTable · retrieved 2026-08-08

menu-pricing-included-allowance differentiator

Missed object: ItemIncludedModifier (IsIncluded, AutomaticallyAdd, PrintInKitchen, Position) models modifiers bundled into an item at no charge and auto-applied. Caveat: it is a per-modifier included flag, not an 'N toppings included then charge for the N+1th' counted allowance, so partial is the defensible landing spot if the rubric requires a counted allowance. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01 adversarially verified

menu-pricing-combos

ItemCompositeComponent structures support composite/combo items with component pricing; automatic a-la-carte-to-combo detection not documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01

menu-pricing-upsell-prompts differentiator

"AI-powered upsells, cart reminders, and special offers" in PAR Ordering; per-channel configuration and attach-rate reporting not documented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

menu-pricing-86-propagation

Real-time item 86ing and item availability checks are mandatory DPIP capabilities PAR must support; no published propagation latency and no documented POS/KDS/kiosk propagation guarantee. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01

menu-pricing-countdown-auto-86 differentiator

A per-item countdown exists. Ordering.svc's ItemAvailabilityDetail type carries "QuantityAvailable: Quantity still available for the Item, or -1 if Item has unlimited availability" and "IsAvailable... When updating: If you specify True, the default for QuantityAvailable is -1 to indicate an unlimited supply, unless a quantity is specified. If you specify False, the QuantityAvailable is set to 0" - so zero quantity is the unavailable state, which is auto-86 at zero. GetUnavailableItems returns "item IDs that are active but unavailable at the location on current business date", and Settings2's Items type carries IsQuantityCounted ("True if this Item quantity is counted"). Shortfall: PAR nowhere documents that a register sale decrements QuantityAvailable, and there is no scheduled auto-restore field - the business-date scoping of GetUnavailableItems hints at a daily reset but no document states it, and no configurable restore time exists in the Items or LocationOptions schema. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/ordering#UpdateItemAvailability · retrieved 2026-08-08

menu-pricing-dayparting

Researcher missed a real object. Settings2 documents JobMenu: MenuId, Days (byte bitmask, 1-64, additive for multiple days) and StartTime (TimeSpan) — "Time at which the scheduled menu will begin displaying." That is time-and-day-scheduled menu switching. Caveat: it is scoped by employee job/role and I found no scheduled price change, so if the rubric requires daypart pricing as well as daypart menus, score partial rather than yes. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01 adversarially verified

menu-pricing-channel-price-books

SavePriceChanges (markup/markdown), PriceLevel, and DestinationAvailabilities exist; PAR Ordering claims unified menu/pricing across marketplaces. Percentage-markup-per-channel rules not explicitly documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01

menu-pricing-dual-pricing differentiator

A cash-discount mechanism exists but not at the item level. The Integration Settings Portal User Guide's Payment Device Configuration > ParPay Settings includes "Non-Cash Adjustment Enabled - Check to charge guests the credit card processor interchange fee when paying with credit card." Shortfall: this is a single checkbox on one payment-device integration, applied at tender time, not a per-item card price. Settings2's Items type carries one Price plus a PriceLevelId, with no second cash price; the online-ordering MenuItem type (Description, Id, ImageId, ItemId, ItemOptions, ModifierGroups, ModifierMethod, Name, Price, PriceMethod, SortOrderId) has no dual-price field either, so the card price cannot be published as the base price to kiosk or online ordering; and no PAR document describes receipt printing of both cash and card prices. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

menu-pricing-versioning-effective-dates differentiator

Changeset Publisher stages a named package of changesets and schedules its activation as "Immediately" or "End of Day" (the target location's own End of Day time) up to two weeks in the future, running an automatic pre-validation check before Submit. Shortfall: no visual preview of the resulting menu before publish is documented (only an error-validation pass), and no rollback-to-prior-version mechanism after publish is described — Cancel/Retry apply only before or during publishing. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

menu-pricing-franchise-hierarchy differentiator

Enterprise central menu management marketed for multi-location brands; field-level override governance not documented. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

menu-pricing-allergen-nutrition

Two complete schemas, no allergen or nutrition data. The Settings2 Items type - the full item record for GetItems/SaveItems, roughly fifty fields from AllowAutoCombo through VideoGroupId - has no allergen flag, no calorie or macronutrient value and no nutrition object; its only free-text carriers are Description and generic CustomFields (FieldName + Value). The MenuItem type that feeds the customer ordering portal is likewise Description, Id, ImageId, ItemId, ItemOptions, ModifierGroups, ModifierMethod, Name, Price, PriceMethod, SortOrderId - so even if a value were entered somewhere it has no channel to publish through. Recipe-derived nutrition is ruled out too: ItemIngredient carries only Id, ItemId and "Position: an index of where this ItemIngredient is positioned" - no quantity, no unit, no nutrient data. "Allergen", "nutrition" and "calorie" occur zero times across the 1.75MB portal dump and the 5.16/5.16r2 release notes. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#ItemsTypeTable · retrieved 2026-08-08

menu-pricing-recipe-linkage differentiator

PAR OPS Inventory does recipe management and actual-vs-theoretical food costing driven off POS sales; item-level theoretical cost linkage claimed but mechanics not documented. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · retrieved 2026-08-01

menu-pricing-3p-menu-push

Real-time menu syncing is a mandatory DPIP capability and PAR Ordering claims unified menu/pricing/order updates to marketplaces; per-item sync status and rejection-error surfacing to the operator not documented. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01

menu-pricing-dynamic-pricing

Settings2's menu/pricing object model — already accepted elsewhere in this record as an exhaustive enumeration (PriceLevel, SavePriceChanges/UpdateItemPrice, ItemPriceChange, ComponentPriceChange) — contains no time-of-day, demand, or channel-variable pricing rule and no floor/ceiling guardrail field. PAR Intelligence's product page (partech.com/solutions/par-intelligence, re-checked 2026-08-04) markets campaign/offer economics but never mentions dynamic or surge item pricing. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-04 adversarially verified

payments-processor-choice differentiator

PAR's own DataCap EMV USA Payment Matrix (published on PAR's documentation index at cdn.parpos.com) says "Brink POS supports several payment gateway solutions and processors for accepting EMV card payments" and lists the supported processors/hosts for the USA by name: Chase Paymentech, Global Payments Inc., Mercury Payment Systems, First Data Rapid Connect, Heartland Payment Systems, TSYS, Vantiv, WorldPay, BluePay, Elavon, Monetary, each with its certified devices and per-processor feature table. PAR's own gateway (PAR Pay) is one option among these, not a precondition. Same index also publishes separate FreedomPay Setup and Configuration and Tender Retail Payment Gateway Configuration guides. Caveat: this matrix is a 2020 revision, still the current version PAR links. https://cdn.parpos.com/docs/Brink%20DataCap%20EMV%20USA%20Payment%20Matrix%20.pdf · retrieved 2026-08-06 · not refetchable · site policy · graded B when read adversarially verified

payments-published-rates differentiator

Payment services page markets "transparent" pricing but publishes no rate, markup, or per-transaction figure. Not published publicly. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01

payments-dual-pricing differentiator

The Integration Settings Portal User Guide's ParPay Settings section documents "Non-Cash Adjustment Enabled - Check to charge guests the credit card processor interchange fee when paying with credit card", so a native cash-discount-style mode does exist on PAR's own payment integration. Shortfall: it stores no second price. Settings2's Items type has a single Price plus an item-scoped PriceLevelId (PriceLevel itself being Id/Name/Price), and Settings2's PaymentOptions decomposes into CreditCardOptions, ExternalPaymentOptions, GiftCardOptions, RoundingOptions, TipAndSignatureOptions and PayAtTableOptions with no dual-price or cash-price field in any of them. No PAR document describes printing both a cash total and a card total on the guest check or receipt. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-surcharge-guardrails differentiator

The prior assessment was wrong that no Surcharge configuration object is published - Settings.svc's GetSurcharges returns a fully enumerated Surcharge type: Amount, AutomaticallyApply, Days, EndDate, EndTime, EnforceDateRanges, EnforceDays, EnforcePartySize, EnforceTimeRanges, Id, LimitDestinations, LimitSections, MaximumPartySize, "Method: 0 = Fixed Per Order, 1 = Percentage Per Order, 2 = Fixed Per Item, 3 = Percentage Per Item", MinimumPartySize, Name, Prompt, StartDate, StartTime, TaxIds, and "TerminalTypes: 0 = None, 1 = Register, 2 = Web Ordering, 8 = Web Mobile Ordering, 16 = Web-Service". Every dimension is time, party size, destination, section or terminal - there is no card-type, BIN, product-code, debit or prepaid field, and no percentage-cap enforcement. The one card-aware surcharge PAR ships is the PAR Pay "Non-Cash Adjustment Enabled" checkbox, whose entire documented behaviour is "charge guests the credit card processor interchange fee when paying with credit card" - again no debit/prepaid exclusion and no cap. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings#SurchargeTypeTable · retrieved 2026-08-08

payments-emv-nfc

EMV credit and debit plus contactless including Apple Pay, Google Pay and Samsung Pay. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01

payments-softpos-tap-to-pay differentiator

PAR's own Payment Device Configuration section is the supported-device enumeration and contains no phone-as-reader option. It lists exactly eight integrations: ParPay (5.0i+), Pax POS Link (5.0i+), Datacap US EMV (5.0j+), Tender Retail (5.0j+), Elavon (5.0j+), Datacap Canadian EMV (5.0j+), FreedomPay (5.0j+, updated 5.0L) and Verifone Point (5.0j+, updated 5.0L) - every one configured by IP address/COM port/terminal ID against a physical PIN pad. The PAR Pay API (developers.partech.com/docs/par-pay/) exposes 26 operations across credit card, gift card, tokens and OAuth, of which the card-entry paths are /creditcard/v1/purchase, /creditcard/v1/preauth, a hosted iFrame URL and Google Pay configuration - no Tap to Pay on iPhone and no Android tap-to-pay SDK. partech.com/solutions/payment-services/ and /solutions/pos-hardware/ describe Apple Pay, Google Pay and Samsung Pay only as wallets tapped against a PAR terminal. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-pay-at-table

PAR Tablet handheld with NFC/RFID card processing; tip prompt and tableside check splitting not documented. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

payments-qr-guest-pay differentiator

"QR Code to Pay" and "Text to Pay" named as supported payment methods; automatic check closure in the POS not documented. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01

payments-tip-adjust

The Admin Portal guide documents "Allow Tip Adjust On Register: When tender Type is set to Credit Card or Gift Card and [enabled, staff can adjust] the register via 'Adjust Tips' or 'Adjust Payment' buttons," a CanAdjustTipsFromAnyTill security permission (a manager-level cross-till adjust screen), and Tip Type (Percent/Fixed Amount) configuration for the on-device tip prompt. Shortfall: no documented batch/adjust cutoff window is specified, and pre-auth-then-tip-adjust is not itself named as a supported flow. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

payments-tip-pooling differentiator

The Admin Portal guide documents "Tip Pooling Enabled: Allows for the definition and management of employee tip pools," with per-job "Contribute to Tip Pool" (percentage of compensation) and "Receive Distributions from Tip Pool" flags. The PAR OPS Payroll API (already cited in this record for labor-tip-distribution-audit-trail) separately exposes TipShareHours, TipShareAmounts, TipShareJobWeights and TipShareSettings, producing a per-employee, per-payroll-period distributed tip amount exportable via API. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

payments-offline-store-and-forward differentiator

Datacap US EMV Settings (5.0j+) in the Integration Settings Portal User Guide document the feature and its limits verbatim: "Support Store and Forward - If credit card terminal is offline, allows customer to still pay with a credit card; transactions are stored and forwarded for settlement when system is back online"; "Force Offline - [enter offline] mode immediately"; "Maximum Number of Offline Transactions - Controls how many transactions are allowed while offline, any value between 1 and 9999 (default = 300)"; "Maximum Transaction Amount - Maximum amount allowed for an offline transaction (default = 500.00)". That is a configurable per-transaction limit and a configurable cumulative limit. Note the capability is carried by the Datacap integration rather than by every processor integration PAR supports. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-offline-decline-liability differentiator

Assessed 2026-08-08. Store-and-forward itself is now documented (Integration Settings Portal User Guide, Datacap US EMV Settings), but its entire configuration surface is four fields - Support Store and Forward, Force Offline, Maximum Number of Offline Transactions, Maximum Transaction Amount - and none states liability or produces a report. Also re-read the In-Store Resilience release notes (Rev 05), whose FAQ enumerates what is unavailable offline (online ordering, changeset publishing, End of Day, historical data sync) and says nothing about stored card transactions; walked cdn.parpos.com/Documentation.html, PAR's master document index, whose PAR Pay Resources section lists twelve guides (EMV setup, 2024 PCI upgrade, refund without card present, prior-day partial refund, wallet loyalty, RMA, six terminal setup guides) with no decline-liability or offline-settlement guide, and whose Administrator Portal Reports section lists nine report guides with no failed-offline-payment report. Unresolved: liability language of this kind normally lives in the merchant processing agreement, which PAR does not publish, so absence here is not evidence of absence.

payments-gift-cards

Physical and digital gift cards supported through PAR Payments with loyalty integration; brand-wide multi-location redemption and online-channel redemption not explicitly documented. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01

payments-house-accounts

A dedicated HouseAccounts SOAP service exists in the PAR POS API; per-account credit limits and statement/invoice generation not documented. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01

payments-split-tender

The Admin Portal guide's Split Order screen supports moving/splitting items across multiple new orders from one party, and the Pay at Table section states a check "can be paid in full or split among multiple guests at the same table." Shortfall: no explicit tender-count cap or confirmation of an eight-plus-way split was found anywhere in the guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

payments-refund-void-controls

Role gating and approver audit are documented for voids and discounts: Settings2 SecurityLevel carries discrete VoidItems, ApproveDiscounts and DeletePayments permissions, and Sales2 order history attributes both actor and approver (OrderItemVoid.ApproverEmployeeId "Maps to the Id of the Employee who approved this OrderItem"; OrderDiscount carries EmployeeId plus ApproverEmployeeId), queryable via GetOrders. Shortfalls: refunds appear only as Order.IsRefund plus RefundReasonId with no documented approver or refund-specific permission, no no-sale permission or audit object is documented, and no immutability statement exists. https://brinkapiportal.parpos.com/sales2 · retrieved 2026-08-03

payments-chargeback-tooling differentiator

Assessed 2026-08-08. developers.partech.com/docs/par-pay/ enumerates 17 endpoints in five groups - Authentication (1), Credit Card (9: purchase, preauth, capture, void, refund, iFrame URL, Google Pay configuration, saved-card list and update), Gift Card (12 across redemption/balance/reload/refund/transfer/issuance), Transactions (2: status lookup, transaction listing) and Health Check (2) - with no dispute, chargeback, representment or evidence-submission operation. cdn.parpos.com/Documentation.html's PAR Pay Resources section lists twelve first-party guides and none concerns disputes. partech.com/solutions/payment-services/ publishes no dispute tooling. PAR OPS Recovery remains delivery-marketplace dispute recovery, not card-network chargebacks, and is a separate product. Unresolved because an in-product dispute dashboard would live in the PAR Pay merchant portal UI, which PAR does not document publicly - the API's silence does not settle it.

payments-card-on-file differentiator

The Admin Portal guide documents "Enable Stored Credit Cards: Credit cards can be stored on customer accounts" for the in-store channel. On the digital side, the Punchh Mobile API (already cited in this record) documents Payment Cards/Payments endpoint groups and a secure_tokens endpoint for guest accounts. Shortfall: no explicit "no PAN stored by merchant" statement was found, and phone-order reuse of the same stored card is not documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

payments-payout-timing differentiator

Assessed 2026-08-08. partech.com/solutions/payment-services/ markets processing flexibility and "enterprise-grade security" but publishes no deposit schedule and no next-day/same-day/instant funding language. The PAR Pay API (developers.partech.com/docs/par-pay/) has no payout, funding, settlement-batch or deposit endpoint among its 17 operations. cdn.parpos.com/Documentation.html's twelve PAR Pay guides cover device setup, refunds, PCI upgrade and RMA only. Settings2's CreditCardOptions shows why this is hard to settle: the Processor enum is None, FirstData, GlobalPayments, Heartland, Hypercom, Mercury, Vantiv, WorldPay, Tsys, so on most Brink installations the deposit schedule belongs to a third-party processor and PAR would have nothing to publish. Unresolved for PAR Pay itself, where funding terms would sit in the merchant agreement PAR does not publish.

payments-multi-entity-routing differentiator

Separate MIDs per location are a documented configuration. The Integration Settings Portal User Guide's Payment Device Configuration gives Datacap US EMV "Merchant ID - Provided by processor" and "Terminal ID - ID unique to location, exposed for all Datacap payment devices"; Elavon adds "Terminal ID - Unique by location" plus Chain and Location; FreedomPay has "Merchant ID - Defined by FreedomPay" and "Terminal ID - Unique by location"; Datacap Canadian EMV the same. Because payment devices are configured per location and linked to registers there, a group can run distinct MIDs per site while reporting rolls up in one Admin Portal (the published report guides include Sales by Destination, Sales by Order Source and Royalties by Location). Shortfall: PAR documents no settlement-routing control of its own - the only bank account and routing number fields in the Admin Portal guide sit on Options > Accounting > Royalties and exist "to appear on the Royalties by Location report", a display field - and nothing describes split settlement or assigning funds to different legal entities from one account. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-p2pe-pci4

cdn.parpos.com/docs/PARPOSSoftwareSecurityFrameworkFAQ.pdf carries a Coalfire Systems letter dated 18 Oct 2022: "This letter affirms that Par Tech has engaged Coalfire Systems, Inc. to perform a Secure Software Assessment in line with the PCI SSC P2PE requirements... The assessment is planned to conclude in early 2023", and "Please feel free to distribute this letter to business partners who need to know the status of your SSF engagement activities." The FAQ answers "What if my auditor requires SSF documentation for POS? ParTech will provide our most recent PA-DSS AOC for POS as well as our Letter of Engagement from our third-party consultant" - so attestation documents are supplied on request. Shortfall: the document PAR offers is a PA-DSS Attestation of Compliance, and the same FAQ records that "The SSF replaced the Payment Application Data Security Standard (PA-DSS) on October 28, 2022"; no completed SSF validation, no current PCI DSS 4.x AoC and no PCI SSC P2PE validated-solution listing is published. The only newer PCI artefact on PAR's document index is PARPay2024PCIUpgrade.pdf, a device-upgrade notice warning that "failing to comply with this upgrade will result in your devices losing the ability to process transactions". https://cdn.parpos.com/docs/PARPOSSoftwareSecurityFrameworkFAQ.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

kitchen-station-routing

First-party KDS is part of the platform and PAR markets kitchen management; per-location operator-configurable routing rules not documented. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

kitchen-expo-consolidation

The 5.16r2 Admin Portal Config Guide documents native expo: kitchen queues have an 'Is Expediter' option that 'displays check marks beside order items that have been bumped from all kitchen queues that do not have Is Expediter enabled' — the expo view consolidates the order and tracks per-station bump state — plus 'Bump From Other Kitchen Queues' (optionally limited to selected queues), an Order Expediter Action fired when the order is bumped from the expo queue, and Options > Kitchen expo-sequence controls (Prioritize Expeditor Only Items; identify/rearrange out-of-sequence orders on expo). https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

kitchen-course-firing differentiator

Items can be held and fired to the kitchen on demand, but not by course and not from the expo screen. The 5.16r2 Admin Portal Config Guide's register behavior table documents Hold ("Places selected order items on hold, to be sent at a later time"; Clusivity inclusive or exclusive of the selected items; Release Type Manual - "held until employee explicitly releases" - Prompt for hold minutes, or Specific predefined minutes), Release ("Releases selected items that are currently being held so that they can be manually sent to the kitchen") and Send Order Items ("Sends to the kitchen selected unsent order items, which are not being held, on the current order"). The Kitchen View Format tab carries "Held Items: Color of order items that are currently being held", so the KDS distinguishes the state. Shortfall: no course object exists to assign items to - "course" occurs zero times in the 8,425-line guide and in the 1.75MB API portal dump - the release is by manual selection or a hold timer rather than a fire-next-course action, and the firing controls are register button behaviors; Kitchen.svc's only operations are the read-only GetOrderBumpTimes and GetOrderItemBumpTimes, so nothing fires from the expo screen in the documented surface. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

kitchen-prep-time-pacing differentiator

Per-item cook times are not configurable in Brink. The Settings2 Items type - the complete item record used by GetItems and SaveItems - carries kitchen-facing fields (AlternateKitchenName, BlinkInKitchen, KitchenColor, KitchenBackgroundColor, ModifierRouting, PrinterGroupId, VideoGroupId) but no cook time, prep time or start-offset field of any kind. The only minute-valued prep fields in the whole schema are FutureOrderingOptions.MinimumPrepMinutes and PrepTimeThreshold.PrepMinutes ("Minutes for a prep time threshold"), which govern when a scheduled future order opens on the register - one value for the location, not per item. Kitchen.svc reports a per-item FireTime (OrderItemBumpTime) but that is read-only history, and the Admin Portal guide's Kitchen Queue Thresholds tab only drives colour/flash escalation once an order exceeds a target time. Nothing staggers item start times so an order finishes together. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#ItemsTypeTable · retrieved 2026-08-08

kitchen-order-throttling differentiator

No kitchen-load pacing exists. The 5.16r2 Admin Portal Config Guide's kitchen configuration screens are Kitchen Queues, Kitchen Views, Thresholds and Load Balance: Thresholds sets visual/audible escalation (Color, Seconds, Flash, Mode) once an order exceeds a target time and changes nothing about order release, and Load Balance distributes orders across kitchen views by time-of-day override, not by capacity. The API side agrees - Settings2's KitchenQueue is Id/Name, KitchenVideoGroup adds only colour and routing overrides, and Kitchen.svc's two operations are read-only bump-time reporting - so there is no configurable order-volume or ticket-time threshold that delays release or extends a quote. "Throttl" occurs zero times in the 1.75MB portal dump, the 5.16 and 5.16r2 release notes, the Features QRGs and on partech.com. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#KitchenQueueTypeTable · retrieved 2026-08-08

kitchen-channel-pause-propagation differentiator

Item-level 86 propagation has a documented mechanism; store pause does not. Ordering.svc publishes GetUnavailableItems, "to retrieve the list of item IDs that are active but unavailable at the location on current business date... can be filtered basis specific destination as well", plus GetItemAvailability and UpdateItemAvailability with QuantityAvailable - so a marketplace integration can read 86s made in the POS, per destination, and DoorDash's DPIP requires exactly this ("86 items + Item Polling"). Shortfall: propagation is pull-based and integrator-implemented - the legacy PAR POS API portal exposes no webhook, callback, event or subscription surface at all (zero occurrences across the 1.75MB dump; PAR's webhooks manager on developers.partech.com is documented for Punchh guest/engagement events, not POS availability) - there is no store-level pause object anywhere in the schema, only per-item availability, and PAR publishes nothing about Uber Eats or Grubhub receiving either signal. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/ordering#GetUnavailableItems · retrieved 2026-08-08

kitchen-order-ready-callback differentiator

Assessed 2026-08-08. Kitchen.svc (brinkapiportal.parpos.com/kitchen) enumerates exactly two operations, GetOrderBumpTimes and GetOrderItemBumpTimes, returning OrderBumpTime and OrderItemBumpTime (BumpTime, FireTime) for a business date - pollable read-only history, so a marketplace integration could derive readiness but PAR documents no push of it. The legacy API portal contains no webhook, callback, event or subscription surface anywhere in its 659 operations; PAR's webhooks manager on developers.partech.com covers Punchh guest events, not POS bumps. The Order Ready Board Config Guide (April 2026) shows bump events being distributed in-store over MQTT from the Primary Register to a customer display, which is an internal path, not a marketplace callback. DoorDash's DPIP does mandate an "Order Ready Signal" of certified POS partners, but PAR publishes no document stating Brink emits it. Unresolved: the requirement is DoorDash's, the implementation would be in PAR's certified integration, and neither party publishes the Brink-specific answer.

kitchen-bump-bar-hardware

PAR sells a programmable bump bar alongside its KDS. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

kitchen-all-day-counts

Assessed 2026-08-08. Kitchen.svc exposes only GetOrderBumpTimes and GetOrderItemBumpTimes; Settings2's kitchen types are KitchenQueue (Id, Name), KitchenVideoGroup (Id, Name, KitchenBackgroundColor, RoutingOverrides, KitchenQueues), KitchenVideoGroupQueue and KitchenVideoGroupRoutingOverride - none carries an aggregate or summary view setting. Walked cdn.parpos.com/Documentation.html, PAR's master document index, whose nine Administrator Portal Report guides (Hourly Sales, Hourly Sales by Destination, Product Mix by Item Group, Sales and Labor by Hour, Sales by Destination, Sales by Order Source, Sales Summary, Sales Summary by Day Part, Employee Timecard) and two Register Report guides are all closed-sales reporting, not a live outstanding-quantity view. "All day" appears nowhere in the 5.16/5.16r2 release notes or Features QRGs. Unresolved because the KDS screen's own display options live in the register/KDS application, and PAR publishes neither a KDS user guide nor a settings reference for it - so this is a gap in the published corpus, not evidence the view is missing.

kitchen-sla-alerts

The Admin Portal guide documents a per-kitchen-queue "Thresholds tab": "Color: Color of the order card border," "Seconds: Number of seconds after the order appears in the queue to apply the threshold style," "Flash: Flash the order card timer," and "Mode: Animate/Switch" — configurable target times with visual color escalation, reinforced by the Kitchen Performance report family which counts "orders bumped prior to each threshold time defined on each kitchen queue" versus those "bumped beyond the last threshold." https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

kitchen-printer-fallback differentiator

A designated backup exists: the Edit Printer dialog carries a 'Backup Printer' drop-down (guide p.262), and the 5.16 release notes (cdn.parpos.com/release-notes/5.16ReleaseNotes.pdf) add kitchen-printer reroutes that automatically follow a KDS queue reroute and can be persisted. Shortfall: nothing public states that failover to the backup printer is automatic when a printer or KDS goes offline, or that queued tickets are preserved — the documented 'Reroute Printers' / 'Reroute Kitchen' flows are operator-initiated button behaviors. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

kitchen-offline-operation differentiator

The In-Store Resilience release notes (already cited elsewhere in this record for reliability-offline-kds-printing) state that on complete internet loss "offline mode operates normally with the primary register acting as the host" — all in-store terminals, including kitchen displays, continue operating against the local host rather than the cloud, with kitchen printers configured as attached to specific registers per the 5.16r2 Admin Portal guide. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

kitchen-item-build-screens differentiator

Station screens show modifier detail but not build detail. Settings2's KitchenVideoGroup type defines KitchenBackgroundColor as "Background color for all items and modifiers in the video group", and the Items type carries ModifierRouting plus ModifierRoutingOptions and AlternateKitchenName, so modifiers are routed to and rendered on kitchen displays rather than collapsed into the line text. Shortfall: there is no recipe or assembly content to display - ItemIngredient carries only Id, ItemId and "Position: an index of where this ItemIngredient is positioned", with no step text, quantity or portion size, and the Items type has no build-instruction field. The 5.16r2 Admin Portal guide's Kitchen Views sections document ticket-text formatting, thresholds, colours and bump behaviour with no recipe-step or portioning screen. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#KitchenVideoGroupTypeTable · retrieved 2026-08-08

kitchen-pizza-fractional-display differentiator

Fractional intent reaches the make line as a modifier code, not as a section model. The 5.16r2 Admin Portal Config Guide's Options > Kitchen > General tab reads "Consolidate Like Modifier Codes: Consolidate modifiers into groups based on the modifier code (ADD, NO, HALF, etc.) on both kitchen displays and printed kitchen chits", and the Modifier Codes page defines the object as Name, Id, "Abbreviation: Text to be added to the beginning or end of the modifier name", Applies To (Ingredients / Non Ingredients / Both), Type (Normal, No, Sub, For, On Side), Charge Type, "Enable KDS Font Color: Controls whether the Modifier Code is seen on the KDS in a specified color" and KDS Font Color. So a HALF code is displayed and printed to the kitchen, grouped and optionally colour-coded. Shortfall: it is a text abbreviation, not a placement dimension. The published order model has no section or placement field (NewOrderItemModifier carries none, and "quarter" and "fraction" occur zero times across the 1.75MB / 659-anchor API portal dump), so which half is never expressed and quarters or specific sections cannot be; there is no graphical section rendering, and the item Type "Pizza" is documented "NO LONGER USED". https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

kitchen-recall-refire

The Admin Portal guide documents "Recalled Border: Color of the border surrounding orders that have been recalled" on the Kitchen View (unbump), plus "Reprint Previous Items Sent: Reprints items that were previously sent to the kitchen on chits for orders that items were later added to" and a dedicated Kitchen Order reprint function — recall and refire/reprint without re-entering the order. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

kitchen-order-modification-alerts differentiator

The Admin Portal guide's Kitchen View format options document "Edited Items: Color of order items that have been edited after being sent to the kitchen" and "Editing Items: Color of order items that are in the process of being edited after being sent to the kitchen," plus a separate "Modified Item Indicator: Symbol that will be printed on kitchen chits and displayed on kitchen displays for items that have been modified." https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

kitchen-guest-ready-notification differentiator

The PAR POS Order Ready Board Configuration Guide (Version 01, April 2026) documents it end to end: "A new customer-facing display, the Order Ready Board, has been introduced for installation inside the store, near the front counter. This screen provides real-time order status updates to guests, eliminating the need for staff to manually communicate order progress. Each order displayed on the board includes the order number, guest name, and order destination." The bump trigger is explicit: "IncludedKitchenQueueIds - The kitchen queue ID(s) that the ORB monitors to determine when an order is complete. When the specified queue is bumped, the order automatically moves from In Progress to Now Serving. Example: The Front Counter Expo is typically the last screen to be bumped, signaling that the order is bagged and ready for the customer." Statuses are "In Progress - the order has been received and is currently being prepared by the kitchen" and "Now Serving - the order has been completed, bagged, and is ready for guest pickup". Supported order types are in-store register, self-service kiosk, digital ordering platforms and third-party delivery applications. It is configured with PAR POS's own appsettings.json and ORBUIConfiguration.json files and communicates with the Primary Register over MQTT; no separate product purchase is named, though it needs a dedicated display. SMS is available only via a third-party provider account (Integration Settings Portal > Third-Party SMS Provider Configuration: EZ Texting, Plivo). https://cdn.parpos.com/docs/Order%20Ready%20Board%20Config%20Guide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

kitchen-waste-logging

Waste can be captured with a reason code, but not where the claim asks. The 5.16r2 Admin Portal Config Guide ships "Waste" as one of five Void Reason names (with 86'd Item, Kitchen Error, Server Error, Test Order), and Settings.svc confirms these are first-class configurable objects - GetVoidReasons returns a VoidReason type (Id, Name) - so an operator can log a waste void against an order with a reason code. Two shortfalls: the entry is made at the register void flow (and by End-of-Day auto-void of abandoned orders), not "directly at the kitchen/KDS screen" - Kitchen.svc has only two read-only bump-time operations and the KDS configuration types carry no logging action; and it depletes nothing, because Brink holds no inventory model (the Settings2 Items type has Cost but no on-hand or stock object anywhere in the 264-type schema). Structured waste logging with inventory debit requires PAR OPS's separate Store Waste Templates, a different product a Brink customer buys alongside. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

kitchen-speed-of-service-reporting

Kitchen SOAP service exposes queue and bump times consumable via API; PAR sells a drive-thru timer. No documented canned percentile SOS report sliced by daypart/station/channel. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01

kitchen-prep-forecasting

PAR OPS Forecasting predicts demand and PAR OPS includes prep label printing and checklists; a generated prep-quantity task list is not explicitly documented. https://partech.com/solutions/back-office-solutions/restaurant-forecasting-software/ · retrieved 2026-08-01

delivery-driver-roster

Drivers are first-class in PAR POS/Brink: the Jobs page has a 'Delivery' section with 'Delivery Driver: Displays the employee as the order recipient in the "Assign Delivery Order" screen' and 'Delivery Dispatcher: Allows the employee to execute "Assign Delivery Order" button behavior'; the Assign Delivery Order behavior states 'only employees clocked in under a job marked as delivery driver will appear' (so driver availability derives from real clock-in state) and 'Assigning an order to a delivery driver transfers ownership of non-cash payments to the driver'; Security Levels carry 'Can Close Orders Assigned to Delivery Drivers'. The Settings2 API exposes the same as Job.IsDeliveryDriver / Job.IsDeliveryDispatcher. SHORTFALL: no assignment state model beyond assigned/not-assigned - nothing documents an in-store / on-run / returning status - and the Admin Portal report catalogue (Accounting, Audits, Comparative, Configuration, Employees, Future Orders, Kitchen, Labor, Loyalty, Marketing, Orders, Product Mix, Sales by Brand / Day Part / Details / Summaries) contains no delivery or per-driver run-history report; the only Orders report is 'Order List by Destination'. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

delivery-dispatch-board

Register button behavior 'Assign Delivery Order' - 'Opens "Assign Delivery Order" screen, which allows for assigning delivery orders to delivery drivers. Only orders with a destination marked as delivery will appear, and only employees clocked in under a job marked as delivery driver will appear. Current employee must be logged in under a job with "Delivery Dispatcher" enabled.' That is a dedicated dispatch screen with an undispatched-order queue and live driver availability. SHORTFALL: the behavior's Configuration Parameters column reads 'None' and the guide describes no elapsed-time-per-order column and no multi-order run batching (assigning 2+ orders to one driver as a single run); order-age styling in this product is a Kitchen Queue threshold feature (Color / Seconds / Flash / Mode) attached to kitchen displays, not to the dispatch screen. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

delivery-route-map differentiator

Assessed 2026-08-08 against primary docs rather than marketing. Settings2 (brinkapiportal.parpos.com/settings2) does carry geospatial data: Destination.ValidDeliveryZones -> DestinationDeliveryZone -> DestinationDeliveryZoneCoordinates with Latitude/Longitude doubles, plus Destination.LimitByDeliveryZone and a per-zone SurchargeId. The 5.16r2 Admin Portal Config Guide (cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf) describes these purely as an address boundary - 'Limit by Delivery Zones: Limit delivery address to specific delivery zones', 'Delivery Zone List: Valid geographical areas' - never as routing input, and it describes the Assign Delivery Order screen in two sentences with 'None' configuration parameters, mentioning no map, geocoded stop list, or turn order. No map, route or sequencing object appears among the 659 operation and type anchors on brinkapiportal.parpos.com (/ordering, /sales2, /settings, /settings2, /labor2, /kitchen, /houseAccounts). Unresolved because the guide documents that screen's function, not its layout, so a map pane could exist undocumented; techcenter.brinkpos.net is login-gated and PAR's Integrations Portal User Guide is not public.

delivery-driver-tracking differentiator

Assessed 2026-08-08. PAR does document an in-house driver module (Job 'Delivery Driver' and 'Delivery Dispatcher' flags, the Assign Delivery Order screen, and the 'Can Close Orders Assigned to Delivery Drivers' permission in the 5.16r2 Admin Portal Config Guide), so this record's prior premise that PAR has no driver management is false - but nothing in that 290-page guide, in the 659 operation and type anchors on brinkapiportal.parpos.com, or on developers.partech.com describes a driver-facing mobile app or any driver position field. The only Latitude/Longitude in the POS schema are DestinationDeliveryZoneCoordinates (zone polygons); in the PAR OPS Portal API the only Latitude/Longitude is on the store address record. Left unknown rather than no because a driver companion app would be a separate mobile product and would not necessarily appear in the POS configuration guide or the POS API surface.

delivery-zones-polygon differentiator

Settings2 documents DestinationDeliveryZone with a "Coordinates" field (alongside Name and SurchargeId) — a polygon/coordinate-defined delivery area, not solely a radius or ZIP/postcode list. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-04 adversarially verified

delivery-zone-pricing

Settings2 documents DestinationDeliveryZone (Name, Coordinates, SurchargeId "ID of the surcharge") and Destination fields LimitByDeliveryZone ("True if delivery address is to be limited to specific zones") and ValidDeliveryZones — polygon zones with a per-zone fee attached via surcharge and address limiting. Shortfall: no per-zone order minimum and no per-zone quoted promise time field is documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03

delivery-address-validation

Settings2 documents Destination fields "LimitByDeliveryZone: True if delivery address is to be limited to specific zones" and "ValidDeliveryZones," gating orders to configured delivery-zone polygons. Shortfall: no documented geocoding provider or address-level validation/rejection message at order time — only zone-membership limiting is described. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-04 adversarially verified

delivery-driver-comp differentiator

Two of the three inputs are documented. Driver-retained tips: assigning an order to a driver 'transfers ownership of non-cash payments to the driver', and jobs can be set to 'Must Declare Tips: Prompts employee for declared tips amount at clock out' with an optional 'Require Reporting of Minimum System-Calculated Tips'. Reimbursement-vs-wage split on export: the PAR OPS Delaget Connect API time_card object (api.delaget.com/swagger/v1/swagger.json) carries 'reimbursements' (type + amount) as its own collection alongside pay_rate, regular_hours, overtime_hours, charged_tips and tips, so reimbursements export as lines separate from wages. SHORTFALL: mileage or distance driven is not captured anywhere - zero occurrences of mileage or distance across the 290-page Admin Portal guide, the 659 anchors of brinkapiportal.parpos.com and the Delaget schema set - and the reimbursement field is a generic timecard line rather than a per-delivery flat reimbursement tied to a run, so per-delivery compensation must be derived outside the product. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

delivery-cash-reconcile

The pieces of a driver settle-up exist as the generic self-banking flow. Job option 'Self Banking: Employee cannot be assigned a cash drawer - instead a personal till is automatically created for the employee'. Register behaviors: 'Start Bank: Assigns a new self-banking till to the current employee'; 'Checkout: Checks out the till assigned to the current employee' with parameters 'Type: Self-banking Employee or cash Drawer', 'Confirm Checkout', 'Print Report (checkout report)'; 'Edit Checkout: Prompts employee to select a previously checked out till to re-enter the declared cash'; 'Clock Out: Clocks out the current employees, and forces checkout if a till is assigned to the employee'; 'Undo Checkout'. Reporting: the Accounting report 'Till History' 'Lists till details for all checked out cash drawers and self-banking tills, sorted by checkout time'. SHORTFALL: none of this is delivery-aware - the guide documents no driver bank that nets cash collected against the orders assigned to that driver and the tips owed, and no per-driver over/short figure appears in the enumerated report catalogue. The only delivery-specific money behavior is that assignment 'transfers ownership of non-cash payments to the driver'. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

delivery-daas-dispatch

Enumeration of the exposed order surface. The Order type on brinkapiportal.parpos.com is fully field-listed - Balance, BusinessDate, CreatedTime, CustomerId, DestinationId, Discounts, Entries, FutureOrder, Id, IdEncoded, IsClosed, IsSent, IsTaxExempt, LaneId, Name, Number, Payments, Promotions, Rounding, SectionId, Subtotal, Surcharges, Tax, Taxes, Total - with no courier, quote, ETA, driver or delivery-status field, so a courier quote and status have nowhere to return into the order record. The delivery payload on a new order is NewDeliveryDetails, which is address only (Address, Address2, City, Country, PostalCode, StateCode). The complete Ordering operation list is ApplyPayment, CalculateOrder, CancelOrder, GetItemAvailability, GetMasterTerminalStatus, GetOrder, GetParty, GetUnavailableItems, SendKitchenInstructions, SendOrder, SubmitOrder, UpdateItemAvailability - none dispatches to a courier. The register button-behavior table in the 5.16r2 Admin Portal guide, which is the entire configurable register surface, has exactly one delivery behavior, 'Assign Delivery Order', and it assigns to in-house drivers. PAR's own delivery product page describes 'Connect instantly to DoorDash, Uber Eats, and Grubhub platforms', '24/7 automated dispute detection' and 'Delivery reconciliation' - marketplace order ingestion and reconciliation, not DaaS courier dispatch of a first-party order. Reference is the legacy PAR POS API Portal, still fully served. https://brinkapiportal.parpos.com/sales2#OrderTypeTable · retrieved 2026-08-08

delivery-daas-fallback differentiator

Follows from the enumerated order surface (see delivery-daas-dispatch): the Order type carries no courier, quote or delivery-status field and no Ordering operation dispatches to a courier, so there is nothing for an overflow rule to target. On the in-house side the only documented assignment mechanism is the manual 'Assign Delivery Order' register behavior, whose Configuration Parameters column reads 'None'; the 5.16r2 Admin Portal guide documents no auto-assign, no wait-threshold escalation and no out-of-zone rerouting. The only zone rule is 'Limit by Delivery Zones: Limit delivery address to specific delivery zones', which blocks an out-of-zone delivery address rather than rerouting the order, and the only threshold rule engines in the product (Prep Times, Lead Times, Kitchen Queue thresholds) act on quote time and kitchen display styling. NOTE: this verdict shares its premise with delivery-daas-dispatch - if PAR ships courier dispatch through an undocumented partner path, both fall together. https://brinkapiportal.parpos.com/sales2#OrderTypeTable · retrieved 2026-08-08

delivery-3p-direct-integration differentiator

DoorDash direct integration is certified (2026 DPIP). PAR OPS claims instant connection to DoorDash, Uber Eats and Grubhub, but that page describes reconciliation/dispute data, not necessarily first-party order integrations for all three. https://partech.com/solutions/insights-and-delivery-solutions/ · retrieved 2026-08-01

delivery-3p-injection

DPIP eligibility requires a POS proactive cancel rate below 1% and merchant-avoidable cancellation rate below 1% on 250+ live stores — only achievable with automatic POS injection. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01

delivery-menu-push

Real-time menu syncing is a mandatory DPIP capability; PAR Ordering claims unified menu/pricing across marketplaces. Channel-specific markup rules not documented. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01

delivery-86-sync

Verified independently: "86 items" and "Item Polling" are both on DoorDash's mandatory capability list, with rolling 28-day enforcement (order failure rate and merchant cancel rate each below 1%, 250+ DoorDash stores to qualify as Established), and PAR holds 2026 PIP status. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01 adversarially verified

delivery-store-pause

Self-guided store setup and self-serve store activation are DPIP requirements; timed auto-reactivation driven from inside the POS is not documented. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01

delivery-3p-reconciliation differentiator

Downgraded on verification. Named shortfall: reconciliation is delivered by PAR OPS Delivery Operations (and disputes by the separate PAR OPS Recovery module), not by the POS, and covers only the three DSPs the page names - "Connect instantly to DoorDash, Uber Eats, and Grubhub platforms". The page says only that it "simplifies reconciliation and operations for all your delivery service providers" and never states what is matched against what. No product documentation exists: delaget.com now 302s to partech.com/delaget/, a placeholder offering only a client login and parops.support@partech.com, and the one primary artifact PAR publishes for this product line - the Delaget Connect API OpenAPI 3.0.4 spec at api.delaget.com - contains no delivery, DSP, DoorDash, Uber or Grubhub surface at all (its nine paths are organizations, workers, retail_transactions, location summary, time_cards, shift_diff and two diagnostics). https://partech.com/solutions/insights-and-delivery-solutions/ · retrieved 2026-08-02 adversarially verified

delivery-injection-error-visibility differentiator

Detailed order error reporting is a mandatory DPIP capability, and DoorDash's 2026 program gives merchants visibility into integration performance. A PAR-side operator alerting console for failed injections is not documented. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01

delivery-tracking-page

Assessed 2026-08-08 against the 5.16r2 Admin Portal Config Guide (cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf), which enumerates every Customer Portal and Future Orders guest-communication setting: Options > Future Orders > Reminders ('Send Order Reminder Email', 'Send X minutes before pickup time', Default Message, Email Template); Options > Online Ordering > General 'Allow Order Cancellation: Order cancelation page allows orders to be cancelled and link to the page is included in the footer of the confirmation email'; the Electronic Receipt register behavior; the Send Email Template admin tool; and the in-store Order Confirmation Display. None is a guest order-status or driver-tracking page and none is an SMS link. The only guest SMS in the product is the register behavior 'Set Party Contact Data - Contact Method: None, Pager, or SMS', an order-ready contact method rather than a tracking link. Left unknown because PAR's current digital-ordering product (PAR Ordering, developers.partech.com/commerce-engines/par-ordering/) publishes an overview page only, with no API or configuration reference, so its guest-facing surface cannot be enumerated.

delivery-promise-time differentiator

The complete quote-time surface is enumerated in the 5.16r2 Admin Portal guide and contains none of the three named dynamics. Options > Future Orders > Prep Times: 'Minimum Prep Time: Default minimum prep minutes to be used for all future orders' plus Prep Time Rules whose Type is exactly one of 'Item Count', 'Order Amount', 'Contains Item', 'Contains Item In Group'. Options > Future Orders > Lead Times: 'Minimum Lead Time' plus Lead Time Rules with the identical four types, and 'Prep time is calculated as the Minimum Lead Minutes, or the highest Lead Minutes on all matching rules.' The delivery component is an explicit constant: Destinations > Delivery tab, 'Delivery Time: Average delivery time in minutes, used to calculate approximate delivery driver arrival time' - Settings2 exposes it as Destination.DeliveryMinutes (byte?). So the quote varies with what is on the order and never with current kitchen load, driver availability or zone drive time; delivery zones carry Latitude/Longitude coordinates and a SurchargeId but no drive-time attribute, and the API's LeadTimeThreshold and PrepTimeThreshold types carry a single LeadMinutes / PrepMinutes integer each. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

delivery-offline-behavior

Assessed 2026-08-08. PAR does document offline behavior, in more places than the prior pass checked: the In-Store Resilience release notes (cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf, backup-primary architecture and resync), and in the 5.16r2 Admin Portal Config Guide the register 'Show Offline Indicator' option, the 'Force Authorization' security permission for the Voice button 'used for offline credit authorizations', the terminal Online/Offline status model, and Options > Online Ordering > General 'Accept Orders when Primary is Offline: Customer Portal and Ordering API accepts orders when the primary Register's connection status is offline'. None of these is delivery-specific: no statement covers whether the Assign Delivery Order screen, driver assignment, driver till checkout or driver settlement continue during an outage. The nearest adjacent statement is the End of Day tool note that 'At least one Register must be online in order to initiate the end of day process ... to ensure that an offline store does not have transactions that need to be synchronized'. Unresolved because PAR's offline documentation is organised by subsystem - ordering, payment, kitchen - and simply never addresses delivery.

digital-first-party-web

PAR Ordering provides first-party branded web ordering; commission model not published. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

digital-menu-single-source

"Real-time POS sync" keeps menus synchronized across channels without manual intervention. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

digital-native-app differentiator

Citation re-pointed 2026-08-09 after the old developers.partech.com slug 301'd; quotation re-verified at the destination. The Punchh Mobile API reference states the APIs execute loyalty programs "primarily via business-branded mobile apps and websites tailored by Punchh" - PAR's own documentation asserting it produces the branded app, not merely APIs a brand could build one against. The documented endpoint groups are a complete consumer-app surface: Users (login, social login via Facebook/Google/Apple, profile, password reset), Payment Cards, Payments, Offers, Coupons, Collectibles, Challenges, Check-ins, Badges, Beacons, Drive-Thru, Gift Cards, Locations, Notifications, Redemptions 2.0, Referrals, Loyalty Transfers, Surveys, Single Scan Code, Swag, WiFi Acquisition. Not documented: any native iOS/Android SDK. https://developers.partech.com/docs/dev-portal-mobile/apis/mobile-api · retrieved 2026-08-09 adversarially verified

digital-account-saved-payment

Citation re-pointed and strengthened 2026-08-09. The Punchh Mobile API - PAR's documented surface for business-branded guest apps and websites - documents a Users group with signup/login (including Facebook, Google and Apple sign-in), profile and account_history, and a Payment Cards group whose operations are explicitly "Fetch All Saved Payment Cards" (GET /api2/mobile/payment_cards), "Create a Payment Card" (POST), "Update a Saved Payment Card" (PUT /{payment_card_uuid}) and "Delete a Saved Payment Card" (DELETE), alongside a Payments group. Guest accounts with saved, tokenized payment methods are therefore documented rather than inferred. Shortfalls: there is no addresses endpoint or address-book group anywhere in the Mobile API reference (the guest record carries only a single profile address_line1/city/state/zip), and no reorder or order-history endpoint - one-tap reorder of a previous order is not documented. https://developers.partech.com/docs/dev-portal-mobile/apis/mobile-api/tag/payment-cards · retrieved 2026-08-09 adversarially verified

digital-upsell-engine differentiator

AI-powered upsells and cart reminders claimed; attach-rate reporting on those suggestions not documented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

digital-scheduled-pacing

Scheduled orders supported; per-daypart capacity throttling that auto-closes slots is not documented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

digital-fulfillment-modes

Pickup, QR table ordering, delivery, kiosk and catering named. Curbside with arrival check-in not named. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

digital-qr-table

The in-store guest-scan pieces are documented. Options > Online Ordering > General: 'In-Store Menu: Menu to be displayed on Customer Portal mobile when in in-store ordering mode'; a dedicated 'Mobile In Store Destinations' tab ('allows you to specify which destination or destinations a mobile in-store order can be processed under') and an 'In Store Alternate Menus' tab. Tipping is supported on the same channel: 'Allow Tips: Customers ordering online will be prompted to add a tip to their order' plus three configurable 'Suggested Tip' percentages. The scan vector is configurable: Receipt Footer 'Show QR Code: Prints QR code at bottom of receipt' with a free-form 'URL: URL to be embedded in QR code (must be valid URL)' and 'Always Print'. Scan-to-pay exists through the loyalty partner: 'For Punchh Single Scan Payment to work on the POS, the location must be configured with Punchh Loyalty and Punchh External Payment. Note: The Punchh application must also be enabled for QR code payment.' SHORTFALL: nothing documents a scan opening or attaching to an existing open POS check, and no guest-side check splitting is documented - a mobile in-store order is a new order under an in-store destination, and Split Check is a register behavior gated on a staff security level. Native pay-at-table is a payment terminal rather than a QR flow: Settings2 PayAtTableOptions is PayAtTableType (None | ParPay), PortNumber ('Port the payment device is connected to') and PromptForTip. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

digital-kiosk differentiator

First-party kiosk with loyalty identification, points, redemption and payment in one scan (Loyalty Pay); no published accessibility conformance. https://partech.com/solutions/guest-engagement-platform/digital-experience/ · retrieved 2026-08-01

digital-group-ordering

Assessed 2026-08-08. Checked the whole configurable surface of Brink's native Customer Portal - Options > Online Ordering (General, Destinations, Mobile In Store Destinations, Modifier Codes, Alternate Menus, In Store Alternate Menus) and Options > Future Orders (General, Reminders, Prep Times, Lead Times, Destinations) in the 5.16r2 Admin Portal Config Guide - and found no shareable cart link, no participant concept, and no per-person or total spend cap; the closest settings are 'Customer Required', 'Order Prepayment' and 'Required Deposit Percent'. The Ordering API's NewOrder schema (brinkapiportal.parpos.com/ordering#NewOrderTypeTable) has no participant or sub-cart construct and the Order type has no group field. Left unknown rather than no because group ordering would live in PAR's newer PAR Ordering / MENU product, and developers.partech.com/commerce-engines/par-ordering/ is an overview page with no API reference; partech.com's online-ordering page names channels ('web, mobile, kiosks, catering, and third-party platforms') without addressing it.

digital-catering-portal differentiator

Catering order management named; separate minimums, lead-time rules, quotes, deposits and invoice/ACH terms not documented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01

digital-voice-ai-phone differentiator

Assessed 2026-08-08. The record's SYNQ3 basis is stale (SYNQ3 was absorbed into SoundHound in January 2024) and PAR has published nothing since that names a certified voice-phone-ordering partner. Checked: partech.com/integrations/, the official Partner Ecosystem directory, which renders its PAR Products and Categories filters client-side - the retrieved page exposes an unfiltered partner list (7shifts, Accubar, Acrelec, Adyen, Altametrics, Appfront.ai, Attentive and others) with no category labels, so no voice-AI category could be enumerated; developers.partech.com, whose sitemap is five URLs and whose only rendered references are PAR Pay (26 operations) and Identity Service (23 operations), neither voice-related; and the 659 operation and type anchors on brinkapiportal.parpos.com, whose Ordering service is the generic order-injection API a voice vendor would consume but which names no partner. Third-party voice vendors advertise Brink integrations on their own sites, which is the partner's claim rather than PAR naming a certified partner, and this differentiator-weight cell needs grade A or B. Unresolved rather than absent: an integration directory is not an enumeration.

digital-drivethru-ai

Assessed 2026-08-08. PAR's documented drive-thru surface is conventional. The 5.16r2 Admin Portal Config Guide covers drive-thru lanes (Job.LaneId, Options > Future Orders 'Default Lane: Lane in which future orders are to be added'), order channels 'Delivery, Drive-Thru, etc.' selectable per promotion and per price change, a 'Vehicle ID Panel' register behavior, and 'Use Paid Order Sequencing: Applies order sequencing to drive-thru orders based on order payment' (annotated 'No longer supported as of the 5.0m Release'). Nothing in that 290-page guide, in the 659 anchors on brinkapiportal.parpos.com, or on developers.partech.com describes AI voice ordering at the lane, menu/modifier grounding for a voice agent, or an escalation-to-human handoff. partech.com/integrations/ renders its category filter client-side so no voice-AI category could be enumerated, and an integration directory would not be enumeration evidence regardless. Unresolved rather than absent.

digital-sms-ordering

Assessed 2026-08-08. Every SMS reference in the 5.16r2 Admin Portal Config Guide is non-ordering: the register behavior 'Set Party Contact Data' takes 'Contact Method: None, Pager, or SMS' (an order-ready contact for the current party); a Kitchen Queue Order Expediter Action can 'Send SMS' with a configurable Message, alongside Send Email and Send Page - a staff/system alert; and the Options > SMS tab says only 'SMS settings and configuration are accessed via Admin Portal > Integrations Portal. Please see the Integrations Portal User Guide for detailed configuration information', and that guide is not public, which is precisely why this stays open. The Customer Portal channel settings (Options > Online Ordering) offer no text-to-order path, and the Ordering API's SubmitOrder takes a structured NewOrder rather than free text. On the loyalty side, PAR Punchh markets a 'Text To Join' SMS program, which is list acquisition rather than ordering; support.punchh.com has moved to Salesforce and returns HTTP 401 redirecting to /s/login for both article URLs and the Zendesk /api/v2/help_center endpoints, so its articles could not be read.

digital-google-order differentiator

Assessed 2026-08-08. Checked the complete configurable surface of Brink's native online ordering - Options > Online Ordering (General, Destinations, Mobile In Store Destinations, Modifier Codes, Alternate Menus, In Store Alternate Menus) in the 5.16r2 Admin Portal Config Guide - with no Google, Google Business Profile, Order with Google, or ordering-link provisioning setting; the string 'Google' does not occur anywhere in that 290-page guide. The only Google reference across PAR's developer surface is PAR Pay's GET /creditcard/v1/googlepayconfiguration (Google Pay, a wallet, not ordering placement), and developers.partech.com's five-URL sitemap documents no GBP integration. Left unknown rather than no because Order with Google placement is normally performed by the ordering provider through Google's own program rather than exposed as a POS setting, so its absence from the settings editor is not evidence of absence; techcenter.brinkpos.net remains login-gated and PAR Ordering publishes no reference.

digital-apple-business-connect

Assessed 2026-08-08. The string 'Apple' does not occur anywhere in the 5.16r2 Admin Portal Config Guide, which is the complete Brink configuration surface including all six Online Ordering tabs, and no Apple object appears among the 659 operation and type anchors on brinkapiportal.parpos.com. PAR's only documented Apple integration remains the Punchh Apple Wallet pass guide on developers.partech.com (docs/dev-portal-pos/additional-topics/applepassintegrationwithpos), which is a loyalty pass rather than an Apple Maps place-card 'Order Food' action. Unresolved rather than absent for the same reason as Order with Google: an Apple Business Connect custom action is registered in Apple's own console by the ordering provider and would not appear as a POS setting, and PAR Ordering publishes no reference to check.

digital-loyalty-attach

Punchh loyalty is integrated into PAR Ordering; Loyalty Pay lets a guest identify, earn, redeem and pay in a single scan at counter, kiosk or drive-thru. https://partech.com/solutions/guest-engagement-platform/digital-experience/ · retrieved 2026-08-01

digital-subscriptions

Punchh program design explicitly includes memberships; recurring-billing mechanics not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

digital-promo-parity

Punchh integrates across POS, digital and mobile via open APIs so offers are defined centrally; explicit channel-eligibility controls not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

digital-guest-data-ownership differentiator

Self-serve bulk export exists and is an Admin Portal function rather than a support request: 'The Export section provides tools for exporting customers, sales, labor, settings, and surveys.' 'Customers - The Export Customers tool produces a CSV file for download which contains customer records that match the selected filters', with filters for birthday, gender, 'Preferences: Filter the customers by one or more communication preferences' (the consented-marketing dimension), order date, items ordered, preferred location, signup location, signup date, 'Filter By Email Address: Filter customer to those whose email address is in a given list of email addresses' and 'Filter By Zip Code'. No fee, quota or approval step is mentioned anywhere in the Export section. SHORTFALL: PAR publishes no statement that the operator owns the guest records; the guide never enumerates the exported CSV's columns, so email and phone presence is inferred from the filter set rather than documented; and order history is not part of this export - 'The Export Sales tool produces a file that can be imported into a third-party accounting or inventory system', formatted from the Options > Accounting > GL Export mapping (QuickBooks IIF, for example), which is general-ledger data rather than per-guest order history. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

digital-checkout-pci-sca

The hosted-fields half is documented. The PAR Pay Service API reference on PAR's unified developer portal exposes GET /creditcard/v1/iframeurl, documented as a hosted iFrame URL for secure card data entry, alongside /creditcard/v1/purchase, /preauth, /capture, /void, /refund, /creditcards (GET and PATCH) and /googlepayconfiguration, with OAuth via POST /oauth/token; card-on-file is a stored-instrument surface rather than a PAN surface. On the POS side, Brink's Ordering API accepts a NewOrderPayment of type NewExternallyTokenizedCreditCardPayment, so a digital channel can settle without the PAN entering the order payload, and the Admin Portal carries a group-level Tokenization page for third-party tokenization providers. SHORTFALL: no 3-D Secure endpoint, parameter or field appears anywhere in the PAR Pay reference, and PAR publishes no PCI DSS 4.0 statement at all - nothing addressing the client-side script-integrity requirements (6.4.3 and 11.6.1) effective March 2025 - on developers.partech.com, brinkapiportal.parpos.com or cdn.parpos.com/docs/. https://developers.partech.com/docs/par-pay/ · retrieved 2026-08-08

digital-surcharge-transparency differentiator

One engine, scoped to channels. Surcharges are configured once - 'Surcharges are additional fees that can be applied to an order and are excluded from reported sales' - with Surcharge Style = Gratuity, Service Charge, or 'Non-Cash Adjustment: Allows the restaurant to take the interchange fee which it has to give to the processors for a credit card payment from the guest. If the guest pays by cash, they do not have to pay the interchange fee. If the guest pays through credit card, the interchange fee is added to the bill amount' - dual pricing - and Method = Fixed Per Order, Fixed Per Item, Percentage Per Order, Percentage Per Item, with 'Automatically Apply' for qualifying orders. Digital parity comes from the 'Valid Destinations tab: When Limit Destinations is checked, the surcharge can only be applied to the selected destinations', and online orders run under destinations chosen in Options > Online Ordering > Destinations, so the same surcharge configuration governs the Customer Portal and the Ordering API; surcharges are also first-class in the API (Order.Surcharges, NewOrderSurcharge, GetSurcharges). SHORTFALL: the Edit Surcharge dialog's complete tab set is Party Size, Dates, Hours, Days, Valid Terminals, Valid Destinations, Valid Items, Valid Sections and Taxes - there is no guest-facing disclosure text field, no card-brand restriction (hence no way to suppress on brands that prohibit surcharging), and no state or jurisdiction control. Compliance is left entirely to the operator's own destination, terminal and section scoping. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

guest-loyalty-unified-profile

Punchh integrates across POS, digital and mobile channels; PAR ships a Guest Identity Service in PAR Common Services on the developer portal. Documented dedup/merge behavior not published. https://developers.partech.com/ · retrieved 2026-08-01

guest-loyalty-thirdparty-identity-attach differentiator

PAR closed its acquisition of Bridg (identity resolution / shopper intelligence) on March 24, 2026, which is aimed at resolving otherwise-anonymous transactions. Marketplace-order attach specifically is not documented. https://partech.com/wp-content/uploads/2026/05/050726-PTC-Earnings-Release-Q1-2026-Final.pdf · retrieved 2026-08-01

guest-loyalty-accrual-models

Punchh supports visit-based programs, points that unlock rewards, points redeemed at a threshold, and banked currency — well past the two-model bar. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

guest-loyalty-tiers differentiator

Loyalty tiers explicitly supported and configurable; automatic rolling-window promotion AND demotion not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

guest-loyalty-offline-behavior differentiator

Assessed 2026-08-08. Brink's own loyalty program is retired - the 5.16r2 Admin Portal Config Guide states 'NOTE: The PAR POS Loyalty program is no longer supported as of March 31st, 2024', the Loyalty report category reads 'This functionality is no longer supported as of March 31st, 2024', and the Print Member and Replace Customer register behaviors are likewise marked retired - so loyalty is delivered by a configured provider: Options > Loyalty lists Paytronix, NCR, SessionM, Punchh, Heartland, Givex and Beanstalk, all configured through the non-public Integrations Portal User Guide, plus Relevant inline. PAR's offline documentation (In-Store Resilience release notes; 'Show Offline Indicator'; the Voice button for offline credit authorizations; 'Accept Orders when Primary is Offline' for Customer Portal and the Ordering API) never mentions loyalty lookup, accrual or redemption. On the provider side, developers.partech.com/docs/dev-portal-pos states the POS 'contacts the Punchh server to retrieve, update, and store the associated information' and lists Point of Sale, Redemptions 1.0 and Redemptions 2.0 API groups with no fallback, queue or reconcile statement; the detailed references are certification-gated and support.punchh.com returns HTTP 401 to a Salesforce login. Unresolved for lack of a reachable statement in either direction.

guest-loyalty-offer-stacking-rules differentiator

The Promotions type on the PAR POS API portal exposes stacking and precedence directly as configuration fields: 'AllowLaterOrderReductions - True if other promotions and discounts can be applied to orders that already have this promotion applied'; 'AllowPriorOrderReductions - True if this promotion can be applied to orders that already have a promotion or discount applied'; 'AllowPriorItemPromotions - True if this promotion can be applied to items that already have a promotion applied'; 'AllowPriorModifierPromotions - True if this promotion can be applied to modifiers that already have a promotion applied'. That is exclusive-versus-combinable in both directions and at order, item and modifier scope. Order of application is 'Priority (ushort) - Sort priority of this Promotion'. Volume is capped by 'MaximumPerOrder - Maximum number of times the promotion can be applied to a single order' with 'EnforceMaximumPerOrder', and value by MaximumAmount with EnforceMaximumAmount. This is the engine third-party loyalty rewards land in: the 5.16r2 Admin Portal Config Guide defines 'Loyalty Discount: Discount can only be applied via the redemption of a loyalty reward' and 'External ID: External identifier for mapping to loyalty rewards in external loyalty providers', so a provider's rewards are subject to the same stacking and precedence rules. Reference is the legacy PAR POS API Portal, which still serves full content. https://brinkapiportal.parpos.com/settings2#PromotionsTypeTable · retrieved 2026-08-08

guest-loyalty-targeted-offers differentiator

Upheld, evidence replaced with the API reference. The Custom Segment APIs document nine operations - list, create, update and delete a custom segment, plus add, remove, search, bulk-add and bulk-remove guests within one - and "Custom Segments" is a first-class endpoint group in the Platform Functions API. The Campaigns page defines a campaign as "a scheduled batch job or triggered action that adds gifts... for users, typically targeted at a particular user segment", and Offers is a documented Mobile API domain. Segment-targeted, scheduled offer delivery is documented rather than marketed. Not established: predicate/rule-authoring depth - the segment endpoints manage membership, not criteria. https://developers.partech.com/docs/dev-portal-platform-functions/additional-topics/gettingstartedwithcustomsegment · retrieved 2026-08-02 adversarially verified

guest-loyalty-rfm-segmentation differentiator

Segmentation is offered, partly as a managed service, and Bridg adds shopper intelligence. Automatic named lifecycle segments (new/regular/at-risk/lapsed/VIP) computed without operator query-building are not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

guest-loyalty-lifecycle-automation

Automated campaign generation and deployment is claimed at the PAR Intelligence layer; specific always-on birthday / first-visit / lapsed win-back triggers are not enumerated in public docs. https://partech.com/solutions/par-intelligence · retrieved 2026-08-01

guest-loyalty-native-email-sms differentiator

PAR Engagement includes a Marketing & Offers product deploying campaigns across channels; native email AND SMS sending is not separately confirmed in the pages reviewed. https://partech.com/solutions/guest-engagement-platform/ · retrieved 2026-08-01

guest-loyalty-consent-management

Citation re-pointed 2026-08-09 after the old opaque slug 301'd; quotations re-verified at the destination. Punchh's eClub Guest Upload endpoint documents per-channel consent primitives: "If the 'Explicit-Opt in' flag is enabled, marketing_email_subscription is a required parameter"; a compliance/opt-in SMS flow (send_compliance_sms with active_registration, where active_registration false plus send_compliance_sms true "will be treated as a bulk upload and no campaigns or compliance/opt-in SMS will be triggered"); terms_and_conditions and privacy_policy booleans in the user object; and a per-business validated source parameter - "only the source configured in the Punchh platform is considered valid in the API request" - which is source-of-consent capture with explicit opt-in enforcement. Shortfalls: no consent-timestamp field is documented on the upload or on the guest record (the guest webhook exposes created_at/updated_at for the user, not a per-channel consent timestamp), and nothing documents honoring revocation received by any reasonable means across all channels - only the SMS compliance flow and boolean subscription/unsubscribed flags are described. https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/eclub/post/api2/dashboard/eclub_guests · retrieved 2026-08-09 adversarially verified

guest-loyalty-10dlc-registration

Assessed 2026-08-08. No A2P 10DLC brand or campaign registration statement is reachable in any PAR first-party surface. Checked: partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ (names 'custom rules, tiers, and rewards' and 'open APIs and enterprise-grade security'; no SMS, no 10DLC); developers.partech.com/engagement-tools/par-punchh/ and its six sections - Developer Resources, Online Ordering, Platform Functions, Mobile, POS & Kiosk, Webhooks Manager - where Platform Functions documents Location, Business Migration, Custom Segment, User Operations, Franchisee and Eclub guest upload with no messaging-registration topic; and the 5.16r2 Admin Portal Config Guide, whose Options > SMS tab defers entirely to the non-public Integrations Portal User Guide. Punchh's own help centre, support.punchh.com, has moved to Salesforce and returns HTTP 401 redirecting to /s/login for both article URLs and the Zendesk /api/v2/help_center endpoints, so its 'Text To Join' article - which public summaries describe as SMS short-code based, with a separate Attentive partnership for SMS marketing - could not be retrieved. Unresolved because the operative document is gated, not because the capability is absent.

guest-loyalty-campaign-attribution differentiator

Real-time dashboards claimed for participation, ROI and customer lift; tying redeemed offers to actual check totals is not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

guest-loyalty-data-export-portability differentiator

Self-serve guest-list export is documented and needs no ticket: 'The Export section provides tools for exporting customers, sales, labor, settings, and surveys' and 'The Export Customers tool produces a CSV file for download which contains customer records that match the selected filters', filterable by birthday, gender, communication preferences, order date, items ordered, preferred and signup location, signup date, email address and zip code. No fee or approval step is mentioned. SHORTFALL: transaction history is not in it - the companion Export Sales tool 'produces a file that can be imported into a third-party accounting or inventory system', formatted from the GL account mapping (QuickBooks IIF and similar), which is ledger data rather than per-guest transactions. And this is the POS customer database, not the loyalty ledger: PAR POS loyalty is retired ('no longer supported as of March 31st, 2024', including this tool's own 'Filter By Loyalty Cards'), so points, tiers and redemption history sit with the configured provider - Punchh, Paytronix, SessionM, Givex and others - whose export terms are documented only behind certification-gated or login-gated material, with support.punchh.com returning HTTP 401. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

guest-loyalty-cdp-event-api differentiator

The Webhooks Manager documents guest create/update/delete only. A CDP event feed needs transaction/order events, which PAR explicitly does not push — its own guidance is to poll GetOrders with a ModifiedTime filter. The researcher scored 'partial' for exactly this on extensibility-webhooks-push and reporting-webhooks, then 'yes' here; inconsistent. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01 adversarially verified

guest-loyalty-review-capture-routing differentiator

Post-transaction feedback capture is documented and first-party. Receipt Footer options include 'Show QR Code' with a configurable URL and 'SMG Code: Survey code to be added to receipt for customer surveys'; the receipt and chit token list includes '%SurveyCode% - SMG survey code will be placed on receipt and or chit' and '%QualtricsSurveyCode% - Qualtrics survey code will be placed on the receipt and or chit'. Responses return into reporting: the Marketing report category carries Survey Summary, Survey Detail and Survey Question Summary; customers can be filtered by 'Surveys Taken' and 'Surveys NOT Taken' when exporting; and 'The Export Survey Results tool produces a CSV file containing survey responses for the selected survey completed within the selected date range'. SHORTFALL: no routing by score anywhere - nothing sends low scores to a private service-recovery workflow or steers high scores toward public review sites, and no review-site destination is configurable. PAR's own survey authoring is retired: the Settings Editor entries for Surveys, Survey Questions, Survey Question Groups and Survey Rating Scales all read 'This functionality is no longer supported as of March 31st, 2024', leaving the survey platform itself (SMG, Qualtrics) or a reputation partner such as Birdeye to perform capture and any routing. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

guest-loyalty-referral-program

Referrals named as a layerable Punchh program element; per-guest codes, attribution and two-sided rewards not detailed. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

guest-loyalty-wallet-pass differentiator

Upheld at grade B on documentation rather than the Smart Passes landing page. PAR's POS developer docs describe Apple Wallet pass integration with the POS: "Apple Loyalty Passes, part of Apple Wallet, contain various details like loyalty points, the user's name, email address, etc.", redeemed either by NFC tap on certified terminals (One-Tap Flow) or, in the Alternative Flow, by barcode - "the POS system should have a Punchh integration and a scanner to scan the user's QR code or barcode for user/redeemable look-up" - resolving through the Punchh User Look-up API. Caveat: Google Wallet appears nowhere in that document, so only the Apple side is documentation-backed; the Apple+Google "Smart Passes" pairing is a marketing claim. https://developers.partech.com/docs/dev-portal-pos/additional-topics/applepassintegrationwithpos · retrieved 2026-08-02 adversarially verified

guest-loyalty-privacy-rights-tooling

Upgraded from partial 2026-08-09; the prior inference from webhook status names is withdrawn. PAR/Punchh documents a complete business-admin DSAR toolset in the Platform Functions API, all authorized by the operator's own BUSINESS_ADMIN_KEY. Access: GET /api2/dashboard/users/info "lets you fetch a user's information by user ID, phone number, or email address", returning the full profile plus the loyalty balance object (points_balance, banked_rewards, membership_level, total_credits/debits) and reward ledger. Export: POST /api2/dashboard/users/send_user_details_export "Emails a guest export to the guest as well as the requester", with an email_admin_only flag. Deletion: DELETE /api2/dashboard/users takes a reason of delete_general, delete_test_data, anonymize_forget_me or anonymize_inactivity; Delete "Deletes the user and all associated transaction data permanently" and Anonymize "Deletes all of the user's PII (personally identifiable information), while keeping anonymized transaction data for reporting integrity. This is in compliance with GDPR/CCPA standards". Propagation is corroborated by the Webhooks Manager guest event, which states Punchh sends no guest events for deleted, anonymized or archived users "as personally identifiable information (PII) is not stored once a guest is moved into these statuses". Caveats rather than shortfalls against this claim: deletion is asynchronous (configurable grace period, default 7 days) and the guest must be deactivated first. https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users/post/api2/dashboard/users/send_user_details_export · retrieved 2026-08-09 adversarially verified

guest-loyalty-redemption-fraud-controls

Settings2's SecurityLevel enumerates OverrideDailyLoyaltyCardLimit and ApproveLoyaltyCards — a daily loyalty-card usage limit exists with role-gated override, i.e. a documented redemption velocity control of the kind the claim enumerates, plus role-gated loyalty-card approval. Shortfalls: manager approval on manual point adjustments, employee self-redemption flagging, and a loyalty-specific audit log are not documented; Punchh-side fraud tooling does not appear in the public docs. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03

guest-loyalty-ai-offer-recommendation differentiator

Sole source is the PAR Intelligence marketing page, and the researcher's own note says 'verify in a demo that it is GA, not roadmap.' A cell you cannot confirm is shipped cannot be a 'yes'. https://partech.com/solutions/par-intelligence · retrieved 2026-08-01 adversarially verified

guest-loyalty-stored-value-gift

Physical and digital gift cards with loyalty integration; explicit tie to the same guest profile and brand-wide redemption not documented. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01

labor-clock-in-at-pos

A Labor2 service exposes shifts/labor data from the POS, implying terminal-based punching; PAR OPS syncs POS timekeeping to payroll. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01

labor-photo-punch-verification differentiator

Enumeration of the entire employee identification surface in the 5.16r2 Admin Portal Config Guide. Per job: 'Can Login with Card: Clock-in, login, and permission authorization via magnetic card is allowed'; 'Can Login with Finger: Clock-in, login, and permission authorization via finger scan is allowed'; 'Can Login with Pin: Clock-in, login, and permission authorization via four-digit PIN is allowed'; 'Can Login with Username/Password: ONLY when Revenue Quebec is enabled'. Per employee the same methods appear (Card / Finger / PIN). The register 'Set Login' behavior's parameter is 'Login type: Prompt for type, Card, Finger Scan, or PIN'. The terminal peripheral list enumerates Coin Dispenser Name, Customer Display Name, Barcode Reader Name, MSR Type and 'Finger Scan Reader Type: Brand and model of the biometric finger scanner connected to the terminal' - no camera device exists in it. There is therefore no photo capture at punch, no facial verification, and no photo-only mode; the only biometric is fingerprint, of which PAR notes it stores 'only a hexadecimal string of data', not the fingerprint itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

labor-geofenced-mobile-punch

API-schema enumeration. In the PAR OPS Portal v2 OpenAPI, PUT /v2/TimeClock/ClockIn takes exactly CurrentDateTime, TimeClockID, JobID, ClockID, IsManagerOverride and DeclaredTipsAmount, plus the DCKey header - no latitude, longitude, accuracy, device or geofence parameter - and the rest of the punch surface (/v2/TimeClock, /v2/TimeClock/ClockOut, /StartBreak, /EndBreak, /Settings, /EmployeesActualTime, /EmployeesLiveTimeClocks) is likewise location-free; the TimeClockModel and LiveTimeClockData schemas carry only ClockIn, ClockOut, BreakIn, BreakOut, UnpaidBreakMinutes and identifiers. The only Latitude/Longitude in the entire PAR OPS Portal API is on the store address record, and the ShiftWorks API's timeclock endpoints (/shiftworks/Timeclock/history/{unitID}, /shiftworks/Timeclock/firstweekday/{unitID}) carry none. On the POS side punching is terminal-bound by construction: clock-in is a register function authenticated by Card, Finger Scan or PIN, and TimeClockID identifies a physical clock. No geofenced or location-validated mobile punch exists in the documented surface. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-08

labor-offline-time-punch differentiator

The In-Store Resilience release notes document a 15-minute guardrail that explicitly blocks "Clocking Out" (alongside Checking Out and Cash Drawer Assignment) on the Backup Primary register immediately after it takes over from a failed primary, "to decrease the frequency of state synchronization issues." Shortfall: this is a documented restriction on offline punch actions, not a loss-free, duplicate-free reconciliation guarantee — no such guarantee is stated anywhere in the document. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

labor-granular-rbac

SecurityLevel objects (Id, Name, Permissions, retrievable via GetSecurityLevels) carry 26+ discrete per-action booleans — VoidItems, ApproveDiscounts, ApprovePromotions, DeletePayments, AddSurcharges, DeleteSurcharges, ManageCashDrawers, CanOpenAnyDrawer, ApproveClockIn, ApproveClockOut, ApproveCheckout, ReopenOrders, SplitCheck, OverrideMaximumTipPercent and more — and Jobs bind a DefaultSecurityLevelId, so permissions are genuinely per-action rather than fixed cashier/manager/admin tiers, configured per location (Brink settings and API provisioning are location-scoped). Shortfalls: no documented permission for report access or price change (two of the claim's enumerated actions), and Admin Portal / back-office role configuration is not publicly documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03

labor-manager-override-audit

Approver attribution is documented and queryable after the fact: Sales2 order history carries ApproverEmployeeId on OrderItemVoid, OrderDiscount, OrderPromotion and OrderSurcharge (each "Maps to the Id of the Employee who approved..."), alongside the applying EmployeeId, retrievable via GetOrders by business date — individual attribution, not a shared-PIN black hole. Shortfalls: no immutability guarantee is documented anywhere, and refund orders (Order.IsRefund) carry no approver field. https://brinkapiportal.parpos.com/sales2 · retrieved 2026-08-03

labor-native-scheduling differentiator

PAR POS Cloud APIs, Using SOAP APIs - the vendor's own developer portal - carries the proposition as a shipped API surface rather than as a manual screenshot. The Labor2 service is described verbatim as "Labor2 - Employee shifts, worked hours, and labor schedules", and its summary reads "Provides labor functionalities like the ability to save and retrieve labor schedules, as well as retrieve shifts recorded by the Register at a location." Three of its methods are named and described: "GetLaborSchedule - What is the Labor Schedule at this location?", "SaveLaborSchedule - Saving ScheduledShifts for this location." and "GetShifts - What are the Shifts that have been worked at this location?" - so the schedule is a first-class, writable entity in the product, and planned shifts and worked shifts are distinct retrievable record sets. PRODUCT IDENTITY IS ESTABLISHED ON THE PAGE rather than assumed from the vendor name: the endpoint template listed for the service is "http://www.brinksoftware.com/webservices/labor/v2/ILaborWebService2/{MethodName}", so Labor2 is Brink's own service, which is the product this record scores. SCOPE OF THIS CITATION, stated so it is not over-read: the API reference establishes that native labor scheduling exists, is writable, and is held separately from worked shifts. It does NOT carry the Admin Portal detail the quarantined guide held - the drag-to-create Scheduler UI, the Copy button, the "Shift Exceeds Scheduled" alert, the Weekly Labor Schedule report, or the "Exempt from Labor Schedule" job flag. Those rest on the barred PDF and are not re-cited here. RE-EVIDENCED 2026-08-30: the cell previously rested on https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf, quarantined behind a host-wide robots bar on cdn.parpos.com (user-agent group "*", "Disallow: /", re-measured 2026-08-16) and NOT re-fetched. The barred PDF is not recovered; a different document on a permitted host was found to carry the same proposition, so the quarantine stamps come off and the grade is set from the new source rather than restored from grade_before_quarantine. developers.partech.com/robots.txt was fetched whole (76 bytes, HTTP 200, one group "*", no Anthropic agent named) and matched mechanically with the shared parseRobots/refusedForUs: refusedForUs("/docs/parpos-cloud-apis/soap") returns null, and no Content-Signal reserves anything. A BARRIER THAT WAS NOT CROSSED: this page links the WSDL files themselves at cdn.parpos.com/WSDL/latest/Labor2.xml, which is the barred host. The WSDL was NOT fetched and nothing above rests on it. api.brinkpos.net was also checked as a candidate host and is NOT usable: its robots.txt names claudebot and bars it at /. The verified flag on this row records the 2026-08 adversarial pass on the VALUE, taken against the original citation; it does not carry over to this replacement document. No verification.jsonl row was added, because a re-citation is not an adversarial pass and must never be counted as one. https://developers.partech.com/docs/parpos-cloud-apis/soap · retrieved 2026-08-06 adversarially verified

labor-demand-labor-forecast differentiator

Upheld and re-graded D->A on the PAR OPS Portal v2 OpenAPI. GET /v2/StoreSchedule/ScheduleForecast "Returns a list of Schedule Projections and daily requirements" for a ScheduleTemplateID over a period; GET /v2/StoreSchedule/ProjectedSales returns projected sales per business date (example {BusinessDate, Amount: 1852.74, ForecastRecordType}); GET /v2/StoreScheduleForecastCharts/ProjectedData and /ActualData return a week of demand in hourly buckets (Interval 01:00:00 from StartTime 06:00:00), so projected can be read against actual. Schedule templates and scheduleBases exist at store, multiStore and administrator scope. Not established: whether the requirement is broken out by job or duty. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-02 adversarially verified

labor-realtime-labor-percent differentiator

The Admin Portal guide documents an Admin Portal dashboard "Summary" widget showing "Net Sales, Labor cost, Sales Per Labor Hour, the number of employees Clocked In" together, and a "Sales & Labor" widget graphing net sales and labor cost by hour when viewing a single day. Shortfall: no explicit "labor cost as a percentage of sales" metric is named (only Sales Per Labor Hour), and this is documented as an Admin Portal (back-office) dashboard, not confirmed as available on a POS terminal during service. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

labor-overtime-prevention differentiator

The Admin Portal guide documents an "Overtime" alert: "Send alert when an employee goes from regular time to overtime." Shortfall: this fires as an email alert at or after the moment of crossing into overtime, not as a clock-in warning or block before the overtime is incurred, which is what the claim requires. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

labor-break-compliance-by-state differentiator

The PAR OPS (Data Central) portalV2 OpenAPI documents a jurisdiction-scoped Autocompliance rules engine: /v2/Autocompliance/MealPeriodPenalty rules are scoped by CountryID/CountryStateID/CountyID/CityID with EffectiveStartDate/EndDate and carry MinBreakMinutes, PenaltyMinutesAwarded, PenaltyRate, BreakType and ScheduleValidation; penalty lines carry BreakRequiredAfter/TakeBreakWithin and a SignedWaiver flag; RestPeriodBetweenShiftsRule and TimeclockThresholdRule (BreakIn/CheckIn/BreakDuration) are similarly jurisdiction-scoped, and the State model includes MealBreakWaiver. Missed-break premium pay is explicit (penalty minutes awarded at a penalty rate). Shortfalls: an employee-facing break attestation prompt is not documented anywhere public — waivers appear only as flags — and the POS-side 5.16r2 guide documents only generic break types, minimum-minutes enforcement and break start/end receipt printing; the compliance engine lives in the separately sold PAR OPS back office. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04

labor-fair-workweek-support

The PAR OPS (Data Central) portalV2 OpenAPI documents a jurisdiction-scoped predictive-scheduling rules engine: /v2/Autocompliance/ScheduleRule (AutocomplianceScheduleRuleGetDto) carries CountryID/CountryStateID/CountyID/CityID, EffectiveStartDate/EndDate, Threshold, PenaltyType, PenaltyValue and DaysAdvanceNotice, validated at schedule time via /v2/StoreSchedule/ScheduleRules/Validate — an advance-notice-deadline-and-predictability-pay engine matching the claim. Shortfall: this lives in the separately sold PAR OPS back office, not the POS itself, consistent with the record's existing findings for the sibling meal-period and minor-labor Autocompliance rules. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified

labor-minor-labor-rules

The PAR OPS portalV2 OpenAPI documents a minor-labor rules engine: /v2/Autocompliance/MinorRule objects scoped by CountryID/CountryStateID/CountyID/CityID with MinAge/MaxAge, SchoolInSession, Weekdays, effective dates, CanBeExempted and AllowOverride; school calendars with event dates are maintained and assignable per employee (/v2/schoolCalendars, /v2/StoreEmployee/schoolCalendar); and /v2/StoreSchedule/MinorRules/Validate plus /v2/StoreSchedule/MinorRules/Override enforce the rules at scheduling, with override explanations recorded per employee and business date. Shortfall: clock-in-time enforcement of minor rules is not documented — the POS-side 5.16r2 guide enforces only generic schedule punctuality windows at clock-in — and the engine lives in the separately sold PAR OPS back office. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04

labor-tip-pooling-rules

The Admin Portal guide documents "Tip Pooling Enabled: Allows for the definition and management of employee tip pools," with per-job "Contribute to Tip Pool" (percentage of compensation) and "Receive Distributions from Tip Pool" flags. The PAR OPS Payroll API (already cited elsewhere in this record) separately computes TipShareHours/TipShareAmounts/TipShareJobWeights per employee per payroll period, exportable to payroll — automatic per-shift computation from configurable rules rather than a manual spreadsheet. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

labor-tip-distribution-audit-trail

The PAR OPS (Data Central) Payroll OpenAPI documents a full tip-share engine: /Payroll/TipShareHours ("Tip Share Recipients Hours" per StoreEmployee/Job), /Payroll/TipShareAmounts (CalculatedAmount, PostingAmount, Hours per StoreEmployee/Job for a payroll period), TipShareContribution models with patchable PostingAmount, /Payroll/TipShareJobWeights (OriginalPercent/PostedPercent), /Payroll/TipShareSettings (Frequency, DateFrom/Thru, AllowAdjustJobWeights, Shift) and POST /Payroll/TipShareAmountToPayroll; the portalV2 CashBalancing API adds per-employee, per-business-date CashOut records with TipShareOutAmount, and jobs carry TipShareMethodEnum {None, Contributor, Recipient} plus UseInPool. All queryable/exportable via API. Shortfalls: this lives in the PAR OPS back office, a separately sold module, not the POS itself; and a per-employee tips-received record (declared/charged tips) is not in the public spec — contributions, weights and distributed amounts are. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portal/swagger.json · retrieved 2026-08-03

labor-qualified-tips-w2-reporting differentiator

The cash-versus-charged separation is real and machine-readable. The Delaget Connect API (the PAR OPS Insights & Delivery API linked from developers.partech.com/operations-tools/par-ops/) defines time_card with distinct 'charged_tips' and 'tips' fields alongside job_code, pay_rate, regular_hours, overtime_hours, doubletime_hours, sales, worker and a separate 'reimbursements' collection (type + amount), so charged tips, total tips and non-wage reimbursements export as distinct values per shift. The PAR OPS Portal API adds a tip-share pipeline (/Payroll/TipShareHours, /Payroll/TipShareAmounts, /Payroll/TipShareJobWeights, /Payroll/TipShareSettings, /Payroll/TipShareAmountToPayroll) and POST /v2/PayrollExport/timeclocks; Brink itself carries DeclaredTipsAmount at clock-out and the Employee Timecard Report splits Non-Cash from Declared Tips. SHORTFALL: no Treasury tipped-occupation code and no W-2 mapping. There are zero occurrences of occupation code, Box 12, Box 14 or a 'TP' code across the Delaget schema set and all three PAR OPS specs (portal 239 paths, portalV2 813 paths, shiftworks 127 paths); the worker record (first_name through home_location_id, gender, address, client_worker_identification) carries no occupation classification, and job_code is the operator's own POS job rather than a Treasury code. An operator can therefore derive cash versus charged tips but must map the Box 12 code TP and Box 14b reporting for tax year 2026 in their payroll system. https://api.delaget.com/swagger/v1/swagger.json · retrieved 2026-08-08

labor-native-payroll differentiator

Supported by enumeration rather than by the quoted sentence: the PAR OPS page lists exactly three modules — Inventory Management, Labor Management, Reporting & Analytics — and mentions no payroll processing anywhere. PAR does not run payroll. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01 adversarially verified

labor-payroll-export-formats

Wrong source: a 291-entry partner directory is not evidence of export formats. The correct evidence is the PAR OPS Workforce page, which lists "Payroll export" as a bare bullet with zero detail — no named format (Gusto/ADP/Paychex/QuickBooks), no field spec. Also note the PAR OPS overview page enumerates only Inventory, Labor, and Reporting & Analytics and names no payroll providers, so 'Netchex and 7shifts' is unsourced in the pages I checked. https://partech.com/solutions/back-office-solutions/restaurant-labor-management-scheduling-software/ · retrieved 2026-08-01 adversarially verified

labor-shift-swap-workflow differentiator

PAR OPS Workforce includes employee-facing applications; self-service swap/open-shift claiming with manager approval and OT/role eligibility enforcement is not documented. https://partech.com/solutions/back-office-solutions/restaurant-labor-management-scheduling-software/ · retrieved 2026-08-01

labor-digital-onboarding-i9

Both new-hire forms are first-class in the PAR OPS (Data Central) Portal API. EmployeeGetModel carries 'FederalW4', 'StateW4' and 'I9' sub-objects, and HRManagement.EmployeeI9Model is a full Form I-9 record: ResidentStatus, AlienNumber, AuthorizedToWorkUntilDate, and DocumentTitle, IssuingAuthority, DocumentNumber and ExpirationDate for each of List A, List B and List C. W-4 is modelled federally and by state (HRManagement.EmployeeW4FederalGetModel, EmployeeW4StateGetModel, W4FederalFilingStatusModel, W4StateFilingStatusModel; in v2, /v2/W4Form/federal, /v2/W4Form/state and their filingStatuses endpoints, with EmployeeW4FederalModel and EmployeeW4StateModel). SHORTFALL: no E-Verify anywhere - zero occurrences across all three PAR OPS specs (portal 239 paths, portalV2 813 paths, shiftworks 127 paths), so there is no case creation, no DHS or SSA response handling and no tentative-nonconfirmation state. Note also what the evidence does and does not show: these are data models for storing W-4 and I-9 information, not a documented new-hire-facing onboarding wizard, and PAR OPS is a separate product a Brink customer buys alongside the POS. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portal/swagger.json · retrieved 2026-08-08

labor-server-performance-metrics differentiator

The Admin Portal guide's "Employee Sales Summary" report lists "key performance metrics for each employee," its "Item Sales By Employee"/eligible-sales reports track item-group attach rate by employee, and "Void Details" is "grouped by employee." Shortfall: no single report is documented that names average check, items-per-check, and void/comp rate together as one per-server scorecard — the relevant metrics are spread across separate reports. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

inventory-recipe-bom-costing

Recipe management across locations with actual-vs-theoretical costing; multi-level sub-recipes and automatic plate-cost recalculation on ingredient price change not documented. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · retrieved 2026-08-01

inventory-unit-conversion-yields

The PAR OPS (Data Central) portalV2 OpenAPI's ItemUM model stores multiple units of measure per item, each flagged as Purchase, Recipe, CountYN (count unit) and/or Waste, with an explicit ConversionFactor and a YieldPercent per unit of measure (plus CostingUnits, Tare, Thaw and ShelfLife); recipe-content models (GetItemRecipeContentsModel) expose per-ingredient ConversionFactor ('Item unit of measure conversion factor') and Yield ('Item unit of measure yield') applied in recipe costing. Inventory lives in the PAR OPS back-office module, which is where PAR implements this across its enterprise peer group. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04

inventory-theoretical-vs-actual differentiator

Downgraded on verification. Usage-variance tracking is real and configured as a first-class concept - the PAR OPS (Data Central) Portal v2 OpenAPI carries store-level NegativeUsage, VarianceUsageThreshold and EnableInventoryEstimating and item-level VarianceUsageTargetQty and NegativeUsageQtyLimit, alongside the full actual-side apparatus (Counts/PeriodData with RefreshFromTemplate and Estimate, Waste and Store Waste Templates, PurchaseManagement Invoices and PurchaseOrders, item measures carrying CostingUnits and Yield). Named shortfall: the theoretical side is undocumented. The strings "theoretical" and "ideal" appear nowhere in any of the three published specs (portal, portalV2, shiftworks), there is no recipe or menu-item-build endpoint from which POS sales could be exploded into theoretical usage, and no variance report is exposed. "Actual vs. theoretical food costing" appears only on a marketing page. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-02 adversarially verified

inventory-realtime-depletion differentiator

Re-examined 2026-08-08 against two surfaces the earlier pass had not read. (1) The 5.16r2 Admin Portal Configuration Guide (cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf, 8,425 extracted lines covering every Admin Portal and Settings Editor screen) contains no inventory, recipe, purchase-order or vendor screen at all, and defines the Item 'Ingredients tab' as "Items that are considered ingredients when calculating modifier prices, and when determining valid modifier codes on Customer Portal" - a pricing construct, not stock. (2) The legacy Brink API portal (brinkapiportal.parpos.com, 12 pages / 659 operation anchors, dumped in full) exposes only item-level availability - ItemAvailabilityDetail carries IsAvailable and QuantityAvailable, with no ingredient quantity anywhere; the ItemIngredient type carries only Id, ItemId and Position. So Brink POS does not itself deplete ingredient on-hand. Ingredient-level inventory in the PAR stack is PAR OPS / Data Central, a separately sold back-office product (rmhs.rmdatacentral.com DC_Inventory/DC_Item SOAP services expose recipe cards, recipe ingredients, CalculateCountCost and ReCalculateInventoryRecipes but no POS-fire-triggered depletion operation, and the PAR OPS UI is login-gated). Whether PAR OPS depletes recipe ingredients in near real time from POS fires, including modifier-driven depletion, is therefore still unresolved.

inventory-86-auto-sync differentiator

Item-level 86 exists and reaches every channel, but is not ingredient-driven and is not automatic. Settings Editor has an Item Availability screen that "gives users the ability to quickly turn an item 'on' or 'off' depending on the item supply at the restaurant by utilizing the Active checkbox", and "Item availability may also be set for specific order channels (Delivery, Drive-Thru, etc.) by using the checkbox in their respective columns"; there is a matching register button that "Opens 'Item Availability' screen, which allows for setting availability of all items", and 86'd Item is a built-in Void Reason. The legacy Brink API exposes the same state to online ordering and third-party partners: Ordering.svc GetItemAvailability / UpdateItemAvailability carry ItemAvailabilityDetail (IsAvailable plus QuantityAvailable, "-1 to indicate an unlimited supply", set to 0 when IsAvailable is false), and GetUnavailableItems returns "the list of item IDs that are active but unavailable at the location on current business date", optionally filtered by DestinationId. Shortfalls: the configurable threshold drives a notification, not an 86 - the Alerts engine's Item Availability type "is sent when an item is marked 'Unavailable', when the available amount reaches a certain amount, or when an item's available amount falls below a specified threshold" (Alert if Greater Than X / Less Than X / Not Available), and it is an email alert; and the trigger is the item's own available count, not a component ingredient's stock - Brink has no ingredient stock model, so nothing 86s a menu item when an ingredient hits zero. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

inventory-count-modes

PAR OPS markets reducing count effort, and PAR partnered with NomadGo for AI-powered computer-vision counting; full/spot/cycle count modes with separate variance history are not documented. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · retrieved 2026-08-01

inventory-mobile-count-offline

A handheld counting workflow with barcode support is enumerated in the PAR OPS (Data Central) DC_Inventory web service, whose operation list includes PDAGetCountBarcodes and PDAGetCountBarcodesZip, PDAGetLocationsList(Zip), PDAPrepareData(Zip) and PDAReceiveData(Zip), alongside GetMyCountItems, GetTemplates, ReEstimateCounts, ConvertMissingCountsToZero and UpdateInventoryLines. The prepare-data / receive-data pair is a download-to-device then upload-counts cycle, i.e. counting is not required to be online continuously. Shortfalls, all material to this claim: this is PAR OPS / Data Central, a separate back-office product a Brink operator buys alongside the POS, not a Brink POS capability; the surface is a legacy 'PDA' data-transfer pattern with no documented tablet or smartphone app, no QR support (barcodes only), and nowhere does PAR state that the device keeps accepting counts with no connectivity and syncs on reconnect - that is inferred from the operation set. Brink POS itself has no counting screen: the 5.16r2 Admin Portal guide has no inventory or count screen anywhere in its 8,425 lines. https://rmhs.rmdatacentral.com/Web1243/services/DC_Inventory.asmx · retrieved 2026-08-08

inventory-vendor-catalogs-edi differentiator

"Scan Assist" converts paper invoices into EDI receipts — that is invoice digitization, not a pre-built broadline distributor catalog with outbound PO transmission. No named Sysco/US Foods/PFG catalog integration documented. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01

inventory-invoice-ocr differentiator

Scan Assist ("Scan paper invoices for instant EDI receipts creation") is explicitly listed as a premium add-on, not part of any base PAR OPS module. Priority-1 attack: paid add-on, not native included capability. The researcher's own note said 'premium add-on' and scored yes anyway. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01 adversarially verified

inventory-price-change-alerts differentiator

Re-examined 2026-08-08. The Brink Admin Portal's alert engine is fully enumerated in the 5.16r2 Admin Portal Configuration Guide (cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf, Configuration > Alerts): the Type list is Auto Clock Out, Cash In Drawer, Customer Assigned, Discount Amount, Item Availability, Overtime, Paid In/Out, Promotion Amount, Refund, Shift Exceeds Scheduled and Void Amount. None concerns purchase price, invoice cost or a received-versus-contracted variance, and the guide contains no vendor, purchase-order or receiving screen anywhere in its 8,425 lines - Brink POS does not do purchasing. The capability, if it exists, belongs to PAR OPS / Data Central: its DC_Vendor service exposes only GetVendors, GetLocalVendors, UpdateVendor, UpdateLocalVendor and DeleteVendor, and the earlier pass found no price-variance-threshold field in the portal or portalV2 swagger beyond CostOriginal. PAR OPS's own alerting and invoice-receiving UI is behind a login (dc01.rmdatacentral.com), so per-item purchase price history with a configurable variance alert is unresolved rather than absent.

inventory-par-auto-suggest differentiator

The PAR OPS (Data Central) portalV2 OpenAPI's PurchaseOrderPostModel documents a per-line SuggestedOrderQuantity together with PredictionCalculationID and a PredictedUsages array of per-date forecasted usage (e.g. {"PredictionDate":"2022-12-01","Usage":2.0}) — a forecast-driven suggested purchase quantity, not only a static-par calculation. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified

inventory-waste-logging

The PAR OPS portalV2 OpenAPI documents "Waste and Store Waste Templates" as a distinct object family from the usage-variance apparatus (NegativeUsage, VarianceUsageThreshold — already cited elsewhere in this record), i.e. a structured waste-logging mechanism kept separately reported from usage variance, matching the claim's requirement. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified

inventory-transfers

Re-examined 2026-08-08 on two surfaces. Brink POS has no inter-location inventory concept at all: the 5.16r2 Admin Portal Configuration Guide has no inventory, transfer or requisition screen, and the only 'Transfer' in the legacy Brink API portal's 659 operation anchors is a till/cash movement type ("4 = Transfer from", "5 = Transfer to"). On the PAR OPS side, the three readable Data Central SOAP services - DC_Inventory, DC_Item and DC_Vendor at rmhs.rmdatacentral.com/Web1243/services/ - contain no transfer or requisition operation, but that endpoint directory is not listable (a fabricated DC_Transfer.asmx and DC_Order.asmx both 404, so the catalogue cannot be enumerated) and the PAR OPS UI is login-gated. A two-sided transfer with an in-transit or approval state may exist in a PAR OPS module I cannot see, so this stays open rather than resolving to absence.

inventory-commissary

The PAR OPS portalV2 OpenAPI's Vendor model carries ProductionKitchenID/ProductionKitchenDescription/ProductionKitchenNumber fields and a UsePOCostForCommissary flag — a location can be configured as an internal supply "vendor" with a designated production kitchen and a purchase-order-cost-for-commissary toggle. Shortfall: no dedicated commissary/transfer-pricing object, and no computed-transfer-cost mechanic beyond this vendor-record flag, is documented. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified

inventory-lot-traceability

Re-examined 2026-08-08. Brink POS carries nothing lot-related: 'Lot' appears zero times across the fully dumped legacy Brink API portal (brinkapiportal.parpos.com, 12 pages, 659 operation anchors) and the 5.16r2 Admin Portal Configuration Guide has no receiving screen at all. On the PAR OPS side, DC_Item (rmhs.rmdatacentral.com/Web1243/services/DC_Item.asmx) exposes recipe cards, recipe ingredients, item measures and LinkItemToPLU with no lot or batch operation, and DC_Inventory exposes counts, templates and PDA count transfer with none either; the only batch object found in the earlier pass, ButcherBatches (BatchNumber, ButcherDate, BatchCost) in portalV2, is meat-cutting yield, not receiving-to-sale traceability. The Data Central endpoint directory is not listable and its UI is login-gated, so a recall-trace module cannot be ruled out - unresolved, not absent.

inventory-shelf-life-expiry

Re-examined 2026-08-08, and the prep-label premise in the earlier note did not survive. The 5.16r2 Admin Portal Configuration Guide's Labels section and the Epson TM-L90 Label Printer Formatting Guide (cdn.parpos.com/docs/Epson%20L90%20Label%20Printer%20Setup%20Guide.pdf) enumerate every replaceable parameter available on a printed label and none is a use-by, expiry or prep-date field. Across the fully dumped legacy Brink API portal every occurrence of 'Expiration' is a credit-card, gift-card or employee health-card date - no item or inventory expiry field exists. On the PAR OPS side DC_Item's operations (recipe cards, recipe ingredients, item measures, item groups) contain no shelf-life or expiry operation. What is not settled: PAR OPS's receiving and production UI is login-gated (dc01.rmdatacentral.com) and its SOAP catalogue is not listable, so an expiring-soon report inside that product cannot be ruled out.

inventory-bar-partial-bottle

Re-examined 2026-08-08. The only weight surface in Brink is the Settings Editor Scales screen (5.16r2 Admin Portal Configuration Guide p.278): "Scales are the weigh scale peripherals connected to the POS system", configured with Name, Model (brand and model), Interface Type, Parity, Handshake, COM Port, Baud Rate and the Register it is attached to - a serial scale for items sold by weight, paired with the Tares type in Settings2.svc, with no bottle, pour, tenth-of-an-ounce or fractional-unit semantics anywhere. On the PAR OPS side DC_Item exposes GetItemMeasures / UpdateItemMeasure (unit and yield conversion) but no pour-cost, partial-bottle or liquor-scale operation, and DC_Inventory's count model is line-and-template based. Unresolved rather than absent because PAR OPS's counting UI, where a by-weight or fraction-of-bottle count entry would live, is behind a login and its SOAP catalogue is not listable.

inventory-cogs-gl-export

The PAR OPS portalV2 OpenAPI documents dedicated named-format export endpoints: POST /v2/QuickBooks/ExportAccountingData ("Exports Accounting Data into QuickBooks according to GL export format") and POST /v2/QuickBooks/ExportPurchases ("Exports purchase documents into QuickBooks" — Bills and Vendor Credits), plus /v2/ChartOfAccounts/{id}/Mappings and a Meta-Accounts model whose FlagField values include Expense, Inventory, Tax, POSAdjustment and more — configurable GL account mapping in a named accounting system's import format. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified

inventory-native-not-partner differentiator

PAR OPS (Restaurant Magic Software, a PAR company) publishes its own web-service reference at rmhs.rmdatacentral.com/Web1243/services/. DC_Item documents recipe costing primitives directly: GetRecipeCards, GetRecipeCardsHtml, UpdateRecipeCard / UpdateRecipeCardEx, DeleteRecipeCard, GetRecipeIngredients, UpdateRecipeIngredient, DeleteRecipeIngredient, FinalizeBulkRecipesUpdate, plus item, item-group and unit-of-measure maintenance and LinkItemToPLU ("Link DC Item to PLU Item") tying the inventory item to the POS menu item. DC_Inventory documents the counting and costing cycle - CalculateCountCost ("Calculate count cost"), ReCalculateInventoryRecipes ("Re-calculate inventory recipes"), ReEstimateCounts, SyncInventoryWithTemplate, ApproveInventory/UnapproveInventory, GetInventoryLines/UpdateInventoryLines and PDA count-sheet transfer; DC_Purchasing covers purchase orders, invoices, credit and trade memos, and vendors. Named shortfall of packaging, not of ownership: none of this appears anywhere in the 306-page Brink POS Admin Portal guide (zero occurrences of "inventory"), so inventory and recipe costing are a separately-licensed PAR module rather than a Brink POS feature - but the module is PAR's own, not a contracted third party such as MarginEdge or Restaurant365. https://rmhs.rmdatacentral.com/Web1243/services/DC_Item.asmx · retrieved 2026-08-06 adversarially verified

inventory-menu-margin-linkage differentiator

The cost-to-sales-mix join exists as a standard report; the threshold flagging does not. The Admin Portal's Accounting report category includes Ideal Food Cost By Item, which "Lists all items sold along with cost relative to sales, both on an average per item and cumulative bases, which is sorted by item name. It can be run for one or more locations, and for a given date range" - item cost set against actual sales, multi-location, over an arbitrary period. It sits beside the full Product Mix family (All Items, By Brand, By Day Part, By Destination, By Interval, By Item Group, By Revenue Center, By Section, Forecasted), each "sorted by percent of total sales", which supplies the sales mix. Shortfalls: no report or alert flags items whose margin fell below a configured threshold - the Admin Portal's alert engine enumerates eleven alert types (Auto Clock Out, Cash In Drawer, Customer Assigned, Discount Amount, Item Availability, Overtime, Paid In/Out, Promotion Amount, Refund, Shift Exceeds Scheduled, Void Amount) and none is cost, margin or ingredient-price based; and the recipe cost that feeds 'ideal' cost is maintained in PAR OPS / Data Central (DC_Item GetRecipeCards / GetRecipeIngredients), a separately sold product, so the join depends on owning that as well. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

reporting-realtime-dashboard

The cited Cloud POS page's actual wording is "fully cloud-enabled, which means you can manage menus, pricing, and reporting remotely." Remote access to reporting is not a documented real-time dashboard, and the researcher concedes mobile access is unconfirmed. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01 adversarially verified

reporting-eod-closeout

A Sales2 service exposes deposits and tills via API; a single canned EOD document reconciling gross/net/tax/tips/discounts/refunds/tenders is not documented publicly. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01

reporting-pmix-modifier-level

The substrate is documented at modifier grain: Sales2 order detail carries OrderItemModifier ("Modifiers applied to this OrderItem") with Price, and each order item maps DayPartId and RevenueCenterId, so item- and modifier-level mix by daypart and revenue center is extractable via GetOrders; PAR OPS additionally treats PmixTracking as a first-class account category in its Chart of Accounts API. Shortfall: the claim asks for a PMIX report in the reporting UI, and no PAR-published report documentation (a modifier-level PMIX screen or export with those filters) exists publicly. https://brinkapiportal.parpos.com/sales2 · retrieved 2026-08-03

reporting-comps-voids-audit

The Admin Portal guide documents "Void Details" (grouped by employee, sorted by void time), "Void Summary" (totals by void reason), and "Manager Override Detail" ("Lists details regarding all manager override actions, including: Approval Time, Login User, Button Name, Button Action, Approval User, and Approval Method") — together an audit trail of voids/comps/discounts/overrides attributing both the applying and approving employee, with reason codes and timestamps. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

reporting-cash-over-short

Sales2 exposes tills and deposits, the raw inputs for over/short; a per-drawer/per-shift/per-employee over-short report is not documented. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01

reporting-labor-productivity

PAR OPS provides labor management with KPI reporting against POS sales; specific SPLH and labor-% by hour/department/employee cuts not documented. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01

reporting-server-scorecards differentiator

Same evidence as labor-server-performance-metrics: Employee Sales Summary, Item Sales By Employee/eligible-sales-%, and Void Details (grouped by employee) are documented, but no single per-server report combines average check, items-per-check, and tip percentage as one scorecard. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

reporting-channel-profitability differentiator

PAR OPS Delivery Operations reconciles DSP payouts and commissions in one dashboard, giving per-marketplace net revenue; dine-in vs direct-online margin comparison is not documented. https://partech.com/solutions/insights-and-delivery-solutions/ · retrieved 2026-08-01

reporting-multiloc-drilldown differentiator

Marketing-page 'yes' where the note itself says drill-down to individual transaction is not documented. Drill-down is the sub-feature. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01 adversarially verified

reporting-custom-report-builder differentiator

The Administrator Portal's Reports section enumerates a fixed catalog of roughly sixty named canned reports across Sales, Employees, Inventory, Comparative and Audits categories (Product Mix, Sales Summary, Void Details, Employee Productivity, etc.), each with a fixed description of its columns and filters. No self-service tool for choosing dimensions/measures/filters and saving a custom report is described anywhere in the guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

reporting-scheduled-delivery

The Admin Portal guide documents "Scheduled Reports": "reports that are automatically generated and sent via email at a particular time or system event," configurable by Schedule Type (End of Day/Specific Time), Days of Week, Report Locations, a list of attached Reports, and a "Recipients: Email addresses to send the reports to" field. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

reporting-raw-warehouse-export differentiator

PAR's own configuration guide closes the enumeration: "The Export section provides tools for exporting customers, sales, labor, settings, and surveys." Each is a download, not a delivery - Export Customers "produces a CSV file for download", Export Sales "produces a file that can be imported into a third-party accounting or inventory system" formatted from the GL account mapping (QuickBooks IIF is the example), Export Labor "produces a file that can be imported into a third-party payroll system", Export Settings "produces a CSV file" and "Currently, only items can be exported", Export Surveys a CSV. The one automated recurring mechanism is Scheduled Reports, and it emails finished reports: "Reports that are to be generated and attached as PDFs to the email." No S3, SFTP, warehouse, Snowflake or BigQuery destination appears anywhere in the 8,425-line guide (SFTP and FTP: zero occurrences). Independently, the transaction API pushes nothing and is deliberately slow: Sales2.svc GetOrders takes a single BusinessDate, the Brink API FAQ says only GetHouseAccountCharges, GetLaborSchedule and GetFutureDateOrders accept a date range and "Otherwise... you will have to make a loop that will call the API with those business dates individually", under a best practice of "5 concurrent calls with a sleep of 2-3 minutes in between calls". Caveat stated rather than hidden: PAR sells Delaget / PAR Intelligence as a separate analytics product, and this finding is about Brink POS itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

reporting-public-api differentiator

Documented REST and SOAP APIs cover orders, sales, labor, settings and payments and are readable without a signed agreement — but credentials are not self-service; PAR must provision an API account against each location. https://developers.partech.com/ · retrieved 2026-08-01

reporting-webhooks differentiator

Webhooks Manager documents guest lifecycle events. For POS orders the documented pattern is polling GetOrders with a ModifiedTime filter, not push. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01

reporting-api-not-upcharged differentiator

Re-examined 2026-08-08 with a source the earlier pass did not use. PAR's 2025 Form 10-K (partech.com/wp-content/uploads/2026/02/10-K-Document-2025.pdf) disaggregates revenue into Hardware, Subscription Service (SaaS solutions, software support, managed platform development services and transaction-based payment processing) and Professional Service; API or data access is nowhere a separate performance obligation, and the only mention of APIs is positioning - "Our SaaS solutions are extensible and built on open application programming interfaces". That is consistent with API access being bundled but does not establish it, since the filing is disaggregated by revenue type, not by SKU. Nothing else is published: partech.com carries no price list or plan page, the legacy Brink API portal and developers.partech.com publish no fee schedule, and both require tokens obtained from a PAR representative (api.support@partech.com per the Brink FAQ), so provisioning is commercial and its terms are not public. Whether API and raw-data access carry a per-location fee, revenue share or enterprise-only requirement remains undeterminable from public sources.

reporting-tier-paywall differentiator

Re-examined 2026-08-08. Every report this claim names is documented as a standard Admin Portal report in the 5.16r2 Admin Portal Configuration Guide, with no add-on module or analytics SKU mentioned anywhere in its 8,425 lines: labor against sales (Labor category - Labor Cost By Job, Employee Summary By Job With Salary, Hourly Labor By Labor Group - plus the published Sales and Labor Report by Hour), PMIX (a nine-report Product Mix category: All Items, Forecasted, By Brand, By Day Part, By Destination, By Interval, By Item Group, By Revenue Center, By Section), comps/voids audit (Audits category - Business Date Audit, Manager Override Detail, Reopened Order, Location and Group Security Audit - and Accounting's Discount Detail/Summary and Refund Detail), and multi-location comparison (a dedicated Comparative category whose four reports each compare "two groups of locations"). What cannot be resolved is the claim's actual question: PAR publishes no plan names, no tier table and no pricing anywhere on partech.com, and the 2025 10-K reports SaaS revenue in aggregate without SKU detail, so there is no public basis for saying whether these reports sit on an entry-level paid plan or behind a higher tier.

reporting-history-retention differentiator

Re-examined 2026-08-08 across every first-party surface now readable. The 5.16r2 Admin Portal Configuration Guide contains zero occurrences of 'retention' and states no history limit on any report - the report catalogue repeatedly says only "for a given date range" with no stated floor. The one retention figure PAR does publish is unrelated to reporting: the In-Store Resilience release notes document BackupRetentionPeriodInDays for the local register.sdf during End of Day, "Default = 30 days (previously 5 days), Max = 30 days, Minimum = 7 days". On the API side, Sales2.svc GetOrders takes a BusinessDate with no documented range floor or archive policy and the Brink API best-practice/FAQ page says nothing about how far back data is queryable; the PAR POS Network Connectivity document describes a move to real-time Kinesis-based data processing but states no retention. A differentiator yes needs a documented window of at least 24 months with no truncation or archive fee, and PAR publishes no window at all.

reporting-anomaly-alerts differentiator

PAR Intelligence claims a prioritized view of where to focus and proactive loss identification; operator-configurable metric thresholds with push/email alerts are not documented. https://partech.com/solutions/par-intelligence · retrieved 2026-08-01

reporting-nl-query

PAR Intelligence is marketed as an agentic system that surfaces insights and recommends next actions across 12B+ transactions; a natural-language ad-hoc query interface returning a figure or chart is not explicitly documented. https://partech.com/solutions/par-intelligence · retrieved 2026-08-01

reporting-guest-cohorts differentiator

The Punchh page I read supports only "real-time dashboards track participation, ROI, and performance metrics" plus open APIs. New-vs-returning, frequency, and lifetime-spend cohort reporting is not documented; Bridg is an identity-resolution acquisition, not a documented cohort report. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01 adversarially verified

reporting-sales-forecast differentiator

Upheld and re-graded D->A; the granularity question the researcher left open is now answered. The PAR OPS Portal v2 OpenAPI documents GET /v2/Forecast/{forecastId}/{date} returning seven days across Sales, Entree, Checks and Guests categories; SevenDaysSales and SevenDaysEntrees category filters; POST /v2/Forecast/Regenerate/{forecastId}/{date}, which "will cancel all applied revises"; PATCH /v2/Forecast/ByMinutes and /MultiUnit/ByMinutes setting revised amounts "for the specific forecast and time", i.e. intra-day granularity; SevenDaysLock/UnLock and Revise at unit and multi-unit scope; GET /v2/Forecast/SevenDaysWeather/{date} as a forecast input; GET /v2/Forecast/Formats; and /v2/EventForecast plus /v2/StoreEventForecast with targets and a sales chart. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-02 adversarially verified

reporting-tip-tax-compliance

The Employee Timecard Report shows per-employee, per-shift Non-Cash Tips (charged) alongside Declared Tips, with signature lines for employee and supervisor; 'Must Declare Tips' prompts declaration at clock-out with an optional system-calculated minimum (5.16r2 Admin Portal guide), and the Admin Portal ships a Declared Tips report plus tax reports (Tax Summary grouping tax collected by tax per location, Taxes by Day Part, Tax Exempt Sales, Tax By Item). Shortfalls: no tip-pool distribution detail report appears in the documented Admin Portal report list — pooling contribution/distribution is configurable on jobs but distributed amounts are only exposed via the separately sold PAR OPS payroll API — and no jurisdictional tax-liability rollup beyond per-location, per-tax summaries is documented. https://cdn.parpos.com/docs/Employee%20Timecard%20Report.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

multi-location-org-hierarchy

The API models a two-level business/location hierarchy via paired business and location tokens. A named three-level enterprise > region > location object that reporting and permissions scope to is not documented. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01

multi-location-central-menu-publish

Cloud POS markets remote central menu and pricing management for multi-location brands; publish/version history is not documented. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

multi-location-local-override-policy differentiator

Re-examined 2026-08-08 against the sections the earlier pass missed. Brink's corporate configuration model is a one-way cascade, not a lock: Settings Editor is explicitly per-location ("Location drop-down list: Lists all locations available to the current user, configuration for the selected location is visible"), and corporate change is distributed by Changeset Publisher, which packages changesets made at an originating location and publishes them to target locations or location groups immediately or at End of Day, with per-location publish status, Retry and Download Errors. The Brink API FAQ describes the same pattern - "Changes should be published on one location and once tested on a single location, they may be cascaded ahead to other locations". Access control is by function and location, not by field: Roles carry "Rights: Functions that are visible and allowed" plus a Rank, and Users carry Limit Locations and Limit Roles. Nothing in the guide describes a per-field override or a corporate lock on specific item attributes; tellingly, PAR ships a Menu Comparison report that "Displays items that have any different values set between two locations", implying divergence is detected after the fact rather than prevented. Left unknown rather than scored no because the guide does not enumerate the individual Rights available to a Role, so a field-level restriction inside that list cannot be excluded.

multi-location-price-zones

PriceLevel plus SavePriceChanges/UpdateItemPrice allow per-location prices without duplicating the item; formal price zones/groups spanning channel and daypart are not documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01

multi-location-scheduled-publish differentiator

Changeset Publisher schedules a changeset package to publish "Immediately" or at "End of Day" — the target location's own End of Day time, itself a per-location setting — up to two weeks in advance, with a pre-validation check before submission. Shortfall: no rollback-to-prior-state after activation is documented; Cancel/Retry apply only before or during publishing. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

multi-location-new-store-template differentiator

PAR markets "Fast Multi-location Rollouts" with on-time opening rates approaching 99%; a documented cloneable configuration template and a published expected time-to-open are not provided. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

multi-location-corp-vs-franchisee-roles differentiator

The Admin Portal guide documents an "Ownership Types" attribute on locations — "All Ownership Types, Corporate, or Franchisee" — filterable in the Admin Portal. Shortfall: no documented permission boundary distinguishing what a corporate user can see/enforce versus what stays under exclusive franchisee control (employees, banking, labor data) — only the ownership-type tag itself is documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

multi-location-royalty-calculation differentiator

The Admin Portal guide documents royalty entries defined as a percent of net sales or a flat dollar amount per month, with Start/End Date effective ranges and a "Limit Location" scope, feeding the "Royalties by Location" report. Shortfall: only a net-sales basis is documented — no configurable gross-vs-net-of-discounts/comps/third-party basis toggle was found, and calculation is report-driven rather than documented as executing unattended on a defined schedule. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

multi-location-royalty-collection

The Admin Portal guide's Options > Accounting > Royalties tab carries Bank Account Number and Routing Number fields stated to appear "on the Royalties by Location report." Shortfall: no automated ACH/debit collection execution flow is documented — these are display/reporting fields, not a documented collection mechanism — and no franchisee-visible statement artifact is described. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

multi-location-consolidated-reporting

Enterprise reporting and analytics consolidate performance across locations with KPI management; store-vs-store ranking and variance flags not explicitly documented. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01

multi-location-normalized-item-rollup differentiator

Cross-location item rollup exists; the shared corporate item identity the claim requires does not. Product Mix > All Items "Lists all items and their sales totals, sorted by percent of total sales. Can be run for one or more locations, for a given date range", and the whole Product Mix family (By Brand, By Day Part, By Destination, By Interval, By Item Group, By Revenue Center, By Section) is multi-location; the Comparative category adds a Product Mix report that "Lists sales totals for two groups of locations by item, along with comparative value between the two groups of locations, sorted by item name". Locations are organised for this by Location Groups, which "allow you to arrange locations in a hierarchical fashion", can be nested, and replace the older Locations and Report Groups. Shortfalls: the reports are documented as grouped and sorted by item name, not by a corporate identifier, so an item a store renamed would not obviously roll up with its siblings; PAR provides a Menu Comparison report precisely because item configuration diverges between locations ("Displays items that have any different values set between two locations. Must be run with two, and only two locations selected"); and Brink identity is per-location by design - the API FAQ states of employees that "Employee IDs are unique on a per-location basis... Pushing the same Employee IDs across multiple locations is not possible", with settings likewise retrieved per LocationToken. No master-item-ID mechanism spanning renamed or locally priced items is documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

multi-location-cross-location-giftcard

The Admin Portal guide documents Gift Card Filters that "restrict the locations at which gift cards can be redeemed or applied," via a "Filter Locations: Limit gift card tendering by location" list — implying cross-location redemption is configurable when the filter spans multiple locations. Shortfall: no outstanding-liability-balance report or inter-store settlement/reconciliation mechanism between location owners is documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

multi-location-cross-location-loyalty

Punchh is a brand-level loyalty platform with a single guest profile across the brand's locations (500M+ members claimed). https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01

multi-location-multi-brand differentiator

The Admin Portal guide documents Item "Brand Allocation": "Distribute sales of the item across more than one brand" by weighted percentage, with Product Mix reporting grouped by brand. Shortfall: this is a sales-attribution mechanism for accounting purposes, not documented support for two brands running separate menus, receipts/branding, and drawer-level revenue separation on one terminal. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

multi-location-multi-tax-jurisdiction

Settings/Settings2 are per-location configuration services covering location-level setup; multiple simultaneous rates, prepared-food vs grocery rules and per-location exemptions are not documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01

multi-location-multi-currency-locale

The schema has no such field, on both surfaces. Settings.svc's LocationOptions type is the complete location configuration object exposed by the API and its fields are Address1, Address2, City, Country, Fax, Latitude, Longitude, Name, Phone, State, TimeZone and Zip - country and timezone but no currency and no locale. The string 'Currency' appears zero times across the entire dumped legacy Brink API portal (12 pages, 659 operation anchors, 1.75MB of text), including every money-bearing type in Sales2.svc and Ordering.svc, so order, payment and tender amounts carry no currency qualifier and there is nothing to convert. It appears zero times again in the 5.16r2 Admin Portal Configuration Guide (8,425 lines covering every Admin Portal and Settings Editor screen, including Location Groups, Taxes, Tenders and the Rounding options), whose only localisation feature is a UI toggle - "To Change the Administrator Portal to the French Language". Consolidated multi-location reporting exists (Comparative and Product Mix across location groups) but is arithmetic on unqualified amounts, with no reporting currency or conversion step documented. Scope note: this is Brink POS; PAR does sell internationally through other product lines. https://brinkapiportal.parpos.com/settings · retrieved 2026-08-08

multi-location-config-audit-log differentiator

Changeset Publisher/Changeset Packages record "Created By" (full name of the publishing user), "Created Time," per-changeset entity-level change detail (viewable by clicking the change count), and an exportable CSV of publish status per location — a queryable, corporate-visible record of who changed what and when. Shortfall: no explicit immutability guarantee is stated for the changeset log anywhere in the guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

multi-location-enterprise-sso differentiator

The account settings screen is the entire configurable identity surface for above-store users, and it is local-only. The Admin Portal User configuration page enumerates: First Name, Last Name, Email Address, Alert Email Address, Mobile Number ("Used for Multi-Factor Authentication (if applicable)"), Username ("Username used for logging into the Admin Portal"), Password ("Password used to log into the Admin Portal"), Status Enabled/Disabled, "Account temporarily locked... automatically resets after 30 minutes", Force user to change password, "Email password on save: Generate an email to the user's email address that contains Admin Portal URL, username, and password", "Enable Multi-Factor Authentication: Place Holder for future development (MFA)", Limit Locations and Limit Roles. There is no identity-provider, federation or directory field, and even MFA is an unimplemented placeholder. Deprovisioning is manual - a user is set to Disabled, and the parallel employee model is explicit that records cannot be deleted, only overwritten or flagged Terminated. Across the 8,425-line guide, SAML, OIDC, SSO, 'single sign' and SCIM each appear zero times, as they do across the 659-operation legacy Brink API portal. Above-store access scoping is done instead by Roles ("Rights: Functions that are visible and allowed", plus Rank) and Location Groups. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

multi-location-enterprise-api differentiator

A business-level token exists alongside the location token, but PAR's own FAQ describes access failures caused by "unprovisioned API account access to specific locations," indicating per-location provisioning rather than one authenticated all-locations call. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01

multi-location-central-labor-policy

Overtime rules (Day Hours/Week Hours/Shift Hours/Day-In-Week, with a per-rule pay-rate Factor) are configured per location via Settings Editor, and the PAR OPS Autocompliance ScheduleRule/MealPeriodPenalty/MinorRule engines (already cited elsewhere in this record) are jurisdiction-scoped (country/state/county/city). Shortfall: rules are jurisdiction- or per-location-scoped, not organized as a "location group" hierarchy as the claim describes, and terminal-level enforcement is confirmed only for overtime — the Autocompliance break/minor/schedule rules enforce within the separately sold PAR OPS module, not documented as blocking at the POS terminal itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

hardware-commodity-devices differentiator

PAR says its POS works with "many types of hardware you may already have," and PAR Volt runs Android or Windows — but no commodity iPad/Android tablet support is explicitly documented and PAR's pitch centers on its own terminals. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

hardware-os-platforms

Android and Windows named for PAR Volt; no minimum OS versions or device specs published. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

hardware-handheld-purpose-built

PAR Tablet: rugged, Gorilla Glass, sealed design, integrated NFC/RFID card processing. No published drop rating or IP ingress rating. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

hardware-handheld-battery-swap differentiator

PAR Tablet has no swappable battery; the 'yes' rests entirely on a marketing spec of "10-hour battery life" with no test standard or duty-cycle definition. (The swappable-module language on the hardware page belongs to PAR Volt compute modules, not batteries.) A vendor battery-life number is claim-level and should not clear a hot-swap bar. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01 adversarially verified

hardware-handheld-lte

Re-examined 2026-08-08 with the first-party documentation index (cdn.parpos.com/Documentation.html) the earlier pass had not found. PAR does publish a cellular statement, but at the wrong layer for this claim: PAR POS System Requirements (cdn.parpos.com/docs/POSSystemRequirements.pdf, updated 4/1/26) specifies under Internet a broadband "'Always on' connection at minimum speeds of 10Mbit/s down" and then "3G/4G/LTE only viable as backup solution" - a fallback for the store's connection, not a radio in a handheld, and PAR neither supplies nor specifies the failover device. The PAR POS Network Connectivity Requirements document (cdn.parpos.com/docs/PARPOSNetworkConnectivity.pdf) is entirely about firewall rules, hosts and ports and describes no cellular path; the VLAN speed document likewise. The hardware page (partech.com/solutions/pos-hardware/) describes PAR Tablet only as a "line-busting workhorse [that] powers through the transactions with a 10-hour battery life" with no connectivity spec, and System Requirements lists tablets by CPU/RAM/SSD only. So no built-in cellular on a PAR handheld and no vendor-supplied device-level Wi-Fi failover is documented either way.

hardware-offline-mode

PAR publishes offline behaviour and its limits in a dedicated document. Continued operation: "in the event of primary register failure, the backup register takes over, operating independently, without dependence on above-store/cloud services. This ensures seamless store operations even in the case of an internet outage"; the test procedure states that on killing the internet "the primary and all secondary registers will continue to function but in offline mode", and on losing the primary the backup primary "swiftly assumes control and continues operating in offline mode. The remaining secondary registers subsequently recover and also operate in offline mode". Single-register sites are covered too: "the primary register transitions to offline mode after a connection loss, as it currently does". The degradation list is explicit: "online ordering will not be available, as the backup primary does not currently support online orders", "If internet connectivity is lost, offline mode operates normally with the primary register acting as the host... However, online orders will still fail", and changeset publishing, the End of Day process and "synchronizing historical data to the cloud" are each stated as unavailable while the primary is down. It also names when offline mode does not work ("the primary and backup primary registers are both having a power loss or network failure"), and the 5.0n.r2/5.14 guardrails that block Clocking Out, Checking Out and Cash Drawer Assignment on the backup primary for a default 15 minutes. On recovery, "When the Primary connection reestablishes itself, it automatically initiates self-correction and resynchronizes with both the backup primary and the cloud server." Not covered by PAR's degradation list: card-authorization, loyalty-lookup and refund behaviour while offline are not addressed in this document. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

hardware-kds

First-party KDS sold with a programmable bump bar and docking stations; PAR also exposes a Kitchen API service for queue and bump times. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

hardware-kiosk differentiator

Kiosk offered with the same loyalty/ordering engine; countertop vs freestanding form factors and ADA conformance are not documented. https://partech.com/solutions/guest-engagement-platform/digital-experience/ · retrieved 2026-08-01

hardware-drive-thru

PAR sells drive-thru headsets (G5 audio), a Drive-Thru Timer for speed-of-service measurement, and integrates order confirmation boards. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

hardware-printer-compatibility

The Edit Printer dialog's General tab documents the Model drop-down list by name: "Epson TM-L90, NCR 7197, PAR M3876, Partner RP-320, Star TSP100, or Zebra TTP 2000" (which then expose Parity, Handshake, COM Port and BaudRate), and separately "Epson TM T88, Epson TM T88 ReStick, or Epson TM U200", which expose an Interface Type of "Ethernet: TCP/IP Address: Enter the IP address of the printer" or Serial. That is six manufacturers - Epson, NCR, PAR, Partner, Star and Zebra - so vendor-branded hardware is one option among many, and the Epson TM-T88 family is the standard ESC/POS thermal receipt printer, supported over LAN as well as serial. Kitchen use is a per-printer flag on the same dialog ("Is Kitchen: Can be included in printer groups", with Print All Items, Print Only Customized Items and Chit Type None/Summary/Single/Bag/Both). The API mirrors it: Settings2.svc's Printer type carries Model (PrinterModel), Interface ("Select one of the following: Ethernet, Serial, Windows"), BaudRate, ComPort, Parity, Handshake and IsKitchen. PAR also publishes a standalone Epson TM-L90 Label Printer Formatting Guide. The phrase 'ESC/POS' is not used in PAR's documentation; the manufacturer and model list is the evidence. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

hardware-peripherals

Docking stations, printers and cash drawers named. No published compatibility list; scales, barcode scanners and customer-facing displays not confirmed. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

hardware-p2pe-terminal

Card entry is on dedicated PIN pads, but PAR states neither a validated P2PE listing nor the merchant's SAQ type. The devices are named in PAR's own PAR Pay RMA guide - P400, Move 5000, Link 2500, Lane 3000, Lane 3600, Lane 7000, Lane 8000 - all Ingenico Tetra-family PIN pads rather than the POS tablet, and PAR publishes per-device setup guides for them plus a DataCap EMV payment matrix; the PAR Pay 2024 PCI Upgrade notice shows PAR pushing mandatory device firmware and warns that "failure to comply will result in your devices being unable to process transactions", with transactions routed to Aurus endpoints. What is missing is exactly what the claim demands. PAR's Software Security Framework FAQ says "ParTech will provide our most recent PA-DSS AOC for PAR POS as well as our Letter of Engagement from our third-party consultant to demonstrate our current efforts for PAR POS to be certified with SSF", and the attached Coalfire letter dated 18 Oct 2022 states only that PAR "has engaged Coalfire Systems, Inc. to perform a Secure Software Assessment in line with the PCI SSC P2PE requirements" with "The assessment is planned to conclude in early 2023" - an engagement, not a validated P2PE solution listing, and PAR has published no completion notice since. No PCI PTS listing is cited for any device by PAR, no claim is made that the POS application and tablet are out of PCI scope, and no merchant SAQ type is stated anywhere - the Network Connectivity guide instead pushes the question back to the customer: "PAR recommends reviewing all policy changes with your network security team and PCI auditors". https://cdn.parpos.com/docs/PARPOSSoftwareSecurityFrameworkFAQ.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

hardware-tap-to-phone differentiator

Re-examined 2026-08-08 against PAR's first-party payment documentation rather than the hardware landing page. Every PAR Pay acceptance device PAR names is a dedicated PIN pad: the PAR Pay RMA Quick Reference Guide lists eligible devices as P400, Move 5000, Link 2500, Lane 3000, Lane 3600, Lane 7000 and Lane 8000, and the documentation index (cdn.parpos.com/Documentation.html) carries setup guides only for those Ingenico units plus a FreedomPay Lane 3600. PAR's contactless messaging is about accepting Apple Pay, Google Pay and Samsung Pay on NFC-certified terminals, which is the opposite side of the transaction from Tap to Pay on iPhone; the phrase 'Tap to Pay' as a software-only acceptance mode appears nowhere on partech.com, developers.partech.com or cdn.parpos.com, and the PAR Pay API on developers.partech.com (26 operations covering credit card, gift card and tokens) documents no phone-as-reader flow. Left unknown rather than no because neither the RMA eligibility list nor the setup-guide index is presented as a complete supported-hardware list, and PAR publishes no such list.

hardware-pricing-transparency differentiator

No SKU-level prices anywhere on the hardware page; the page directs buyers to a demo or 1-800-382-6200. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01

hardware-ownership-vs-lease differentiator

PAR states which, in an SEC filing. The 2025 Form 10-K's revenue recognition policy reads: "Hardware revenue consists of hardware product sales and is recognized as a point in time revenue. Revenue on these items is recognized when the customer obtains control of the asset in accordance with the terms of sale. This generally occurs upon delivery to a third-party carrier for onward delivery to customer. We accept returns for hardware sales and recognize them at the time of sale as a reduction to revenue based on historical experience." Title and control pass to the customer on delivery - a sale, not a rental. It is reported as a separate revenue stream from Subscription Service, whose SaaS fees are by contrast "recognized ratably over the contract period" on contracts "generally for a period ranging from 12 to 36 months", so hardware is not a subscription-bundled rental; hardware revenue was $106.4 million in 2025. The accompanying warranty policy confirms ownership economics - a warranty reserve is recorded "When a sale is consummated", over a warranty period that "can range from 12 to 60 months". Not established by this source: the retail purchase price of any device, or whether PAR or a reseller separately offers a financing or lease option alongside outright sale - partech.com publishes no hardware pricing or acquisition terms. https://partech.com/wp-content/uploads/2026/02/10-K-Document-2025.pdf · retrieved 2026-08-08

hardware-usable-after-churn differentiator

Re-examined 2026-08-08. PAR does now state that hardware is sold rather than leased - the 2025 Form 10-K recognises hardware revenue "when the customer obtains control of the asset" - but ownership of the asset is not the same as the vendor confirming it remains usable with other software, and PAR makes no such confirmation anywhere. The places such a statement would live were checked: PAR POS System Requirements (cdn.parpos.com/docs/POSSystemRequirements.pdf) describes terminals as commodity Windows IoT Enterprise x64 machines (Intel Celeron J1900/J6412 class, 4-8GB RAM, 64-128GB SSD), which is suggestive but says nothing about entitlement; the PAR POS Network Connectivity Requirements and In-Store Resilience notes describe cloud dependence during operation but no remote disable; the 5.16r2 Admin Portal Configuration Guide has no device-entitlement or deactivation screen; and the PAR Pay 2024 PCI Upgrade notice shows PAR can push firmware that renders payment devices "unable to process transactions" if not applied, which cuts the other way but concerns compliance, not cancellation. No terms of service or hardware warranty document addressing post-cancellation use is published on partech.com or cdn.parpos.com.

hardware-rma-sla differentiator

A turnaround SLA is published; a customer-facing warranty term is not. The PAR Pay RMA Quick Reference Guide sets out two tiers side by side: Standard RMA - "No contract required", "Get a replacement device shipped to the store within 3-4 business days after the Help Desk processes the RMA request", "Replacement fee: $200, billed to your account"; and Advanced Exchange RMA - "Contract required", "Get a replacement device shipped to the store within 2-3 business days", "No replacement fee". Both require the damaged unit back on a provided FedEx label within 10 business days or "you are billed the full price of the device plus a 15% fee", and eligible devices are enumerated (P400, Move 5000, Link 2500, Lane 3000/3600/7000/8000). The 2025 Form 10-K corroborates the programme at company level: "We offer depot repair, warranty, and overnight Advanced Exchange services", with hardware support revenue coming from "the Company's Advanced Exchange overnight hardware replacement program, on-site support, and extended warranty repair service programs". Shortfalls: the published turnaround SLA covers PAR Pay payment devices only - no equivalent is published for POS terminals, KDS units or printers; and no customer-facing warranty term is published for any product, the only figure PAR states being the 10-K's accounting range that a warranty period "can range from 12 to 60 months", which is a reserve-estimation range rather than a stated term. https://cdn.parpos.com/docs/PARPayRMAQRG.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

hardware-byod

Re-examined 2026-08-08 with PAR's first-party documentation set rather than marketing pages. PAR POS System Requirements (cdn.parpos.com/docs/POSSystemRequirements.pdf, updated 4/1/26) specifies the ordering application as a Windows 10/11 IoT Enterprise LTSC x64 program requiring .NET Framework 4.7.2+, listing Terminal, KDS/ORB and Tablet profiles all as x64 Windows devices - which is incompatible with a staff member's personal iPhone or Android phone, though PAR never says so. Register identity is device-bound in the same way: the Network Connectivity guide requires each terminal to carry a Private Windows network profile with IPv6 disabled and Network Discovery enabled, and the In-Store Resilience notes show terminals identified by entries in C:\brink\pos\register.cfg and a Terminal Topology on the Admin Portal Devices page. No BYOD permission or security model is documented anywhere on partech.com, cdn.parpos.com or developers.partech.com. Left unknown because PAR's guest-facing and mobile surfaces (PAR Ordering, the Punchh Mobile API) are separate products and none of these documents is presented as a complete statement of which devices staff may use.

hardware-remote-device-management differentiator

A device console exists and covers terminals and KDS, but not the rest of the claim. Admin Portal > Home > Devices "displays the connection status for all Kitchen Displays and Registers for the selected location", along with "the Terminal Topology, which is the configuration of the terminal e.g. IP Address, Machine ID"; "The status of the Maintenance Service for each Register and Kitchen Display is reported in the Maint. Svc. Status column"; the page also shows all cash drawers with who they are checked out to and their cash, and lets an admin change a location's environment type. Terminal Topology is where the backup primary register is elected for In-Store Resilience, and register displays are labelled with role and state ("Register 2 (BP) - Online"). Remote action is limited but real: Tools > Run End of Day "lets an Admin Portal user initiate the end of day process at a location remotely", and configuration is rolled out through Changeset Publisher, which targets selected locations or location groups either Immediately or at End of Day with per-location status, Retry and Download Errors. The API exposes one status probe, Ordering.svc GetMasterTerminalStatus, "to check whether the Primary Register of the location is online (connected to the cloud) or offline" (0 = Offline, 1 = Online). Shortfalls: printers are not shown on the Devices page - they are configuration objects only; there is no remote reboot; no software-version display per device is documented, and version state is handled by overnight patching (BMS patch applications requiring "Terminals should be powered on at all times"); and update rollout is not staged by ring or cohort - the only staging PAR documents is configuration changesets, and its own guidance is procedural ("Changes done in one location should not be cascaded ahead to more than a set of 500 locations"). https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

hardware-selfpour-scales

Re-examined 2026-08-08 by reading the Settings Editor's peripheral screens in the 5.16r2 Admin Portal Configuration Guide rather than searching for keywords. The configurable in-store device set is Printers (Model drop-down spanning Epson, NCR, PAR, Partner, Star and Zebra units), Kitchen Displays, Order Confirmation Display, Caller ID, Scales and Registers. The Scales screen is a weigh-scale peripheral for items sold by weight - "Scales are the weigh scale peripherals connected to the POS system", configured by Name, Model, Interface Type, Parity, Handshake, COM Port, Baud Rate and Register - paired with the Tares type in Settings2.svc; it carries no pour, keg, tap or flow semantics. Nothing tap-wall, flow-meter or pour-spout related appears in the guide, in the 659-operation legacy Brink API portal, or on partech.com's hardware page. Left unknown rather than no because self-pour vendors typically integrate through the ordering API rather than a device screen - Ordering.svc SubmitOrder plus the NewExternalPayment tender type would be the natural route - and PAR publishes no supported-integration list that would close the question (its partner-ecosystem page is a directory, which is not an enumeration).

hardware-callerid-integration

Caller ID hardware is supported and surfaces the call at the POS, but stops at name and number. Settings Editor > Options > System > Caller ID is a dedicated configuration tab: "Configuration settings for caller ID device, which communicates caller name and number to the POS when an incoming call is received. When enabled, displays caller name and phone number at the top of the 'Future Order' screen." The device is configured by Register ("Register that is caller ID device is physically connected to"), Model ("Make and model number of the caller ID device"), Interface ("Interface type of the caller ID device"), COM Port and Reverse Caller Name ("Displays the caller name as 'Last Name, First Name'") - a serial caller-ID unit attached to a named terminal, with the model left open rather than restricted to a PAR part. Shortfall: what pops is the inbound caller's name and number on the Future Order screen, not the matched customer record - PAR documents no lookup of the stored customer, no order history recall and no linkage to the Customers module or the Lookup Customer register button from an incoming call, and no telephony/VoIP integration is documented anywhere as an alternative route. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

extensibility-public-api-docs

Both the unified PAR Developer Portal and the legacy Brink API portal are readable with no login, NDA or sales call; OpenAPI documents, Postman collections and client libraries are downloadable. https://developers.partech.com/ · retrieved 2026-08-01

extensibility-api-access-cost differentiator

Re-examined 2026-08-08. Four surfaces were checked and none answers it. (1) PAR's 2025 Form 10-K disaggregates revenue only into Hardware, Subscription Service (SaaS solutions, software support, managed platform development services, payment processing) and Professional Service - API access is not a named performance obligation, and the only API mention is positioning: "Our SaaS solutions are extensible and built on open application programming interfaces". (2) The legacy Brink API portal (brinkapiportal.parpos.com) publishes the full reference free and un-gated but no fee schedule; its FAQ routes token requests to a person - "you can direct any token requests to: Main Support at api.support@partech.com or (800) 403-9027" - and diagnoses failures with "Are you provisioned to access this location with your API account's AccessToken?", so access is provisioned commercially. (3) developers.partech.com, the newer unified portal, likewise publishes references (PAR Pay, Identity Service, POS, Punchh) with no pricing. (4) partech.com publishes no price list or plan page at all. So a per-location API fee is neither documented nor excluded.

extensibility-partner-revshare

The public partner directory lists 291 partners but publishes no referral fee, revenue share, or certification cost. Not documented publicly. https://partech.com/partner-ecosystem/ · retrieved 2026-08-01

extensibility-free-sandbox differentiator

Development/test servers exist (Brink dev server; Punchh sandbox base URLs), but the URLs and keys must be requested from a PAR/Punchh representative — no self-serve seeded sandbox. https://developers.partech.com/docs/dev-portal-pos/additional-topics/make-first-pos-call · retrieved 2026-08-01

extensibility-oauth-partner-apps

Verified at the source. The developer portal states the header format `Authorization: Token token=LOCATION_KEY_GOES_HERE, btoken=BUSINESS_KEY_GOES_HERE` and "If you do not have these keys, reach out to your Punchh representative." Sandbox and production base URLs must also be requested from a rep. Brink side is the same pattern: the FAQ tells you to email api.support@partech.com or call (800) 403-9027 for tokens, and diagnoses failures with "Are you provisioned to access this location with your API account's AccessToken?" Static tokens, per-location provisioning, no OAuth, no operator-granted https://developers.partech.com/docs/dev-portal-pos/additional-topics/make-first-pos-call · retrieved 2026-08-01 adversarially verified

extensibility-webhooks-push

Guest lifecycle webhooks are documented; order lifecycle events are not — PAR's own guidance is to poll GetOrders with a ModifiedTime filter. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01

extensibility-webhook-reliability differentiator

Re-examined 2026-08-08. The only webhook surface PAR publishes is the Punchh Webhooks Manager on developers.partech.com; its Event - Guest page (developers.partech.com/docs/dev-portal-webhooks-manager/8c18e3660f73f-event-guest) documents a single event type, 'users', covering guest create, update and delete, and describes only the payload schema and a business-level option to emit events for deleted guests. It states nothing about signature verification (no HMAC, signing secret or signature header), nothing about retry policy or backoff, nothing about failure handling, and there is no replayable event log or delivery-history endpoint. The POS side has no webhook mechanism to assess at all: the string 'webhook' appears zero times across the fully dumped legacy Brink API portal (12 pages, 659 operation anchors), and PAR's documented pattern for order data is polling - GetOrders with a ModifiedTime filter, under a best-practice cadence of "5 concurrent calls with a sleep of 2-3 minutes in between calls". Left unknown rather than no because the Webhooks Manager has additional pages behind the Scalar/OpenAPI viewer on developers.partech.com whose spec does not load at the conventional openapi.json/spec.json/swagger.json paths (all 404), so a delivery-semantics page may exist that I could not render.

extensibility-order-injection-api

A dedicated Ordering service (api2.brinkpos.net/Ordering.svc) creates orders as POS transactions; DPIP membership requires those injected orders to behave as first-class tickets. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01

extensibility-menu-write-api differentiator

Verified: SaveItems, SavePriceChanges and UpdateItemPrice are the only documented writes, and GetMenu retrieves structure with no modification capability. Asymmetry is real. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01 adversarially verified

extensibility-data-symmetry differentiator

Asymmetric. Items, modifier groups and prices are writable; menu structure, kitchen and much of sales/labor are read-only. Not every readable object is writable. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01

extensibility-published-rate-limits

Verified verbatim: "5 concurrent calls with a sleep of 2-3 minutes in between calls" (multi-tenant) vs "10 concurrent calls with a sleep of at least 1 minute" (single-tenant); save batches capped at 100 and delete batches at 20, "RPM should not be more than 5 requests per minute." Guidance, not enforced quota semantics — partial is correct. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01 adversarially verified

extensibility-doordash-preferred differentiator

PAR is named in DoorDash's 2026 Preferred Integration Partner roster (announced May 18, 2026), alongside Checkmate, Chowly, Deliverect, Otter, Qu, Square, Stream, Toast and UrbanPiper. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01

extensibility-first-party-delivery-integrations differentiator

DoorDash direct and certified. Uber Eats and Grubhub connectivity is claimed on PAR's delivery-operations page, but that product is reconciliation/dispute recovery — first-party certified order integrations for all three are not separately documented. https://partech.com/solutions/insights-and-delivery-solutions/ · retrieved 2026-08-01

extensibility-middleware-compatibility

PAR's 291-partner public directory covers aggregation middleware categories, and Deliverect/Chowly-class platforms broadly list Brink as a supported POS — but individual middleware endpoints were not verified vendor-side in this pass. https://partech.com/partner-ecosystem/ · retrieved 2026-08-01

extensibility-accounting-connectors

Restaurant365 maintains a PAR partner integration and PAR's directory spans accounting/BOH categories; a vendor-maintained QuickBooks Online connector with mapped journal entries is not documented. https://partech.com/partner-ecosystem/ · retrieved 2026-08-01

extensibility-payroll-export

Same defect — scored against the partner directory. A bare "Payroll export" bullet supports partial at best. https://partech.com/solutions/back-office-solutions/restaurant-labor-management-scheduling-software/ · retrieved 2026-08-01 adversarially verified

extensibility-bi-data-warehouse differentiator

No scheduled push to a customer-controlled destination exists. The Admin Portal's export capability is stated as a closed set - "The Export section provides tools for exporting customers, sales, labor, settings, and surveys" - and every one of the five produces a file for the user to download: Customers is "a CSV file for download", Sales "a file that can be imported into a third-party accounting or inventory system" shaped by the GL Export account mapping, Labor "a file that can be imported into a third-party payroll system", Settings "a CSV file" of which "Currently, only items can be exported", Surveys a CSV of responses. The only recurring automated delivery in the product is Scheduled Reports, which sends "Reports that are to be generated and attached as PDFs to the email" at End of Day or a specific time - finished reports by email, not raw rows to a destination. FTP, SFTP, S3, Snowflake, BigQuery and 'warehouse' appear nowhere in the 8,425-line configuration guide. The transaction API confirms it from the other direction: Sales2.svc GetOrders takes one BusinessDate, only three calls in the whole API accept a date range, and PAR's guidance for continuous data is to poll - "Live dashboarding or live data calls include: GetOrders in Sales2.svc - using the ModifiedTime field", at 5-10 concurrent calls with a 2-3 minute sleep. Scope note: PAR sells Delaget and PAR Intelligence as separate analytics products; this is a finding about Brink POS itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

extensibility-app-marketplace

A public, filterable partner directory of 291 named integrations exists and is browsable without login — but there is no self-install flow; partners are sales-mediated. https://partech.com/partner-ecosystem/ · retrieved 2026-08-01

extensibility-custom-fields-scripting

The Admin Portal guide documents "Custom Fields" (Admin Portal > Configuration > Custom Fields): an operator adds a new field via "+ New Field," then applies it to Items/Promotions with no vendor engineering engagement. Separately, "Script Functions are VB Script functions that can be called via the 'Execute Script' button behavior," configured directly in Settings Editor and documented further in a companion "PAR POS Register Scripting" guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

extensibility-headless-embedded

PAR markets "Build a custom POS experience with PAR POS" APIs plus an order-injection service, which supports a headless pattern; no formal headless/embedded mode is documented. https://developers.partech.com/ · retrieved 2026-08-01

extensibility-api-versioning-deprecation

The legacy portal states the old API portal has moved and "will eventually be deprecated," and WSDL versioning is described — but no changelog and no stated notice period for breaking changes were found. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01

extensibility-data-portability-exit differentiator

Some of the data is exportable on demand in documented formats; the transaction record and the exit guarantee are not. What the operator can self-serve, from the Admin Portal Export section: Customers ("produces a CSV file for download" with filters on birthday, gender, communication preferences, order date, items ordered, surveys taken, preferred and signup location, signup date, email address and zip), Settings ("a CSV file containing records of the selected settings type", but "Currently, only items can be exported"), Labor ("a file that can be imported into a third-party payroll system") and Sales ("a file that can be imported into a third-party accounting or inventory system", formatted from the GL Export account mapping - QuickBooks IIF is the worked example). Shortfalls: order-level and payment-level detail is not in that list at all - it is reachable only through Sales2.svc GetOrders, one business date per call, under a rate-limit guidance of 5 concurrent calls with a 2-3 minute sleep, using an AccessToken and LocationToken that PAR provisions per location and that would presumably lapse with the contract; the Sales export is GL-summarised rather than transaction-level; menu export covers items only, not modifier groups, panels or promotions; and neither the Admin Portal guide, the API portal nor partech.com states any post-termination retrieval window, data-ownership clause or exit-export commitment. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

reliability-offline-order-entry

Testing and Validation, step 2: 'Turn off the internet connection. a. This will be your DSL or cable modem. b. The primary and all secondary registers will continue to function but in offline mode, just as they currently do.' The FAQ repeats it: 'If internet connectivity is lost, offline mode operates normally with the primary register acting as the host as it does today (prior to 5.0m).' The 5.16r2 Admin Portal guide carries the matching register-side UI: 'Show Offline Indicator: Displays "Offline" at the top of the panel on the Register when the connection status of the current register is offline.' Ticket routing rides the same local host (see this record's reliability-offline-kds-printing). What does not survive an outage is the cloud-dependent work: online orders still fail, and changeset publishing and End of Day are unavailable. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

reliability-offline-card-auth differentiator

Subscription Services Agreement (v2.0, 11.14.25) section 6.a, 'PAR Pay Services Supplemental Terms - Store and Forward Functionality': 'The PAR Pay Services offer functionality that enables Transaction Data to be stored in a payment device in the event the payment device's connection to the processor is lost, and to forward the Transaction Data upon reconnection with the processor (commonly known as "Store and Forward" or "SAF" functionality). Customer may, in its discretion, enable SAF functionality and set available parameters for number and value of Transactions that may be stored.' The fees clause (13.c) confirms it operationally, defining a billable Transaction to include 'offline/store and forward requests'. A second, manual offline path also exists: the 5.16r2 Admin Portal guide's 'Force Authorization' permission lets an employee 'select the Voice button on the "Credit Card" payment dialog used for offline credit authorizations'. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08

reliability-offline-decline-liability differentiator

Subscription Services Agreement section 6.a states the liability allocation explicitly: 'In the event that SAF Transaction Data stored in a payment device is not forwarded to the processor as desired, Customer may request that ParTech attempt to recover the SAF Transactions... provided that ParTech does not represent or warrant that recovery (in whole or in part) is possible or will be successful. Any SAF recovery efforts by ParTech will be chargeable on a time and material basis... ParTech disclaims, and Customer releases ParTech from, any liability resulting from Customer's election to enable SAF functionality or ParTech's SAF recovery efforts.' Named shortfall: the cap is described as a capability but never quantified - 'Customer may... set available parameters for number and value of Transactions that may be stored' - and no default, ceiling or per-transaction limit is published in the agreement, the PAR Pay EMV Setup Guide, or the 5.16r2 Admin Portal guide. Who bears the loss is answered (the merchant, in full); the numeric offline cap is not. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08

reliability-lan-degraded-multi-terminal differentiator

The release notes enumerate the outage cases. Example 3, 'Both Primary Register and Above-Store Services Offline': previously 'Secondary Registers are Down with no Connection'; from 5.0m, 'Secondary Registers Connect to Backup Primary Register (No Interruption)'. With only the internet down, the FAQ says 'offline mode operates normally with the primary register acting as the host'. That the state is shared over the LAN rather than islanded is proved by the contrasting case: 'What happens if the local area network (LAN) or switch in the store experiences an outage? A: The primary and backup primary registers will both operate independently in offline mode. Meanwhile, the remaining secondary registers will show an error message stating "Waiting for connection to server".' The 5.0m fix list names the shared-order failure mode directly: 'synchronization failures occurred due to multiple registers editing the same order'. Limits during host failover: Clocking Out, Checking Out and Cash Drawer Assignment are blocked on the Backup Primary for a configurable 15 minutes. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

reliability-local-transaction-engine differentiator

The PAR POS Architecture Evolution FAQ (5.0n) lists the applications that maintain the business day's activity data - Settings, Business Date, Orders, Shifts, Tills, Terminal Status - as Cloud (PAR POS Cloud Service, Ordering Service, Admin Portal, Reporting Services) and 'In-Store (At a single location): PAR POS Register, PAR POS Kitchen', with 'the PAR POS Register maintain[ing] only for the one location at which it is deployed', and says these applications 'no longer require constant synchronization'. On resiliency: 'On-premise applications currently leverage the PAR POS Cloud Service as a backup primary device, which is problematic if it is not available due to a network or communication outage between the store and the cloud. This re-architecture includes changes for on-premise applications to remove their dependency on cloud services. Registers can communicate directly with each other to handle system backups or failures, without relying on internet services.' The engine is concrete elsewhere: a local register database (register.sdf) under c:\brink\pos with a configurable BackupRetentionPeriodInDays, a primary register that 'act[s] as Host', and a local REST endpoint - PAR POS Network Connectivity Requirements documents the 'Orbit (In-Store) API' served by the Primary Register on port 5000 so that 'Orbit [can] be accessed by other devices on the local network, such as Order Menu Boards, Kiosks, and other integrations'. https://cdn.parpos.com/docs/5.0nArchitectureEvolutionFAQ.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

reliability-offline-kds-printing

The In-Store Resilience release notes state that on complete internet loss 'offline mode operates normally with the primary register acting as the host' — in-store operation is hosted on the local primary (or backup primary) register, not the cloud. Kitchen terminals are explicitly part of the local terminal topology (named as ineligible to serve as backup primary), and kitchen printers are configured as attached to specific registers (5.16r2 Admin Portal guide), so kitchen routing rides the local host. The doc does not narrate KDS behavior offline device-by-device; what it documents is that the entire in-store device set continues normal operation with local hosting. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

reliability-printer-fallback

Settings2 documents backup printing as first-class configuration: Printer carries BackupPrinterId ("Id of the BackupPrinter") and PrinterGroup carries RoutingOverrides (PrinterGroupRoutingOverride objects with Type and alternate Printers). Shortfalls: the automatic failover trigger (detection of an unreachable printer) and any staff alert on reroute are not described in public documentation — only the configuration fields are. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03

reliability-sync-conflict-handling

The In-Store Resilience release notes document partition behavior explicitly: a configurable 15-minute guardrail blocks Clocking Out, Checking Out and Cash Drawer Assignment on the Backup Primary after it starts hosting 'to decrease the frequency of state synchronization issues'; on reconnect the primary 'automatically initiates self-correction and resynchronizes with both the backup primary and the cloud server'; and the 5.0m changelog acknowledges sync failures caused by 'multiple registers editing the same order' with an added prevention layer. Shortfall: the resolution rule for concurrent edits that do occur — last-write-wins, merge, or operator prompt — is never stated; prevention guardrails and automatic resync are documented, the conflict-resolution policy itself is not. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

reliability-offline-feature-matrix

No offline feature matrix is published anywhere on partech.com or the API portals. Not documented publicly.

reliability-public-status-page

Verified live: exactly two components (PAR PAY WALLET API, 'Merchent Service Portal' — sic), 100.0% 90-day uptime, 14-day incident history, all operational as of 2026-08-01. Payments only; no POS/Ordering/Punchh status page exists. https://status.parpay.partech.com/ · retrieved 2026-08-01 adversarially verified

reliability-contractual-uptime-sla differentiator

Service Level Commitment - PAR POS Services (v2.0, 11.14.25), published openly at partech.com/terms-and-conditions/ and incorporated into the Subscription Services Agreement by section 5.b. Two commitments: 'ParTech shall achieve an In-Store Transaction Service Level Commitment of at least 99.8% at each Participating Location... in each Measurement Period' (a calendar month, 24x7 base hours, an In-Store Transaction defined as opening and closing an order on a point of sale terminal or the in-store API), and an Above-Store Admin Portal Availability commitment 'of at least 98.8% in aggregate across all Participating Locations'. Credit schedule for in-store: 99.5-99.79% = 10% of the monthly subscription Fee, 99.0-99.49% = 25%, 98.0-98.99% = 50%, 97.99% or less = 75%; admin portal: 10/25/50%. Read the fine print: in-store Downtime is measured from the creation of a support case rather than by PAR's own monitoring, credits are waived if no case was opened within 15 days of month end, credits cap at 100% of the month's fee, and no credit accrues while invoices are 45 or more days past due. This contract, not the '99.99% uptime' figure on the Cloud POS marketing page, is the SLA. https://partech.com/wp-content/uploads/2026/02/08-Service-Level-Commitment-PAR-POS-Services-v2.0-2025-11-14.pdf · retrieved 2026-08-08

reliability-incident-postmortems

The Service Level Commitment names https://status.parpos.com as the PAR POS Status Page. It is an Atlassian Statuspage created 2018-08-13 with per-stack components (PAR POS on Admin1 through Admin25) and, via its api/v2/incidents.json, 50 incident threads reaching back to 2024-09. Resolution updates do state causes in a sentence or two: 'Due to an external issue on the funding side, certain Merchant IDs experienced a shortage in deposits on June 26th, 2026'; 'This issue has been identified to be due to a release that OLO made today'; 'a degradation in service due to an AWS outage'; 'Due to an internal calculation error on our end, certain monthly processing fees may have been undercharged'. Named shortfall: no written post-incident report or root-cause document is published for any incident. The clearest illustration is the 2026-06-16 'Scooters: Terminal boot loop' entry, closed with 'The issue has resolved and an RCA is being investigated to determine the casue' [sic] and no RCA ever posted. What exists is cause attribution inside an incident thread, not postmortems. https://status.parpos.com/ · retrieved 2026-08-08

reliability-247-live-support

Technical Support Services Terms - PAR POS Services and PAR Pay Services (v2.0, 11.14.25), section 2.a: 'ParTech will provide Technical Support Service Representatives to respond directly to Customer Branded Restaurants available 24 hours a day, 7 days a week, 365 days a year for requests for Technical Support Services either via telephone, email, or self-service portal.' Two named shortfalls. (1) It is not documented as included in the base subscription: Subscription Services Agreement section 5.a makes technical support 'Subject to Customer's payment of the applicable Fees', and section 13.a lists 'support fees' as a Fee category separate from subscription service fees. (2) Customers who route through their own IT helpdesk get materially less: section 2.b limits Peer-to-Peer IT Group support to 7 AM - 8 PM Eastern Monday to Friday and 9 AM - 5 PM Eastern Saturday and Sunday, with representatives 'available by pager after hours' for Priority 1 issues only. The only phone response target published - 90% of synchronous contacts answered within 15 minutes - is expressly business hours only. https://partech.com/wp-content/uploads/2026/02/12-Technical-Support-Services-PAR-POS-Services-v2.0-2025-11-14.pdf · retrieved 2026-08-08

reliability-onsite-install differentiator

PAR claims on-time opening rates approaching 99% on multi-location rollouts, implying a field deployment organization; on-site install as a named, purchasable service is not documented. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

reliability-menu-build-service differentiator

Menu Maintenance Service Terms - PAR POS Services (v2.0, 11.14.25) treats the initial build as an existing, separately-scoped ParTech deliverable: 'initial menu layouts and panels for the PAR POS Services menus are created under the menu build statement of work. These menu layouts and panels will be maintained as part of the Menu Maintenance Services.' The exclusions list confirms the split, excluding 'configurations and mapping of existing menu items created and configured under any applicable menu build statement of work as part of professional services prior to Customer's deployment and Activation of the PAR POS Services' and likewise 'payment configurations and credit and gift card configurations created and configured under any applicable menu build statement of work'. Named shortfall: it is professional services at additional Fees under a separate statement of work (Subscription Services Agreement 5.e), not something the subscription includes, and the SSA pushes configuration responsibility back onto the operator - 'Customer is solely and exclusively responsible for ensuring the ParTech Solution, including Customer's menu, integrations, labor scheduling, inventory, offers and campaigns (as applicable) are properly configured prior to Customer deploying the ParTech Solution to production' (3.c). Ongoing menu maintenance is separately purchasable, Monday to Friday 8:00am-5:00pm EST, requiring five business days' notice for 1-15 new menu items and ten for more. https://partech.com/wp-content/uploads/2026/02/03-Menu-Maintenance-Services-PAR-POS-Services-v2.0-2025-11-14.pdf · retrieved 2026-08-08

reliability-hardware-replacement-sla

Terms of Hardware Sale (US and Canada) (Equipment, Installation and AE Services), v2.0, 11.14.25, section 5: 'ParTech will provide the Advance Exchange Services (the "AE Services") as to the purchased Hardware identified and set forth in the Order... for a period of one (1) year or three (3) years, as elected by Customer... During the AE Services Period, ParTech will provide 24/7 support, tracking and dispatch services and fully operational replacement Hardware', and the turnaround is stated: 'ParTech will ship replacement Hardware to Customer's ship-to address, freight prepaid, with next day delivery within the United States for requests received prior to 3:00 p.m. (Eastern Time), Monday through Friday.' Defective units return on a prepaid label and must be back within 14 days or the customer buys the replacement at full price plus a 20% restocking fee; ten ParTech holidays are excluded. Payment devices get a maintained spare pool ('PD AE Pool'), its cost included in the AE price. Baseline warranty without AE is a 30-day Out of Box Failure Warranty Period and a one-year Depot Warranty Period. A parallel, non-contract program covers payment terminals: the PAR Pay RMA Quick Reference Guide gives Standard RMA at 3-4 business days with a $200 replacement fee and Advanced Exchange RMA (contract required) at 2-3 business days with no fee. https://partech.com/wp-content/uploads/2026/02/03-Terms-and-Conditions_Sale_-Hardware-Installation-AE-Services-On-Site-v2.0-2025-11-14.pdf · retrieved 2026-08-08

reliability-backup-restore

The In-Store Resilience release notes document the local backup as an operator-editable setting: 'Extended Local Register Database Backup to 30 Days [BRNK-33562 and BRNK-34355]. Adds the ability to configure the retention period of the local register.sdf during the End of Day process in the register.exe.config file... Default = 30 days (previously 5 days), Max = 30 days, Minimum = 7 days', with step-by-step instructions to edit BackupRetentionPeriodInDays in c:\brink\pos\register.exe.config. The Admin Portal separately offers self-service CSV exports of customers, sales, labor, settings and surveys (5.16r2 guide, Export section). Named shortfalls: the retention change exists for PAR's own support workflow ('customers reported missing data on support calls... the backup data on the system has often already been purged'), restore is nowhere an operator-facing function in the Admin Portal guide, and no RPO or RTO figure is published - the Security Overview (v2.0, 11.14.25) commits only that ParTech will 'perform regular backups sufficient to restore services to Customer within a commercially reasonable period of time' (3.7(i)) and to a business continuity plan tested at least annually with an attestation on written request (5.2). https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

reliability-pci-dss-4-attestation

trust.partech.com (found via the footer of partech.com/terms-of-use/) is a live trust center carrying compliance badges for PCI DSS, PCI SSF, SOC 2, CIS Controls 8.1, NIST CSF, GDPR, CCPA, PIPEDA, EU-US DPF and RH-ISAC, and its document index names a 'PCI DSS v4.0.1' artifact alongside 'SOC 2 Type 2', 'SOC 2 Type 1' and 'SOC 1 Type 2'. Named shortfalls: the version-named artifact is access-gated, not a published AoC - nothing is downloadable from the public page; the public PCI text is non-committal ('PAR follows industry expectations for securely handling payment-related information in alignment with applicable PCI DSS requirements'), naming no product scope, no assessor and no date; and there is no validated P2PE listing and no SAQ type anywhere on the site. The only PCI artifact PAR has ever published in full is the PAR POS Software Security Framework FAQ, which is stale - dated 18 Oct 2022, it offers 'our most recent PA-DSS AOC' plus a Coalfire letter of engagement for an SSF assessment 'planned to conclude in early 2023', and PA-DSS was retired on 28 Oct 2022. https://trust.partech.com/ · retrieved 2026-08-08

reliability-mfa-role-based-access

Role-based permissions are extensively documented (SecurityLevel's 26+ discrete booleans, already cited elsewhere in this record), and the two halves of the claim diverge on the authentication side. At the register there is a real second factor: "Secondary Authentication PIN: Additional layer of security for employee register access. Must be a three to 12-digit numeric PIN", set per employee in the Register Access section alongside PIN, Card Number and Finger, and exposed on the API's Employee type as SecondaryAuthPin. On back-office Admin Portal accounts there is none - the User configuration page offers only "Mobile Number: Used for Multi-Factor Authentication (if applicable)" and "Enable Multi-Factor Authentication: Place Holder for future development (MFA)". So MFA is enforceable on POS logins but not on the back office, which is the half that matters most for an above-store administrator. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read adversarially verified

reliability-self-serve-training

The Admin Portal guide documents a Training Mode at the register/kitchen level: "Indicate Training Mode on Kitchen Chits: Automatically prints 'Training Order' and 'Do Not Make' on kitchen chits while training to prevent waste." Shortfall: no public, free video/LMS training library was found; partech.com/solutions/cloud-pos/ only claims "Train employees... in under 30 minutes" without naming a library. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

reliability-failover-terminal-role differentiator

The In-Store Resilience release notes document automatic failover to a pre-elected "Backup Primary" register: on primary-register network loss, the backup "swiftly assumes control and continues operating in offline mode" without manual intervention. The backup is auto-elected among eligible secondary registers the first time the feature is enabled (or manually pinned via BackupPrimaryTerminalNumber). Shortfall: not literally any terminal — only registers not marked "Exclude from Topology" are eligible, and kitchen terminals are separately documented elsewhere in this record as ineligible — so it is a single pre-designated backup rather than dynamic per-failure election among all terminals. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified

reliability-cellular-backup

PAR POS System Requirements (updated 4/1/26), Internet section: '1. Broadband class of connection: a. "Always on" connection at minimum speeds of 10Mbit/s down 10Mbit/s; b. 100 Millisecond Minimum Latency; c. 3G/4G/LTE only viable as backup solution.' Cellular is therefore supported and named as a backup connection for the store's WAN. Named shortfalls: it is the operator's own backup link rather than first-party hardware - no PAR terminal is documented with an LTE modem - and nothing describes automatic failover. PAR POS Network Connectivity Requirements (rev 4/9/2026), the definitive connectivity document, sets out three connectivity Options (wildcard DNS, static IP list, customer-maintained AWS IP blocks) and never mentions cellular, failover behaviour or a cutover trigger; the In-Store Resilience release notes' Feature Optimization table says only 'Only high speed internet should be used' and frames the WAN as 'your DSL or cable modem'. https://cdn.parpos.com/docs/POSSystemRequirements.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

commercial-month-to-month-contract differentiator

Subscription Services Agreement (v2.0, 11.14.25) section 12.a: 'Unless a different term is agreed to by Customer pursuant to an Order or a Pricing Addendum to this Agreement, the term of this Agreement will commence on the Effective Date and continue for a period of three (3) years ("Initial Term"), automatically renewing for successive periods of one (1) year at a time.' Section 2.a adds 'All Orders are non-cancellable by Customer' and 13.c 'all Fees and payments are nonrefundable'. The payment side matches: PAR Payment Services Terms section 8.1, 'These Terms will remain in effect for a period of three (3) years ("Initial Term") and will renew for successive twelve (12) month periods.' PAR's published standard agreements are its public offer, and that offer is a three-year term with one-year renewals; no month-to-month tier appears in any of the fifteen contract documents at partech.com/terms-and-conditions/. A shorter term is possible only by individual negotiation on an Order or Pricing Addendum, which is not a public offer. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08

commercial-no-early-termination-fee differentiator

PAR Payment Services (PPS) Terms and Conditions (v2.0, 11.14.25), section 8.2 'Termination for Convenience': 'Subject to payment of the Early Termination Fee set forth herein, Merchant may terminate this Agreement by closing its PPS Account and sending at least thirty (30) days advance written notice to PPS of such closure. Merchant shall incur and pay an early termination fee equal to the Merchant's estimated Monthly Transaction Volume as set forth in the Application multiplied by the Fees, as identified in Schedule 1, excluding any network, interchange, assessment and related Acquirer processing Fees and charges, for each MID under these Terms multiplied by each month for the remainder of the then-current term ("Early Termination Fee"). Merchant acknowledges that the Early Termination Fee is not a penalty, but rather a reasonable estimate of the damages PPS sustained because of Merchant's termination of the Agreement before the end of the Initial Term and any Renewal Term.' That is liquidated damages, named as such. The software side is harder still: the Subscription Services Agreement provides no customer termination-for-convenience right of any kind - section 12.b allows termination only for uncured material breach or insolvency - and 2.a states 'All Orders are non-cancellable by Customer'. One narrow escape exists and is scored separately at commercial-rate-increase-clause: the ETF is waived where the merchant exits in response to a fee change. https://partech.com/doc/04-sub-merchant-agreement_stand-alone/ · retrieved 2026-08-08

commercial-autorenew-terms-published

Subscription Services Agreement (v2.0, 11.14.25) section 12.a, published at partech.com/terms-and-conditions/ with no login or gate: the agreement runs three years and continues 'automatically renewing for successive periods of one (1) year at a time (each a "Renewal Term"), unless and until Customer provides written notice of cancellation to ParTech at least 30 days prior to the first day of any Renewal Term'. Both elements the claim requires are stated - the auto-renewal term (one year) and the cancellation notice window (30 days before the renewal date). The payment side is published too: PPS Terms section 8.1 (three-year initial term, successive twelve-month renewals) with 8.2 requiring 30 days' advance written notice to close the account. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08

commercial-processing-not-bundled differentiator

PAR's EMV Card Processor Configuration Guide carries a "Features Matrix for PAR Certified Configurations" listing seven gateways, only one of which is PAR's: Datacap US EMV, Datacap Canadian EMV (Mercury NETePay / Vantiv Integrated Payments), PAX POSLink (Heartland Portico), Tender Retail Merchant Connect Multi (Chase Paymentech), VeriFone Point Classic (Vantiv), VeriFone Point Enterprise (First Data), alongside PAR Pay. The 5.16r2 Admin Portal User Guide separately documents Options > Payment > Credit Processor: "Processor Type: When you select a processor in this drop-down list, an Edit dialog is displayed. The information that must go into the fields on this dialog is provided to you by the credit processor" (Heartland shown as the example). Shortfall of the evidence, not the capability: PAR publishes no rate card, so processing is unbundled but unpriced, and PAR Pay-only features (tokenization, virtual terminal, quick chip, store-and-forward on some rivals) are listed as exclusive to PAR's own gateway. https://cdn.parpos.com/docs/EMV%20Card%20Processor%20Config%20Guide.pdf · retrieved 2026-08-06 · not refetchable · site policy · graded B when read adversarially verified

commercial-interchange-plus-published differentiator

No interchange-plus markup, bps figure, or per-transaction rate published anywhere. Not documented publicly. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01

commercial-rate-increase-clause differentiator

PAR Payment Services (PPS) Terms and Conditions (v2.0, 11.14.25) section 3.1: 'We reserve the right to change our fees with at least thirty (30) days advance notice. By continuing to use the Services, you consent to the change in Fees. To withdraw your consent, you must close your Account and provide us with written notice prior to the effective date of such change in Fees. If you do not accept the change in Fees and withdraw your consent prior to the expiration of the Initial Term of this Agreement or any Renewal Term, you will be deemed to have terminated these Terms for convenience under Section 8.2 below; provided however, the Early Termination Fee in Section 8.2 will not apply.' That is the penalty-free exit the claim asks for, and it is the second of the two limbs - the increase itself is not capped, only noticed, and the merchant must close the account before the effective date to use it. Worth contrasting with the software side, which has no equivalent: Subscription Services Agreement 13.b escalates fees at each Renewal Term automatically by 'the applicable annual percentage increase in the Consumer Price Index (CPI) over the prior 12-month period plus two percent (2%)', and reserves ParTech's right to exceed even that on 60 days' written notice, with no exit right attached. https://partech.com/doc/04-sub-merchant-agreement_stand-alone/ · retrieved 2026-08-08

commercial-pricing-published

partech.com has no pricing page and no dollar figures for software or terminals; every path is "schedule a demo." The "$90/month + $50 per terminal" figure circulating on aggregators is not PAR-sourced. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

commercial-module-unbundling differentiator

PAR OPS is described as offering "modular pricing options" and PAR sells POS, Ordering, Punchh, OPS and Payments as distinct products — but independent cancellation without repricing the base POS is not documented. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01

commercial-hardware-purchase-outright

PAR designs and sells its own terminals, KDS and peripherals — hardware product revenue is reported line-item in its earnings releases, so outright purchase is the business model, and no mandatory hardware lease is published either way. Shortfall: no published prices — the PAR Hardware page (re-checked 2026-08-04) lists no dollar figures and no acquisition terms at all (purchase, lease or hardware-as-a-service); every path routes to 'Schedule a Demo', consistent with partech.com publishing no pricing anywhere. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-04

commercial-hardware-not-locked differentiator

PAR states the POS works with "many types of hardware you may already have" and PAR Volt runs Android or Windows; no specific non-proprietary device or printer is named. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

commercial-implementation-fee-published

No implementation, menu-build, onboarding or training fees published. Not documented publicly.

commercial-data-export-self-serve

Orders, sales, labor and settings are all pullable via documented APIs, but the API account and its per-location access must be provisioned by PAR — so it is API-available, not truly self-serve. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01

commercial-export-customer-and-loyalty differentiator

Citation re-pointed and evidence strengthened 2026-08-09. Machine-readable guest data is genuinely reachable by the operator: the Webhooks Manager guest event streams create/update/delete of the full guest record as JSON (email, phone, name, address, birthday, signup_channel, marketing_email_subscription, marketing_pn_subscription, sms_subscription, favourite_store_numbers, up to 25 custom profile fields, joined_at/last_activity_at); GET /api2/dashboard/users/info returns an individual guest's profile plus the loyalty balance object (points_balance, banked_rewards, net_balance, total_credits/debits, membership_level) and unredeemed reward ledger; and POST /api2/dashboard/users/send_user_details_export emails a per-guest export. Shortfalls that keep this below yes: every documented route is per-guest or event-driven - the Platform Functions Users group enumerates ban/unban, send_message, reactivate, deactivate, delete, patch, send_user_details_export, extensive_timeline, favourite locations, info and redemption, with no list or bulk-download operation, and the Mobile API index has no export group either; the export endpoint delivers by email rather than as a retrievable file; and gift-card liability balances have no documented operator-side export at all. https://developers.partech.com/docs/dev-portal-webhooks-manager/events/guest · retrieved 2026-08-09 adversarially verified

commercial-post-termination-export-window differentiator

Subscription Services Agreement (v2.0, 11.14.25) section 11.e, 'Return of Customer Data/Transaction Data': 'Provided Customer has paid all Fees and other amounts due under this Agreement, ParTech will extend Customer's access to the ParTech Services for a period of sixty (60) days beyond the expiration or early termination of this Agreement. During such period, Customer may extract any data in appropriately available formats for each ParTech Services... After such sixty (60) day period, ParTech shall have no obligation to maintain or provide any access to Customer Data and may thereafter, unless legally prohibited, delete all Customer Data.' Longer retention is available by agreement and continued payment of the applicable subscription Fees. Conditions worth recording: the window is contingent on the account being paid in full; hands-on help is chargeable ('Any assistance required by Customer to execute such data extraction will be provided by ParTech in a cooperative fashion as professional services, billed at prevailing rates and payable in advance'); self-service export in the Admin Portal covers customers, sales, labor, settings and surveys as CSV; and section 12.c states flatly that on termination 'ParTech will have no obligation to maintain, deliver or provide access to any Customer Data', so 11.e is the operative carve-out. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08

commercial-data-ownership-clause differentiator

Ownership is unambiguous. Subscription Services Agreement (v2.0, 11.14.25) section 11.c: 'Customer has and shall retain sole and exclusive title and ownership of all information and data, including all derivatives and transformations thereof, input by Customer or Authorized Users into the ParTech Services', covering card-derived data and payment Transaction Data. The constraint the claim also requires is where it fails. The same clause licenses ParTech to use Customer Data not only to perform the agreement but '(y) to offer or develop other ParTech products and services and/or alternative pricing structures' - unrestricted and not de-identified - while the de-identification limit attaches only to the third limb, '(z) to create derivatives of Customer Data, solely in de-identified and aggregated form', with ParTech owning that Aggregated Data outright and free to share it with affiliates and across the ParTech Services. Section 11.f additionally authorises disclosure of all of a franchisee's location data to its franchisor or authorised reseller, with a release of liability. The payment terms go further: PPS Terms section 4.1, 'Merchant acknowledges that PPS or Acquirer may retain and use Transaction data during and after the term of this Agreement without restriction and may share such data with third parties, including, but not limited to third party service providers', with PPS or Acquirer the sole owner of the aggregated data. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08

commercial-source-available-selfhost

PAR POS is proprietary commercial SaaS from a public company. No source availability or self-hosting option. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01

commercial-pci-p2pe-tokenization

Half the claim is documented. Subscription Services Agreement 5.d: 'ParTech shall protect and secure the Customer Data and Transaction Data (both as defined herein) within the PAR Pay Services in accordance with the requirements of the PCI-DSS.' Tokenization is defined in the contract at 11.d - a 'Customer Token' is 'a derived alphanumeric value that is linked with a Gift/Debit/Credit card and is only used within Customer's database of Customer Data to uniquely identify a customer; it cannot be used to process a payment transaction' - with card data otherwise handled in masked (last four) and unmasked classes. Hardware entry is documented in the PAR Pay EMV Setup Guide on Ingenico and Verifone PIN pads ('A customer can dip, swipe, tap or manually enter their card'), and trust.partech.com carries a PCI SSF badge. Named shortfall: the other half is missing entirely - no validated P2PE solution or application listing is claimed on trust.partech.com, in the fifteen contract documents, or anywhere on cdn.parpos.com, and no SAQ type is named in any published PAR document, not SAQ A, not SAQ P2PE-HW, not SAQ C. Without a named SAQ the scope-reduction assertion this claim tests is simply never made. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08

commercial-pci-dss-4-controls

PAR documents one of the claim's two named controls, and only on one of the two named surfaces. Register logins: PAR POS 5.15r2 (Nov 2025) shipped "Secondary Authentication PIN for Register Sign-On (BRNK-55231)" - "PAR POS now supports a Secondary Authentication PIN as an additional layer of security when accessing registers. This new feature allows businesses to require a second user-entered PIN after the primary PIN login method, helping to prevent unauthorized access and supporting compliance with stricter security policies. Secondary Authentication PIN is configurable and can be enabled per employee." The release note's own use case is headed "Customer has enabled MFA for all team members", and the 5.16r2 Admin Portal Configuration Guide carries the field on the employee record: "Secondary Authentication PIN: Additional layer of security for employee register access. Must be a three to 12-digit numeric PIN." It is settable through the API as SecondaryAuthPIN on Settings2.svc/SaveEmployees. Shortfalls, all four material: (1) two sequential PINs are two knowledge factors, not two distinct factor types, so this does not satisfy PCI DSS Req 8.4.2/8.5 as written, and PAR nowhere cites v4.0.1 or Req 8.4.2, 6.4.3 or 11.6.1 in any published document; (2) back-office MFA is still unbuilt - the same guide's Admin Portal User configuration page reads "Enable Multi-Factor Authentication: Place Holder for future development (MFA)", so the claim's "back-office logins" half is not met; (3) nothing is published on payment-page script integrity monitoring for hosted ordering pages, and the trust center Security Overview 3.9 commits only to a secure development methodology, secure coding standards, automated secure code review, annual vulnerability scans and annual penetration tests; (4) PAR's published PCI posture is the Software Security Framework FAQ, whose offered artifact is "our most recent PA-DSS AOC for PAR POS as well as our Letter of Engagement from our third-party consultant" (Coalfire, 18 Oct 2022), with SSF certification described as still in assessment - a lifecycle standard, not a DSS v4.0.1 control statement. Checked the 5.16 and 5.16r2 release notes and Features QRGs, the PAR Pay 2024 PCI Upgrade notice and the full cdn.parpos.com document index for a newer MFA or script-integrity statement; there is none. https://cdn.parpos.com/release-notes/5.15r2ReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

commercial-soc2-attestation

Security Overview (v2.0, 11.14.25), incorporated into the Subscription Services Agreement by section 5.d, clause 3.3 'Audits of ParTech's Information Security Program': 'ParTech shall cause an independent third party to conduct at least once each year a SOC 1 Type II audit and a SOC 2 Type II Audit of the ParTech Services for ParTech's Services. ParTech will provide a copy of these reports upon Customer's request, subject to the Customer's confidentiality obligations under the Agreement.' That is both limbs of the claim - a current attestation held, and the report provided on request under confidentiality. Corroborated on trust.partech.com, which carries a SOC 2 badge, states 'PAR maintains a SOC 2 Type II report that outlines the design and operating effectiveness of our security and privacy controls', and indexes 'SOC 2 Type 2', 'SOC 2 Type 1' and 'SOC 1 Type 2' documents. Not established: the report period, the assessing firm, and whether coverage spans every ParTech Service or only the hosted platform - the trust center publishes no dates, and no ISO 27001 certification is claimed for ParTech itself (ISO 27001 appears only as an example of a report PAR may seek from its own subprocessors, Security Overview 3.10(iv)). https://partech.com/wp-content/uploads/2026/02/04-Security-Overview-v2.0-2025-11-14.pdf · retrieved 2026-08-08

commercial-privacy-dsar-tooling

Citation re-pointed and evidence replaced 2026-08-09; the old note's inference from webhook status names is withdrawn in favour of the endpoints themselves. Punchh documents the full data-subject-request path under the operator's business admin key: GET /api2/dashboard/users/info fetches a guest "by user ID, phone number, or email address"; POST /api2/dashboard/users/send_user_details_export "Emails a guest export to the guest as well as the requester"; DELETE /api2/dashboard/users takes reason delete_general ("Deletes the user and all associated transaction data permanently") or anonymize_forget_me ("Deletes all of the user's PII (personally identifiable information), while keeping anonymized transaction data for reporting integrity. This is in compliance with GDPR/CCPA standards"), after a required deactivation step and a configurable grace period defaulting to 7 days. Shortfalls that keep this at partial: the documented tooling is an API, not the in-app self-service DSAR console the claim describes - no Punchh platform admin-UI screen for locating, exporting or deleting a guest is documented publicly; and no executable Data Processing Addendum is published - partech.com/legal/ and partech.com/data-processing-addendum/ both 404, the partech.com privacy policy contains no DPA reference or link, and punchh.com/privacy-policy/ 404s. https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users/delete/api2/dashboard/users · retrieved 2026-08-09 adversarially verified

commercial-wcag-kiosk-accessibility differentiator

Assessed 2026-08-08 across every first-party surface that would hold an accessibility conformance report. partech.com/accessibility/ and partech.com/vpat/ both 404 (calibrated: a real partech.com page returns 200 at 130-210KB, a fabricated path returns a 404 body at ~107KB, so status discriminates here). trust.partech.com - PAR's compliance trust center, found via the terms-of-use footer - indexes roughly forty titled documents including narrow ones such as Cyber Insurance and the Responsible AI Statement, and carries badges for PCI DSS, PCI SSF, SOC 2, CIS Controls 8.1, NIST CSF, GDPR, CCPA, PIPEDA, EU-US DPF and RH-ISAC; there is no VPAT, ACR, WCAG or Section 508 entry among them. The fifteen contract documents at partech.com/terms-and-conditions/ contain no accessibility warranty or conformance representation. cdn.parpos.com/Documentation.html, which indexes the entire first-party PDF library (release notes, admin guides, PAR Pay guides, system requirements, report guides), lists no accessibility guide and no kiosk configuration guide at all. Left unknown rather than no: a trust center index does not assert its own completeness, PAR's self-order kiosk documentation is not public, and a tactile/audio non-visual access mode could exist undocumented.

commercial-dual-pricing-compliant differentiator

The Admin Portal guide documents a "Non-Cash Adjustment" surcharge style: "Allows the restaurant to take the interchange fee which it has to give to the processors for a credit card payment from the guest. If the guest pays by cash, they do not have to pay the interchange fee. If the guest pays through credit card, the interchange fee is added to the bill amount," configurable as Fixed or Percentage Per Order/Item and itemized as a "Surcharges" line on the order. Shortfall: no documented automatic debit/prepaid-card exclusion and no documented receipt/menu-board disclosure requirement — the card-network compliance mechanics themselves are not spelled out. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified