UrbanPiper

menu-pricing-nested-modifiers

REPLACES a placeholder rationale that said nesting depth, min/max counts and forced selection "are not documented". Depth and the forced flag are documented; the counts are not. Nesting is stated as a supported feature with its depth named in the label: the Zomato, Swiggy and Keeta feature matrices all carry "Nested Option Group (L2) -- Manage options within options for maximum flexibility." Forced selection is the documented distinction between the two group types -- "Add-ons: Optional modifications such as extra onion or extra chicken" versus "Variants: Mandatory selections that you want an end user to make while buying an item. For example, size is a mandatory selection... it has to be one of regular, medium, or large." SHORTFALL on both remaining limbs: the documented nesting is L2, which is two levels and not the three this claim requires, and no min/max selection count appears anywhere in the modifier documentation -- the only per-modifier field the article edits is "the default sales price". https://help.urbanpiper.com/business-manager/creating-a-menu/adding-modifier-groups-and-modifiers · retrieved 2026-08-31

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

The full menu-push payload schema gives an option exactly one scalar price field — 'price (float): The option price specific to the platform' — with no per-parent or per-size override structure; an option attaches to its parents only via opt_grp_ref_ids. The menu architecture page (downstream/menu/architecture.md) models size as an option group ('Size' holding 'Personal' and 'Medium' options) whose options carry nested option groups, so pricing the same topping differently per size means creating it again as a separate ref_id under each size branch — duplication, which the claim excludes. The Atlas help article on modifiers likewise shows a single 'default sales price' per modifier. Item prices can vary store-wise, but no price matrix by parent item and size exists in the data model. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-08-04

menu-pricing-fractional-placement differentiator

Documented absence in the data model, not silence. The Add/Update Menu endpoint defines the whole menu as six object types -- 'A menu is considered to comprise of the following objects: Categories, Items, Item Option/Modifier Groups, Item Options/Modifiers, Taxes, Charges' -- and then enumerates every attribute of each. The Option object's complete field list is ref_id, ref_title, title, description, price, food_type, sold_at_store, available, sort_order, images/img_url, weight, translations, opt_grp_ref_ids, nested_opt_grps, key_value_groups, recommended and code. There is no placement, position, section, half, portion or fraction attribute anywhere in it, and no per-section price; an option carries exactly one scalar price. The Option Group object likewise offers only min_selectable, max_selectable, multi_options_enabled, display_inline, active and sort_order -- quantity constraints, not geometry. The merchant-side Atlas modifier article (help.urbanpiper.com/business-manager/creating-a-menu/adding-modifier-groups-and-modifiers) matches: modifier groups are typed only as 'Add-ons' or 'Variants' and the only price field it edits is 'the default sales price'. A pizza half cannot be expressed, so it cannot be priced. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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

Entailed by the same schema enumeration that refutes fractional placement, and independently by the absence of any pricing-rule object. The Add/Update Menu endpoint states the menu comprises exactly Categories, Items, Item Option/Modifier Groups, Item Options/Modifiers, Taxes and Charges, and enumerates every attribute of each. Nothing in that model represents a portion of an item, so there is no pair of halves to price; and nothing in it represents a calculation rule -- prices are literal floats on items (price, external_price, markup_price, platform_pricing) and on options (price), with no highest-half, averaging or fractional-topping selector, and no configuration surface for one. The Atlas menu and modifier help articles (help.urbanpiper.com/business-manager/creating-a-menu/*) show the same: sections, items, add-on and variant modifier groups, and a single default sales price per modifier. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

menu-pricing-topping-quantity-tiers

The complete menu-push schema enumerates every field on option groups and options: groups are typed only as variants or add-ons, and options carry ref_id, title, price, availability, sort_order and nested groups. No tier construct (light/regular/extra/double) and no per-tier price multiplier exists anywhere in the model. Order payloads and the Option-wise Order Transactions Report do carry an option quantity, but that is repeat-selection counting — the mechanism the claim explicitly distinguishes from tiering. Tiers can only be faked as separate options, each with its own flat price. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-08-04

menu-pricing-size-style-matrix differentiator

The menu architecture page documents exactly the size x crust case as a nested structure: 'Inside the Subcategory "Veg Pizza", the item - "Spiced Paneer" has an Option Group - "Size". This Option Group has 2 Options - "Personal" and "Medium". Each one of the Options has a different Nested Option Group called - "Base". Each Nested Option group has a Nested Option called - "San Francisco Style Crust".' Because each size option owns a distinct nested group, the crust options under each size can be given different prices, so a per-combination price is reachable. SHORTFALL: it is not a grid and there is no per-cell override of the item base price. In the menu-push schema (api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md) an item has one price per store/platform and every option has one scalar price, so a combination price is the sum of item price plus option price plus nested option price; there is no two-axis price table and no cell that overrides the base. Differing a crust price by size requires duplicating the crust as a separate ref_id under each size branch -- the same duplication already recorded against menu-pricing-modifier-price-by-parent-size. https://api-docs.urbanpiper.com/downstream/menu/architecture · retrieved 2026-09-01

menu-pricing-included-allowance differentiator

The Option Group object's documented attributes are ref_id, ref_title, title, description, min_selectable, max_selectable, multi_options_enabled, display_inline, active, sort_order, item_ref_ids, opt_grp_ref_ids, translations and the clear_* flags. The two count fields are constraints, not allowances: 'min_selectable (integer): The minimum number of options belonging to this group, that need to be selected when placing an order. Defaults to 0' and 'max_selectable (integer): The maximum number of options belonging to this group, that can be selected when placing an order. Defaults to -1'. There is no free-quantity, included-count, overage-price or substitution-credit attribute on the group, on the option, or on the item, and no rule object anywhere in the model to carry one -- the endpoint defines the whole menu as Categories, Items, Option Groups, Options, Taxes and Charges. An option's price is a single scalar that applies to every selection, so 'three toppings included, charge for the fourth' cannot be expressed; the nearest construct is a separate zero-priced group capped at three, which is a modelling workaround, not the capability. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

menu-pricing-combos

Construction is reachable but the automatic half of the claim is absent. In the menu-push schema an item can carry a zero base price with option groups whose options each carry their own price -- the worked payload does exactly this for 'Chicken BBQ Pizza' (price 0) with option group 'Choose Your Pizza' -- so a meal with swappable components at a price delta is expressible, and aggregator constraint pages assume combos exist as items ('Description is mandatory for items with keywords such as meals, platter, combo, box, thalis'). SHORTFALL, two parts. First, the endpoint defines the menu as exactly Categories, Items, Option Groups, Options, Taxes and Charges: there is no combo, bundle or meal-deal object, so a combo is only a hand-built item. Second, nothing in the model or in the order path detects eligible a-la-carte lines and converts them to a combo price -- UrbanPiper does not own the aggregator cart, and its own Meraki promotion engine offers only fixed-amount and percentage discounts and Buy-X-Get-Y (help.urbanpiper.com/direct-ordering/configuring-coupons), which discount qualifying items rather than substituting a combo. The Foodics setup guide is blunter still for that POS: 'In the group section for UrbanPiper, avoid using the subgroup or combos option as they are not supported.' https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

menu-pricing-upsell-prompts differentiator

Re-examined 2026-09-02. Independently re-grepped both complete first-party doc sets retrieved 2026-09-01 -- all 116 pages of help.urbanpiper.com and all 87 of api-docs.urbanpiper.com: 'upsell' and 'cross-sell' return ZERO hits on either host, and the only merchandising construct is the menu-push item attribute `recommended` (api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu), 'Indicates whether this item is a special/recommended item. Enhances the discoverability of items on merchant's website/apps or aggregator listing' -- a listing flag, not a prompt fired during ordering, and several aggregator-constraint pages state it is 'NOT supported' at all (Amazon, Careem, Jahez). On the attach-rate limb the Data & Reports section lists order transactions, order status transitions, item-wise, items summary, option-wise, menu snapshot and store action, none of which reports prompt impressions. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. The ordering surfaces where such a prompt would fire are the aggregators' own apps and the Meraki storefront, and Meraki's cart/checkout merchandising configuration is documented nowhere -- the Direct Ordering section covers domain, gateway, maps, banners, SMS mask, coupons and campaigns only. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: no readable page addresses configurable per-channel suggestion prompts or reports on them.

menu-pricing-86-propagation

One 86 action does propagate outward from a single control, and the propagation latency is stated for one platform. From Prime Order Tracker's Stock Control an operator toggles an item or a modifier and saves "to switch off the particular item or modifier on the aggregator's UI"; Keeta's article gives the latency plainly -- "Updates are real-time. Changes take effect immediately on Keeta" and "Out-of-stock is effective immediately when triggered." SHORTFALL is the claim's enumeration of destinations. The documented propagation reaches connected marketplaces; nothing documents an 86 reaching a KDS, a kiosk, or the vendor's own first-party ordering channel (Meraki). CORRECTED WITHIN THIS SESSION: an earlier draft of this note said Meraki has no article in the help centre, which was false and was an artefact of reading only page 0 of a paginated llms-full.txt. Meraki has eight articles -- getting started, custom domain, payment gateway, Google Maps, banner images, SMS mask ID, coupons and campaigns -- and none of them mentions item availability, stock or 86 propagation to the Meraki storefront, so the shortfall stands on a read of the actual articles rather than on their supposed absence. Latency is also documented for only one of the four marketplaces, and the general figure that IS published applies to menu publishes rather than 86s: "Menu updates typically take up to 5-10 minutes to appear on the UI." https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

menu-pricing-countdown-auto-86 differentiator

Scheduled auto-restore is documented, the countdown is not. The Prime app inventory flow ends with 'Step 6: Set Snooze Duration -- Return to the inventory section and click on snooze. Choose a time period to turn the item off, either indefinitely or for a specific duration. For a custom duration, set a date, click OK, and choose a time', and 'The items and modifiers will be snoozed until the selected date and time', with the same flow available for modifiers. SHORTFALL: there is no par count that depletes on sale. The item attribute the schema offers is `current_stock`, documented only as 'The stock of the item at the outlet. If the item is never supposed to go out of stock, set this to -1' (api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md) -- a value the integrating POS pushes, with no documented decrement on order and no documented auto-86 at zero. Availability is otherwise an explicit on/off action: 'Using this API an item or option can be toggled off if unavailable and toggled on when available. However, if you turn off an item/option and do not explicitly turn it on, the item/option will continue to stay out of stock on all the aggregator platforms' (downstream/availability/item-option). Restore is also channel-dependent -- the Keeta guide states 'Auto stock-in by Keeta is not supported. Items do not automatically restock at the start of the day or at store closing time.' https://help.urbanpiper.com/store-manager/prime-app/86ing-an-item-or-modifier · retrieved 2026-09-01

menu-pricing-dayparting

Time-based menu availability is a first-class object with its own app. Schedules are created under All Apps > Schedules with "daily, weekdays, weekends, or custom timings", noting "timings should be in multiple of 30 minutes", and are then attached in Catalog > Categories via "Associate Category Timing" -- the worked examples being "a Breakfast-only category or a Chinese menu that is available only during dinner hours". A second schedule type covers location operating hours and is associated to a list of locations. SHORTFALL on two of the claim's three limbs. The unit of scheduling is the CATEGORY, not the item and not the price: no article schedules an individual item or a price change, and inheritance is explicitly absent -- "If there are any subcategories under the parent category, you need to assign timings for each subcategory as well." And no documentation states that schedule times are interpreted in the location's own timezone, which for a platform marketed across 14-plus countries is a real gap rather than a pedantic one. https://help.urbanpiper.com/business-manager/setting-up-schedules-for-locations · retrieved 2026-08-31

menu-pricing-channel-price-books

Two documented price axes, neither of them the one this claim names, and no markup engine. Fulfilment-mode pricing exists -- "Can an Item have different pricing for different Fulfilment Modes? Yes. Some DSPs allow different pricing for items based on the selected fulfilment mode", with a worked table pricing Pizza Margherita at $10.00 for delivery and $9.00 for pickup -- and location pricing exists ("Location-Based Pricing -- Apply different prices for different locations"). SHORTFALL: per-CHANNEL price books are documented only as a facility of the connected POS, not of Atlas -- the Foodics article "Enabling Price Tags on Foodics - Aggregator-Specific Pricing" describes assigning "different prices for the same product based on the delivery channel, without duplicating the item... between channels such as Talabat, Careem", configured in the Foodics console. And no percentage-markup rule exists in any documentation: every documented price is entered per item. Fulfilment-mode pricing is also conditional on the marketplace -- "Support for fulfilment mode-specific pricing varies by DSP." https://help.urbanpiper.com/business-manager/creating-a-menu/understanding-fulfilment-mode-for-an-item · retrieved 2026-08-31

menu-pricing-dual-pricing differentiator

The menu-push schema enumerates every price an item can hold and all four are channel prices, not tender prices: `price` (the base, used for Meraki web/apps), `external_price` ('The aggregator online price of the item at the store for aggregator platforms'), `markup_price` ('For promotional purposes, the merchant might desire to show an original higher price alongside the current price... appear as struck-out') and `platform_pricing` (a per-aggregator price list). Options carry one scalar `price`. Nothing keys a price to the tender the guest uses. The phrase 'Cash Discount' does appear once in the corpus, in the Meraki coupon documentation, and it is a different thing: 'Cash Discount -- Applies a fixed amount discount on the order subtotal... cannot be applied to specific items -- it apply to the total bill value before taxes and delivery' (help.urbanpiper.com/direct-ordering/configuring-coupons), a flat-value coupon, not a card-price/cash-price pair. Consistent with the record's existing payments-processor-choice finding that UrbanPiper takes no processing position -- Meraki payments run through the merchant's own third-party gateway -- so there is no card price for a base price to be set to, and no receipt on which two totals could print. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

menu-pricing-versioning-effective-dates differentiator

Staging and preview are documented; rollback is not. A menu change can be held as a "Scheduled Publish... used to update the menu at a later point in the future", where the operator selects locations and platforms, the internal validation runs, and a date and time are chosen before submitting. Preview is separate and explicit: "select the location and platform whose menu you want to preview. Our internal verification engine runs checks on your menu. If there are no errors or warnings, the menu is ready to publish." A pending schedule can be withdrawn -- "You'll see a Cancel Scheduled Publish button instead in that case." SHORTFALL, and it is the claim's last limb: everything documented happens BEFORE the menu goes live. No prior menu version is retained, no version list appears in any article, and no rollback after publish is documented -- the only documented way back is to change the menu again and republish. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

menu-pricing-franchise-hierarchy differentiator

The central template and the field-level override list are both documented explicitly. 'In our system, the menu is handled in a federated structure. For each of the menu entities, a master record is maintained and then for each store, references are set to the master menu entities. The master menu can be considered to be the universal set of all menu entities available across all stores... NOTE: At present, categories and option groups are maintained only at the master level, since there aren't many scenarios where the metadata for these entities would vary between stores. For an item, the metadata that varies between stores are: price, current_stock, sort_order, recommended and availability. And for an item option, this can be price and availability.' The architecture page adds that the same item ID must be reused across every store ('the same item should be used based on the availability... the item should not be created again and again for different stores'). Publishing is a one-to-many push: 'Select the locations you want to publish to. Select the platforms you want to publish to' (help.urbanpiper.com/business-manager/publishing-your-menu), on demand or scheduled to a future date and time. SHORTFALL: the override set is a platform constant, not brand-configurable governance. A corporate operator cannot choose which attributes a given location may or may not change -- categories and option groups are simply not store-varying for anyone, and every store may vary exactly price, stock, sort order, recommended and availability. No per-brand, per-field or per-location permission surface over menu attributes is documented on either host; Atlas roles gate who may edit the catalogue at all, not which fields a location may override. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

menu-pricing-allergen-nutrition

Nutrition publishes and allergens do not. The Zomato and Swiggy menu matrices both carry "Nutritional Info -- Display nutritional information for your products", so per-item nutrition values are stored in the catalog and pushed to the marketplace with the menu. SHORTFALL on the other two limbs, both absences in a set of documentation that is otherwise exhaustive about item attributes: no allergen field, flag or tag is documented anywhere -- the only item tag the help centre describes is the India-specific "packaged goods" tax tag -- and there is no recipe or bill-of-materials construct in the product at all, so nutrition cannot be derived from components and must be entered by hand. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

menu-pricing-recipe-linkage differentiator

REPLACES an unknown that rested on doc-host silence; the marketing host refutes the premise that no ingredient-level inventory exists. Prime holds stock at the INGREDIENT level and an ingredient's level drives the linked menu item: 'Now you can set a minimum stock level for your ingredients in the stock levels module', configured by navigating to 'the Stock levels tab within each of the ingredient's settings' to set their 'Critical Stock Level', whereupon 'you will get a notification and your item status will be updated'. Depletion is transactional -- 'we have revised our stock deductions to occur only after you acknowledge an order, rather than solely after order placement' -- and the Prime Manager role 'handle[s] inventory transactions' (help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas, retrieved 2026-09-01). An ingredient threshold cannot change an item's status without an item-to-ingredient mapping, so the first limb is met in substance. SHORTFALL, and it is most of the claim: no recipe or bill-of-materials structure, and no per-item component QUANTITY, is documented on any readable first-party surface -- 'recipe', 'bill of material' and 'food cost' return zero hits across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages retrieved 2026-09-01, and the menu-push schema's complete object enumeration ('A menu is considered to comprise of the following objects: Categories, Items, Item Option/Modifier Groups, Item Options/Modifiers, Taxes, Charges') carries no component object; modifier-level linkage is therefore unevidenced. And there is NO COST FIELD ANYWHERE -- no ingredient cost, no item cost, no margin, and no costing report among the eight documented -- so the claim's second limb, item-level theoretical food cost, is wholly unevidenced. The one vendor page that appears to describe recipe setup, support.urbanpiper.com/support/solutions/articles/12000092223-preparing-recipe-at-a-location, is on a DECOMMISSIONED host: probed 2026-09-02, every URL there including /robots.txt 301-redirects to itself in an infinite loop, so it could not be read and is NOT scored from -- and a search-engine summary of it is not a page I read. Grade D because the single readable source is a product-update post on the marketing host; neither documentation host mentions ingredients at all. https://www.urbanpiper.com/blog/january-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-02

menu-pricing-3p-menu-push

The certified-direct-integration half is met: menus publish from Atlas to Zomato, Swiggy, Uber Eats and Keeta over the vendor's own integrations, each with its own authorisation flow, and the published entities are enumerated per platform ("Product names and descriptions / Prices, taxes, and charges / Modifier groups, options, and variants / Product images / Product availability"). Errors are surfaced BEFORE publish: "Our internal verification engine runs checks on your menu. If there are no errors or warnings, the menu is ready to publish", and the scheduled-publish flow runs the same validation. SHORTFALL: the claim asks for PER-ITEM sync status and rejection errors, and after a publish the only documented feedback is elapsed time -- "Menu updates typically take up to 5-10 minutes to appear on the UI." No per-item status list or rejection report is documented; when a publish silently fails, the troubleshooting article sends the operator to a log line and then to the marketplace's own point of contact. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

menu-pricing-dynamic-pricing

The channel axis of the claim is met with dedicated schema fields. `price` is the base used for Meraki web/apps, `external_price` is 'The aggregator online price of the item at the store for aggregator platforms', and `platform_pricing` is an explicit per-aggregator price array, with precedence documented: 'platform_pricing only ever sets or updates the price for the platforms explicitly listed in it... Platform with no platform-specific price configured: that platform falls back to the item's base price.' Fulfilment mode is a second axis -- the Atlas help article on fulfilment modes gives the worked example of Pizza Margherita at $10.00 delivery and $9.00 pickup, noting 'Support for fulfilment mode-specific pricing varies by DSP'. SHORTFALL on the rest of the claim: every one of these is a value an operator or POS sets and the platform then applies, not a rule the platform evaluates. Nothing in the menu model varies price by time of day, by day of week or by demand -- schedules exist in the system but attach to menus, sections and categories to control availability, not price -- and no floor, ceiling, minimum or maximum price attribute exists on the item, the option or anywhere else in the schema, so there are no guardrails to configure. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

payments-processor-choice differentiator

This is the strongest form of the claim: the operator brings their own gateway account and UrbanPiper takes no processing position at all. "You can configure payment gateways on Meraki to enable online payments for your customers. Multiple payment methods, such as credit/debit cards, UPI, wallets, and COD, can be supported depending on the gateway." Configuration is Atlas > Meraki > Payments > Add Gateway, where the operator selects from a list and pastes credentials they obtain themselves -- "Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard." The supported list is published as a region matrix of twelve gateways across India, MENA, KSA, UK, LATAM and USCAN: RAZORPAY, PAYMENTOS, PHONEPE, INSTAMOJO, PAYSTACK, PAYTABS, STRIPE, PAYTMBLINK, PAYTABS_V2, PAYULATINAMERICA, MERCADOPAGO and FREEDOMPAY. Scope stated plainly: this governs the vendor's own first-party ordering channel (Meraki), which is the only channel where UrbanPiper handles a payment at all -- on marketplace orders the marketplace collects. No in-house processing product exists anywhere in the documentation. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-08-31

payments-published-rates differentiator

The vendor does not sell card processing, so the question of publishing a rate does not arise. On its only first-party ordering channel, Meraki, payment acceptance is delegated: 'Click Add Gateway. Select your preferred payment gateway from the list (e.g., Stripe, Razorpay, PayU, Paytm, etc.)... Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard.' The supported set is published as a twelve-provider region matrix (RAZORPAY, PAYMENTOS, PHONEPE, INSTAMOJO, PAYSTACK, PAYTABS, STRIPE, PAYTMBLINK, PAYTABS_V2, PAYULATINAMERICA, MERCADOPAGO, FREEDOMPAY across India, MENA, KSA, UK, LATAM and USCAN). The rate is therefore a matter between the merchant and Stripe or Razorpay, and no flat rate, interchange-plus markup or per-transaction card fee appears anywhere in either documentation host. This is the same evidence on which this record already scores payments-processor-choice yes: UrbanPiper takes no processing position, and on marketplace orders the marketplace collects. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-01

payments-dual-pricing differentiator

The menu-push schema enumerates every price an item may hold: `price` (base, used for Meraki), `external_price` (aggregator price), `markup_price` (a struck-out promotional higher price) and `platform_pricing` (per-aggregator price array). Every one is keyed to a channel; none is keyed to a tender, and options carry a single scalar `price`. There is consequently no second price for the system to store, let alone print. On the receipt limb, UrbanPiper does not process cards -- Meraki payments run through the merchant's own gateway account (help.urbanpiper.com/direct-ordering/configuring-payment-gateway) -- and the order payload it relays records how the guest already paid rather than driving a tender: 'payment (array[object]): A list of payment objects... option: The payment option used. Can be one of: prepaid, payment_gateway, cash, card_on_delivery, paytm, wallet_credit, simpl, aggregator.' Note that Meraki's 'Cash Discount' coupon is not this capability: it is 'a fixed amount discount on the order subtotal', not item-specific (help.urbanpiper.com/direct-ordering/configuring-coupons). https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

payments-surcharge-guardrails differentiator

Re-examined 2026-09-02. Re-grepped both complete first-party doc sets retrieved 2026-09-01 (116 help.urbanpiper.com pages, 87 api-docs.urbanpiper.com pages): every 'Surcharge' occurrence is a pass-through CHARGE TITLE, not an engine. It is one of the enumerated titles in the relayed order payload -- 'Restaurant Packaging Charge, Packaging Charge, Delivery Charge, Service Charge, Driver Tip, Surcharge, Deposit Charge, Other Charges' (api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay) -- it recurs in the per-aggregator constraint pages as an amount Zomato, Swiggy, Talabat, Careem and Deliveroo may include, and the Lightspeed K-Series guide has the merchant create a matching charge item in their own POS back office. Nothing anywhere mentions BIN or card product-code detection, debit or prepaid exclusion, or a network percentage cap. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The merchant agreement is silent on cards and PCI and says only 'You acknowledge and agree that You shall not use the Services to transmit or process any payments on behalf of a third-party' (s2.5) -- a restriction on the MERCHANT, not a statement that the vendor operates no surcharging; the DPA names no payments compliance at all. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. The one Atlas payments article on a permitted host, help.urbanpiper.com/direct-ordering/configuring-payment-gateway, is a how-to (Add Gateway, paste credentials, choose methods), not the whole configurable surface, so its silence cannot establish that no per-location surcharge toggle exists. Unresolved.

payments-emv-nfc

Replaces an inference-only rationale with the vendor's own hardware document. The page opens 'Please find below the minimum specification requirements for buying hardware to use UrbanPiper products' -- the merchant buys the hardware, the vendor ships none -- and enumerates the entire supported surface: Android handhelds, phones, tablets and terminals by RAM/storage/CPU/screen/OS; iOS phones and tablets; receipt printers by command mode (ESC/POS, STAR LINE, STAR GRAPHIC), interface (USB, Bluetooth, Ethernet, parallel, serial) and paper width; and Chrome on a laptop. It closes with the completeness statement 'Any device that adheres to the Minimum Specification Requirements (MSR) will work fine with our products.' No card reader, PIN pad or payment terminal appears anywhere in it, and no EMV or NFC certification, Apple Pay or Google Pay reference occurs anywhere on either documentation host. This matches the payment model: UrbanPiper takes no processing position -- Meraki payments go through the merchant's own gateway account, and marketplace orders are collected by the marketplace -- so there is no first-party terminal line for this claim to be true of. https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-09-01

payments-softpos-tap-to-pay differentiator

Re-examined 2026-09-02, and REWRITTEN to remove material the previous rationale repeated from changelog.urbanpiper.com: that host is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) which refuses us, so its content may not be read OR restated here, even in an inference. What stands on permitted surfaces: 'tap to pay', 'contactless' and 'NFC' return ZERO hits across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages retrieved 2026-09-01. The earlier asserted `no` was correctly withdrawn -- its evidence, help.urbanpiper.com/basics/compatible-hardware, is a minimum-spec page for devices the merchant BUYS ('Please find below the minimum specification requirements for buying hardware to use UrbanPiper products') that closes open-endedly ('Any device that adheres to the Minimum Specification Requirements (MSR) will work fine with our products'); it enumerates Android and iOS device classes and ESC-POS/Star printers and never speaks to payment acceptance at all. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. None of /hub, /meraki, /orderline or /integrations names tap-to-pay, a card reader or a terminal, and /integrations has no payments category; a marketing feature grid is grade D and bounds nothing. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: no readable page states whether Prime can take a contactless card on the phone itself.

payments-pay-at-table

The first limb fails outright: UrbanPiper ships no handheld. Its hardware page states 'Please find below the minimum specification requirements for buying hardware to use UrbanPiper products' and lists Handheld, Phone, Tablet and Terminal purely as merchant-purchased device classes with RAM, storage, CPU, screen and OS minima, adding 'Any device that adheres to the Minimum Specification Requirements (MSR) will work fine with our products' -- a specification, not a product. No card reader, PIN pad or EMV/NFC capability appears in it. The second limb fails too: UrbanPiper processes no cards, since Meraki payment acceptance is the merchant's own gateway account and marketplace orders are collected by the marketplace. Prime does have a dine-in surface -- 'Captain: Perfect for your front-of-house team. Captains take customer orders, especially for dine-in. Please note, they cannot settle bills; that's handled by Cashiers' (help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas) -- but nothing in it accepts a card at the table, and no tip prompt or check splitting is documented on either host. https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-09-01

payments-qr-guest-pay differentiator

Re-examined 2026-09-02. Re-grepped both complete first-party doc sets retrieved 2026-09-01: 'QR' returns no capability hit on either host -- in help.urbanpiper.com the matches are inside image URLs, and the only barcode on a printed bill belongs to a different feature, the Prime web Scan and Pack workflow, which generates 'a KOT and a barcoded bill' so packers can verify contents against the order, not so a guest can pay. Dine-in is real in Prime -- 'Captains take customer orders, especially for dine-in. Please note, they cannot settle bills; that's handled by Cashiers', who 'manage operational shifts using registers, process bills, and complete settlements' (help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas, re-read 2026-09-02) -- but the MECHANISM by which a cashier settles is documented on no permitted host, so nothing states whether a guest-facing payment link or QR can close that bill. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. help.urbanpiper.com/direct-ordering/configuring-payment-gateway covers gateway credentials and which methods to enable and is a how-to, not an exhaustive settings enumeration. Unresolved: the Prime billing screen, where this would live, is unpublished rather than shown to lack it.

payments-tip-adjust

Re-examined 2026-09-02 and REWRITTEN to remove content the previous rationale quoted from changelog.urbanpiper.com; that host's robots.txt is a named allowlist that refuses us, so its material may not be read or restated, including the Meraki tipping and POS payment-settings items it carries. On permitted surfaces: 'tip' occurs in only two shapes across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages retrieved 2026-09-01 -- the aggregator charge 'Driver Tip', enumerated among the relayed order's charge titles and listed as supported for Zomato, Swiggy, Talabat, Careem, Deliveroo and Just Eat, and prose headings ('Additional Tips', 'Final Tips') in help articles. Neither is a staff gratuity captured at settlement. The enumeration the earlier `no` rested on -- the order-relay payment array (prepaid, payment_gateway, cash, card_on_delivery, paytm, wallet_credit, simpl, aggregator) -- describes an order UrbanPiper RECEIVES, not its own settlement surface, so it cannot ground a no. Nothing on any permitted host documents a pre-authorisation, a later capture, a batch or adjust window, an on-device tip prompt, or a manager screen listing unadjusted tips. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: the Prime cashier settlement screen is documented on no host we may read.

payments-tip-pooling differentiator

Re-examined 2026-09-02. Re-grepped both complete first-party doc sets retrieved 2026-09-01 (116 help.urbanpiper.com pages, 87 api-docs.urbanpiper.com pages). 'Tip' occurs only as the aggregator charge 'Driver Tip' -- enumerated among the relayed order's charge titles alongside Packaging, Delivery, Service Charge and Surcharge (api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay) and listed as supported for Zomato, Swiggy, Talabat, Careem, Deliveroo and Just Eat -- which is a gratuity for the delivery rider, plus prose headings in help articles. No tip to a member of staff is captured anywhere, so there is no allocation to distribute by hours, sales, role percentage or points. The payroll side has no documented surface to enumerate at all: the help centre's sections are Basics, Business Manager, Store Manager, POS Integrations, Ordering Channels, Data & Reports and Direct Ordering, with no labour, scheduling, shift-earnings or payroll section, and the eight documented reports are order- and menu-shaped. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Prime does carry shift-bearing roles -- 'Cashiers manage operational shifts using registers, process bills, and complete settlements' -- and that register/shift screen is published on no permitted host, which is precisely where an allocation would appear. Unresolved rather than no, because the surface is unpublished rather than shown to be empty.

payments-offline-store-and-forward differentiator

Re-examined 2026-09-02 and REWRITTEN to remove content the previous rationale took from changelog.urbanpiper.com, a named-allowlist host that refuses us. On permitted surfaces: 'offline' returns eight hits in help.urbanpiper.com and three in api-docs.urbanpiper.com (re-grepped 2026-09-02) and NOT ONE concerns payment capture -- they are a location taken 'offline' from a delivery platform, a printer being offline, aggregator-side mapping done 'offline' with the Zomato or Swiggy team, and API error strings ('Your outlet is currently offline due to high number of rejections'). No store-and-forward mode, offline queue, deferred capture, per-transaction limit or cumulative offline limit is documented anywhere on either host. The page the earlier asserted `no` cited, help.urbanpiper.com/direct-ordering/configuring-payment-gateway, is a how-to for connecting a gateway to the Meraki web storefront and enumerates providers, never offline behaviour, so it cannot ground the verdict. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Two legacy first-party support hosts are also unreadable: support.urbanpiper.com 301-redirects every URL to itself in an infinite loop (probed 2026-09-02, /robots.txt included, so no policy is even obtainable there), and urbanpiper.helpjuice.com returns HTTP 402. Unresolved: the Prime register and settlement surface, where an offline queue would live, is published on no host we may read.

payments-offline-decline-liability differentiator

Re-examined 2026-09-02 and REWRITTEN to remove content the previous rationale took from changelog.urbanpiper.com, which refuses us by named allowlist. Nothing on either permitted documentation host states who bears the loss when a stored offline transaction declines on reconnect, and nothing documents a post-reconnect report of failed offline payments: 'offline' never appears in a payment-capture sense across the 116 help.urbanpiper.com pages or the 87 api-docs.urbanpiper.com pages retrieved 2026-09-01 (re-grepped 2026-09-02), and no liability, indemnity or loss-allocation language of that kind appears in www.urbanpiper.com/legal/merchant-agreement, which is silent on cards, chargebacks and PCI and whose only payment terms concern the merchant's own fees to UrbanPiper ('all Fees are non-refundable'). Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Two legacy first-party support hosts are also unreadable: support.urbanpiper.com 301-redirects every URL to itself in an infinite loop (probed 2026-09-02, /robots.txt included, so no policy is even obtainable there), and urbanpiper.helpjuice.com returns HTTP 402. So the premise the earlier `no` rested on -- that there is no offline card capture and therefore no decline to allocate -- cannot be tested on any readable surface, and its converse is not established either. Unresolved.

payments-gift-cards

Re-examined 2026-09-02 against the complete first-party dumps retrieved 2026-09-01 -- all 116 pages of help.urbanpiper.com and all 87 of api-docs.urbanpiper.com, each host's llms.txt fully fetched and every listed page live. The string 'gift' occurs ZERO times in either corpus (re-grepped 2026-09-02). Adjacent constructs exist and are not gift cards: the Meraki payment-configuration article offers 'Wallets or Loyalty Points (if configured)' among the methods a merchant may enable; the campaign template variables include {{user_points}} ('the customer's current loyalty points balance') and {{user_wallet_balance}}; and the relayed order's wallet_credit option is documented in the reports guide as AGGREGATOR wallets ('e.g., Swiggy Money, Zomato Wallet'). None is a merchant-issued stored-value instrument with a balance redeemable across a group's locations. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. /meraki's grid names 'Loyalty Program', 'Customer Directory' and 'Payment Integrations' and no gift card; that grid is grade D marketing and not an enumeration. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: the Meraki loyalty/wallet feature has no reference article on either documentation host, so a stored-value product could sit inside it undocumented; the payment-methods list appears inside a step-by-step walkthrough, not a settings reference documented as the whole configurable surface.

payments-house-accounts

Re-examined 2026-09-02 against both complete first-party doc sets retrieved 2026-09-01 (116 help.urbanpiper.com pages, 87 api-docs.urbanpiper.com pages). 'House account', 'on account' and 'credit limit' return ZERO hits on either host. The two 'credit' constructs present are unrelated to a guest tab: wallet_credit as a relayed order payment option, described in the reports guide as aggregator wallet money ('Swiggy Money, Zomato Wallet'); and the merchant's own account with UrbanPiper via the Atlas Billing role, which 'provides oversight of all financial transactions and credit management in your Atlas account. Billing users can access detailed transaction records and invoices, and initiate credit purchases' (re-read 2026-09-02) -- the restaurant buying UrbanPiper credit, not a guest running a tab. The relayed order's payment enumeration (prepaid, payment_gateway, cash, card_on_delivery, paytm, wallet_credit, simpl, aggregator) contains no on-account tender, though 'simpl' is a third-party deferred-payment service used with the aggregator, not a merchant house account. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: Prime has a billing surface -- cashiers 'manage operational shifts using registers, process bills, and complete settlements' -- documented on no permitted host, so a per-customer running balance with a credit limit and statements cannot be excluded from what is published.

payments-split-tender

The multi-tender half is documented in the order schema and stated in as many words: 'payment (array[object]): A list of payment objects. A customer can use more than one mode of payment to pay for an order (commonly, seen in Meraki orders)', each object carrying 'amount (float): Amount paid through given payment option' and 'option (string): The payment option used. Can be one of: prepaid, payment_gateway, cash, card_on_delivery, paytm, wallet_credit, simpl, aggregator.' The array is unbounded, so no cap below eight ways is imposed. SHORTFALL on the splitting half: nothing splits a check. There is no seat, cover or guest-position concept anywhere in the order model, no even-share or by-item split function, and no split-check article on either documentation host -- the payment array records how a single order was paid for, not a division of one check among several payers. Prime does settle bills (cashiers 'process bills, and complete settlements') but that screen is undocumented, and it is amounts paid rather than a splitting engine that the API exposes. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay · retrieved 2026-09-01

payments-refund-void-controls

Re-examined 2026-09-02; I re-read help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas in full from the corpus retrieved 2026-09-01, and re-grepped 'refund' and 'void' across both hosts -- ONE refund hit in help (prose about a guest's refund request in the Scan and Pack article), one in api-docs (Ireland's refundable container deposit charge), and no 'void' hit that is a tender action at all. Role-based access is real and documented: Prime ships 'six standard roles, primarily for managing your in-store operations' plus custom roles that 'assign very specific permissions, giving you granular control over what each team member can do', and exactly one financial action is gated by role in as many words -- 'Captain... Please note, they cannot settle bills; that's handled by Cashiers', with cashiers who 'manage operational shifts using registers, process bills, and complete settlements'. Store operations also carry a per-user PIN, set in Atlas under Settings > Users > Edit access (help.urbanpiper.com/business-manager/user-access/how-to-reset-pin-for-store-operations), but that page treats it purely as a credential to reset, never as an approval prompt for a void or discount. NEITHER LIMB IS MET: no page on any permitted host states that voids, refunds, discounts or no-sales require a manager PIN or approval, and the Prime custom-role permission list is not itself published, so its contents cannot be inspected. On the audit limb the closest of the eight documented reports, the Store Action Report, logs store-platform actions (publish, enable, disable) rather than tender-level events with an approver identity. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: resolving this needs the Prime custom-role permission reference or the Prime billing screen, published on no host we may read.

payments-chargeback-tooling differentiator

Re-examined 2026-09-02 against both complete first-party doc sets retrieved 2026-09-01 (116 help.urbanpiper.com pages, 87 api-docs.urbanpiper.com pages): 'chargeback' and 'dispute' each return ZERO hits on both hosts. The nearest documented construct is a different thing -- the customer-complaints endpoint (api-docs.urbanpiper.com/downstream/api/endpoints/miscellaneous/customer-complaints) and the `complaints` field in the relayed order's extras, carrying marketplace guest complaints about an order, and the Atlas Support role over 'customer details, manage feedback, and analyze NPS'. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. www.urbanpiper.com/legal/merchant-agreement contains no chargeback, dispute or card-data terms at all (its only payment clauses are the merchant's own non-refundable fees), and the DPA addresses personal data, not cardholder data. /hub's grid names 'Payment Reconciliation', which in this product means reconciling aggregator payouts -- the reports frame the money side that way ('for payment reconciliation, especially with aggregator-specific wallet systems') -- not card-network disputes. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: the Atlas payments area is documented only by a how-to (add gateway, paste credentials, choose methods), not an enumeration of the whole payments surface, so a read-only dispute list fed from a connected gateway cannot be excluded from what is published.

payments-card-on-file differentiator

Re-examined 2026-09-02 against both complete first-party doc sets retrieved 2026-09-01 (116 help.urbanpiper.com pages, 87 api-docs.urbanpiper.com pages): 'card on file', 'saved card', 'token' and 'tokenised/tokenized' return ZERO hits on either host (re-grepped 2026-09-02). UrbanPiper does not itself hold card data on the documented path: on Meraki the merchant connects THEIR OWN gateway account -- Stripe, Razorpay, PayU, Paytm and eight more across a published region matrix -- pasting credentials obtained from that provider (help.urbanpiper.com/direct-ordering/configuring-payment-gateway), which is where a token vault would sit. In the relayed order the payment options are prepaid, payment_gateway, cash, card_on_delivery, paytm, wallet_credit, simpl and aggregator, none denoting a stored credential reused against a guest profile. Guest profiles do exist -- Meraki gives access to customer and order data, campaigns address customers by segment, and Atlas has a Support role over customer details. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The DPA states 'Personal data is encrypted at rest using AES-256... and encrypted in transit using TLS v1.2 or higher' but says nothing about cardholder data or tokenisation. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: no article documents the Meraki checkout, guest account or saved-payment-method screen at all, and no page states that repeat guests must re-enter card details -- the surface is undocumented, not documented as lacking one.

payments-payout-timing differentiator

The vendor never holds merchant funds, so it has no deposit schedule of its own to publish and nothing to advance. Meraki payments are taken by a gateway the merchant owns: 'Click Add Gateway. Select your preferred payment gateway from the list (e.g., Stripe, Razorpay, PayU, Paytm, etc.)... Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard' -- twelve providers across India, MENA, KSA, UK, LATAM and USCAN -- so settlement timing is set by Stripe or Razorpay under the merchant's own contract with them. Marketplace orders are collected and remitted by Zomato, Swiggy, Talabat and the rest under their own payout terms, which is why UrbanPiper's reports frame the money side as reconciliation (the order transactions report's wallet-credit field exists 'for payment reconciliation, especially with aggregator-specific wallet systems'). Nothing resembling a deposit schedule, settlement window, next-day funding or instant-payout product appears anywhere across the 116 help.urbanpiper.com pages or the 87 api-docs.urbanpiper.com pages retrieved 2026-09-01. The vendor's own billing direction runs the other way: the Atlas Billing role handles the restaurant's invoices and credit purchases from UrbanPiper. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-01

payments-multi-entity-routing differentiator

The per-location half is documented as a supported configuration: "You can configure gateways globally for all outlets, or per outlet if needed", so two outlets can settle through two different gateway accounts while both report into one Atlas tenant, and consolidated reporting across those locations exists in Central Report. SHORTFALL: everything downstream of the gateway is outside what the vendor documents. No article mentions bank accounts, MIDs, legal entities or split settlement; where the money lands is a property of the gateway account whose credentials were pasted in, and UrbanPiper documents neither a settlement destination nor a split-settlement construct of its own. The claim is satisfied in effect for a merchant willing to run one gateway account per entity, and is nowhere stated as a feature. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-08-31

payments-p2pe-pci4

Re-examined 2026-09-02. Across both complete first-party doc sets retrieved 2026-09-01 -- all 116 pages of help.urbanpiper.com and all 87 of api-docs.urbanpiper.com -- 'P2PE', 'PCI' and 'encryption' return no substantive hit; the only 'PCI' matches are table-cell artefacts inside the charge-attribute tables. Neither corpus holds a security, compliance, trust or certification page: the help centre's sections are Basics, Business Manager, Store Manager, POS Integrations, Ordering Channels, Data & Reports and Direct Ordering, and the API host's 'certification' is UrbanPiper's own POS-integration certification programme, nothing to do with PCI. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The closest thing to a trust page the vendor publishes is www.urbanpiper.com/legal/data-processing-agreement, which DOES enumerate technical measures -- 'Personal data is encrypted at rest using AES-256, applied at the storage layer across databases, object storage and backups' and 'encrypted in transit using TLS v1.2 or higher' -- and names NO PCI DSS, P2PE, ISO 27001 or SOC 2 attestation; the merchant agreement is likewise silent on cards and PCI. That is a personal-data measures list, not an enumeration of payments compliance, so it does not establish absence, and an AoC or P2PE listing is customarily furnished under NDA on request rather than published. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: no readable first-party page either publishes such an attestation or states that none exists.

delivery-driver-roster

UrbanPiper has no driver entity. The only rider representation in the published partner API is a per-order payload the POS sends to UrbanPiper: 'rider_data' with exactly 'rider_data.rider_name' (Rider contact name) and 'rider_data.rider_phone_number' (Rider contact phone number), plus a status enum (ASSIGNED / UNASSIGNED / AT-STORE / OUT-FOR-DELIVERY / RIDER-REACHED / DELIVERED / NO-RIDER-FOUND) that UrbanPiper relays onward -- 'Currently, Swiggy is the sole user of this feature.' There is no rider object to create, no clock-in/out, no assignment state held by UrbanPiper and no per-rider run history: riders are named per order and discarded. The staff model confirms it from the other side -- 'Prime offers 6 standard roles' (Captain, Online Order Processor, Online Order Supervisor, Cashier, Manager, Administrator) at help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas, none of them a driver. On aggregator orders rider assignment is the marketplace's: the Zomato matrix marks 'Dispatched (UrbanPiper -> Zomato)' unsupported while relaying Zomato's own rider statuses inward. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/self-delivery-rider-management/rider-status-updates · retrieved 2026-09-01

delivery-dispatch-board

Prime's Order Tracker is a real dispatch-adjacent board: orders move New -> Accept -> In Progress -> Food Ready -> Awaiting Pickup -> 'When picked up by the rider, the order moves to Dispatched. View dispatched orders under Dispatch Status', and the Filter option lets you 'view orders for a specific location, platform, or sort by delivery time or time left to deliver' -- i.e. undispatched orders and per-order elapsed/remaining time. SHORTFALL on the other two limbs: there is no driver availability view, because UrbanPiper holds no driver roster, and nothing anywhere batches 2+ orders into one run. Assignment belongs to the marketplace -- the Zomato capability matrix (help.urbanpiper.com/ordering-channels/zomato/manage-your-orders) marks 'Dispatched (UrbanPiper -> Zomato)' as NOT supported while 'Rider Status Updates' and 'Rider Reassignment' are inbound relays only, and for self-delivery the POS pushes rider identity to UrbanPiper rather than the reverse. https://help.urbanpiper.com/store-manager/prime-app/manage-orders-on-order-tracker · retrieved 2026-09-01

delivery-route-map differentiator

Re-examined 2026-09-02 against both complete first-party documentation sets retrieved 2026-09-01 -- all 116 pages of help.urbanpiper.com and all 87 of api-docs.urbanpiper.com, each enumerated by the host's own llms.txt. Mapping appears in exactly one place, help.urbanpiper.com/direct-ordering/google-maps, and it is CONSUMER-SIDE only: store-locator map, address autocomplete, pin drag, and 'a static map is displayed on the order confirmation page'; the required GCP APIs listed are Maps JavaScript, Places and Geocoding -- no Directions and no Distance Matrix, which is what a routing engine would need. Nothing in Prime app or Prime web (order tracker, print automations, 86ing, scan-and-pack) shows a dispatch map, and the partner API has no route, stop, sequence or waypoint object anywhere ('route' returns one incidental hit in api-docs, re-grepped 2026-09-02). Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. /hub's feature grid is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control -- no dispatch, driver assignment, route or map entry -- and /integrations shows four categories (POS Systems, Fulfilment, Delivery platforms, Online Ordering) naming logistics providers Dunzo, Adloggs, Nash and Careem Box. Both are marketing surfaces: a feature grid and an integrations directory bound nothing and cannot carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: no page states that multi-stop routing is unavailable, and whatever routing the logistics partners perform is documented on their hosts, not UrbanPiper's.

delivery-driver-tracking differentiator

Re-examined 2026-09-02. This cell was withdrawn to unknown on 2026-09-01 for a RETRIEVAL-PERMISSION reason, not a finding: the earlier `no` ('no live driver position reaches an UrbanPiper screen') was refuted, but the refutation was read from changelog.urbanpiper.com, whose robots.txt allows twelve named crawlers and disallows '*' at the root, so that page may not be fetched and its content may not carry a verdict here. I did not fetch it and I do not restate it. The prior `no` therefore cannot stand and the refutation cannot be used, which is exactly what unknown records. What I verified myself on the permitted host: api-docs.urbanpiper.com's Self-Delivery Rider Management section holds exactly two endpoints, and BOTH RUN OUTWARD. Rider Live Tracking (POST /ext/api/v1/generic/pos/rider-location/) takes order_id plus 'location.latitude -- latitude of the rider carrying the order' and is described as 'used to send live rider tracking updates to AGGREGATORS for self-delivery orders. Currently, it is exclusively utilized by Swiggy'; Rider Status Updates (POST /ext/api/v1/generic/pos/rider-status/) carries only rider_name and rider_phone_number with a fixed status list (ASSIGNED, UNASSIGNED, AT-STORE, OUT-FOR-DELIVERY, RIDER-REACHED, DELIVERED, NO-RIDER-FOUND). Inbound, api-docs.urbanpiper.com/downstream/order/order-rider-information says only 'We will send the rider details and the rider status update AS LONG AS THE AGGREGATOR SHARES THIS INFORMATION WITH US... they limit it to the name of the rider along with their phone number' -- no coordinates. So on permitted evidence UrbanPiper is a RELAY of a position captured elsewhere, there is no rider entity in the documented schema, and no driver-facing UrbanPiper app or dispatch screen is documented. That is not enough to score the claim either way. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. TO SETTLE THIS: find the capability documented on help.urbanpiper.com or api-docs.urbanpiper.com, which permit us.

delivery-zones-polygon differentiator

The store schema's zip_codes field carries the platform's deliverability rule verbatim: 'A set of Zip codes to which the store can deliver. NOTE: if this is set for even one store, the platform will only consider Zip codes on all stores for checking deliverability. The logic of delivery based on distance or an area polygon will not be considered. This applies for the merchant's own website and apps.' That names three mutually exclusive deliverability modes -- postcode list, distance, and area polygon -- so first-party delivery areas are not solely a radius or a ZIP list. Two caveats worth recording: the polygon EDITOR is not documented anywhere on either host (help.urbanpiper.com/direct-ordering/google-maps describes only the consumer-side radius check at store selection), and no drive-time isochrone is mentioned; the claim is satisfied by the polygon limb alone. https://api-docs.urbanpiper.com/downstream/api/endpoints/stores/add-update-stores · retrieved 2026-09-01

delivery-zone-pricing

The store object is the platform's full configuration surface for a location and it carries exactly one of each: 'min_order_value (float) -- Mininum amount for an online order to be accepted at this store' and 'min_delivery_time (integer) -- Minimum time (in seconds) required to deliver an order', both per store, not per area. Delivery fee is a Charge, and the Charges model is likewise zone-free: the API's menu/charges page says 'delivery charges are generally at the order level' and the sample menu payload titles one 'Delivery Charge' / 'Fixed Delivery Charge on order', while the Atlas guide (help.urbanpiper.com/business-manager/creating-a-menu/create-and-manage-charges) gives a charge three modes -- Item Quantity, Order Subtotal, Item Price -- and scopes it by pairing an Item Group with a LOCATION Group. SHORTFALL: the platform does have area-polygon/distance/zip deliverability (see delivery-zones-polygon) but no fee, minimum or promise time hangs off that area -- vary any of the three and you are varying it per store or per location group, not per zone, and nothing applies a zone-specific value from the validated customer address. https://api-docs.urbanpiper.com/downstream/api/endpoints/stores/add-update-stores · retrieved 2026-09-01

delivery-address-validation

Validation and geocoding are documented and mandatory: on the Meraki storefront 'Customers can search for their address using autocomplete' or 'drag a pin on the map to select their exact location', and the merchant must enable Maps JavaScript API, Places API and Geocoding API in their GCP project or 'Maps-related functions on your website will not work'. A serviceability test runs at the same moment -- 'When a customer searches for a location, the system checks if a store is available within the selected radius and assigns it.' SHORTFALL: the documented check is a store-radius assignment, and no page states the guest-facing outcome when the address falls outside it -- no rejection message, no out-of-zone flag, no checkout behaviour is described on either host. Related evidence that out-of-radius is at least a recognised state, though on the aggregator leg rather than first-party: the order-status API lists 'out_of_delivery_radius' among the cancellation reasons allowed for merchant-delivery orders. https://help.urbanpiper.com/direct-ordering/google-maps · retrieved 2026-09-01

delivery-driver-comp differentiator

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01 (116 help.urbanpiper.com pages, 87 api-docs.urbanpiper.com pages, each the host's own llms.txt enumeration). There is no payroll, wage, mileage or reimbursement concept anywhere: the only rider data the platform holds is a per-order name and phone relayed by the POS (api-docs.urbanpiper.com/downstream/api/endpoints/order-management/self-delivery-rider-management/rider-status-updates, whose entire rider_data object is rider_name and rider_phone_number -- re-read 2026-09-02), and driver tips appear only as read-only amounts arriving in aggregator payloads ('Driver Tip' among the order-relay charge titles and in the per-aggregator constraints for Zomato, Swiggy, Talabat, Careem and Just Eat) -- money the marketplace collected, not something UrbanPiper allocates to a named driver. There is no driver ENTITY at all, so there is nothing for a compensation line to attach to across runs. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. /hub and /meraki name no labour, payroll or driver feature. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Not scored no: the reporting index (help.urbanpiper.com/data-and-reports/getting-started) lists order, item-wise, option-wise, item-summary, menu-snapshot and store-action reports but says 'including ... and more', so it is not a closed enumeration. Unresolved.

delivery-cash-reconcile

Re-examined 2026-09-02 on both permitted first-party hosts. The pieces exist separately and never meet. COD is a supported Meraki payment method (help.urbanpiper.com/direct-ordering/configuring-payment-gateway) and 'COD' is a payment mode in the order transactions report; Prime has shift and register machinery -- 'Cashier: ... Cashiers manage operational shifts using registers, process bills, and complete settlements' (help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas, re-read 2026-09-02). But that role description is the ONLY published mention of registers, shifts or settlement on either host: the help centre's Prime app and Prime web sections document login, printing, KOT, order tracker, 86ing, pause/resume, notifications and scan-and-pack, and carry no cashier or register article at all, so the contents of a Prime settlement are unpublished. There is no driver entity in the documented schema for a per-driver over/short figure to hang on -- the rider object is name and phone per order -- but no page states that. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. /hub's grid names 'Payment Reconciliation' with no detail, and no cash-bank or settle-up feature appears on any marketing page. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Two legacy first-party support hosts are also unreadable: support.urbanpiper.com 301-redirects every URL to itself in an infinite loop (probed 2026-09-02, /robots.txt included, so no policy is even obtainable there), and urbanpiper.helpjuice.com returns HTTP 402. Unresolved.

delivery-daas-dispatch

The vendor states it integrates on-demand courier networks and names providers: the partner table's Logistics Partners row reads "Access a network of delivery providers to ensure your orders get to your customers efficiently" against "Dunzo, Shadowfax, and others." SHORTFALL, and it is most of the claim: this is a first-party marketing page inside the help centre (it closes with "Book a demo"), graded C accordingly, and it is the ONLY place logistics dispatch is mentioned. No article documents handing an order to a courier, and nothing describes a courier quote or courier status returning into the order record. The rider status fields that ARE documented -- "Rider Status Updates... Assigned, Arrived, and PickedUp" and "Rider Reassignment" -- belong to the MARKETPLACE's own rider on a marketplace order, which is a different thing from dispatching a first-party order to a DaaS courier. https://help.urbanpiper.com/basics/partner-with-us · retrieved 2026-08-31

delivery-daas-fallback differentiator

Re-examined 2026-09-02 on both permitted first-party hosts. Two adjacent facts, neither settling the claim. (1) Logistics providers are a documented integration category -- help.urbanpiper.com/basics/partner-with-us lists 'Logistics Partners: Access a network of delivery providers ... Dunzo, Shadowfax, and others', and www.urbanpiper.com/integrations (read by hand 2026-09-02) shows a Fulfilment category naming Dunzo, Adloggs, Nash and Careem Box -- but both are integration DIRECTORIES, and no page on any readable host documents how a courier is booked, let alone a rule that books one automatically on a wait threshold, a zone miss or an unavailable in-house driver. (2) Hybrid dispatch exists as the AGGREGATOR's decision: api-docs.urbanpiper.com/downstream/aggregator-constraints/zomato says 'Zomato gives the flexibility to choose self (merchant driven delivery) and partner delivery ... termed Hybrid Logistics. This toggle of enabling the Hybrid Logistics to be done at Zomato end. Later, the control of enabling/disabling the logistics will be taken care of from Atlas Dashboard' -- future tense, and a per-store toggle rather than a per-order rule. The documented behaviour when a self-delivery order has no rider is to CANCEL and turn the store off, not to overflow: the order-status API allows 'rider_not_available' and 'out_of_delivery_radius' as merchant-delivery cancellation reasons and says 'the stores will be turned off'. That is suggestive of no fallback engine but describes the aggregator leg only; the Meraki and logistics legs are unpublished. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved.

delivery-3p-direct-integration differentiator

UrbanPiper documents first-party marketplace integrations it operates itself rather than reselling, with per-platform authorisation flows, feature matrices and a stated activation timeline ("typically takes up to 48 hours to go live"). Uber Eats has its own documented integration section (getting started, menu update and publish, menu timings, order prep time), as do Zomato, Swiggy and Keeta. SHORTFALL, and it is the claim's own named list: of DoorDash, Uber Eats and Grubhub, only Uber Eats is documented. DoorDash and Grubhub appear once each, in the Business Manager introduction's prose -- "organize menus across various online food delivery platforms such as DoorDash, Grubhub, and Uber Eats" -- with no integration guide, no feature matrix and no authorisation flow for either anywhere in the help centre. A marketing sentence naming a marketplace is not a certified integration. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

delivery-3p-injection

The per-platform feature matrices in the help centre answer this directly and identically for every marketplace documented. Zomato and Swiggy both carry "Real-Time Order Push -- Orders are sent to your system the moment they are placed" and "Auto-Acceptance -- Automatically accept new orders without manual intervention", with "Order with Options -- Orders with custom options are fully supported and relayed correctly"; the Keeta matrix adds "Orders placed on Keeta are pushed to your UrbanPiper-integrated system instantly." The integration overviews state that "You can receive orders from Zomato and have them sent directly to your POS." Firing to kitchen hardware is documented in the Scan and Pack article, whose test procedure reads "Head to the Live Orders section and acknowledge an incoming order. A KOT and a barcoded bill are generated automatically. Go to the KDS -- the order will appear there." No tablet re-keying and no manual accept step appears anywhere in the order path. Read from help.urbanpiper.com/llms-full.txt (231,780 bytes, retrieved 2026-08-31), sections "Zomato / Integration Overview", "Swiggy / Integration Overview", "Keeta / Manage Your Orders" and "Prime web / Scan and Pack Workflow". https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

delivery-menu-push

The master-menu-out-to-marketplaces half is documented in full and the channel-markup half is not. Menus are imported from the connected POS ("If you have a live POS integration on Urban Piper, you can make menu changes on the POS and import them to be published on the DSPs directly... manage your menu from a single platform") and published by selecting locations and platforms, so no separate menu is maintained in each portal. What publishing updates is enumerated per marketplace: "Product names and descriptions / Prices, taxes, and charges / Modifier groups, options, and variants / Product images / Product availability", with "Menu updates typically take up to 5-10 minutes to appear on the UI." SHORTFALL: the claim also requires channel-specific price markups, and UrbanPiper's own documented pricing axis is the LOCATION ("Location-Based Pricing -- Apply different prices for different locations"). Per-channel prices are documented only as something configured in the connected POS (Foodics Price Tags) or as a DSP-dependent fulfilment-mode price, never as a markup rule in Atlas. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

delivery-86-sync

Documented at both item and modifier level, in two products, against named marketplaces. In the Prime app: "To mark an item in stock or out of stock, click on the toggle", "Select modifiers and toggle them on or off", then a snooze duration -- "Choose a time period to turn the item off, either indefinitely or for a specific duration." In Prime Order Tracker's Stock Control: "Toggle the top button and hit Save to switch off the particular item or modifier on the aggregator's UI", verified through "the Logs to verify if the item was successfully turned off." Latency and scope are stated for Keeta: "Updates are real-time. Changes take effect immediately on Keeta", "Bulk updates are supported", for items and, identically, for modifiers. Zomato and Swiggy both list "Product Inventory Snooze -- Toggle items as out-of-stock for a set period." RECORDED LIMIT, which does not defeat the claim but belongs with it: automatic restoration is a snooze timer, not a stock signal, and on Keeta it does not exist at all -- "Auto stock-in by Keeta is not supported. Items do not automatically restock at the start of the day or at store closing time. Stock in must be triggered either manually in UrbanPiper." Read from help.urbanpiper.com/llms-full.txt, sections "86'ing an Item or Modifier" (Prime app and Prime web) and "Keeta / Manage Item Availability" and "Manage Modifier Availability". https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

delivery-store-pause

Per-platform pause from inside the product is documented twice. In the Prime app: "Click on the platform toggle option... After selecting the store, you will see the different platforms that the store is associated with. To pause or unpause the store on any desired platform, simply click on the toggle for the respective platform." In Prime Order Tracker the same action runs through Session Settings and is confirmed in a log. Zomato and Swiggy both list "Store Availability -- Manage your store's availability directly from UrbanPiper." SHORTFALL, which is the claim's own second half: no timed auto-reactivation exists. The only timing construct is a location operating-hours schedule, and the docs warn that the two interact badly -- "Any manual override of store availability will disable store timing. The store time will need to be synced again." The Zomato troubleshooting article documents further platform-side overrides the operator must undo by hand: after a menu publish Zomato re-enables a store automatically, so "if the store was already turned off before the menu was published, you will need to manually turn it off again", and a rejected order can make Zomato close the store, after which it must be "manually turned back on within 4-5 minutes." https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

delivery-3p-reconciliation differentiator

The report is documented field by field and several fields exist precisely for 3P reconciliation: 'External Platform ID ... Provides an additional reference point for reconciling with the aggregator'; 'Payment Transaction ID ... Essential for matching online payments with your bank statements'; 'Aggregator Discount -- the part of the discount that was funded by the online platform' split from 'Merchant Discount'; 'Wallet credit amount ... For payment reconciliation, especially with aggregator-specific wallet systems'; plus Charges, Merchant Taxes and a per-order Delivery Type of Partner or Self. It exports to CSV/XLSX and can be scheduled daily by email. SHORTFALL, and it is the heart of the claim: nothing matches a marketplace PAYOUT DEPOSIT to these orders, because no payout or settlement file is ingested anywhere on either host; commission is explicitly out of scope -- 'Merchant Total ... the amount your restaurant is expected to receive from the order, after aggregator discounts but BEFORE aggregator commissions'; and there is no marketing-fee, refund/adjustment or missing-and-unpaid-order identification. The merchant is given the sales side and must do the matching. https://help.urbanpiper.com/data-and-reports/order-transactions-report · retrieved 2026-09-01

delivery-injection-error-visibility differentiator

Integration health is surfaced to the operator through two documented mechanisms. A public per-component status page covers "Integrations (e.g., with POS and delivery platforms) / Dashboard performance / API availability / Scheduled maintenance / Known incidents or outages", posts "Issue identification and investigation / Ongoing resolution progress / Final incident resolution and root cause (post-mortem)", and takes email or SMS subscriptions. Inside the product, Prime Order Tracker writes a Logs entry for store-status and stock actions that the operator is told to check to confirm the change landed, and the Zomato troubleshooting article teaches operators to read a specific log message -- "All items are in inactive state" -- as the signature of a lapsed GST registration. SHORTFALL: all of that is CHANNEL and CONFIGURATION health. Nothing in the help centre documents a failed or rejected ORDER injection surface -- no failed-order queue, no per-order retry, and no alert on an injection failure -- which is the specific thing this claim asks for. https://help.urbanpiper.com/basics/urbanpiper-status · retrieved 2026-08-31

delivery-tracking-page

Branding is real and first-party: the Mask ID guide covers configuring 'a custom Mask ID for SMS communications (OTP, ORDER UPDATES, and marketing campaigns) on the UrbanPiper Meraki platform' -- DLT template registration, PE-TM bonding with Gupshup, then 'you can now send all SMS (OTP, order updates, campaigns) via Meraki using your Mask ID' -- and the storefront itself sits on the merchant's own domain (help.urbanpiper.com/direct-ordering/configuring-a-custom-domain). SHORTFALL: no page documents a guest-facing status or tracking PAGE. The only post-order screen described anywhere is static -- 'Order Success Page: a static map is displayed on the order confirmation page' (help.urbanpiper.com/direct-ordering/google-maps) -- and since UrbanPiper holds no driver state for first-party orders beyond what a POS or aggregator relays to it, nothing documents a page or link driven by live driver state. What the order-update SMS contains is also unspecified: the templates are the merchant's own, registered on the DLT portal. https://help.urbanpiper.com/direct-ordering/setting-up-your-own-mask-id-for-sms · retrieved 2026-09-01

delivery-promise-time differentiator

The quoted time does vary, but only between two hand-set constants and only when a human says so: in Atlas, 'Settings -> Platforms -> Automations Tab -> Food Preparation Time', you enter a 'Normal Prep Time' and a 'Busy Prep Time' ('Busy time must be greater than the normal prep time'), apply them at 'Location level or Business level', and 'Save and Sync' to push them to the channel. The article then states the switch explicitly: 'The active prep time mode (Normal or Busy) is controlled from Prime -- not Atlas. Atlas is used only for configuring and syncing prep time values.' SHORTFALL: that is a manual two-state toggle, not a dynamic quote. The delivery half is a flat constant too -- the store schema carries a single 'min_delivery_time (integer) -- Minimum time (in seconds) required to deliver an order' per store (api-docs .../api/endpoints/stores/add-update-stores) -- and no page on either host describes kitchen load, order volume, rider availability or zone drive time feeding the quoted time. The aggregator-side prep_time bounds relayed in the order payload (prep_time.min / .max / .adjustable) are the marketplace's constraints on what the store may set, not an automatic adjustment by UrbanPiper. https://help.urbanpiper.com/ordering-channels/uber-eats/manage-order-prep-time · retrieved 2026-09-01

delivery-offline-behavior

Re-examined 2026-09-02 and REWRITTEN to remove content the previous rationale took from changelog.urbanpiper.com, a named-allowlist host that refuses us; nothing from it is read or restated here. I re-grepped every occurrence of 'offline' on the permitted hosts: eight in help.urbanpiper.com and three in api-docs.urbanpiper.com, and NOT ONE describes trading through an internet outage. They are a location taken 'offline' from a delivery platform when permanently closed, a printer being 'offline' (with QZ-Tray named as a print fallback 'if cloud printing fails for any reason (network issue, printer offline, etc.)'), aggregator-side menu mapping 'carried out offline, with assistance from the Zomato/Swiggy team', and API error strings about an outlet being switched off for rejections. So no page on either permitted host documents whether cash delivery orders can be captured, riders assigned, or driver settlement completed while the connection is down. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. No marketing page addresses offline operation either. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Two legacy first-party support hosts are also unreadable: support.urbanpiper.com 301-redirects every URL to itself in an infinite loop (probed 2026-09-02, /robots.txt included, so no policy is even obtainable there), and urbanpiper.helpjuice.com returns HTTP 402. The vendor's surface is known to be larger than the two doc hosts, and the part of it that would answer this is either barred or dead. Unresolved.

digital-first-party-web

Meraki is explicitly sold as self-branded ordering websites and apps, positioned against marketplace commissions. https://www.urbanpiper.com/ · retrieved 2026-08-01

digital-menu-single-source

Hub markets updating all online menus in real time with one click across Swiggy, Zomato, UberEats and Talabat, driven from the existing POS. https://www.urbanpiper.com/hub · retrieved 2026-08-01

digital-native-app differentiator

A branded app is a documented product, not an inference. Meraki is "UrbanPiper's self-branded, commission-free online ordering platform for restaurants. It allows you to build and launch your own website and mobile app -- complete with customizable menus, discounts, analytics, and marketing tools -- without relying on third-party aggregators", under "Full brand control: Tailor store design, menus, and customer experience under your own identity", and the app is corroborated elsewhere as a real running artefact: push-notification campaigns reach "users who have your app installed" and "will only be received by users who are logged into your app". SHORTFALL, and it is what separates this claim from a mobile web page: nothing documents publication to the App Store or Play Store -- not the listing process, not who owns the developer account, not review handling, and not whether iOS and Android are both delivered. The custom-domain article covers the WEBSITE only (Atlas > Meraki > Editor > Domain, CNAME/A records, 24-48 hour propagation). Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/getting-started · retrieved 2026-08-31

digital-account-saved-payment

Accounts are real: campaign messages personalise from the customer record with {{user_name}}, {{user_phone}}, {{user_email}}, {{user_points}} ('the customer's current loyalty points balance') and {{user_wallet_balance}}, and push notifications 'will only be received by users who are logged into your app'. Addresses are held per customer -- the Meraki Google Maps article documents 'Adding or Updating Customer Address' with Places autocomplete and pin drag (help.urbanpiper.com/direct-ordering/google-maps). SHORTFALL on the other two limbs. Saved/tokenized payment: the payment-gateway article enumerates twelve gateways in a region matrix (Razorpay, Paymentos, PhonePe, Instamojo, Paystack, Paytabs, Stripe, Paytm Blink, Paytabs v2, PayU Latin America, Mercado Pago, FreedomPay) and lists the enable/disable options as Online Payments, Cash on Delivery and 'Wallets or Loyalty Points (if configured)' -- no card vaulting, tokenization or saved instrument anywhere in that configuration surface. One-tap reorder: absent from all 116 help pages and all 87 API pages; the word reorder does not occur on either host. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-09-01

digital-upsell-engine differentiator

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01. The words 'upsell', 'cross-sell' and 'recommendation' do not occur on either host (re-grepped 2026-09-02; 'recommend' occurs only as the menu-push `recommended` listing flag and as ordinary advice prose); 'suggestion' occurs once, as a coupon-list toggle. The Meraki configuration articles that exist -- getting-started, custom domain, payment gateway, Google Maps, banner images, SMS mask ID, coupons, campaigns -- cover banners and discounts and never reach cart or checkout merchandising, and the promotion engine that does exist is rule-based discounting (Cash Discount, Item Specific, Buy X Get Y with items-to-check / items-to-discount lists), not an add-on suggestion at checkout. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. /meraki's grid names 'Discount Module' and 'Marketing Automation' and no recommendation or upsell feature. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Not scored no: the reporting suite carries order, item-wise, option-wise, item-summary, menu-snapshot and store-action reports and no attach-rate report, but that index is self-described as 'including ... and more' and is not a closed enumeration. Unresolved.

digital-scheduled-pacing

Scheduled ordering is supported end to end: the order-relay reference has a 'Future/Scheduled Order' section -- 'A few aggregators allow the customers to place the orders for future date-time (ex: A customer can place an order for tomorrow)' -- with the flag the POS partner must read; certification requires testing an 'Order with Is future order? toggle enabled' (api-docs .../integration-certification/testing-and-validation); the reporting layer exposes 'Request Delivery Time' plus 'Time Slot Start / Time Slot End ... If the customer chose a specific delivery window' (help.urbanpiper.com/data-and-reports/order-transactions-report); and the Lightspeed K-Series integration exposes a 'Food prep time (in minutes): Set-up to establish the delay in relay of Future orders (only) to POS'. SHORTFALL: there is no pacing. No per-slot or per-daypart capacity, order cap or item cap appears on either host, and nothing closes a slot when the kitchen saturates -- the only load controls documented are manual (the Normal/Busy prep-time toggle switched by staff in Prime) or blunt (store pause/resume, item 86ing). 'Throttle' on these hosts refers exclusively to API request rate limits. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay · retrieved 2026-09-01

digital-fulfillment-modes

Two of the four modes are documented with mode-specific pricing and item eligibility. "A Fulfillment Mode defines how a customer receives their order", with delivery and pickup as the standard pair; delivery is on by default and pickup is enabled per outlet; an item can be priced differently per mode (the worked table gives Pizza Margherita at $10.00 delivery and $9.00 pickup) and can be restricted to one mode -- "Ice Cream Sundae -> Pickup only (not available for delivery)." SHORTFALL on the rest of the claim. Curbside with arrival check-in and dine-in or QR table ordering are absent from the help centre entirely. Mode-specific PREP timing is not a documented setting here (prep time appears only as a value relayed on marketplace orders). And the whole mechanism is delegated rather than owned: enabling pickup means "Contact your DSP Point of Contact (POC)", and both the per-mode pricing and the per-item restriction carry the same caveat -- "Support for fulfilment mode-specific pricing varies by DSP", "Item-level fulfilment restrictions depend on DSP support." https://help.urbanpiper.com/business-manager/creating-a-menu/understanding-fulfilment-mode-for-an-item · retrieved 2026-08-31

digital-qr-table

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01. Dine-in is a real fulfilment mode -- one of the values of the order transactions report's Fulfillment mode field ('delivery', 'pickup', 'dine-in'), the Gupshup constraints refer to 'all modes of ordering (dine-in/delivery/pickup)', and Prime's Captain role 'takes customer orders, especially for dine-in ... cannot settle bills; that's handled by Cashiers'. But NO QR code, table code, scan-to-order or scan-to-pay flow appears on either host: re-grepped 2026-09-02, 'QR' matches only inside image URLs on help.urbanpiper.com and once in api-docs, and there is no table, check-splitting or tipping article anywhere. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. None of /meraki, /hub or /orderline names QR ordering, table ordering, splitting or tipping. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: the Prime dine-in and cashier screens are the one product area the 116-page help centre does not document (its Prime sections cover login, printing, KOT, order tracker, 86ing, pause/resume, notifications and scan-and-pack), so the surface where such a flow would live is unpublished rather than shown to be empty.

digital-kiosk differentiator

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01: the word 'kiosk' does not occur on either host (re-grepped 2026-09-02, zero hits in all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages). help.urbanpiper.com/basics/compatible-hardware, the nearest thing to a hardware census, gives 'minimum specification requirements for buying hardware to use UrbanPiper products' and covers Android handheld/phone/tablet/terminal, iOS phone/tablet, ESC-POS and Star receipt printers and Chrome on a laptop -- no kiosk enclosure and no card reader or PIN pad of any kind -- but it is written as a spec FLOOR ('Any device that adheres to the Minimum Specification Requirements will work fine with our products'), not a closed list of products, so it cannot carry a no. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The vendor's product pages are /hub, /meraki and /orderline with no kiosk product, and /integrations' four categories (POS Systems, Fulfilment, Delivery platforms, Online Ordering) include no kiosk category -- but a marketing site is grade D and a directory is never an enumeration. Unattended EMV is equally unassessable: the documented payment surface is gateway configuration for the Meraki web storefront, with no card-present or terminal integration at all. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved.

digital-group-ordering

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01 (116 help.urbanpiper.com pages, 87 api-docs.urbanpiper.com pages). No group ordering, shareable cart link, participant, per-person cap or split-payment concept appears anywhere ('group order' returns zero hits on both hosts, re-grepped 2026-09-02). The Meraki articles document the storefront's domain, payments, maps, banners, SMS, coupons and campaigns and never reach cart behaviour; the partner API models an order as a single customer with one payment block, but it is a relay schema and would not necessarily expose a storefront cart feature even if one existed. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. No page asserts the absence, and the Meraki cart/checkout surface is documented nowhere. Unresolved.

digital-catering-portal differentiator

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01: 'catering' does not occur on either host (zero hits, re-grepped 2026-09-02). The adjacent machinery that would carry it exists but is generic -- menus can be scoped by channel and by location group, categories carry slot-based timing groups (api-docs.urbanpiper.com/downstream/api/endpoints/menu/category-timing-groups), stores carry a min_order_value, and future-dated orders are supported -- yet nothing documents a separate catering menu, a lead-time rule, a quote or proposal, a deposit, a house account, invoice terms or ACH. Payments in Meraki are gateway-collected at checkout (help.urbanpiper.com/direct-ordering/configuring-payment-gateway) with Cash on Delivery the only alternative, which points against invoice terms but sits on a page about gateway setup, not a statement about catering. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved.

digital-voice-ai-phone differentiator

REPLACES an unknown that rested on the two documentation hosts, which do not bound the vendor: 'orderline' returns ZERO hits across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages, yet UrbanPiper sells a named first-party AI voice product. www.urbanpiper.com/orderline (and its /us/orderline variant), read by hand 2026-09-02, describes Orderline AI as handling 'all customer calls, reservations and orders, with AI', with feature bullets 'Instant call answering: No missed calls or busy lines -- every call is picked up instantly', 'Direct POS integration: Connects with 250+ POS systems for real-time order routing', 'Seamless AI-to-human handoff: Smooth transfer to your team with full context', 'Call logs and transcripts' and 'Analytics & Insights'. The vendor dates the product publicly: www.urbanpiper.com/blog/the-7-second-window-how-missed-calls-hurt-restaurant-orders-and-reservations (2026-04-10) promotes it as removing 'dependency on manual handling'. That answers the claim's first two limbs -- an inbound AI voice channel that routes the order to a POS without staff transcription. SHORTFALL: the evidence is grade D and nothing stronger exists. Neither documentation host carries a single Orderline page, so no POS is NAMED among the '250+', no order payload or integration contract is published, and nothing shows the completed order landing in a specific POS -- including UrbanPiper's own Prime. The atlas grade floor forbids a yes on a differentiator from marketing alone, and that is the right answer here: the capability is claimed by the vendor and undocumented everywhere it could be verified. https://www.urbanpiper.com/orderline · retrieved 2026-09-02

digital-drivethru-ai

Re-examined 2026-09-02. Neither 'drive-thru' nor 'drive thru' occurs on help.urbanpiper.com or api-docs.urbanpiper.com (zero hits across all 116 and all 87 pages, re-grepped 2026-09-02), and the fulfilment modes the platform models are delivery, pickup and dine-in (order transactions report; Gupshup aggregator constraints), with no lane, curbside or window concept. IMPORTANTLY, the premise that there is 'no voice capability to escalate from' is now WRONG: Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. the vendor ships Orderline AI (www.urbanpiper.com/orderline, read 2026-09-02), an AI voice product with 'Seamless AI-to-human handoff'. But that page scopes the product to INBOUND TELEPHONY -- 'all customer calls, reservations and orders' -- and names no drive-thru, lane, headset or speaker-post deployment, and it is a grade-D marketing page rather than an enumeration of where the voice agent can run. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: nothing readable states either that Orderline runs at a drive-thru lane or that it cannot.

digital-sms-ordering

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01. Two conversational-commerce platforms are supported ordering channels with full menu-publish and order-relay integrations -- 'gupshup' and 'chatfood', each with its own aggregator-constraints page. I re-read api-docs.urbanpiper.com/downstream/aggregator-constraints/gupshup in full on 2026-09-02: it documents ONLY catalogue and order plumbing -- fulfilment modes, category timing groups not supported, nested option groups not supported, item images, included platforms, discount splits, Store On/Off supported, Item On/Off supported -- and says NOTHING about how a guest orders. So I cannot say from UrbanPiper's documents that a text-to-order or chat reorder lands in the POS; that description would come from Gupshup's or ChatFood's own documentation, and scoring it from the channel's name would be an inference about a third party. UrbanPiper's own SMS is OUTBOUND only: 'OTP, order updates, and marketing campaigns' under the merchant's DLT-registered mask (help.urbanpiper.com/direct-ordering/setting-up-your-own-mask-id-for-sms), with no inbound keyword or reply handling documented. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The vendor's conversational product, Orderline AI (/orderline, read 2026-09-02), is VOICE telephony and names no SMS, text-a-link or chat channel at all. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved.

digital-google-order differentiator

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01. Google appears in exactly one functional context: help.urbanpiper.com/direct-ordering/google-maps, covering the storefront's use of the Maps JavaScript, Places and Geocoding APIs with the merchant's own GCP key. 'Google Business' returns ZERO hits on both hosts (re-grepped 2026-09-02), as do 'Business Profile' and 'Preferred by Business', and the Meraki setup articles that would carry it (getting-started, configuring-a-custom-domain) stop at the domain. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. /meraki's grid names Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations, with no Google placement feature; the only Google-marketing content on the host is a generic how-to blog about managing a Business Profile, not a product integration. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Because the Meraki storefront runs on the merchant's OWN domain a merchant could add that URL to their Business Profile by hand, but that is not the vendor-provisioned placement the claim asks about. Unresolved: nothing published says whether UrbanPiper supports the integration.

digital-apple-business-connect

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01: neither 'Apple Business Connect' nor 'Apple Maps' nor any place-card or custom-action concept occurs on help.urbanpiper.com or api-docs.urbanpiper.com (two 'Apple' hits in help and one in api-docs, re-grepped 2026-09-02, all of them the device platform). Apple appears only as a target platform -- iOS minimum device specs on help.urbanpiper.com/basics/compatible-hardware and the Prime staff app on the App Store. Guest-side mapping is Google-only (help.urbanpiper.com/direct-ordering/google-maps). Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. No product page (/hub, /meraki, /orderline) and no integrations category mentions Apple Maps or an Order Food action. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: no page states whether an Order Food action can be pointed at a Meraki storefront, and the Meraki storefront's external-placement configuration is documented nowhere.

digital-loyalty-attach

Redemption is in the checkout: the Meraki payment configuration lists the methods a merchant enables as 'Online Payments (UPI, cards, net banking, wallets)', 'Cash on Delivery (COD)' and 'Wallets or Loyalty Points (if configured)'. The balance lives on the guest's own account rather than a separate enrollment -- campaign messages personalise from {{user_points}}, 'the customer's current loyalty points balance', and {{user_wallet_balance}} alongside {{user_name}}, {{user_phone}} and {{user_email}} (help.urbanpiper.com/direct-ordering/manage-campaigns). SHORTFALL on both remaining limbs: no page on either host documents ACCRUAL -- there is no earn rate, tier, points-per-currency or reward-rule article, and the 'if configured' qualifier is never expanded, so whether points are earned in Meraki or imported from a partner loyalty platform (partner-with-us names Gupshup under 'Marketing & Loyalty') is unstated. And there is no in-store identity to share: UrbanPiper sells no till, and nothing documents the Meraki guest identity being recognised by the merchant's POS at the counter. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-01

digital-subscriptions

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01. 'Subscription' occurs only at help.urbanpiper.com/business-manager/cancel-your-subscription, which is the RESTAURANT cancelling its own UrbanPiper service, not a guest programme; 'membership' occurs nowhere (re-grepped 2026-09-02). Guest-side, the pieces that would underpin one exist -- a per-customer wallet balance and loyalty points balance, exposed as {{user_wallet_balance}} and {{user_points}} campaign variables (help.urbanpiper.com/direct-ordering/manage-campaigns), and twelve payment gateways -- but no page documents recurring or scheduled billing of a guest, a delivery-fee waiver entitlement, a per-period item entitlement or a paid loyalty tier, and the Meraki coupon engine is per-order (Cash Discount, Item Specific, Buy X Get Y) with start and end dates rather than a subscription. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. /meraki's grid names 'Loyalty Program' and 'Marketing Automation' with no paid tier or membership. The /meraki feature grid is Online Store Builder, Customizable UI, Menu Management, Discount Module, Advanced Analytics, Marketing Automation, Loyalty Program, Customer Directory, Customer Feedback and Payment Integrations; /hub's is Order Management, Menu Management, Stock Management, Store Toggle, Advanced Analytics, Detailed Reporting, 99.99% Uptime, Payment Reconciliation and Multi-store Control. Both are marketing feature grids, grade D and not enumerations, so neither can carry a no. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved.

digital-promo-parity

Parity holds within the first-party estate and stops at the channel boundary. A Meraki coupon is defined once in Meraki and applies to the storefront the operator publishes to both web and app, with a single engine covering cash discounts, item and subtotal percentages and BXGY, plus mandatory redemption codes and start/end date-times. SHORTFALL: promotions are NOT defined once across channels, and the documentation makes that structural rather than incidental -- marketplace discounts are configured on the marketplace side and have their own per-platform articles (Running Discounts on Keeta), while what UrbanPiper receives from Zomato, Swiggy and Keeta is discount INFORMATION relayed onto the order ("Order Discount Info", "Order-Level Discount", "Item-Level Discount", split into aggregator-funded and merchant-funded on the transaction report). There is no shared offer object, no channel eligibility control, and no kiosk or POS channel to be consistent with. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-coupons · retrieved 2026-08-31

digital-guest-data-ownership differentiator

The vendor asserts operator ownership of first-party guest data as a selling point of the channel -- Meraki gives "Valuable customer insights: Access customer and order data, enabling loyalty programs and marketing automation (email, SMS, social)" -- and the data is demonstrably reachable: order exports carry Customer Name and Customer ID, campaigns address customers by {{user_phone}} and {{user_email}}, and the export route is self-serve CSV/XLSX with no fee or approval documented. SHORTFALL on the claim's specific requirements. No article documents a BULK export of guest records as such, consented marketing status is never mentioned as a stored or exportable field, and no terms or contractual statement of ownership is published in the help centre -- what exists is a marketing sentence about access plus a report that happens to carry two customer columns. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/getting-started · retrieved 2026-08-31

digital-checkout-pci-sca

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01: 'PCI', '3DS', '3-D Secure' and 'SCA' occur nowhere on help.urbanpiper.com or api-docs.urbanpiper.com, nor does any other compliance attestation (no SOC 2, ISO 27001 or GDPR article). help.urbanpiper.com/direct-ordering/configuring-payment-gateway is the only checkout-payments article: the merchant pastes their OWN gateway credentials (API key, secret key, merchant ID) for one of twelve gateways in a regional matrix (Razorpay, Paymentos, PhonePe, Instamojo, Paystack, Paytabs, Stripe, Paytm Blink, Paytabs v2, PayU Latin America, Mercado Pago, FreedomPay) and runs a test transaction. That the merchant's own gateway account collects the money suggests the card never touches the restaurant's page, but the article never says whether the checkout uses hosted fields, a hosted page or a redirect, and says nothing about tokenisation, 3DS or PCI DSS 4.0's client-side script-integrity requirements. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. www.urbanpiper.com/legal/data-processing-agreement is the closest thing to a trust page and it DOES enumerate technical measures -- 'Personal data is encrypted at rest using AES-256, applied at the storage layer across databases, object storage and backups' and 'encrypted in transit using TLS v1.2 or higher' -- while naming no PCI DSS, P2PE, ISO 27001 or SOC 2 attestation and saying nothing about cardholder data; the merchant agreement is silent on cards and PCI too. That is a personal-data measures list, not a payments-compliance enumeration, so it cannot establish absence. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved.

digital-surcharge-transparency differentiator

Re-examined 2026-09-02 across both complete first-party sets retrieved 2026-09-01. UrbanPiper does have a real fee engine reaching every channel: a Charge is created in the Atlas catalogue with one of three modes -- Item Quantity, Order Subtotal, Item Price -- and scoped by pairing an Item Group with a Location Group (help.urbanpiper.com/business-manager/creating-a-menu/create-and-manage-charges, re-read 2026-09-02), taxes on charges are configurable, and per-aggregator constraints govern how each channel accepts them. But the documented charge types are packaging and delivery -- 'The two most prevalent charges are the Packaging Charges and the Delivery Charges' -- and every 'Surcharge' occurrence is an amount the MARKETPLACE calculated and relays inbound in the order payload (enumerated among 'Restaurant Packaging Charge, Packaging Charge, Delivery Charge, Service Charge, Driver Tip, Surcharge, Deposit Charge, Other Charges' and listed for Zomato, Swiggy, Talabat, Careem, Deliveroo and Just Eat), not something the merchant configures as a card fee. Nothing on either host mentions a card or credit surcharge, dual/cash pricing, a guest-facing disclosure string, card-brand rules or prohibited jurisdictions. Extended the check on 2026-09-02 past the two GitBook doc hosts, which bound only themselves: www.urbanpiper.com (robots.txt carries a lone Sitemap line and no rules) was read BY HAND, not crawled -- sitemap.xml plus the product pages /hub, /meraki, /orderline and /integrations and the legal pages /legal/merchant-agreement and /legal/data-processing-agreement. The merchant agreement carries no surcharging or disclosure terms and the DPA none either; /meraki's grid names only a 'Discount Module' and 'Payment Integrations'. changelog.urbanpiper.com carries first-party Prime POS material and is BARRED to us -- its robots.txt is a named allowlist (twelve crawlers Allow: /, then User-agent: * Disallow: /) -- so it was not read and nothing from it is repeated here. Unresolved: whether the Meraki checkout can carry a card surcharge, and with what disclosure, is unpublished on every readable host.

guest-loyalty-unified-profile

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). The claim needs a single guest profile merging in-store POS, first-party web/app and kiosk transactions on a phone/email match, with documented dedup behaviour. Neither doc host describes a guest profile object, an identity match or any merge rule; the only per-customer state is Meraki's merge fields ({{user_name}}, {{user_points}}, {{user_wallet_balance}}, {{user_phone}}, {{user_email}} on help.urbanpiper.com/direct-ordering/manage-campaigns) and the Atlas Support role that can 'access customer details'. The www host adds two facts and settles nothing: www.urbanpiper.com/meraki lists 'Customer Directory' among its feature chips (grade D, no mechanics), and www.urbanpiper.com/legal/privacy-policy section 2 says Meraki collects 'a Customer's name, contact details, delivery address and order details' on the Merchant's behalf -- a record, but nothing about identity resolution across channels. No kiosk product appears on any first-party surface, and Hub relays orders outward to the POS rather than ingesting in-store POS transactions. Unresolved because the Atlas customer screens are not published, not because merging is stated to be absent. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-thirdparty-identity-attach differentiator

The vendor's own API reference asserts the negative pole of this claim for marketplace orders: 'While the aggregators generally do not share most of the customer-related information, we share whatever is made available to you. For instance, in most cases, the phone number is not shared and hence you can expect a dummy number to be sent from our side. However, in the case of orders delivered by the restaurant themselves, aggregators share the delivery location and in such cases, it would be shared with you in customer info.' The Order Relay payload's customer block is therefore name/email/phone of largely synthetic values, plus an aggregator-scoped hashed id in ext_platforms.extras (zomato_customer_id). The help centre's Order Transactions Report reference repeats it for reporting: 'customer details are suggested to the information passed by DSP. Most of the DSP/Aggregators do not share the customer details. Data might be dummy', and describes Customer ID as 'a unique code for the customer on the online platform... though often masked by aggregators for privacy'. Marketplace orders thus arrive without usable guest identity, and nothing in the 87-page API reference attaches such an order to a native UrbanPiper guest profile. The one documented exception is restaurant-self-delivered orders, where a delivery location is passed. https://api-docs.urbanpiper.com/downstream/order/order-components · retrieved 2026-09-01

guest-loyalty-accrual-models

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). Existence is no longer in doubt: www.urbanpiper.com/meraki lists 'Loyalty Program' among its product-feature chips and its FAQ says 'We have tools like email marketing, a free loyalty program, SMS marketing and wallet to increase ticket sizes and repeat orders' -- but that is grade D marketing with no configuration detail, and this claim turns on WHICH accrual models are configurable. The documentation surfaces carry only a balance and a tender: help.urbanpiper.com/direct-ordering/manage-campaigns documents {{user_points}} as 'the customer's current loyalty points balance' and help.urbanpiper.com/direct-ordering/configuring-payment-gateway lists 'Wallets or Loyalty Points (if configured)' as a checkout option. Earning is nowhere: points-per-currency-unit, visit or punch counts and spend tiers do not occur in either corpus, the eight-article Meraki help section contains no loyalty setup guide, and the six 'loyalty' hits in 479,604 chars of help content are the two above plus role descriptions and an integrations-table row. The eight product-update blog posts read this pass add nothing on loyalty. Unresolved: a marketed module whose settings screen is unpublished. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-tiers differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). Searched both corpora for tier, status, VIP, gold/silver, promotion and demotion: the sole 'tier' occurrence in either is the menu item tag 'tiered-cake' at api-docs.urbanpiper.com/downstream/api/references/item-tags. Loyalty appears only as a points balance ({{user_points}}, direct-ordering/manage-campaigns) and an optional Meraki checkout tender (direct-ordering/configuring-payment-gateway). www.urbanpiper.com/meraki, read 2026-09-02, names 'Loyalty Program' as a feature chip and its FAQ calls it 'a free loyalty program' with no rule engine, tier, or rolling window described, and it is grade D in any case -- a differentiator yes needs A or B. The sitemap holds no loyalty or rewards page and none of the eight product-update posts read mentions tiers. Unresolved because the loyalty rule engine is not documented on any permitted surface, not because tiering is denied. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-offline-behavior differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). This claim needs an explicit statement of what loyalty lookup, accrual and redemption do when connectivity drops. Every 'offline' hit in the two corpora was read and none is loyalty: printer-offline fallback (store-manager/prime-web/cloud-printing-setup-guide and /print-automations), taking a location offline permanently (business-manager/deactivate-a-location), 'this mapping is carried out offline, with assistance from the Zomato/Swiggy team', and an API error string about an outlet offline 'due to high number of rejections'. Since redemption is documented only as a checkout tender ('Wallets or Loyalty Points (if configured)') with no runtime description, there is nothing for a queue-and-reconcile versus blocked answer to attach to. The www pass added nothing: no offline or resiliency page in the sitemap, and the Prime posts read cover billing shortcuts, KDS 2.0 and KOT timing rather than connectivity loss. Unresolved for want of any published loyalty runtime documentation. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-offer-stacking-rules differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). help.urbanpiper.com/direct-ordering/configuring-coupons remains the only discount-engine document on either doc host. It states 'Meraki provides two types of discounts you can configure' -- Cash Discount and percentage, the latter Item Specific or Buy X Get Y -- and names the configured fields: Redemption Code, start and end date/time, bulk generation, Items to Check, Items to Discount, Number of Items to Check, Number of Items to Discount, Max No of Discounts, Coupon Value, plus targeting of 'specific customer groups using the Rules section'. No exclusive-versus-combinable flag, no priority field and no order of application; the only multi-discount rule is the within-coupon tie-break ('the lower-priced item will get the discount'). www.urbanpiper.com/meraki (2026-09-02) lists a 'Discount Module' chip with no mechanics, and the product-update posts read this pass announce billing and KOT changes, not discount precedence. The order payload's separate discount, total_external_discount, Aggregator Discount and Merchant Discount fields are reporting only. Left unknown because a worked-example task guide is not a settings screen enumerating the whole configurable surface, and the 'Rules section' it points at is itself undocumented. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-targeted-offers differentiator

Audience targeting is a documented construct on both the offer and the campaign. Coupons: "You can target specific customer groups using the Rules section", over a discount engine with real depth -- cash discounts on subtotal, percentage discounts on selected items or the whole subtotal, and Buy X Get Y with Items to Check and Items to Discount lists, worked through BOGO, Buy-X-Get-Y and B3G2 examples with parameter tables and stated tie-breaking ("the lower-priced item will get the discount"). Campaigns: "define your target audience." SHORTFALL: what the audience rules can express is never documented. No article names a targetable attribute, and the specific dimensions this claim requires -- recency, frequency, spend, items purchased -- appear nowhere, so a dynamically defined audience is asserted by the product and unevidenced in its documentation. Redemption codes, start and end date-times, and bulk generation ARE documented as mandatory coupon configuration. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-coupons · retrieved 2026-08-31

guest-loyalty-rfm-segmentation differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). The claim requires lifecycle segments computed automatically, without the operator writing the queries. The only segmentation evidence in the corpora is help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas: the Atlas Marketing role 'allows users to view and create campaigns, manage customer segments, and implement discount strategies'. 'Manage' points if anything the other way, and help.urbanpiper.com/direct-ordering/manage-campaigns describes defining a target audience with no audience builder or predefined segment named. No recency, frequency or monetary metric and no new/regular/at-risk/lapsed/VIP vocabulary occurs in either corpus, and data-and-reports is order- and item-level with no customer cohort report. New this pass and still insufficient: www.urbanpiper.com/meraki chips 'Advanced Analytics' and 'Customer Directory', and www.urbanpiper.com/blog/upgraded-industry-leading-analytics-module-for-restaurants describes order-frequency and store heatmaps -- operational analytics, not guest lifecycle segments -- both grade D. Unresolved because the Atlas segment builder is unpublished. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-lifecycle-automation

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). help.urbanpiper.com/direct-ordering/manage-campaigns is still the only campaign document on either doc host and was re-read: SMS (DLT template registration, PE ID, Gupshup telemarketer bonding, whitelisting by UrbanPiper support), email (HTML export, images via Atlas > Meraki > Gallery, test send) and app push ('Define Audience & Message', 'Create Your Campaign', 'Launch'), plus five personalization placeholders. Nothing in it is triggered; birthday, anniversary, win-back, lapsed, first visit, automated and recurring do not occur, and the only hit for those terms across both corpora is the item tag 'birthday-cake'. The www pass sharpens the claim without grounding it: www.urbanpiper.com/meraki lists 'Marketing Automation' as a feature chip and says 'Build loyalty with marketing automation tools ... Reach out to your loyal customers via email, SMS and social media, all from one dashboard' -- grade D, and a dashboard for reaching out is exactly the manual send this claim excludes. None of the eight product-update posts read announces a triggered campaign. Unresolved: a marketing phrase with no documented mechanics. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-native-email-sms differentiator

Both channels are native to the platform, plus a third. "The Meraki suite allows you to send dynamic messages across multiple channels", documented one section each: SMS campaigns ("you can create and launch your personalized SMS campaigns directly from the Meraki platform"), Email campaigns (HTML content, images hosted through Atlas > Meraki > Gallery for public URLs, test send before broadcast) and App Push Notifications ("Create your push notification campaign directly within the Meraki platform, define your target audience, and set the message content"). Personalisation is a documented feature rather than an inference, with a placeholder table -- {{user_name}}, {{user_points}} ("the customer's current loyalty points balance"), {{user_wallet_balance}}, {{user_phone}}, {{user_email}}. Gupshup appears as the underlying SMS carrier, which is what "natively" means in this claim: the campaign is composed, targeted and launched in the vendor's product rather than by exporting a list to an ESP. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-08-31

guest-loyalty-consent-management

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). consent, opt-in, opt-out, unsubscribe, STOP, preference and GDPR occur nowhere in either doc corpus. What manage-campaigns documents for SMS is SENDER-side Indian regulatory registration (DLT Template ID and PE ID, bonded to Gupshup telemarketer IDs, then whitelisted by UrbanPiper support), and for push only that 'notifications will only be received by users who are logged into your app'; setting-up-your-own-mask-id-for-sms is likewise sender identity. New this pass and deliberately not scored as the capability: www.urbanpiper.com/legal/privacy-policy section 10 grants 'the right to opt-out of marketing communications We send You at any time ... by clicking on the unsubscribe or opt-out link', with other channels handled by emailing support@urbanpiper.com -- that is UrbanPiper as controller of ITS OWN marketing list, not the merchant's guest record, for which section 2 makes the Merchant the Controller and UrbanPiper a Processor. So no per-channel consent flag, timestamp, source-of-consent capture or cross-channel revocation is documented for guests. Unresolved because the Atlas customer record is unpublished. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-10dlc-registration

The vendor does exactly what this claim asks -- documents the carrier-registration regime the operator must complete before it will send their SMS -- but for a different jurisdiction than the one the claim names. The documented regime is India's DLT: "Before sending any message, you must get your templates approved on a DLT portal (e.g., Vodafone, Jio, Airtel). Once approved, you will receive a Template ID and a PE ID (Principal Entity ID)", then "bond your PE ID with our SMS provider, Gupshup" by adding three named Telemarketer IDs, then "email your Template ID and PE ID to our support team. Our team will then work with Gupshup to get your templates whitelisted in our system." SHORTFALL: A2P 10DLC, the US regime this claim names, is not mentioned anywhere in the help centre, and neither is any US carrier, brand registration or campaign-vetting step -- which matters for a vendor that markets across 14-plus countries including the US. Partial rather than no: the vendor demonstrably handles SMS compliance registration where it operates, and is silent rather than negative on the US. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-08-31

guest-loyalty-campaign-attribution differentiator

Redeemed offers are tied to actual check totals at row level. The Order Transactions Report's documented column reference carries, under Payment & Financials, 'Coupon applied -- Indicates if a coupon or promo code was used for the order. It will show "None" if no coupon was applied, or the coupon code itself... Why it's useful: Helps you track the effectiveness of your marketing promotions', beside Total Amount ('Sub-total Amount + Total Taxes + Charges - Discount'), Sub-total, Discount, Aggregator Discount, Merchant Discount and Wallet credit amount, one row per order. help.urbanpiper.com/data-and-reports/getting-started documents filtering by brand, location, aggregator, order status and Meraki channel, export as CSV or XLSX, email delivery and a daily 8 a.m. schedule. SHORTFALL: this is raw data the operator must aggregate themselves, not attribution reporting. No documented column or filter identifies the Meraki SMS/email/push campaign an order came from -- only the coupon code -- so campaign-level redemption is not reported; nothing summarises redemption counts or cost; and no incremental-sales, lift or control-group measure appears anywhere in the 116-page help centre. The report suite documented on that host is order-, item- and option-level plus menu snapshots and a store action log; there is no marketing or campaign report. https://help.urbanpiper.com/data-and-reports/order-transactions-report · retrieved 2026-09-01

guest-loyalty-data-export-portability differentiator

Self-serve export without a support ticket is established for order and transaction data: Central Report exports to "CSV or XLSX formats" on demand, with filters by brand, location and aggregator, or by email link, or on a daily schedule, and no fee or approval step appears anywhere in the article. Guest identity is carried on those rows -- the Order Transactions Report defines Customer Name and Customer ID fields. SHORTFALL on both of the claim's halves. There is no guest-list export: no article documents exporting the customer table itself, only orders that happen to carry customer columns. And the PII on marketplace rows is disclaimed by the vendor -- "customer details are suggested to the information passed by DSP. Most of the DSP/Aggregators do not share the customer details. Data might be dummy" -- so usable contact data exists only for first-party Meraki orders, where Meraki's own pitch is "Access customer and order data, enabling loyalty programs and marketing automation." Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

guest-loyalty-cdp-event-api differentiator

A documented, self-configurable outbound event stream exists. 'At present, the following event types can be configured to trigger a webhook callback' enumerates fourteen: User feedback (10005), Order placed (18), Order status update (60008), Order delivery status update (60012), Catalogue Create/Update (60013), Store Create/Update (60014), Store Actions (60015), Items Actions (12004), Options Actions (12005), Category Timing Groups (60016), Hub Menu Publish (12002), Mark Order Items Stock-out (60018), Order Feature Action (60017) and Webhook Order Retry (60019). Each outbound request carries X-UPR-Event-Type and X-UPR-Biz-Id headers; subscriptions are created in Atlas (Settings > Webhooks) or via POST https://pos-int.urbanpiper.com/external/api/v1/webhooks/ with the subscriber's own url, custom headers and retry interval, and api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay documents the full order JSON delivered. SHORTFALL: it is an order and catalogue stream, not a guest stream. That enumeration contains no customer-created, profile-updated, loyalty-balance or consent event, so a CDP can subscribe to order events only; the guest identity carried inside those order events is expressly unreliable for marketplace orders ('in most cases, the phone number is not shared and hence you can expect a dummy number to be sent from our side'); and the whole surface is documented as a POS-partner integration reached through UrbanPiper onboarding, sandbox and certification rather than a self-serve subscription. No named CDP or marketing platform (Olo, Punchh, Bridg, Klaviyo) appears anywhere in the 87-page reference. https://api-docs.urbanpiper.com/downstream/api/references/webhook-event-headers · retrieved 2026-09-01

guest-loyalty-review-capture-routing differentiator

Guest feedback is captured and is available as an event. The API reference's webhook event catalogue carries 'User feedback' with unique code 10005 as a configurable outbound event, with the note 'User feedback is only for white-label websites/app (Meraki) ordering integration', so feedback is collected against first-party orders and can be pushed to an external system. help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas confirms it is a product surface, not just a payload: the Atlas Support role is 'tailored for customer service and feedback handling in Atlas. Support users can access customer details, manage feedback, and analyze NPS (Net Promoter Scores)'. SHORTFALL: the routing half of this claim is undocumented on both hosts. Across all 116 help pages and all 87 api-docs pages retrieved 2026-09-01 there is no score threshold, no split of detractors to private service recovery versus promoters to public review sites, no Google/Yelp/TripAdvisor destination, and no description of when or how a post-transaction feedback request is sent to the guest -- only that a score is collected and can be read or forwarded. Capture and NPS analysis are present; score-based routing is not shown. https://api-docs.urbanpiper.com/downstream/api/references/webhook-event-headers · retrieved 2026-09-01

guest-loyalty-referral-program

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). referral and refer-a-friend occur zero times in either doc corpus; the nearest documented mechanic is Meraki coupons (direct-ordering/configuring-coupons: manual or bulk redemption codes, date windows, item and BXGY targeting), which are not per-guest codes and carry no first-order attribution or two-sided reward. THE TRAP THIS PASS RESOLVED: www.urbanpiper.com/legal/privacy-policy section 3 says 'When You choose to invite others to join our Services through our referral feature, We collect the email address ... for such referrals' and mentions 'Our loyalty programme(s) You may register for'. Both are UrbanPiper's own programmes for its merchant customers -- the sitemap carries www.urbanpiper.com/blog/urbanpiper-india-referral-program-everything-you-need-to-know, a merchant refer-a-restaurant scheme -- and neither is a Meraki guest referral. www.urbanpiper.com/meraki lists 'Loyalty Program' but no referral. Left unknown, not no: no page enumerates the loyalty module's mechanics and the Atlas Meraki screens are unpublished. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-wallet-pass differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). Apple Wallet, Google Wallet, PassKit, .pkpass and loyalty card return zero hits in both corpora. All eleven 'wallet' hits are something else and the confusion is worth recording: help.urbanpiper.com/data-and-reports/order-transactions-report defines 'Wallet credit amount' as 'the amount of the order paid using wallet credits (e.g., Swiggy Money, Zomato Wallet)'; direct-ordering/configuring-payment-gateway lists gateway 'wallets' and 'Wallets or Loyalty Points (if configured)'; the api-docs order relay carries payment option 'wallet_credit'; and manage-campaigns exposes {{user_wallet_balance}}. New this pass, and the same shape: www.urbanpiper.com/meraki's FAQ says 'We have tools like email marketing, a free loyalty program, SMS marketing and wallet' -- a stored-value wallet inside the Meraki app, not a device pass. No enrolment or membership-card article exists on either doc host. Differentiator weight, so a grade-D page could not carry a yes regardless. Unresolved. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-privacy-rights-tooling

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). CCPA, CPRA, GDPR, DSAR, right to erasure and anonymise return zero hits in both doc corpora; the only deletion article, help.urbanpiper.com/business-manager/user-access/how-to-archive-delete-or-restore-atlas-or-prime-user, covers STAFF accounts and states 'We do not delete a user completely on Atlas'. The two legal pages read 2026-09-02 are the real new evidence and they describe a PROCESS, not tooling: www.urbanpiper.com/legal/privacy-policy section 2 makes the Merchant the Controller of Meraki customer data and UrbanPiper the Processor, and directs that 'requests and questions about the relevant Personal Data should be directed to the Merchant as Controller', adding 'We will support the Merchant in responding to You'; www.urbanpiper.com/legal/data-processing-agreement cl. 6.2 promises 'full cooperation, information and assistance ... where instructed by you' on a data-subject Request, and cl. 13 deletes all Customer Data on account termination. None of that says whether an Atlas operator can execute an access or deletion request himself, nor whether such a deletion propagates to loyalty and marketing records. Unresolved rather than no: an assistance clause is standard for vendors that do and do not ship self-serve tooling. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-redemption-fraud-controls

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). fraud, velocity, abuse, manager approval, override and adjustment return no loyalty control in either corpus. The adjacent material was weighed again: direct-ordering/configuring-coupons exposes 'Max No of Discounts' and bulk codes with start/end validation, a per-coupon cap rather than a per-guest or per-period velocity limit; data-and-reports/store-action-report is a real per-user audit log ('username', 'user_first_last_name') whose subject is store turn-on/turn-off actions, not balance edits; and the Atlas roles article separates Marketing from Support with no approval step. The www pass found nothing further -- the sitemap has no security or loyalty-administration page, and the product-update posts read announce billing, KDS and QR-on-receipt changes. Since no manual point-adjustment screen is published, there is nothing an approval gate or an employee self-redemption flag could attach to. Unresolved rather than absent. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-ai-offer-recommendation differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). Every 'AI' hit across the 203 doc pages is the identical GitBook footer stamped on all of them ('GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively'), i.e. platform boilerplate. manage-campaigns describes campaign creation as wholly manual -- the operator writes the SMS or HTML email, picks the audience, launches -- with nothing suggesting content, audience or timing. New this pass: www.urbanpiper.com's product menu carries 'Orderline AI -- Handle all customer calls, reservations and orders, with AI', which is conversational order capture, not marketing recommendation, and www.urbanpiper.com/meraki markets 'Marketing Automation' and 'Advanced Analytics' with no ML claim. Eight product-update blog posts (Nov and Dec 2024, Feb-May 2025) were read and none announces AI-generated offers, audiences or send times. Differentiator weight, so even an explicit marketing claim at grade D could not carry a yes. Unresolved. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

guest-loyalty-stored-value-gift

A native stored-value balance held against the guest exists and is spendable. Under 'Choose Payment Options' the article tells the merchant to 'Enable/disable the methods you want to accept: Online Payments (UPI, cards, net banking, wallets); Cash on Delivery (COD); Wallets or Loyalty Points (if configured)', so wallet credit and points are first-class Meraki checkout tenders rather than gateway wallets. That the balance is per guest rather than per order is documented at help.urbanpiper.com/direct-ordering/manage-campaigns, where {{user_wallet_balance}} 'Displays the customer's current wallet balance' as a personalization merge field beside {{user_points}}. SHORTFALL, on two limbs of the claim. First, no gift card: nothing on either complete first-party corpus (116 help pages, 87 api-docs pages, retrieved 2026-09-01) documents issuing, selling, activating, reloading or redeeming a gift card or e-gift, and no card number, PIN or barcode surface exists. Second, scope is unstated: the article says gateways may be configured 'globally for all outlets, or per outlet if needed' but never says a wallet balance is redeemable across all locations of a brand, and the wallet is documented only for Meraki first-party ordering -- marketplace orders relay a payment option of wallet_credit meaning the aggregator's own wallet (Swiggy Money, Zomato Wallet, per the Order Transactions Report), not this one. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-01

labor-clock-in-at-pos

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). clock-in, clock-out, time clock, timesheet, attendance and punch return nothing about employee time capture -- the only 'punch' hits are 'reducing the dependency on manual punch-ins', about order-entry speed. The single 'shift' in the whole help centre is 'Cashiers manage operational shifts using registers, process bills, and complete settlements' (business-manager/user-access/understanding-standard-roles-in-prime-and-atlas), a register session rather than a timecard. The help centre has no staff or labour section (its sections are basics, business-manager, store-manager, pos-integrations, ordering-channels, data-and-reports, direct-ordering). NEW: the Prime POS Web billing screen, which has no help-centre article, IS partly described on www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform (keyboard shortcuts: Alt+N for a new bill, Shift+Enter to settle, arrow keys to pick payment modes) and www.urbanpiper.com/blog/march-2025-product-updates-whats-new-in-our-restaurant-tech-platform (auto-selected payment method, auto-clearing of settled bills). Those describe billing only and mention no login-to-shift or clock-in step; they are grade-D partial views of one screen and cannot bound it. Unresolved. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-photo-punch-verification differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). The prerequisite is missing: neither doc host documents a clock-in, timesheet or attendance flow at all, so a photo attached to a timecard entry, and the photo-only mode this claim also requires, cannot be assessed. biometric, facial and face return zero hits in both corpora. The Prime app articles under help.urbanpiper.com/store-manager/prime-app cover wifi, printers, login, auto-print, notifications, the order tracker, 86ing and pause/resume, and the only employee identity mechanism documented anywhere is PIN login (business-manager/user-access/how-to-reset-pin-for-store-operations). New this pass: the www sitemap has no staff, security or attendance page, and the Prime-focused posts read (prime-latest-design-upgrade-top-6-exciting-highlights, and the Dec 2024 / Mar 2025 billing updates) announce no camera or verification feature. Unresolved: no page states photo punch is unsupported. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-geofenced-mobile-punch

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). geofence and geo-fence return zero hits in both corpora. Every 'location' in the help centre is an Atlas store outlet (business-manager/creating-a-new-location, business-manager/setting-up-schedules-for-locations), and the only coordinate feature in the API is rider tracking (api-docs.urbanpiper.com/downstream/api/endpoints/order-management/self-delivery-rider-management/rider-live-tracking) -- a delivery driver, not a staff punch. No mobile employee clock-in exists in the documentation to be geofenced. New this pass: the www sitemap carries no workforce or mobile-staff page and none of the eight product-update posts read mentions staff location validation. Unresolved rather than negative: nothing published asserts the restriction is unavailable. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-offline-time-punch differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). The offline hits across both corpora are: business-manager/deactivate-a-location (taking a location offline permanently), store-manager/prime-web/cloud-printing-setup-guide and /print-automations (printer offline fallback, failed print jobs), the Zomato and Swiggy menu articles ('this mapping is carried out offline, with assistance from the Zomato team'), and an API error string 'Your outlet is currently offline due to high number of rejections'. None concerns a time clock, and no clock-in feature is documented on either host in the first place. New this pass: Prime's offline behaviour generally is still unpublished -- the www product-update posts read (Nov and Dec 2024, Feb-May 2025) cover KOT timing, KDS 2.0, billing shortcuts and QR receipts, with no connectivity-loss or queue-and-sync note. Unresolved: no page states that punches cannot be recorded offline. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-granular-rbac

Split model. Prime, the store side, ships six standard roles (Captain, Online Order Processor, Online Order Supervisor, Cashier, Manager, Administrator) plus custom roles — 'Prime gives you the flexibility to create custom roles tailored to your specific needs. With custom roles, you can assign very specific permissions, giving you granular control over what each team member can do' — with location-based restriction. The shortfalls: Atlas, the management console, offers only ten fixed standard roles with no custom-role option, and 'location-level access is not available in Atlas'; and the article asserts granularity generically without enumerating discrete-action permissions of the kind the claim names (void, comp, discount, refund, drawer open, price change), so per-action grantability is not documented. https://help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas · retrieved 2026-08-04

labor-manager-override-audit

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas enumerates 6 Prime roles and 10 Atlas roles and notes custom Prime roles with 'very specific permissions', but permissions there are access scope, not approval gates: nothing in it or in the Prime app / Prime web articles describes a manager override or approval prompt for voids, comps, discounts or price changes. help.urbanpiper.com/data-and-reports/store-action-report is a genuine audit trail with 'username' and 'user_first_last_name' for 'every operational change made to your stores', but its subject is store-level platform actions (publish, enable, disable). The api-docs surface (stores, menu, order relay, order-status-update, availability, riders) exposes no approval or audit object. New this pass: www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform and /blog/march-2025-product-updates-whats-new-in-our-restaurant-tech-platform describe the Prime POS Web billing flow (shortcuts, payment mode selection, settle, auto-clear) without any authorisation step, but a marketing round-up of new shortcuts does not bound the screen's permission model. Unresolved. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-native-scheduling differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). The scheduling concepts documented are business-manager/setting-up-schedules-for-locations (store operating hours), ordering-channels/zomato/category-schedules and .../swiggy/category-schedules (item availability windows), business-manager/publishing-your-menu (scheduled publish) and data-and-reports/getting-started ('Scheduling Reports', a recurring 8 a.m. email). roster, rota, shift schedule and shift plan return nothing in either corpus, and the only 'shift' in 479,604 chars of help content is a cashier register session. New this pass and pointedly not a finding of presence: www.urbanpiper.com/blog/upgraded-industry-leading-analytics-module-for-restaurants says order-frequency heatmaps let you 'optimize staff schedules' -- i.e. the operator schedules staff somewhere else using UrbanPiper's demand data. That is grade D and, if anything, points away from a native scheduler; a differentiator yes would need A or B regardless. Unresolved: no page states shift scheduling is unavailable. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-demand-labor-forecast differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). The documented reporting surface is data-and-reports: order-transactions, order-status-transitions, item-wise-order-transactions, items-summary-across-all-locations, option-wise-order-transactions, menu-snapshot-across-all-locations and store-action, all CSV/XLSX exports of order and menu data; forecast, staffing and labour hours return nothing relevant in either corpus, and no wage or headcount data enters the platform. NEW AND WEIGHED: www.urbanpiper.com/blog/upgraded-industry-leading-analytics-module-for-restaurants (read 2026-09-02) says 'Our order frequency heatmaps highlight your restaurant's peak hours and days. This allows you to optimize staff schedules, meet customer demand, and reduce wait times.' That is demand analytics offered as an input to a human decision, not recommended staffing levels or labour hours by daypart, and it is grade D on a differentiator claim. I did not read the doc silence as absence: data-and-reports/getting-started describes the Central Report list as 'order transactions, item-wise transactions, item summaries, and more'. Unresolved. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-realtime-labor-percent differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). labour/labor cost, wage and salary return zero hits across both corpora. business-manager/user-access/understanding-standard-roles-in-prime-and-atlas describes the analytics roles as 'Sales Analytics' ('comprehensive reports on orders and revenue') and 'Operation Analytics' ('order status metrics'), with the Prime Manager role handling 'inventory transactions and review important reports and analytics' -- no cost-of-labour view. Since no timekeeping or pay-rate input is documented, a live labour-percentage view has no documented inputs. New this pass: www.urbanpiper.com/blog/upgraded-industry-leading-analytics-module-for-restaurants and the April 2025 product-update post describe the analytics module as order heatmaps, line/area charts and shareable reports, with no cost metric; both are grade D and neither enumerates the dashboard's tiles. Unresolved because no page states the metric is unavailable. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-overtime-prevention differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). overtime, OT threshold and hours worked return zero hits across help.urbanpiper.com (116 pages) and api-docs.urbanpiper.com (87). No clock-in flow is documented anywhere on either host, so no punch event exists at which a warning or block could be raised, and the help centre carries no staff or labour section at all. New this pass: the www sitemap (read in full 2026-09-02) contains no workforce, compliance or scheduling page, and the eight product-update posts read announce ordering, kitchen, billing and inventory changes only. Unresolved rather than no: no vendor page states that overtime thresholds are unsupported, and index silence is not evidence of absence. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-break-compliance-by-state differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). meal break, rest break, break attestation and premium pay return nothing in either corpus. The only jurisdiction-specific configuration documented anywhere is fiscal or telecom: GST registration status in the Zomato and Swiggy troubleshooting articles, business-manager/creating-a-menu/create-and-manage-taxes, and DLT template registration in direct-ordering/setting-up-your-own-mask-id-for-sms. There is no employee time record to which a break rule, attestation prompt or missed-break flag could attach. New this pass: the www sitemap carries no US labour-compliance page and the country switcher on www.urbanpiper.com covers market localisation of the product, not employment law. Unresolved: nothing published states per-state break rules are unsupported. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-fair-workweek-support

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). fair workweek, predictive scheduling, predictability pay and advance notice return zero hits in both corpora. Every scheduling article concerns store hours, menu-category timings or scheduled report delivery (business-manager/setting-up-schedules-for-locations, ordering-channels/zomato/category-schedules, data-and-reports/getting-started), so no published employee schedule exists for an ordinance clock. New this pass: the full www sitemap (2026-09-02) lists no labour-compliance, scheduling or workforce page, and none of the eight product-update posts read touches staff scheduling. Left unresolved because no page states this is unsupported; the capability is simply outside the documented surface of Atlas and Prime. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-minor-labor-rules

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). minor labour/labor, school day, age restriction and prohibited hours return nothing in either corpus. The employee model that IS documented is purely access: business-manager/user-access/understanding-standard-roles-in-prime-and-atlas (6 Prime roles, 10 Atlas roles, custom Prime roles), /how-to-reset-pin-for-store-operations and /how-to-archive-delete-or-restore-atlas-or-prime-user -- no date of birth, age or availability field, and neither of the two enforcement points this claim names (scheduling and clock-in) exists in the documentation. New this pass: the www sitemap carries no HR or compliance page; the legal pages read (privacy-policy, data-processing-agreement) address customer data, and the privacy policy's only minors content is about a Merchant's customers, not staff. Unresolved: no published page asserts these controls are absent. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-tip-pooling-rules

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). All 'tip' occurrences were read and each is 'Driver Tip', enumerated among the expected charge titles in api-docs.urbanpiper.com/downstream/order/order-components ('Restaurant Packaging Charge', 'Packaging Charge', 'Delivery Charge', 'Service Charge', 'Driver Tip', 'Surcharge', 'Other Charges') and repeated in the Zomato, Swiggy, Talabat, Careem, Deliveroo, Uber Eats and Just Eat constraint pages -- money for the delivery rider, passed through from the channel. tip pool, tip-out and gratuity return zero hits in both corpora. New this pass: www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform and /blog/march-2025-product-updates-whats-new-in-our-restaurant-tech-platform describe the Prime POS Web settlement flow (payment mode selection, Shift+Enter to settle, auto-clear) with no tip entry, but a shortcuts round-up does not enumerate that screen's fields. Unresolved rather than no: the charge list bounds the aggregator order payload, not Prime's billing surface. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-tip-distribution-audit-trail

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). The only tip concept documented is the aggregator 'Driver Tip' charge (api-docs.urbanpiper.com/downstream/order/order-components), which is the rider's. The reporting surface was re-read: help.urbanpiper.com/data-and-reports/order-transactions-report enumerates its columns one by one (ID, order ref, brand, channel, timestamps, order state, payment mode, totals, discounts, taxes, charges, wallet credit, customer, store, city, fulfilment mode, delivery type) with no employee, cashier or tip-share field; item-wise, option-wise, items-summary, menu-snapshot, order-status-transitions and store-action carry none either. That bounds those reports and not the surface: data-and-reports/getting-started calls the Central Report list 'order transactions, item-wise transactions, item summaries, and more'. New this pass: the December 2024 product-update post announces report scheduling on Atlas and the April 2025 post shareable analytics, neither adding a per-employee tip record. Unresolved on that 'and more' plus the undocumented Prime settlement screen. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-qualified-tips-w2-reporting differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). W-2, Box 12, Box 14, qualified tips, tipped occupation and payroll return zero hits across both corpora. The only tip in the data model is the aggregator 'Driver Tip' charge on an order (api-docs.urbanpiper.com/downstream/order/order-components), and the documented tax content is menu-level GST/VAT configuration (business-manager/creating-a-menu/create-and-manage-taxes), not employment tax. New this pass: www.urbanpiper.com/legal/privacy-policy section 2 enumerates the principal products and their data flows (Hub, Atlas, Meraki, Orderline, Lens, Periscope) with no employee-compensation data anywhere in them, and the www sitemap holds no US tax or payroll page. That bears on whether UrbanPiper runs payroll at all (scored separately at labor-native-payroll) but says nothing about a payroll EXPORT carrying a tipped-occupation code, which is what this claim asks. Unresolved: nothing published addresses the tax-year-2026 requirement either way. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-native-payroll differentiator

Adversarial enumeration audit 2026-09-02 withdrew an asserted `no`. The verdict rested on www.urbanpiper.com/legal/privacy-policy section 2, which I re-read from the cached body: it introduces itself as 'This section explains how Personal Data flows through Our principal Products and whether We act as a Controller or a Processor in each case' and then takes Hub, Atlas, Meraki, Orderline, Lens and Periscope in turn. 'Principal Products' is a self-limiting phrase, so the list is a strong inventory and not a self-asserted complete one, and a product inventory that never claims to be complete cannot ground a `no`. The same applies to the DPA's Schedule A, whose per-module data categories are introduced as 'Such categories may include the following categories of data: (i) For the Atlas module: name, e-mail address, phone number, location data, gender, birthday, anniversary, system access / usage / authorization data, device data; (ii) For the Prime Module: name, e-mail address, phone number, date of birth, location data, customer tax number, system access / usage / authorization data, device data' -- no employee compensation, bank-account or tax-withholding category appears, but 'may include' bounds nothing. What is true and re-measured: 'payroll', 'direct deposit', 'pay run', 'tax filing', 'attendance', 'timesheet' and 'time clock' return ZERO hits across all 116 pages of help.urbanpiper.com and all 87 of api-docs.urbanpiper.com (the two on-disk corpora, re-grepped 2026-09-02), and the site's Products menu offers only Orderline AI, Hub and Meraki. That is silence plus marketing, which is `unknown`, not evidence of absence. No counter-evidence of a first-party payroll product was found either: a web search surfaced only a denylisted review-directory feature checkbox, which is not usable as evidence in either direction. changelog.urbanpiper.com (named-allowlist robots, `User-agent: *` `Disallow: /`) was not fetched; support.urbanpiper.com remains an unresolvable robots redirect loop, so the first-party surface is not closed.

labor-payroll-export-formats

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). Gusto, ADP, Paychex, QuickBooks, Xero, Zoho, Deputy, 7shifts and payroll itself return zero hits across both doc corpora. What is documented is data-and-reports/getting-started: reports pulled from the Atlas 'Central Report' app, previewed or downloaded 'in either CSV or XLSX formats', optionally emailed on a daily 8 a.m. schedule -- all order, item and menu data, with no timecard, wage or tip-share content to export. New this pass: www.urbanpiper.com/integrations was read 2026-09-02 and its category filter offers only 'POS Systems', 'Fulfilment', 'Delivery platforms' and 'Online Ordering', with no payroll or workforce category among the ~200 partners listed -- but an integration directory is near-universally incomplete and may not ground a no. Unresolved, doubly: the report list is described open-endedly ('order transactions, item-wise transactions, item summaries, and more') and the directory bounds nothing. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-shift-swap-workflow differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). shift swap, open shift, shift request and time-off return zero hits in both corpora; the only 'shift' in the entire help corpus is 'Cashiers manage operational shifts using registers' (business-manager/user-access/understanding-standard-roles-in-prime-and-atlas), meaning a register session. The Prime app documented at help.urbanpiper.com/store-manager/prime-app is an order-taking and store-availability tool (order tracker, printing, KOT, 86ing, pause/resume), and no employee schedule is published for a swap or claim to act on. New this pass: www.urbanpiper.com/blog/prime-latest-design-upgrade-top-6-exciting-highlights and the November 2024 to May 2025 product-update posts describe Prime's redesign, billing shortcuts and KOT routing with no staff self-service surface. Unresolved: no page states the workflow is unsupported. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-digital-onboarding-i9

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). All 'onboarding' hits were read and each is merchant or integration-partner onboarding: 'the onboarding team will take care of setting up your account' (business-manager/introduction), the assigned 'UrbanPiper Onboarding Manager' running the three-phase Foodics integration (pos-integrations/foodics), and api-docs.urbanpiper.com/downstream/getting-started/onboarding-process for POS partners, plus GitBook template boilerplate. W-4, I-9 and E-Verify return zero hits in both corpora. The documented employee lifecycle is access only (business-manager/user-access/*: invite a user, assign a role, reset PIN or password, archive/delete). New this pass: the www sitemap has no HR, hiring or onboarding page for restaurant staff (its careers content is UrbanPiper's own hiring), and the legal pages read cover customer data rather than employment records. Unresolved because no published page addresses new-hire documentation either way. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

labor-server-performance-metrics differentiator

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). All seven report articles were re-read. help.urbanpiper.com/data-and-reports/order-transactions-report says 'each row in this report represents a single order, and each column (or field) provides specific information about that order' and then names every column -- ID, order ref ID, brand, brand ID, external platform ID, channel, created at, order state, requested delivery time, time slots, payment mode, payment transaction ID, coupon, totals, discounts (aggregator and merchant), taxes, charges, wallet credit, customer name and ID, store name/ID/ref, city, fulfilment mode, delivery type -- with no cashier or server field. data-and-reports/store-action-report does carry 'username' and 'user_first_last_name' but logs store-level platform actions (publish, enable, disable), not per-employee sales, and no report exposes average check, attachment rate or void/comp rate by staff member. New this pass: www.urbanpiper.com/blog/upgraded-industry-leading-analytics-module-for-restaurants and the April 2025 post describe the analytics module as heatmaps, line/area charts and shareable reports, naming no per-employee metric -- grade D and not an enumeration. Left unresolved because data-and-reports/getting-started calls the list 'order transactions, item-wise transactions, item summaries, and more'. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'.

inventory-recipe-bom-costing

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Recipes exist in UrbanPiper's own Prime Inventory but no recipe COST does. The December 2024 product-update post describes a Batch Production module in which shelf life is set per recipe via an 'Expires In (Days)' field and batch numbers make stock 'traceable, from raw materials to final products'; the January 2024 post sets a minimum stock level 'for your ingredients'. Nothing anywhere names a component cost, a plate or dish cost, a sub-recipe/prep-item nesting level, or recalculation when an ingredient cost moves. Case-insensitive 'recipe' returns ZERO hits in the 116-page help corpus and exactly two in the API corpus, both the menu-push glossary's 'default item recipe' meaning the default modifier set (options_to_add / options_to_remove); 'cost of goods', 'COGS', 'plate cost' and 'sub-recipe' return zero help hits. The help centre documents no inventory module at all -- its only stock pages are store-manager/prime-app/86ing-an-item-or-modifier and store-manager/prime-web/86ing-an-item-or-modifier, which are on/off availability toggles with snooze. Unresolved because the costing half of this claim has no published source in either direction and the blog posts are grade D describing a pilot.

inventory-unit-conversion-yields

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Ingredients with stock levels exist (January 2024 post: set a minimum stock level 'for your ingredients' in the stock levels module) and the December 2024 Batch Production module carries recipe shelf life and automatic batch numbers, piloted 'with select restaurant partners' in India. But no purchase unit, recipe unit, count unit, conversion factor or yield/waste percentage is published: case-insensitive 'yield', 'waste', 'conversion factor' and 'unit of measure' return ZERO hits in both corpora, and the only quantity fields in any published schema are the menu-push item's scalar 'price' and an integer 'current_stock' per item per store (api-docs downstream/menu/architecture and downstream/api/endpoints/menu/add-update-menu), which is a channel availability count carrying no unit at all. Unresolved: the unit mechanics this claim requires are not published on either doc host.

inventory-theoretical-vs-actual differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. No physical count of any kind is documented, so the 'actual usage from counts' input this report requires has no published existence: 'stock count', 'physical count', 'cycle count' and 'variance' return ZERO hits in both corpora. The only count-shaped feature published anywhere is the per-ingredient 'Critical Stock Level' alert of the January 2024 Stock Automation Module post. No source mentions a variance report, theoretical usage, or usage expressed in currency, and none of the seven documented Atlas reports (data-and-reports/order-transactions-report, order-status-transitions-report, item-wise-order-transactions-report, items-summary-across-all-locations-report, option-wise-order-transactions-report, menu-snapshot-across-all-locations-report, store-action-report) carries a cost or usage column -- I read the Order Transactions field list heading by heading. Unresolved rather than negative because Prime Inventory is documented only in dated blog posts, never in the help centre, so the corpora bound the DOCUMENTATION surface and not the module's feature set.

inventory-realtime-depletion differentiator

PARTIAL. Event-driven ingredient depletion is documented, but only in a product-update post and only as an opt-in module. The January 2024 product update states that stock deductions were 'revised ... to occur only after you acknowledge an order, rather than solely after order placement in your online order tracker' -- so depletion is tied to the order event, not an end-of-day batch, which is the axis this claim turns on. The same post establishes that the units being depleted are ingredients: 'you can set a minimum stock level for your ingredients in the stock levels module', and 'Low Inventory Stock Alerts are part of Prime's comprehensive Stock Automation Module'. SHORTFALLS, all three named: (1) the Stock Automation Module is not standard -- 'To enable this Module, reach out to us at support@urbanpiper.com'; (2) the post states availability only 'for all our restaurant partners in India'; (3) no source anywhere states that modifier/option selections drive depletion, and the claim requires that limb explicitly. Note also that the POS-partner API models item stock as a single integer 'current_stock' pushed BY the POS (add-update-menu: 'The stock of the item at the outlet. If the item is never supposed to go out of stock, set this to -1') with no ingredient entity, so in an integrated deployment the depletion is the POS's, not UrbanPiper's. https://www.urbanpiper.com/blog/january-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

inventory-86-auto-sync differentiator

PARTIAL. The threshold-to-86 link is documented, but only in a product-update post. January 2024: 'Now you can set a minimum stock level for your ingredients in the stock levels module. When your stock reaches or falls below the minimum stock level, you will get a notification and your item status will be updated', with the threshold set as a 'Critical Stock Level' on each ingredient's 'Stock levels' tab. Pushing that item status outward to third-party delivery menus is UrbanPiper's core documented function (api-docs downstream/availability/item-option and the Item/Option action API's enable/disable/stock-in/stock-out actions). SHORTFALLS: (1) the auto-86 on threshold appears nowhere in the 116-page help centre -- only in a grade-D blog post -- and belongs to the Stock Automation Module, which must be switched on by emailing support and was announced for India only; (2) the claim's 'on the POS' limb is unestablished: in an integrated deployment the POS is the source of item stock (it pushes 'current_stock' to UrbanPiper), so the documented flow runs outward to aggregators rather than back into a third-party till. https://www.urbanpiper.com/blog/january-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

inventory-count-modes

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. The only inventory the help centre documents is availability: the Prime app and Prime Web stock pages (store-manager/prime-app/86ing-an-item-or-modifier, store-manager/prime-web/86ing-an-item-or-modifier, and the Order Tracker's 'Stock Control' button at store-manager/prime-app/manage-orders-on-order-tracker) are on/off toggles with snooze and a Logs tab. A back-office module exists in blog posts only -- Prime's Stock Automation Module (January 2024) and Prime Inventory's Batch Production module (December 2024, 'currently being piloted with select restaurant partners') -- and neither describes a full physical count, an ad-hoc spot count, a scheduled cycle count, count history or per-count variance. 'physical inventory', 'spot count' and 'cycle count' return ZERO hits in both corpora. Unresolved because the module has no help-centre documentation at all, so nothing bounds its count workflows either way.

inventory-mobile-count-offline

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Prime ships a tablet app whose hardware and connectivity are documented in detail (basics/compatible-hardware, store-manager/prime-app/connecting-your-tablet-to-wifi), and there IS a barcode workflow -- store-manager/prime-web/scan-and-pack-workflow, in which 'each item in an order gets its own printed barcode label' and 'Kitchen staff scan each label before the order is sealed', governed by a 'Scan Barcode Flow' setting that 'Requires activation by the UrbanPiper team'. That scans items into an outbound packing checkpoint, not counts into a stock ledger. No source mentions counting on a mobile device, scanning for stock counts, offline count capture or sync-on-reconnect; every 'offline' hit in these corpora is a store being offline on an aggregator. Since no count workflow of any kind is documented (see inventory-count-modes) the mobile question cannot be reached. Unresolved.

inventory-vendor-catalogs-edi differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'supplier', 'distributor', 'purchase order', 'Sysco', 'US Foods' and 'Performance Food Group' return ZERO hits across both corpora (the apparent 'EDI' matches are all substrings of 'edit'/'edited'), and none appears in the three product-update posts I read by hand. The help centre's integration overview (basics/partner-with-us) tabulates the ecosystem in five categories -- Online Aggregators, POS Systems, Logistics Partners, Payment Gateways, Marketing & Loyalty -- with no procurement or distributor category, but every row of that table ends in 'and more', so it is an overview and NOT an exhaustive enumeration and cannot carry a no. Unresolved on the evidence available.

inventory-invoice-ocr differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'invoice' appears twelve times in the help corpus and never about a supplier: it is printer assignment for KOT/invoice (store-manager/prime-web/assigning-a-printer-for-kot-invoice) and the Atlas Billing role, which 'can access detailed transaction records and invoices' for the merchant's own UrbanPiper subscription (business-manager/user-access/understanding-standard-roles-in-prime-and-atlas). 'OCR', 'scan invoice', 'line-item extraction' and 'accounts payable' return ZERO hits in both corpora and in the three 2024-2025 product-update posts I read by hand. No purchasing or receiving surface is documented at all, so there is no ledger for an extracted line to land in. Unresolved: absence from the documentation is not a statement by the vendor.

inventory-price-change-alerts differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. UrbanPiper documents price history, but of SELLING prices: the Menu Snapshot Across All Locations report carries an internal 'Price' beside 'Aggregator Price' per item per store, and the API models store-level item price overrides (downstream/menu/architecture: the metadata that varies between stores is price, current_stock, sort_order, recommended, availability). Nothing concerns what the restaurant PAID -- no receiving, supplier, invoice line or contracted price appears anywhere in either corpus -- and the only threshold alert published is the January 2024 per-ingredient 'Critical Stock Level', a quantity threshold rather than a price one. Unresolved because purchasing is absent from the documented surface rather than stated to be absent from the product.

inventory-par-auto-suggest differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Half of the first limb is met: the January 2024 product-update post documents a per-ingredient minimum -- 'navigate to the Stock levels tab within each of the ingredient's settings and simply set their Critical Stock Level' -- which is a par in all but name, though no source says it is held per location and the post is grade D. The rest is unevidenced: 'purchase order', 'reorder' and 'suggested order' return ZERO hits across both corpora, so nothing can generate suggested quantities from on-hand versus par, and 'forecast' likewise returns zero in both corpora and in the March 2025, February 2025 and November 2024 posts I read by hand. Left unknown rather than partial because the substance of the claim is the suggested-PO engine and there is no evidence in either direction about it.

inventory-waste-logging

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Case-insensitive 'waste' returns ZERO hits in both corpora; in the blog it appears only rhetorically ('Keep Your Inventory Fresh & Waste-Free', 'Less food waste, better order timing' about scheduled-order KOT print timing) and in evergreen SEO articles about inventory mistakes, never as a product feature. 'spoilage' and 'wastage' return nothing; the only reason codes documented anywhere are order-cancellation reasons in the partner API (item_out_of_stock, store_busy, store_closed, rider_not_available, out_of_delivery_radius). No structured waste log, no inventory debit for waste and no waste-cost reporting is published, and the help centre documents no inventory ledger for such a debit to hit. Unresolved.

inventory-transfers

PARTIAL. Inter-location transfers exist as a named part of Prime's Inventory Module, but only a filter change is documented, not the accounting. The November 2023 product update says: 'Now you can filter your Transfer Requests by delivery date ranges on the Transfers list view page ... so you can easily prioritise and plan your preparations based on the nearest upcoming delivery dates', reached by 'go to the Inventory Module on Prime and select Transfers', with the delivery date shown in a 'Dates' column and the filtered set exportable. That a transfer is a REQUEST carrying a future delivery date implies a raise-then-fulfil lifecycle. SHORTFALLS: no source states the two-sided credit/debit this claim requires, none names an explicit in-transit or approval state, and none states that the two ends are different LOCATIONS rather than a central kitchen issuing to itself. The whole Inventory Module is absent from the 116-page help centre, and the post announces availability for India only. https://www.urbanpiper.com/blog/november-2023-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

inventory-commissary

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Two ingredients of a commissary model are separately documented in blog posts and nothing joins them: Prime Inventory's Batch Production module turns raw materials into final products with automatic batch numbers (December 2024), and Prime Inventory Transfers use dated transfer requests so you can 'plan your preparations based on the nearest upcoming delivery dates' (November 2023). No source describes a central-kitchen or commissary model, names a producing location issuing to consuming locations, or mentions a transfer COST -- 'commissary', 'central kitchen' and 'transfer cost' return ZERO hits across both corpora, and no cost figure of any kind appears in the inventory material (see inventory-recipe-bom-costing). Unresolved: the shape is suggestive, the claim's computed transfer cost is unevidenced.

inventory-lot-traceability

PARTIAL. Batch numbers and a traceability claim are documented, but not at the points this claim names. The December 2024 product update describes 'Batch Number & Expiry Tracking in Prime Inventory's Batch Production module': 'Effortless Batch Tracking: Automatic batch number assignment keeps your inventory organized and traceable, from raw materials to final products', with 'detailed reports with batch numbers and expiry data'. SHORTFALLS: (1) batch numbers are assigned automatically at PRODUCTION, and no source describes capturing a supplier lot at receiving -- no receiving surface is documented at all; (2) the traceability asserted runs raw material to finished product and stops there, with nothing linking a batch onward to a sale or a transfer, so neither a forward nor a backward recall trace is evidenced end to end; (3) the vendor states the feature 'is currently being piloted with select restaurant partners and will soon be available to all', announced for India only, and it appears nowhere in the 116-page help centre. https://www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

inventory-shelf-life-expiry

PARTIAL. Expiry dating is documented for prepped items. December 2024: 'Stay on Top of Freshness: Set shelf-life limits for recipes with easy "Expires In (Days)" tracking to ensure every dish meets your quality standards', and 'Actionable Insights: Access detailed reports with batch numbers and expiry data to make informed stock decisions in real time', both in Prime Inventory's Batch Production module. SHORTFALLS: (1) the shelf life is set on the RECIPE, i.e. on prepped output -- no source describes capturing a use-by date on a RECEIVED item, and no receiving surface is documented anywhere; (2) what is offered is a report carrying expiry data, not the expiring-soon report or pre-spoilage alert this claim names -- the only threshold alert published in Prime Inventory is the January 2024 quantity-based Critical Stock Level; (3) the vendor states the feature 'is currently being piloted with select restaurant partners', announced for India only, and it is absent from the 116-page help centre. https://www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

inventory-bar-partial-bottle

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'scale', 'weight', 'bottle', 'pour' and 'liquor' return no product hits in either corpus; the single 'item weights' occurrence is a KDS display indicator in the April 2025 product-update post, not a stock measurement. The one stock quantity in any published data model is the API's integer 'current_stock' per item per store (downstream/menu/architecture, add-update-menu), which cannot express a fraction of a bottle, and no ingredient unit of measure is published at all (see inventory-unit-conversion-yields). No scale hardware appears in basics/compatible-hardware, whose scope is tablets and printers. Unresolved: this is a bar capability at a vendor whose documented customers are delivery-led restaurants, but nothing published states its absence.

inventory-cogs-gl-export

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'QuickBooks', 'Sage', 'NetSuite', 'Xero', 'general ledger' and 'GL account' return ZERO hits in both corpora and 'COGS' returns zero help hits. What IS documented is generic export with no cost side: data-and-reports/getting-started describes Central Report exporting order, item and option data as CSV or XLSX, emailable and schedulable ('the default schedule is set to deliver reports at 8 a.m. for the previous day'), and I read the Order Transactions field list heading by heading -- Payment Mode, Payment Transaction ID, Coupon applied, Total Amount, Merchant Total, Sub-total Amount, Discount, Aggregator Discount, Merchant Discount, Merchant Taxes, Total Taxes, Charges, Wallet credit amount -- with no cost, COGS or GL column anywhere. The integration overview (basics/partner-with-us) lists five partner categories with no accounting category, but each row ends 'and more', so it cannot carry a no. Unresolved.

inventory-native-not-partner differentiator

PARTIAL. The inventory module is UrbanPiper's own, not a resold third party: the December 2024 update names 'Prime Inventory's Batch Production module', the January 2024 update names 'Prime's comprehensive Stock Automation Module', and the November 2023 update instructs 'go to the Inventory Module on Prime and select Transfers' -- Prime being UrbanPiper's own store-manager application. The help centre corroborates that inventory is a first-party responsibility: the Prime Manager role 'handle[s] inventory transactions' (business-manager/user-access/understanding-standard-roles-in-prime-and-atlas). SHORTFALLS: (1) it is not part of the standard product -- 'To enable this Module, reach out to us at support@urbanpiper.com' (January 2024) -- and Batch Production was 'currently being piloted with select restaurant partners'; (2) the announcements are India-only; (3) the claim's second half, recipe COSTING, is unevidenced entirely: no cost field, plate cost or margin appears in any published source (see inventory-recipe-bom-costing), so native delivery is established for inventory but not for costing. Differentiator weight bars a yes on grade-D blog evidence regardless. https://www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

inventory-menu-margin-linkage differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. The sales-mix half is fully documented and the cost half does not exist. Atlas publishes an Items Summary Across All Locations report (Item ID, Item Name, Item ref ID, Total Quantity, Total Amount, Total Taxes, Total Charges) and an Item-wise Order Transactions Report with per-item Quantity and Unit Price, so item mix and revenue are there field by field. Neither carries a cost column, and no recipe cost exists anywhere to join to (see inventory-recipe-bom-costing); 'contribution margin', 'food cost' and 'margin threshold' return ZERO hits across both corpora. Unresolved because the missing input is unpublished rather than stated to be absent.

reporting-realtime-dashboard

Hub markets a centralised reporting dashboard with operational and sales data; refresh latency and off-premise mobile access are not specified. https://www.urbanpiper.com/hub · retrieved 2026-08-01

reporting-eod-closeout

A day-end workflow exists: Prime's design-upgrade post lists 'Business Day End' among the features reachable from the POS sliding panel ('access features such as Business Day End, Order Voiding, Notes Screen, etc. from a sliding panel'), and the user-access help article has Cashiers who 'manage operational shifts using registers, process bills, and complete settlements'. The shortfall: no published page describes what the Business Day End produces, so the claim's single-document reconciliation — gross and net sales, tax, tips, discounts, refunds, tender types and expected cash deposit — is unverified; the help centre's Data & Reports section contains only per-order transaction exports, none of them an EOD packet. https://www.urbanpiper.com/blog/prime-latest-design-upgrade-top-6-exciting-highlights · retrieved 2026-08-04

reporting-pmix-modifier-level

Modifier-level sales data is published: the Option-wise Order Transactions Report gives 'a breakdown of every single customization, add-on/Variant, and option chosen for each item in an online order' with Option Title, Option Price, Option Quantity and Option Group ID per row alongside order channel, store and date-time, and item-level counterparts exist (Item-wise Order Transactions; Items Summary Across All Locations). The shortfalls: these are row-level transaction exports over online orders, not an aggregated product-mix view; no gross-versus-net sales fields are documented at option level; and no daypart or revenue-centre filtering is documented — slicing is by channel, store and date only. https://help.urbanpiper.com/data-and-reports/option-wise-order-transactions-report · retrieved 2026-08-04

reporting-comps-voids-audit

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. I re-read the Order Transactions Report page heading by heading on 2026-09-02: its four sections enumerate every column (Order Identification & Source; Order Status & Timing; Payment & Financials -- Payment Mode, Payment Transaction ID, Coupon applied, Total Amount, Merchant Total, Sub-total Amount, Discount, Aggregator Discount, Merchant Discount, Merchant Taxes, Total Taxes, Charges, Wallet credit amount; Customer & Store Details; Fulfillment Details). Discounts are reported as order-level money with no employee, approver, reason code or override attached. The one report that attributes actions to people is the Store Action Report (action_time, action_performed publish/enable/disable, application_src, username, user_first_last_name) and its scope is store status changes, not comps, voids or price overrides. 'void' returns no product hits in either corpus -- every match is 'avoid'. Unresolved rather than negative because data-and-reports/getting-started describes the catalogue as 'order transactions, item-wise transactions, item summaries, and more', so the report list does not assert its own completeness.

reporting-cash-over-short

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. A register workflow does exist in UrbanPiper's own till: the May 2024 product-update post describes enabling or disabling 'your register workflow on Prime POS' for 'cashiers who do not require a formal register opening and closing process', with 'Registers open with zero balance and unsettled bills are forcefully settled in cash at the end of the business day', and business-manager/user-access/understanding-standard-roles-in-prime-and-atlas confirms 'Cashiers manage operational shifts using registers, process bills, and complete settlements'. But no over/short REPORT is published: 'over/short', 'declared cash', 'expected cash', 'paid-out' and 'drawer count' return ZERO hits in both corpora, none of the seven Atlas report pages carries a drawer, shift or till column, and the only 'cash drawer' string in all 116 help pages is an 'Auto Open Cash Drawer' checkbox in FOODICS' console (pos-integrations/foodics/configuring-payment-methods), i.e. a third-party POS setting. Prime POS reporting has no help-centre documentation at all. Unresolved.

reporting-labor-productivity

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. No time clock is documented anywhere on either host, so the actual clocked hours this claim takes as its input have no published source: 'clock in', 'time clock', 'timesheet', 'overtime' and 'payroll' return ZERO hits across both corpora. The Prime and Atlas roles at business-manager/user-access/understanding-standard-roles-in-prime-and-atlas -- Captain, Online Order Processor, Online Order Supervisor, Cashier, Manager, Administrator -- are access permissions, not attendance or scheduling, and business-manager/setting-up-schedules-for-locations creates open/close TIMES for a location, i.e. trading hours. None of the seven Atlas reports carries an hours, wage or labour column. The one adjacent mention is marketing framing in the April 2024 analytics post ('optimize staff schedules') about order-frequency heatmaps. Unresolved: a plausible non-surface for a middleware vendor, but no page states it.

reporting-server-scorecards differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Per-server metrics have no published home. I read all seven Atlas report articles' field lists; none carries a server, waiter, employee or tip column, and the closest actor attribution anywhere is the Store Action Report's 'username' / 'user_first_last_name', which records who toggled a store, not who sold. Average check is published only as 'Avg. Order value' in Atlas Analytics (April 2024 product-update post) cut by location, platform and brand -- the three dimensions that post names -- never by employee. Prime does have a front-of-house Captain role that 'take[s] customer orders, especially for dine-in', so the underlying data could exist, but no source describes reporting on it, and 'attachment rate' and 'items per check' return zero hits in both corpora. Unresolved.

reporting-channel-profitability differentiator

The channel dimension and the revenue side are both present at transaction grain, and the cost side is explicitly absent. Every row of the Order Transactions Report carries "Channel: The specific online platform where the order was placed (e.g., 'zomato', 'swiggy')", "Fulfillment mode... (e.g., 'delivery', 'pickup', 'dine-in')" and "Delivery Type... (e.g., 'Partner' for the aggregator's delivery fleet, 'Self' for your own delivery staff)", so revenue separates by marketplace and by fulfilment path, and the promotional cost is split by who funded it -- "Aggregator Discount: The part of the discount that was funded by the online platform" against "Merchant Discount... funded by your restaurant." SHORTFALL is the claim's own qualifier, net of marketplace commission, and the report defines itself out of it: Merchant Total is "the amount your restaurant is expected to receive from the order, after aggregator discounts but BEFORE aggregator commissions." No commission figure appears in any documented report field, so margin by channel cannot be computed from these reports alone. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/order-transactions-report · retrieved 2026-08-31

reporting-multiloc-drilldown differentiator

Consolidated across-location reporting is a documented, named product surface: two reports exist specifically for it -- "Items Summary Across All Locations Report... consolidating all the data from every location into one simple view", carrying Total Quantity, Total Amount, Total Taxes and Total Charges per item, and "Menu Snapshot Across All Locations Report... showing their pricing, availability, and categorization across every one of your restaurant locations". Drill-down to the individual transaction is available in the sense that the Order Transactions Report is one row per order with Store Name, Store ID and Store ref ID on it. SHORTFALL: the claim asks for a consolidated report with SIDE-BY-SIDE location comparison and navigational drill-down from group total to location to transaction, and what is documented is a set of separate exports at different grains. No article shows locations compared against each other in one view, and there is no documented path from a group figure to the rows behind it -- the operator re-runs a different report with a location filter. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/items-summary-across-all-locations-report · retrieved 2026-08-31

reporting-custom-report-builder differentiator

PARTIAL. What is documented is a fixed catalogue with a rich filter and scheduling surface, not a report builder. The reports landing page walks the entire configurable path: 'Navigate to the All Apps section and select Central Report ... You will see a list of all available reports'; then per report, 'Choose a pre-defined time range (daily, yesterday's, this week's, monthly) or select a custom date', 'Apply filters to sort by brand, location, or aggregator', 'Customize your report by selecting which order statuses you want to display', then preview, download as CSV or XLSX, email, or 'set up a recurring schedule', which persists the chosen report plus 'a date range and applying filters for brands, locations, platforms, or Meraki channels'. Atlas Analytics adds in-dashboard configuration -- 'advanced filtering and sorting directly within the dashboards' (April 2024 post), a Compare tab taking up to four location groups (December 2024 post), and a 'Customizable Location Performance Table' where you 'add columns for taxes, charges, discounts, and other revenue components' (February 2025 post). SHORTFALL: every one of those is a filter, a column toggle or a schedule over a PRE-BUILT report or dashboard. No source describes choosing dimensions and measures freely, and the only thing that can be saved is a delivery schedule of a named canned report -- not a user-defined report object. A named limit on the schedule too: 'the default schedule is set to deliver reports at 8 a.m. for the previous day. At this time, custom delivery times are not available.' https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-09-01

reporting-scheduled-delivery

Recurring automatic delivery exists and its cadence is fixed. Any report in Central Report can be scheduled -- "Click on the Schedule button and choose the report you want to schedule", then "Customize the data by selecting a date range and applying filters for brands, locations, platforms, or Meraki channels", then "Confirm and Schedule" and "Choose your desired format to finalize the schedule" -- and delivery is by email: "You will now receive your scheduled order transaction report in your email every day at 8 a.m." A one-off email route exists alongside it, where "A secure link to download the generated report will be sent to your inbox." SHORTFALL, and the article states it against the vendor's interest: the cadence is not operator-defined. "Note that the default schedule is set to deliver reports at 8 a.m. for the previous day. At this time, custom delivery times are not available." No recipient LIST is documented either -- the one-off route takes a single address -- and there is no shared destination (SFTP, bucket, drive) as an alternative to email. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

reporting-raw-warehouse-export differentiator

THE CELL THE 179th DEFERRED PENDING THIS READ, now settled. Recurring automated export of transaction-level data does exist -- the sibling extensibility-bi-data-warehouse cell records the Central Report scheduler delivering a daily order-transaction report at one-row-per-order grain -- so the claim's 'not just manual CSV download' half is satisfied. SHORTFALL is the customer-controlled destination, and the API read is what closes it rather than leaving it open: across the entire public API reference (llms-full.txt, 778,699 bytes, manifest-verified complete at 86 entries and 0 unmatched) the strings export, S3, SFTP, Snowflake and BigQuery occur ZERO times, and the 86 documented endpoints cover stores, menu, availability, order relay and rider status with no reporting, analytics or bulk-extract endpoint among them. So the recurring pipe terminates in email and no programmatic route to a customer-controlled destination is documented on either surface. https://api-docs.urbanpiper.com/downstream/llms-full.txt · retrieved 2026-08-31

reporting-public-api differentiator

The documentation half is fully satisfied and the credentials half is not. A public REST reference covers orders (Order Relay, Order Status Update, Rider Status Update), menu (Add/Update Menu, Menu Toggle, Category Timing Groups) and stores (Add/Update Stores, Store Toggle), readable without any agreement. PARTIAL on three counts, the first being the claim's own operative condition -- self-service credentials. This page states the gate: "We have two environments - the **Staging** environment (also referred to as the **pos-int** environment) and the **Production** environment. The access to the staging environment is provided after the partnership agreement is in place", and "Production environment base URL will be provided in the integration certification email by us." Second, there is no labor data in the API at all. Third, payments are present only as fields inside an order payload, never as a resource with its own endpoints. https://api-docs.urbanpiper.com/downstream/getting-started/environments.md · retrieved 2026-08-31

reporting-webhooks differentiator

Outbound webhooks to a customer-supplied endpoint exist and retry behaviour is documented in unusual detail: "we have a retry logic (3 attempts) in place for dealing with request failures (Read timeout/ *Bad Request/ Connection time-out)* while making the webhook callback to 3rd party URLs", against a published "**Connection timeout of 3 seconds** and **Read timeout of 5 seconds**". PARTIAL on the signature limb, which the vendor forecloses rather than omits. The companion callbacks page (getting-started/webhooks-callbacks.md) states that a static token-based authorization is the only mode available for these endpoints and that no other mode of authorization is supported on the vendor side, and the strings HMAC, signature and X-Signature occur zero times in the entire 778,699-byte reference. There is no payload signature to verify. https://api-docs.urbanpiper.com/downstream/resources/webhook-circuit-breaker.md · retrieved 2026-08-31

reporting-api-not-upcharged differentiator

PARTIAL. Raw data is included; a programmatic API for the merchant is not. Included side: any Atlas user with the Sales Analytics role can export order-, item- and option-level transaction data as CSV or XLSX, receive it by email, or schedule it, with no fee named anywhere (data-and-reports/getting-started). SHORTFALL, and it is the substance of the claim: UrbanPiper's public API is a POS-PARTNER programme, not a merchant entitlement. The onboarding page opens 'Once you have completed the signup formalities for the integration programme you will receive the credentials for Gamma', requires progress tracking through a partner dashboard, and gates production on certification -- 'We shall validate all the APIs marked as "To-be-verified" during the testing session ... Partner will be marked as "Active" post that' -- after which 'POS partnership team converts "Backlog" to "Merchant"'. Every one of the 87 documented endpoints is stores, menu, availability, orders or webhooks; there is no reporting or data-export endpoint at all. Whether money changes hands is undetermined: www.urbanpiper.com publishes no pricing page in its 239-URL sitemap, and the one pricing signal found is the December 2024 launch of Scheduled Reports as a 'Limited Time Free Trial', which implies scheduling is chargeable. https://api-docs.urbanpiper.com/downstream/getting-started/onboarding-process · retrieved 2026-09-01

reporting-tier-paywall differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. There is no published plan structure to test the claim against: www.urbanpiper.com carries no pricing page (its sitemap, re-read by hand 2026-09-02, lists no /pricing or /plans URL, and the product pages /hub, /orderline and /meraki carry a 'Get A Free Demo' call to action and no tiers), and business-manager/cancel-your-subscription describes the cancellation form without naming a plan. With no entry-level plan identifiable the claim cannot be tested. Two signals point toward gating and neither settles it: Scheduled Reports launched in December 2024 as a 'Limited Time Free Trial', and the January 2024 Stock Automation Module must be switched on by emailing support. Against them, the Central Report catalogue and Atlas Analytics are documented with no tier qualifier and the February 2025 Revenue Breakdown is stated 'available to all restaurants using the Analytics module'. Unresolved.

reporting-history-retention differentiator

Adversarial enumeration audit 2026-09-02 withdrew an asserted `no`. The verdict rested on clause 8 of www.urbanpiper.com/legal/privacy-policy, re-read from the cached body: 'Order and integration data routed through Hub: retained only transiently for the purpose of delivering the integration and, where logs are kept, for up to 90 days, unless the Merchant's instructions require otherwise.' That sentence is about personal data traversing the Hub middleware layer, not about aggregate order rows queryable in Atlas reporting -- and the same document says so twice: section 2 states that where information is 'fully anonymised such that no individual can be identified, directly or indirectly, it is no longer Personal Data and this Policy does not apply to it', and describes Lens and Periscope as generating reporting 'using aggregated or anonymised data' wherever possible. The retention clause therefore does not bound the reporting store the claim asks about, and the clause's only 24-month figure belongs to 'Account and User data (Atlas)' held 'for the duration of the Merchant's relationship with Us and for up to 24 months thereafter', a post-termination holding period rather than a query window. That leaves documentation silence: no reporting window is stated anywhere across the 116 help.urbanpiper.com and 87 api-docs.urbanpiper.com pages, and data-and-reports/getting-started offers 'daily, yesterday's, this week's, monthly' presets 'or select a custom date' with no stated bound. That silence is not closed -- support.urbanpiper.com 301-redirects even /robots.txt to itself so no policy is obtainable, and changelog.urbanpiper.com is barred to us by a named-allowlist robots file -- so it establishes neither the presence nor the absence of a documented 24-month transaction-detail window. Unresolved.

reporting-anomaly-alerts differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Every alert documented is event-driven, not metric-threshold-driven. Prime Web's notification settings offer 'New orders, Customer complaints, Cancelled orders, Stock toggles (availability changes), And other important updates' with a chosen sound (store-manager/prime-web/customise-notification-settings), and store-manager/prime-app/managing-notifications is the same shape; the April 2025 payment-reminder alerts concern the merchant's own overdue UrbanPiper invoice. The one threshold alert in the product is inventory, not reporting: crossing an ingredient's Critical Stock Level fires a notification (January 2024 post). Nothing lets an operator set a threshold on a sales, void or discount metric, and 'anomaly', 'deviation' and 'below forecast' return ZERO hits in both corpora. NOT scored no because that settings list ends 'And other important updates', so it does not enumerate its own surface, and Atlas Analytics has no help-centre documentation at all to test. Unresolved.

reporting-nl-query

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. UrbanPiper ships an AI product and it is not this one: Orderline AI is a customer-facing voice agent -- 'Handle all customer calls, reservations and orders, with AI' (www.urbanpiper.com/orderline) -- which takes orders from guests rather than answering an operator's questions about their own data. The April 2024 analytics relaunch post describes Atlas Analytics entirely as charts and tables the user navigates (heatmaps, dynamic line/area charts, distribution curves, pie charts, interactive tables, filtering and sorting), with no query box or assistant, and 'assistant', 'copilot' and 'natural language' return no product hits in either corpus. One retrieval artefact I deliberately did not score from: both GitBook doc hosts expose a generated '?ask=<question>' endpoint on every page, which is GitBook's documentation-search feature, not an UrbanPiper analytics capability. Unresolved because the analytics module has no help-centre documentation to enumerate against.

reporting-guest-cohorts differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Guest identity is present but thin, and cohort analytics are absent. The Order Transactions report carries 'Customer Name' and 'Customer ID' with the vendor's own caveat printed beside them -- 'customer details are suggested to the information passed by DSP. Most of the DSP/Aggregators do not share the customer details. Data might be dummy' -- and Customer ID is 'often masked by aggregators for privacy'. Identifiable guests exist on the first-party side (Meraki campaigns interpolate {{user_name}}, {{user_points}} and {{user_wallet_balance}} at direct-ordering/manage-campaigns, and the Atlas Marketing role can 'manage customer segments'), but no source states what those segments cut by, and no report or dashboard publishes new-versus-returning counts, visit frequency or lifetime spend: 'repeat customer', 'returning', 'lifetime value' and 'cohort' return no analytics hits in either corpus. Unresolved.

reporting-sales-forecast differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'forecast', 'predicted', 'projection' and 'demand planning' return ZERO hits across both corpora, and none appears in the March 2025, February 2025 or November 2024 product-update posts I read by hand. Atlas Analytics is documented as retrospective throughout: the April 2024 relaunch post describes heatmaps of past order frequency and 'Dynamic Line/Area Charts' where 'Dotted line represents the past data and the solid line represents the current data ... utilised for time range comparison', i.e. period-over-period comparison rather than a forward projection, and the November 2024 post adds performance COMPARISON analytics. Nothing downstream consumes a forecast either: no scheduling product exists and there is no suggested-order engine (see inventory-par-auto-suggest). Unresolved rather than negative because the analytics module has no help-centre documentation that could enumerate its dashboards exhaustively.

reporting-tip-tax-compliance

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Tips DO exist in the data model and they are couriers', not servers': the partner API's order payload types a charge 'title' with expected values 'Restaurant Packaging Charge', 'Packaging Charge', 'Delivery Charge', 'Service Charge', 'Driver Tip', 'Surcharge', 'Other Charges', and the per-aggregator support matrix lists 'Driver Tip' for Zomato, Swiggy, Talabat, Careem, Deliveroo, Uber Eats and Justeat. That is an aggregator-passed courier tip on an order with no employee attached; 'gratuity', 'tip pool' and 'declared tips' return ZERO hits in both corpora, no Atlas report carries a tip column, and no employee or timecard object exists anywhere (see reporting-labor-productivity). The tax half exists only as raw columns -- 'Merchant Taxes' ('Taxes that your restaurant is responsible for collecting and remitting'), 'Total Taxes', and a per-charge 'liability_on' attribute in the order payload -- never as a jurisdiction-level liability summary, and no payroll export of any kind is documented. Unresolved: the employee tip reporting this claim is about has no published source in either direction.

multi-location-org-hierarchy

Three named levels exist as first-class objects: a business identified by its Biz ID, brands beneath it ("Multi-Brand Support: Allows restaurants to manage each brand independently, making it ideal for groups with diverse brand offerings"), and locations, with Location Groups as a further grouping object used to scope taxes, charges and schedules. Reporting scopes to them -- the Business Manager "empowers you to oversee all orders processed across various locations and platforms". SHORTFALL is the permissions half, and the documentation states it against the vendor's interest: "The location-level access is not available in Atlas." Above-store permissions are therefore not location-scopable except through two purpose-built roles (Non-HQ Analytics and Non-HQ Report) that restrict downloads to designated locations; genuine per-location role assignment exists only in Prime, the store-level product. There is also no region or area tier as a named object -- location groups are an association device rather than a level of a hierarchy. https://help.urbanpiper.com/business-manager/introduction · retrieved 2026-08-31

multi-location-central-menu-publish

One-click menu updates propagate across all channels and outlets; a publish/version history showing what, when and by whom is not documented. https://www.urbanpiper.com/hub · retrieved 2026-08-01

multi-location-local-override-policy differentiator

REPLACES a seeded placeholder rationale that recorded no work, not absence. The partner API reference documents the override surface field by field. 'In our system, the menu is handled in a federated structure. For each of the menu entities, a master record is maintained and then for each store, references are set to the master menu entities.' Then the per-field rule, quoted in full: 'NOTE: At present, categories and option groups are maintained only at the master level, since there aren't many scenarios where the metadata for these entities would vary between stores. For an item, the metadata that varies between stores are: price, current_stock, sort_order, recommended and availability. And for an item option, this can be price and availability.' That is a closed list of store-varying fields (price and availability among them, as the claim instances) against a master record that holds every other attribute -- name, description, images, tags, category and option-group structure -- so a store cannot diverge on them. The architecture page states the same rule from the other side: 'The same item can have different prices and other possible store-wise varying attributes for different stores. However, the item ID should remain the same.' HONEST LIMIT: this is the data model as the POS-facing API exposes it, and the mechanism is structural (master-only fields have no per-store representation) rather than a per-user editing permission in Atlas; no Atlas article describes a store-level menu editor at all, and the roles article says 'The location-level access is not available in Atlas' outside the two Non-HQ reporting roles. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu · retrieved 2026-09-01

multi-location-price-zones

The location axis is met without duplicating the item record: Zomato, Swiggy and Keeta all carry "Location-Based Pricing -- Apply different prices for different locations", and Location Groups exist as a reusable object that taxes, charges and schedules are associated to. SHORTFALL on the claim's other two axes. Per-CHANNEL pricing is documented only in the connected POS (Foodics Price Tags, "different prices for the same product based on the delivery channel") or as fulfilment-mode pricing whose "support... varies by DSP", not as an Atlas price book. Per-DAYPART pricing does not exist at all: schedules govern whether a category is AVAILABLE at a time, never what it costs, and no article prices an item differently by time of day. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

multi-location-scheduled-publish differentiator

Future-dated activation across a chosen set of locations is documented end to end: "Click on the Scheduled Publish button. Select locations and platforms in a similar way to a regular publish. Our internal validation checks for errors and warnings on the menu. Select the date and time. Clicking on Submit confirms the schedule for a later point of time", and a pending schedule can be withdrawn with Cancel Scheduled Publish. SHORTFALL on both of the claim's qualifiers. Timezone is never stated -- the operator picks one date and time for a publish that may span locations in different countries, and no article says whose clock it is read against. And there is no rollback after activation: the documented reverse action only exists while the publish is still pending. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

multi-location-new-store-template differentiator

REPLACES a seeded placeholder rationale that recorded no work, not absence. Cloning exists and is a first-class step of the provisioning wizard: the ten-step 'How to Add a New Location' flow reads '4. Select Number of Locations: Choose the number of locations you want to create' and '8. Catalog Options: Choose to either copy the catalog from existing locations or skip to add it later', followed by brand association and DSP selection. Operating hours are then attached by associating an existing reusable Schedule rather than re-entering times (business-manager/setting-up-schedules-for-locations: 'Click on Associate Your First Location... Select the list of locations you want to associate with the schedule'). NAMED SHORTFALL, two limbs. (a) The cloned unit is the CATALOG only. The article names no copying of user roles, printer assignments or tenders; printers are bound per device in the Prime Web articles (connecting-a-printer, assigning-a-printer-for-kot-invoice) with no template, and Atlas roles are assigned by per-user email invitation (business-manager/user-access). (b) NO EXPECTED TIME-TO-OPEN IS PUBLISHED. Neither the 116-page help centre nor the 87-page API reference states a provisioning or go-live duration; the partner onboarding page instead routes go-live through a manual gate -- 'Data pushed will be verified by the Onboarding Manager post which outlet will be sent for mapping to the aggregator.' https://help.urbanpiper.com/business-manager/creating-a-new-location · retrieved 2026-09-01

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. An above-store/in-store split is documented and enumerated. Atlas ships ten named roles, two of which exist specifically to fence a location operator out of brand-wide data: 'Non-HQ Analytics: Provides access to analytics data, but strictly limited to specific locations. Users cannot download full business data or reports without a location filter, ensuring localized data security' and 'Non-HQ Report: Similar to Non-HQ Analytics, this role limits report access to designated locations only.' Prime ships six standard roles plus custom roles and 'You can also assign roles with limited access based on specific locations', while Admin has 'complete control over the platform, managing user accounts, system configurations, and all operational settings' -- so corporate can see every location's sales and hold the configuration while a location user sees only its own. NAMED SHORTFALL: this is a role filter within a SINGLE tenant, not the two-tenant model the claim asks for. The same article states 'The location-level access is not available in Atlas' outside those two reporting roles, so a franchisee cannot own its own catalogue or user administration; nothing documents separate franchisor and franchisee accounts, cross-tenant visibility, or franchisee-owned banking. Employees, banking and labor data are not objects in this product at all -- the 116-page help centre has no time clock, payroll or scheduling article -- so the 'franchisee owns its own employees, banking and labor data' limb cannot be satisfied here in any form. https://help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas · retrieved 2026-09-01

multi-location-royalty-calculation differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Case-insensitive 'royalt' and 'franchis' return ZERO hits in both complete corpora, re-verified by grep 2026-09-02. The places such a feature would surface carry no trace: I read the Data & Reports set (getting-started plus the seven report articles) and no published report field is a fee, royalty or ad-fund line -- Order Transactions' money columns are Total Amount, Merchant Total, Sub-total Amount, Discount, Aggregator Discount, Merchant Discount, Merchant Taxes, Total Taxes, Charges and Wallet credit amount -- and the Atlas Billing role covers the operator's OWN UrbanPiper invoices ('access detailed transaction records and invoices, and initiate credit purchases'), not inter-party fees. Unresolved rather than no because these hosts bound only the documentation surface, not the Atlas UI beyond what is documented, and no page asserts a closed list of financial features. changelog.urbanpiper.com was NOT read and is not cited: its robots.txt is a named allowlist whose 'User-agent: *' group is 'Disallow: /', which is the group we are in. developers.urbanpiper.com is a Clerk-authenticated Vite shell and unreadable.

multi-location-royalty-collection

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'royalt' and 'franchis' return ZERO hits in both complete corpora. The one page documenting money movement is direct-ordering/configuring-payment-gateway and it is entirely guest-facing: gateways in a region matrix (Razorpay, Stripe, PayTabs, Paystack, FreedomPay and others) with accepted methods listed as 'Online Payments (UPI, cards, net banking, wallets)', 'Cash on Delivery (COD)' and 'Wallets or Loyalty Points (if configured)'. No ACH or direct-debit collection from a merchant or franchisee account appears there or anywhere else, and no franchisee-visible statement of charges is documented; the merchant's own billing appears only as the Atlas Billing role and the April 2025 overdue-invoice payment reminders. Unresolved rather than no because that gateway article is a Meraki storefront settings page bounding the direct-ordering checkout only, and no page enumerates UrbanPiper's commercial billing surface. changelog.urbanpiper.com was NOT read and is not cited: its robots.txt is a named allowlist whose 'User-agent: *' group is 'Disallow: /', which is the group we are in. developers.urbanpiper.com is a Clerk-authenticated Vite shell and unreadable.

multi-location-consolidated-reporting

STRENGTHENED WITHIN THIS SESSION with the Data & Reports articles from page 1 of a paginated llms-full.txt, which replace a marketing-page inference with named reports. Above-store aggregation ships as purpose-built reports: "Items Summary Across All Locations Report... consolidating all the data from every location into one simple view" (Total Quantity, Total Amount, Total Taxes, Total Charges per item) and "Menu Snapshot Across All Locations Report... showing their pricing, availability, and categorization across every one of your restaurant locations", alongside an order-grain report filterable "by brand, location, or aggregator. You can also choose to select all locations." The role model corroborates the surface, with dedicated Sales Analytics and Operation Analytics roles and Non-HQ variants that exist to restrict the all-locations view. SHORTFALL: the claim's comparison features are still undocumented -- no store-versus-store ranking and no variance flagging appears in any report description -- and two of its named measures cannot exist here, since UrbanPiper has no labour module and no drawer, so labour and voids are not reportable at all. https://help.urbanpiper.com/data-and-reports/items-summary-across-all-locations-report · retrieved 2026-08-31

multi-location-normalized-item-rollup differentiator

REPLACES a seeded placeholder rationale that recorded no work, not absence. The report exists and is named for exactly this: 'Unlike detailed transaction reports, this report gives you a high-level overview of your product performance, consolidating all the data from every location into one simple view.' Its key is the corporate item identifier -- 'Item ID: The unique code for this specific menu item within your system... This is your primary key for tracking the performance of each product' -- and the aggregated measures are 'Total Quantity: The total number of units of this item sold across all orders and all locations during the report period' plus Total Amount, Total Taxes and Total Charges, each described as 'aggregated from all your locations'. The aggregator's own per-platform code is carried alongside as a separate field ('Item ref ID: The unique code for the item as it exists on the online platform (like Swiggy or Zomato)'), so channel-side renaming does not fragment the rollup. The data model guarantees the shared key even where stores price differently: the API menu architecture states 'this item should be created at the master level in the POS system and must carry the same menu ID across all the stores... The same item can have different prices and other possible store-wise varying attributes for different stores. However, the item ID should remain the same', and gives brand-level reporting as the reason -- 'For a brand, it would be very easy to analyse the sales of the Margherita Pizza item since it is one item tagged to multiple stores.' https://help.urbanpiper.com/data-and-reports/items-summary-across-all-locations-report · retrieved 2026-09-01

multi-location-cross-location-giftcard

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Case-insensitive 'gift' returns ZERO hits across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages, re-verified 2026-09-02. I checked the three surfaces where a gift card would have to appear. (1) Tenders: direct-ordering/configuring-payment-gateway lists the enableable checkout options -- Online Payments (UPI, cards, net banking, wallets), Cash on Delivery, and Wallets or Loyalty Points if configured -- with no stored-value instrument. (2) Reporting: I read the Order Transactions field list heading by heading; it carries Payment Mode, Payment Transaction ID and 'Wallet credit amount', defined as AGGREGATOR wallets ('e.g., Swiggy Money, Zomato Wallet'), and no outstanding-liability or breakage figure appears in any of the seven report articles. (3) The API menu and order schemas carry no gift-card entity. NOT scored no: the gateway page is the Meraki storefront settings screen and bounds that checkout only, not Prime's in-store settlement surface, which the help centre describes only as cashiers who 'process bills, and complete settlements' with no tender list. Inter-store settlement between separate owners is unaddressed either way.

multi-location-cross-location-loyalty

REPLACES a seeded placeholder rationale that recorded no work, not absence. A per-customer loyalty balance exists and is held at brand level, not per location. The Meraki campaign placeholder table defines '{{user_points}}: Shows the customer's current loyalty points balance' and '{{user_wallet_balance}}: Displays the customer's current wallet balance', alongside {{user_name}}, {{user_phone}} and {{user_email}} -- one customer record with one balance, addressable from the brand-wide campaign tool. The Meraki storefront it belongs to is a single branded site and app for the business ('build and launch your own website and mobile app... under your own identity'), and the corresponding balances are offered as a checkout tender: 'Wallets or Loyalty Points (if configured)'. Order history is likewise consolidated rather than per-store: the Order Transactions Report carries Customer Name and Customer ID as fields on a report explicitly filterable across 'all locations'. NAMED SHORTFALL: no page states that a balance earned at one location is redeemable at another -- cross-location redemption is inferred from a single brand-level ledger, never asserted -- and the 116-page help centre contains NO loyalty-program configuration article at all, so accrual rules, tiers, expiry and the redemption mechanism are undocumented. The documented scope is the Meraki direct channel; nothing describes points accruing on aggregator (Zomato, Swiggy, Uber Eats) or in-store Prime orders, and the Partner with Us page files loyalty under third-party partners ('Marketing & Loyalty: Gupshup, and more'). https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-09-01

multi-location-multi-brand differentiator

Brands are first-class and separately managed: "Multi-Brand Support: Allows restaurants to manage each brand independently, making it ideal for groups with diverse brand offerings", supported by a "Consistency and Customization" statement about maintaining "a unified brand identity across platforms while enabling each brand to tailor operations", and a dedicated Creating a Brand article. Each brand carries its own menus, and orders are viewable across brands and platforms. SHORTFALL, and it is precisely what this claim asks beyond brand management: nothing documents TWO brands running on ONE location or one terminal. No article describes brand selection at the terminal, per-brand receipt branding, or a shared drawer with separately reportable per-brand revenue, and the virtual-brand case that makes this claim matter for a delivery aggregator is never addressed in the help centre. https://help.urbanpiper.com/business-manager/introduction · retrieved 2026-08-31

multi-location-multi-tax-jurisdiction

Per-location tax configuration with simultaneous rates and item-class rules is documented concretely. Rates are defined in Catalog > Taxes and scoped by association: "By default, all items and location groups are automatically associated with the taxes you create. If you need to limit taxes to specific items or locations", the operator builds an item group and a location group and links the pair to the rate, which is per-location tax and per-location exemption in one mechanism. Multiple simultaneous rates are native -- "For GST rates like 5%, 9%, 12%, or 18%, the platform will automatically divide the rate equally into SGST and CGST (e.g., 5% GST will become 2.5% SGST and 2.5% CGST)" -- and jurisdiction-specific product rules are handled by a tag: an item taxed above 5% "must be accompanied by a packaged goods tag", and the same tag flips a 5% rate from the aggregator's liability to the merchant's. SHORTFALL: every documented rule is India/GST-specific, no other jurisdiction is worked anywhere in the help centre, and the inclusive-versus-exclusive tax setting this claim names is never mentioned. https://help.urbanpiper.com/business-manager/creating-a-menu/create-and-manage-taxes · retrieved 2026-08-31

multi-location-multi-currency-locale

REPLACES a seeded placeholder rationale that recorded no work, not absence. THE LANGUAGE LIMB IS DOCUMENTED. The API reference publishes a supported-language list -- 'The list of supported language codes for certain entity fields: hi for Hindi, ar for Arabic, ja for Japanese, pt for Portuguese, fr for French, es for Spanish' -- and the entity schemas carry it: the Add/Update Stores payload includes a per-store 'translations' array of {language, name} objects, as do menu entities. The platform is operated across regions in one account model (the Meraki payment-gateway article maps gateways across India, MENA, KSA, UK, LATAM and USCAN columns, and gateways 'can be configured globally for all outlets, or per outlet if needed'). NAMED SHORTFALL, and it is the whole currency limb: the string 'currenc' appears NOWHERE in either complete corpus -- not in the store schema, not in the menu or item schema, not in the order payload, and not in any of the seven report articles. Prices are bare floats with no currency field, and no page describes a reporting currency, an FX rate, or consolidation of differently-denominated locations into one figure. So differing languages across locations are supported and differing currencies are simply not addressed by the published data model. https://api-docs.urbanpiper.com/downstream/api/references/supported-languages · retrieved 2026-09-01

multi-location-config-audit-log differentiator

A real audit log exists, is described as one, and names its fields: the Store Action Report is "your detailed report for every operational change made to your stores. Think of it as a security log that helps you audit actions", recording action_time ("the most critical field for auditing. It creates a historical timeline of all changes"), action_performed ("e.g., 'publish,' 'enable,' 'disable'"), platform, status ("e.g., ack_success"), the store and brand identifiers, and both application_src ("an API call, a user in the UI, or an internal system") and username plus user_first_last_name -- so who, what, when, where, how it was initiated, and whether it succeeded. It is exportable, since it is one of the Central Report exports. SHORTFALL is scope, and it is a large one against this claim: the objects covered are STORE STATUS and PUBLISH actions. Nothing documents an audit entry for a price change, a tax change, a permission change or a discount change, and no immutability property is stated anywhere. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/store-action-report · retrieved 2026-08-31

multi-location-enterprise-sso differentiator

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'SAML', 'OIDC', 'SCIM', 'single sign', 'Okta' and 'Azure AD' return ZERO hits in all 116 help pages and all 87 api-docs pages, re-verified by grep 2026-09-02. What IS documented is the local alternative, on exactly the pages where SSO would appear: business-manager/user-access onboards an above-store user by email invitation -- the invitee must 'Pick a unique username and set a password' and validate a phone number by OTP -- and the sibling articles cover password reset, Prime PIN reset and archive/delete/restore of a user, i.e. manual deprovisioning. The partner API uses 'static token-based authentication' with rotation by support email (downstream/authentication/authentication). NOT scored no: none of those pages claims to enumerate the available authentication methods, and enterprise SSO is characteristically sold rather than documented in a merchant help centre. changelog.urbanpiper.com was NOT read and is not cited: its robots.txt is a named allowlist whose 'User-agent: *' group is 'Disallow: /', which is the group we are in. developers.urbanpiper.com is a Clerk-authenticated Vite shell and unreadable.

multi-location-enterprise-api differentiator

REPLACES a seeded placeholder rationale that recorded no work, not absence. Scored on the claim's second limb (data warehouse/BI export), which is met. From the Data & Reports getting-started article: reports live in one place -- 'Navigate to the All Apps section and select Central Report. You will see a list of all available reports, including order transactions, item-wise transactions, item summaries' -- and the scope is explicitly cross-location and cross-brand: 'Apply filters to sort by brand, location, or aggregator. You can also choose to select all locations.' The grain is transaction level: the Order Transactions Report article states 'Each row in this report represents a single order' and documents its fields, including Order ref ID, Channel, Created At, Order State, Payment Mode, Payment Transaction ID, gross and net amounts, taxes, charges, Customer ID, Store ID and Store ref ID. Delivery is machine-readable and unattended -- 'You can download the report in either CSV or XLSX formats', a mailed 'secure link to download the generated report', and 'a recurring schedule to automatically receive your most important reports' defaulting to 8 a.m. for the previous day. All of it is reached with the single Atlas account the operator already holds; nothing in the flow asks for per-location credentials. HONEST LIMIT ON THE OTHER LIMB: the claim's API alternative is NOT satisfied -- the 87-page partner API reference (api-docs.urbanpiper.com, manifest-complete) publishes no reporting, export or bulk-extract endpoint, and scheduling is fixed at 8 a.m. ('At this time, custom delivery times are not available'). https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-09-01

multi-location-central-labor-policy

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. 'overtime', 'payroll', 'break enforcement' and 'predictive scheduling' return ZERO hits in both complete corpora. Both candidate pages are about something else: business-manager/setting-up-schedules-for-locations creates Regular Schedules of open and close TIMES and associates locations to them ('Select the open and close time... Click on Associate Your First Location'), i.e. trading hours rather than staff rosters; and the Prime Cashier role's 'manage operational shifts using registers' is a cash/register session, not a labor shift. No time clock, attendance or scheduling article exists on the help centre and the partner API carries no employee or timecard object. Unresolved rather than no because no page enumerates the product's feature surface as closed; a middleware vendor's silence on labor is silence, not a finding. changelog.urbanpiper.com was NOT read and is not cited: its robots.txt is a named allowlist whose 'User-agent: *' group is 'Disallow: /', which is the group we are in. developers.urbanpiper.com is a Clerk-authenticated Vite shell and unreadable.

extensibility-public-api-docs

WAS `unknown` at grade F, on the rationale that 'no publicly readable API reference was reachable without a partner flow'. That is falsified by a host THIS RECORD ALREADY CITES AT GRADE A. api-docs.urbanpiper.com serves a complete GitBook API reference to an anonymous client: its robots.txt (served from /downstream/robots.txt) is 211 bytes reading allow: / with three GitBook asset allows and no disallow at all, and the whole reference is retrievable in one request as llms-full.txt at 778,699 bytes. No login, agreement or sales contact intervenes. The landing page states the scope plainly: "The UrbanPiper API is organized around REST", followed by a table of contents covering Overview, Getting Started, Authentication, Manage Stores, Managing Menu, Receive/Manage Orders, Availability, Testing and Validation, Certification and Resources. COMPLETENESS WAS MEASURED, NOT ASSUMED, using the 179th's falsifier: the llms.txt manifest lists 86 entries and 0 are unmatched against the dump's 229 headings, and the dump carries no Next Page marker. The same instrument reproduces the 179th's help-centre result (115 entries, 14 unmatched against page 0, 0 against both pages), so the zero is from an instrument shown to produce a non-zero. https://api-docs.urbanpiper.com/downstream/readme.md · retrieved 2026-08-31

extensibility-api-access-cost differentiator

2026-09-02, correcting the 2026-09-01 rationale's statement that there is no published pricing page. https://www.urbanpiper.com/pricing does 404, but https://www.urbanpiper.com/uk/free-trial is a real pricing page and it was read: 'Plans from GBP 79', 'No one-time set-up fee', 'Unlimited orders; No per order charges', 'No additional costs', and 'The pricing for Hub depends on the type of Hub integration you are opting for and the overall scale of your business based on both the number of physical locations and the number of brands you operate. To know the specific pricing for your restaurant, contact us.' That establishes per-location and per-brand pricing and a blanket 'No additional costs' line, but it never mentions API access, an API tier or a developer plan, so it does not answer the claim in either direction. Re-grepped all 87 api-docs.urbanpiper.com pages on 2026-09-02 for fee/pricing/charge/subscription/billing: the only commercial sentence in the whole reference is the sandbox note ('If you haven't yet received the Sandbox, please feel to write back at pos.support@urbanpiper.com') and downstream/getting-started/onboarding-process's reference to 'the signup formalities for the integration programme'. The Merchant Agreement was re-read the same day and has no API, integration-fee or developer-access clause at all; cl. 7.1 defers every charge to a private Order Form. Two further reasons this stays open: the published API is the POS-PARTNER integration API, whose commercial terms would sit in a partner contract rather than a merchant price list, and a fourth first-party doc surface, support.urbanpiper.com (a Freshdesk solutions centre outside both dumped corpora), could not be read -- its /robots.txt answers HTTP 301 to itself in an endless loop under ClaudeBot, Googlebot and a browser UA alike, so no policy is obtainable and it was not fetched.

extensibility-partner-revshare

The vendor does publish the STRUCTURE of its partner commercial terms, on its partner landing page rather than in its documentation: 'Flat fee. No nasty surprises. No hidden charges. No percentage cut from your client's orders. No bill that unexpectedly escalates as they grow. One clear fee, what you see is what you pay.' The same page describes the commercial track as 'referral / reseller programs, and strategic partnerships along with co-marketing' and lists what a live partner receives ('A listing on the UrbanPiper integrations hub, a named partner manager, joint announcement support, access to co-marketing assets, and warm intros into the restaurant brands where your product is the best fit'). SHORTFALL: no figure of any kind is published -- no referral fee amount, no revenue share percentage and no per-location partner fee. The page states only that the fee is flat and is not a cut of order value, and routes the rest to a sales conversation ('Drop us a note at partnerships@urbanpiper.com or fill the form on this page'). The documentation hosts carry none of it: across help.urbanpiper.com (116 pages) and api-docs.urbanpiper.com (87 pages), both verified complete against their llms.txt manifests by link-crawling the retrieved page bodies on 2026-09-01, 'revenue share', 'referral' and 'rev share' return zero hits, and the POS-partner track (onboarding-process, testing-and-validation, certification) states engineering obligations and a certification gate with no commercial figure. developers.urbanpiper.com is Clerk-gated and was not read. https://www.urbanpiper.com/partner-with-us · retrieved 2026-09-01

extensibility-free-sandbox differentiator

A real test environment exists with seeded data and tooling: "The Sandbox is a package that would consist of everything you would need to start the integration, build it, test it and complete the same", comprising "the credentials to access Atlas, the auth details (more on this later) and the sample postman collection", against a published staging host and Atlas portal, and Atlas itself lets the integrator "mock the test orders with the populated menu". A companion Developer Tools feature simulates orders across ten named aggregators in four regions. SHORTFALL is the claim's operative word, self-serve availability: the sandbox is provisioned by hand -- "You would be receiving the details related to sandbox over an email" -- and the companion environments page (getting-started/environments.md) gates access to the staging environment on the partnership agreement being in place. No developer can obtain it without contacting the vendor. https://api-docs.urbanpiper.com/downstream/getting-started/environments/sandbox.md · retrieved 2026-08-31

extensibility-oauth-partner-apps

The partner API reference states the mechanism outright: 'We use a static token-based authentication for all the requests made to our system via API calls.' One token per business entity, constant over time; rotation is manual — a suspected compromise means emailing pos.support@urbanpiper.com for a new token. This is exactly the shared static credential model the claim excludes: no OAuth 2.0, no scopes, no operator-granted consent, no self-serve revocation. The downstream POS-partner API is the only published third-party integration surface. https://api-docs.urbanpiper.com/downstream/authentication/authentication.md · retrieved 2026-08-04

extensibility-webhooks-push

WAS `unknown` at grade F ('UrbanPiper publishes no webhook documentation'). It publishes a great deal. The callbacks page states the model -- "Our platform relies on a system of webhooks" to "Notify an external system when a particular *event* occurs", and "The webhooks get triggered as soon as the event happens" -- and then enumerates ten named endpoints the integrator supplies, including "**Order Relay** - triggered as soon as an order is placed on our system", "**Order Status Update** - triggered as soon as the status of an order changes on our system" and "**Rider Status Update** - triggered as soon as the status of rider for an order changes on our system", alongside processing callbacks for store, menu, category-timing, item and option actions. Push, not polling, is unambiguous. PARTIAL against this claim's own enumeration: order creation and every status transition (including cancellation) are covered, but there is no payment, void or refund event -- money movement happens on the aggregator, and no webhook in the list corresponds to it. https://api-docs.urbanpiper.com/downstream/getting-started/webhooks-callbacks.md · retrieved 2026-08-31

extensibility-webhook-reliability differentiator

This claim is an AND of signing and retry, and the two halves land on opposite sides. Retry and replay are documented thoroughly: "we have a retry logic (3 attempts) in place"; a Webhook Circuit Breaker trips when "a 3rd party system URL throws more than 15 request failures within a minute for particular biz", with a cool-off scaled to recent history -- "If there have been >= 5 incidents in the past week, all webhooks will be disabled for 3 mins. If the number of incidents is less than 5, then the webhooks will be disabled for 1 min" -- and missed deliveries are replayed: "For the orders which were not relayed in the timeframe of webhook deactivation, our system tries to push them at once when the webhooks are re-enabled." A separate Webhook Order Retry API lets the POS partner re-request an Order Relay. SHORTFALL is the signing limb, and it is a positive exclusion rather than silence: the companion callbacks page (getting-started/webhooks-callbacks.md) states that beyond a static token no other mode of authorization is supported for configuration on the vendor side, and HMAC and signature occur zero times across the whole reference. https://api-docs.urbanpiper.com/downstream/resources/webhook-circuit-breaker.md · retrieved 2026-08-31

extensibility-order-injection-api

REPLACES a seeded placeholder rationale that recorded no work, not absence. WHAT IS SATISFIED: orders originating outside the operator's own system are handled as first-class tickets. The integration overview describes the whole product this way -- aggregators are 'upstream', the POS is 'downstream', and Order Relay means 'Receive orders from aggregators directly to the POS through the webhook endpoint configured in UrbanPiper', with order-status and rider-status updates flowing back. Those orders print: Prime's auto-print settings fire the bill and the KOT by order status, kitchen-station KOT routing exists (store-manager/prime-web/print-kot-for-kitchen-stations), and they land in reporting as rows of the Order Transactions Report with Channel and Order ref ID fields. NAMED SHORTFALL: the direction is outbound, not inbound. The API reference is the POS-partner surface -- 'This document lists the API endpoints that can be consumed by a merchant's backend system like a PoS or ERP system' -- and its complete endpoint set (add/update stores, store toggle, add/update menu, menu toggle, category timing groups, order STATUS update, rider status update, webhook order retry, self-delivery rider management, aggregator feature actions, mark order item stock out, customer complaints) contains NO create-order call. The documented scope is stated as closed on that page -- 'order relay and status update, menu management, item and store availability control mark the scope of the integration' -- so a third-party ordering front end cannot inject a ticket except by becoming one of UrbanPiper's integrated channels. Not scored `no` because the same reference disclaims its own completeness: 'We try our best to keep this doc in sync with our development pace, but at times a gap creeps in.' https://api-docs.urbanpiper.com/downstream/getting-started/overview · retrieved 2026-09-01

extensibility-menu-write-api differentiator

The Add/Update Menu endpoint writes the whole catalogue, not a subset, and the same endpoint serves both operations: "Since the same endpoint can be used for both adding and updating menu objects, the required set of attributes differ based on the context of the request. For *create* events, along with the required set of parameters, you have to send all the relevant parameters in the request payload. For *update* events, along with the required set of parameters, you can pass only the updated information-carrying parameters in the request payload." The documented object set is Categories, Items, Option Groups, Options, Taxes and Charges, written at master level or per location, with prices carried on items and options and destructive resets available through documented flush and clear flags. Items, modifiers and prices are all writable, which is the whole of this claim. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-08-31

extensibility-data-symmetry differentiator

REPLACES a seeded placeholder rationale that recorded no work, not absence. Read against the complete 87-page reference (manifest-verified 87/87 on 2026-09-01). Symmetry holds for exactly one object and fails for the rest. ORDERS: readable, as a webhook delivery, and partially writable -- order-status-update and rider-status-update exist, and webhook-order-retry-api re-delivers a missed order -- but there is no create-order endpoint, so the read is richer than the write. MENU AND STORES: writable only. add-update-menu and add-update-stores push the full payload, menu-toggle and store-toggle flip availability, and category-timing-groups sets schedules -- but no GET returns a menu, an item, a store or a timing group. The onboarding page confirms the round trip is a UI one rather than an API one: 'Push the Stores, add the platform details for each store and Menu data using the API or configure the same through Atlas manually. Verify the data using the callbacks or through Atlas.' CUSTOMERS, EMPLOYEES AND INVENTORY: not objects in this API in either direction -- the only customer-shaped endpoint is customer-complaints, item stock is a per-item toggle (mark-order-item-stock-out, availability/item-option) rather than an inventory resource, and there is no employee entity. NAMED SHORTFALL: the claim's universal fails because the API is a one-way push surface for configuration and a one-way receive surface for orders, with the reconciliation read left to the Atlas UI and the Central Report exports. Held at partial rather than `no` because api/readme disclaims completeness -- 'We try our best to keep this doc in sync with our development pace, but at times a gap creeps in' -- so its endpoint list is not a closed enumeration. https://api-docs.urbanpiper.com/downstream/api/readme · retrieved 2026-09-01

extensibility-published-rate-limits

Numeric quotas are published per endpoint, under a "**Constraints & Expectations**" heading on each. This one reads "A *throttle limit* is applicable on this endpoint limiting the maximum of **1 request&#x20;*****per*****&#x20;5 secs**. If you breach this threshold, the platform will respond with a `429` error response code and you will not be able to make new requests for a duration of **5 seconds**." The pattern repeats across the reference with per-endpoint figures ranging from 2 requests/hour to 150 requests/min, one of them split by time of day, each naming its own 429 and its own cool-off window. PARTIAL on the claim's last word: no rate-limit response headers are documented anywhere -- Retry-After, X-RateLimit and RateLimit-Remaining occur zero times in the 778,699-byte reference -- so a client must hard-code the quota rather than read its remaining budget from a response. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-08-31

extensibility-doordash-preferred differentiator

REPLACES a seeded placeholder rationale that recorded no work, not absence. Established by the programme owner, not by the vendor: DoorDash's newsroom announcement of the 2026 Preferred Integration Partner cohort states 'Based on current performance and feature capabilities, the 2026 cohort DoorDash Preferred Integration Partners include Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, and UrbanPiper', footnoted as of 2026-05-08, and adds that 'Partners must meet clear, measurable requirements to maintain their status, helping ensure integrations support the full restaurant operating experience, not just order transmission.' That is a closed ten-name list published and dated by the standard-setter, and UrbanPiper is on it -- the same roster this corpus uses to score the claim `no` for the vendors absent from it. UrbanPiper's own documentation is consistent with an active DoorDash integration but does not itself establish Preferred status: DoorDash is listed as a supported aggregator (aggregator code `doordash`) with its own constraints page, and the Business Manager introduction names 'DoorDash, Grubhub, and Uber Eats' among the platforms managed. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-09-01

extensibility-first-party-delivery-integrations differentiator

UrbanPiper operates its own marketplace integrations rather than reselling someone else's -- each has a per-platform authorisation flow, a feature matrix and a stated 48-hour activation timeline -- and it is itself the aggregation layer this claim contrasts against, so the no-paid-middleware condition is met in the only way it can be for this record. SHORTFALL is the claim's named list: Uber Eats is fully documented (getting started, menu update and publish, menu timings, prep time), but of the other two, DoorDash and Grubhub appear exactly once between them, in a single line of Business Manager prose -- "organize menus across various online food delivery platforms such as DoorDash, Grubhub, and Uber Eats" -- with no integration article, no supported-feature table and no authorisation flow. The documented depth sits instead on Zomato, Swiggy and Keeta, which the claim does not name. Not `no`: a named US marketplace with no help-centre article is an undocumented integration, not an absent one. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

extensibility-middleware-compatibility

2026-09-02: re-confirmed zero hits for 'Deliverect', 'Chowly', 'Otter', 'Checkmate' and 'ItsaCheckmate' across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages, and read the vendor's fullest public integration enumeration for the first time -- https://www.urbanpiper.com/integrations, which groups partners under exactly four headings (POS Systems, Delivery Platforms, Fulfilment, Online Ordering), names over a hundred POS products (3sPOS, Foodics, Epos Now, Lightspeed, LingaPOS, Loyverse, LS Retail, Micros Oracle Symphony, GoFrugal and so on) and lists none of the five middleware platforms in the claim. That is expected rather than probative: api-docs.urbanpiper.com/downstream/getting-started/overview places UrbanPiper itself at that layer -- 'Upstream for UrbanPiper are the Food Delivery Companies/Food Aggregators (Example: Swiggy, Talabat, Deliveroo, etc)... while downstream refers to restaurant POS/ERPs/TILL/Billing Systems' -- so those five are competitors and its own site is not where their support for it would be recorded. UNRESOLVED because the claim turns on Deliverect's, Chowly's, Otter's and Checkmate's own supported-endpoint lists; no such host was fetched in this pass, and an integration directory is disqualified from grounding an absence under this project's enumeration bar, so neither a yes nor a no is reachable from what was read. Note also that UrbanPiper is not a POS, so the claim's subject may not exist here at all -- that is a scope question for peer-groups.yaml, not a value.

extensibility-accounting-connectors

2026-09-02: re-grepped both complete corpora (116/116 help pages, 87/87 api-docs pages) for 'QuickBooks', 'Xero', 'Tally', 'Zoho', 'NetSuite', 'Sage', 'Odoo' and 'journal entry' -- all zero except one 'oodo' and one 'Ginesys' inside a single sentence of help.urbanpiper.com/basics/partner-with-us. That page's 'Our Core Integrations' table has five rows (Online Aggregators, POS Systems, Logistics Partners, Payment Gateways, Marketing & Loyalty), no accounting row, and every row ends 'and more'. NEW this pass: read https://www.urbanpiper.com/integrations, the vendor's fullest public partner directory, which groups everything under four headings only -- POS Systems, Delivery Platforms, Fulfilment, Online Ordering -- with no accounting, ERP or GL category and no QuickBooks, Xero, Tally, Zoho Books or NetSuite entry anywhere; it also carries a 'Load more' control and makes no completeness claim. So two independent first-party enumerations of the integration surface both lack the category outright. Still NOT scored no: both are integration directories, which this project's evidence bar explicitly disqualifies from supporting an absence, and neither is a supported/unsupported matrix. What is documented instead of a connector is the export route -- Central Report CSV/XLSX downloads and scheduled email delivery -- and no page states whether a mapped journal entry is or is not available.

extensibility-payroll-export

2026-09-02: re-grepped all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages for 'payroll', 'Gusto', 'ADP', 'Paychex', 'Paylocity', 'time clock' and 'attendance' -- zero hits in both, confirming the 2026-09-01 read. NEW this pass: https://www.urbanpiper.com/integrations, the vendor's fullest public partner directory, groups every named partner under POS Systems, Delivery Platforms, Fulfilment and Online Ordering, with no payroll, HR or workforce category and no payroll provider named. The prior question is still unanswered too: the seven Data & Reports articles enumerate every field of every published report (order, item, option, menu-snapshot and store-action) and none carries an employee, clock-in or hours field; the Prime role descriptions mention 'operational shifts using registers', which is a cash session rather than a timecard; and the POS-partner API defines no employee entity. UNRESOLVED rather than no on three grounds: an integration directory is disqualified from grounding an absence here, no page enumerates the report or export catalogue as closed, and a fourth first-party surface -- support.urbanpiper.com, a Freshdesk solutions centre carried in neither dumped corpus -- could not be read because its /robots.txt 301-redirects to itself indefinitely under every user agent tried, leaving no obtainable policy to fetch under.

extensibility-bi-data-warehouse differentiator

Scheduled, recurring, transaction-level export exists and its destination is an inbox. The operator schedules any Central Report, filters it "for brands, locations, platforms, or Meraki channels", picks a format, and thereafter "receive[s] your scheduled order transaction report in your email every day at 8 a.m."; a one-off route emails "a secure link to download the generated report", and manual export is CSV or XLSX. The grain is genuinely raw -- one row per order with identifiers, financial breakdown, payment mode and transaction ID, and companion reports at item and option grain. SHORTFALL is the claim's operative requirement, a CUSTOMER-CONTROLLED destination: no S3, SFTP, bucket, warehouse or Snowflake share is documented anywhere, and the recurring pipe terminates in email. NOT scored `no`: this article documents the Central Report UI and not the vendor's API surface, so it cannot establish that no programmatic route exists -- api-docs.urbanpiper.com was not re-read in this pass and reporting-raw-warehouse-export is deliberately left unresolved for that reason. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

extensibility-app-marketplace

A public, categorised list of named integration partners is published in the help centre -- Online Aggregators ("Zomato, Swiggy, Uber Eats, and more"), POS Systems ("Foodics, oodo, Ginesys, RanceLab, and more"), Logistics Partners ("Dunzo, Shadowfax, and others"), Payment Gateways ("Razorpay, PayU, and others") and Marketing & Loyalty ("Gupshup, and more") -- so the browsable-listing half of the claim is met, and the help centre carries full integration guides for four of the named marketplaces plus Foodics, Lightspeed K-Series and TouchBistro. SHORTFALL, and the documentation is unambiguous about it: nothing is self-install. Turning on a marketplace requires a Go-Live Request through Platform Settings with vendor verification and an activation window ("typically takes up to 48 hours to go live", weekdays only), and enabling the Scan and Pack module needs a support ticket -- "Scan and Pack needs to be activated by the UrbanPiper team before it's available in your account." The list is also a partner page written to sell, closing with Book a demo, rather than a catalogue with per-app detail pages. https://help.urbanpiper.com/basics/partner-with-us · retrieved 2026-08-31

extensibility-custom-fields-scripting

2026-09-02: 'custom field', 'custom attribute' and 'extra_data' remain zero across both complete corpora; the only 'custom' hits are Prime custom ROLES (a permission set), custom notification settings and custom report date ranges. NEW this pass: located the single key-value extension point in the menu-push schema and read its definition -- api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu types 'key_value_data' as array[object] whose 'key' carries an ALLOWED-VALUES list ('Servings' -> serve_range_max/serve_range_min; 'Nutrition' -> kcal_range_min/kcal_range_max; 'NutritionalInfo'; 'Deposit' -> deposit_charge with allowed values 0.15 and 0.25), i.e. a fixed vendor vocabulary rather than an operator-defined namespace. The surrounding schemas are closed the same way (api/references/item-tags publishes per-aggregator tag lists, food-types and supported-languages likewise), and the only merchant-supplied free text is name, description and ref_id. The extension mechanism that IS documented inverts the claim: webhooks the PARTNER hosts and UrbanPiper calls (api/endpoints/setting-up-webhooks, getting-started/webhooks-callbacks, resources/webhook-circuit-breaker), so operator logic runs on operator infrastructure, not vendor-hosted. NOT scored no because two of the three surfaces the claim spans are unbounded: api/readme disclaims completeness in as many words ('We try our best to keep this doc in sync with our development pace, but at times a gap creeps in'), the Atlas UI's configurable surface is not enumerated anywhere public, developers.urbanpiper.com is Clerk-gated, and support.urbanpiper.com (a separate Freshdesk solutions centre) has no obtainable robots.txt -- it 301s to itself in a loop under every UA tried -- so it was not fetched.

extensibility-headless-embedded

2026-09-02: 'kiosk', 'headless', 'embedded' and 'drive-thru' remain zero across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages. NEW this pass: tested the architectural premise directly rather than by keyword. 'upstream' occurs twice in the whole API reference and both are the same definition -- 'Upstream for UrbanPiper are the Food Delivery Companies/Food Aggregators (Example: Swiggy, Talabat, Deliveroo, etc)... while downstream refers to restaurant POS/ERPs/TILL/Billing Systems' (downstream/getting-started/overview) -- and grepping both corpora for 'create an order', 'place an order' and 'order creation' finds only a report field ('Order Creation Time') in help/data-and-reports. So the published API has no inbound order-creation endpoint for a third-party UI to drive; every documented flow relays orders the aggregators created, and the only first-party ordering front ends are UrbanPiper's own (the Meraki white-label web/app and the Prime order-taking surfaces). UNRESOLVED rather than no because the limitation is inferred from an instrument that disclaims its own completeness (api/readme: 'at times a gap creeps in'), because the separate UrbanPiper Developer Hub at developers.urbanpiper.com is behind Clerk authentication and unreadable, and because support.urbanpiper.com -- a Freshdesk solutions centre in neither dumped corpus -- serves an endless self-redirect at /robots.txt, so no policy could be obtained and it was not fetched. An embedded-ordering programme documented only in those places would be invisible to this pass.

extensibility-api-versioning-deprecation

An absence measured against a documentation set proven complete, which is what licenses a `no` on a claim about what a vendor PUBLISHES. The public API reference is retrievable whole as llms-full.txt (778,699 bytes), and its completeness was verified rather than assumed: the llms.txt manifest lists 86 entries, 0 of them unmatched against the dump's 229 headings, and the dump carries no pagination marker -- the instrument reproducing the 179th's known-positive case (14 unmatched on page 0 of the help centre) on the same run. Across that whole reference the strings changelog, deprecat and versioning occur ZERO times, and no endpoint carries a version-negotiation header or a sunset policy. SCOPE OF THE FINDING, stated because it bounds it: this is the POS-partner programme's documentation, the only API documentation UrbanPiper publishes; a changelog held privately for certified partners would not appear here and is not excluded by this evidence. https://api-docs.urbanpiper.com/downstream/llms-full.txt · retrieved 2026-08-31

extensibility-data-portability-exit differentiator

REPLACES a seeded placeholder rationale that recorded no work, not absence. WHAT EXISTS: a documented, machine-readable, operator-driven export. Central Report offers order transactions, item-wise transactions, item summaries, option-wise transactions, menu snapshot across all locations and store actions; 'You can download the report in either CSV or XLSX formats', with an emailed secure link and a daily schedule as alternatives, filterable across all brands and locations (data-and-reports/getting-started). The coverage is broad: the Order Transactions Report's documented fields include Customer Name and Customer ID, Payment Mode and Payment Transaction ID, order state, timing, amounts, taxes and charges, and the Menu Snapshot Across All Locations report covers the catalogue -- so orders, customers, menu and payments metadata are all reachable. NAMED SHORTFALL, and it is the 'at contract end' limb, refuted in the vendor's own words: the cancellation article's Before-you-begin warning reads 'Download any reports or data you need from UrbanPiper before your subscription ends, as your data will be permanently removed after cancellation', and the aftermath section states 'A week after the cancellation date, you won't be able to access your portal any longer.' There is therefore no on-demand export AT or AFTER contract end -- the operator must self-serve in advance, inside the retention window, and no bulk archive, escrow or extract-on-request process is offered. The API route is closed too: the 87-page partner reference publishes no export or bulk-extract endpoint. https://help.urbanpiper.com/business-manager/cancel-your-subscription · retrieved 2026-09-01

reliability-offline-order-entry

2026-09-02: re-measured rather than re-read. The word 'internet' occurs exactly TWICE in all 116 help.urbanpiper.com pages -- 'Once connected, your tablet will have access to the internet via the selected Wi-Fi network' (prime-app/connecting-your-tablet-to-wifi) and the cloud-printer prerequisite 'The printer needs internet access because it works by periodically checking in with UrbanPiper's servers online' (prime-web/cloud-printing-setup-guide) -- while 'internet connection', 'no internet', 'connection is lost', 'connectivity', 'goes down' and 'network issue' return zero occurrences each. 'offline' occurs eight times and none is about connectivity loss (marketing 'online and offline operations'; deactivating a location 'takes it offline'; aggregator mappings 'carried out offline, with assistance from the Zomato/Swiggy team'; a cloud printer being 'offline'). On record but still not an answer: Merchant Agreement cl. 16.10 excuses 'unavailability of the Services caused by circumstances beyond Our reasonable control, such as... inability to access the internet' and cl. 13.2 disclaims any warranty that access 'WILL BE UNINTERRUPTED' -- liability allocation, not terminal behaviour -- and store-manager/prime-web says 'No additional installation is needed -- it runs entirely in your browser'. No order-entry, ticket-routing or check-printing page mentions a queue, cache or replay. UNRESOLVED, and the silence is explicitly not bounded: support.urbanpiper.com is a fourth first-party surface (a Freshdesk solutions centre) carried in neither dumped corpus, and its /robots.txt 301-redirects to itself endlessly under ClaudeBot, Googlebot and a browser UA, so no policy is obtainable and it was not fetched.

reliability-offline-card-auth differentiator

UrbanPiper never holds card data, so there is nothing to store and forward. The privacy policy (last updated 11 Aug 2026) states the position affirmatively: 'Where payments are processed in connection with the Services, card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki.' The customer terms say the same from the other side -- 'We do not store, retain or process Your credit card or other payment information' (cl. 1.1, www.urbanpiper.com/legal/customer-terms-and-conditions). The only documented card path is an online gateway the operator brings themselves (Atlas > Meraki > Payments > Add Gateway, twelve gateways across six regions), which authorises against that gateway in real time; there is no card-present entry surface, no terminal-side vault and no offline authorisation mode anywhere in the 116-page help centre or the 87-page POS-partner API reference. Store-and-forward requires the vendor to retain a card credential it says it does not retain. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-01

reliability-offline-decline-liability differentiator

Both limbs fail on a fully read document set. There is no store-and-forward capability to allocate loss for (see reliability-offline-card-auth: the privacy policy states UrbanPiper stores no card numbers and no payment identifiers), and the published Merchant Agreement -- which cl. 16.9 declares 'the entire agreement' together with the Order Form -- contains no offline transaction cap, no per-transaction or cumulative offline limit, and no allocation of chargeback or decline loss. Its Charges and Payment clause 7 covers fees, late-payment interest at 1.5% per month, reactivation fees and non-refundability, and its Limitation of Liability clause 14.1 caps all liability at 'ONE (1) MONTH OF THE FEES PAID BY YOU' without mentioning transaction risk at all. Clause 2.4 pushes payment-dispute risk to the merchant in general terms: 'You are solely responsible for resolving disputes or grievances by the Customer and We shall have no liability or obligation for any claim arising from such payment records.' Nothing on either documentation host addresses offline declines. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

reliability-lan-degraded-multi-terminal differentiator

2026-09-02: re-checked the whole Store Manager set on help.urbanpiper.com (prime-app: connecting-your-tablet-to-wifi, connecting-printer-to-the-tablet, manage-orders-on-order-tracker, enabling-auto-print-settings; prime-web: overview, connecting-a-printer, connecting-a-printer-on-macos, assigning-a-printer-for-kot-invoice, print-automations, print-kot-for-kitchen-stations, cloud-printing-setup-guide), basics/compatible-hardware, and the 87-page POS-partner API reference. Nothing describes multi-terminal state sharing in either the connected or the degraded case: there is no table, check or seat object in the product at all (order state is the aggregator order lifecycle relayed to the POS), no LAN peer discovery, no local server and no primary/secondary designation. The single LAN element documented anywhere is printer transport -- 'The printer is connected to your Wi-Fi router using a LAN cable, and the network allows outbound internet access (no firewall or proxy blocking it). The printer needs internet access because it works by periodically checking in with UrbanPiper's servers online' -- which is a cloud dependency, not LAN-only operation. UNRESOLVED rather than no: every element above is an absence, no page states that LAN-only degraded operation is unsupported, and the doc surface is not closed -- support.urbanpiper.com (Freshdesk solutions centre, outside both dumped corpora) has no obtainable robots.txt, its /robots.txt returning an endless 301 to itself under every UA tried, so it was not fetched, and developers.urbanpiper.com is Clerk-gated.

reliability-local-transaction-engine differentiator

The vendor documents the opposite architecture in two places. The DPA's Schedule B (Technical and Organisational Measures, the SCC annex whose explanatory note requires measures to be described 'in specific (and not generic) terms') opens 'UrbanPiper's production environment is hosted on Amazon Web Services' and describes only cloud infrastructure -- multiple fault-independent availability zones, orchestration tooling that can 'regenerate hosts, building them from the latest backup'. On the merchant side the help centre states there is nothing to install: 'Prime Web is accessible directly through the Atlas management console... No additional installation is needed -- it runs entirely in your browser' (help.urbanpiper.com/store-manager/prime-web). Across 116 help pages and 87 API-reference pages there is no on-premise connector, edge server, local database or installable service; the only local software documented is QZ Tray, a browser print bridge, and the only local device that holds a queue is an Epson printer that polls UrbanPiper's cloud. POS integration is cloud-to-cloud HTTP -- webhooks plus REST endpoints -- which is precisely the request/response path the claim excludes. https://www.urbanpiper.com/legal/data-processing-agreement · retrieved 2026-09-01

reliability-offline-kds-printing

2026-09-02: re-read every printing article on help.urbanpiper.com and re-measured the connectivity vocabulary corpus-wide ('internet' appears in only two of 116 pages; 'no internet', 'connection is lost' and 'network issue' appear in none). prime-web/cloud-printing-setup-guide remains the only page bearing on the claim and it settles only part of it: cloud printing is internet-dependent by design -- 'The printer is connected to your Wi-Fi router using a LAN cable, and the network allows outbound internet access (no firewall or proxy blocking it). The printer needs internet access because it works by periodically checking in with UrbanPiper's servers online' -- and its stated fallback is a manual reprint from the browser, 'if cloud printing fails for any reason (network issue, printer offline, etc.), you will still be able to print the same Bill/KOT the regular way from Prime Web.' That is a fallback ACROSS print paths while the site is still online; Prime Web itself needs 'No additional installation... it runs entirely in your browser' against Atlas, so it is not a statement about a WAN outage. No article states whether KOT generation or kitchen-station routing survives an outage, and UrbanPiper ships no KDS of its own (the Scan and Pack article routes to the operator's KDS). UNRESOLVED: the internet dependency is documented for one print path only, no page states the offline behaviour of the others, and support.urbanpiper.com -- a fourth first-party doc surface in neither dumped corpus -- could not be read, its /robots.txt returning an endless self-redirect under every UA tried.

reliability-printer-fallback

The alerting half is documented and the failover half is manual. Alerting: when a cloud printer is added on Prime Web the operator supplies 'Notification emails -- email addresses to notify if a print job on this printer fails', and there is a failure log -- 'you can check if any print jobs failed, for example if a printer was offline or unreachable when a Bill/KOT was due to print... This opens a drawer listing all failed and expired print jobs, along with the order, printer, print type (Bill/KOT), and the reason each one failed.' A second path is deliberately kept armed: 'Qz-Tray setup is completed, and this same printer is also added under Receipt Printers on Prime Web. This acts as a fallback, if cloud printing fails for any reason (network issue, printer offline, etc.), you will still be able to print the same Bill/KOT the regular way from Prime Web.' SHORTFALL, and it is why this is not a yes: that fallback is an operator re-print from the browser, not automatic re-routing -- 'you will still be able to print', not 'the job is re-sent'. No backup-printer assignment, no failover order between kitchen stations and no KDS fallback target appears in assigning-a-printer-for-kot-invoice, print-automations or print-kot-for-kitchen-stations, and the alert is an email plus a drawer rather than an on-screen prompt to staff at the terminal. https://help.urbanpiper.com/store-manager/prime-web/cloud-printing-setup-guide · retrieved 2026-09-01

reliability-sync-conflict-handling

Two published rules, both in the POS-partner API reference. (1) Partition recovery, resources/webhook-circuit-breaker: when a partner's webhook endpoint fails more than 15 times in a minute the platform trips a circuit breaker and disables that host's webhooks for 1-3 minutes, then 'our system tries to push them at once when the webhooks are re-enabled', and the reconciliation rule is stated explicitly -- 'whatever the state of the order present in the Urbanpiper system, the same will be present in the Order Relay payload under the state/order_state attribute... if the state of the order is Acknowledged in our system due to status change happening from aggregator, then in the order relay payload, the state/order_state attribute will have the Acknowledged status instead of Placed. Please make sure that you do not expect only a Placed state value to be passed in that attribute.' That is current-state-wins on replay, documented as such. (2) Two-surface edit precedence, api/endpoints/menu/add-update-menu: 'platform_pricing only ever sets or updates the price for the platforms explicitly listed in it. It never resets a platform price you don't mention, and the base price never overwrites a platform price that already exists', with the pitfall spelled out -- 'if a platform price was set earlier (for example, through Atlas), sending only the base price will not update that platform -- the existing platform price takes precedence.' That is an explicit merge rule, deliberately not last-write-wins, between an edit made in the Atlas UI and one pushed by the POS. SHORTFALL, three parts. First, both rules govern the UrbanPiper-cloud-to-partner channel, not two operator devices: the claim's scenario cannot arise in Prime, which has no documented offline mode (Prime Web needs 'No additional installation... it runs entirely in your browser' against Atlas). Second, there is no general concurrency machinery -- no version, revision, ETag or updated-at conflict field anywhere in the menu, store or order schemas; the only other collision handling is a menu-push error string ('An item and a modifier have the same name, causing conflict') and the advisory 'Menu push is queued up due to multiple pushes or server lag at Swiggy. Wait for up to 4 hours before publishing the menu again.' Third, no operator prompt on conflict is documented anywhere. Checked against all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages retrieved 2026-09-01. https://api-docs.urbanpiper.com/downstream/resources/webhook-circuit-breaker · retrieved 2026-09-02

reliability-offline-feature-matrix

This is a publication claim and the publication surface is fully enumerated. Both documentation hosts are GitBook with permissive robots and machine-readable manifests -- help.urbanpiper.com/llms.txt lists 116 pages and api-docs.urbanpiper.com/downstream/llms.txt lists 87; all 203 were retrieved on 2026-09-01 and all 203 are live. Across that entire corpus the word 'offline' appears eleven times and not one is a feature-availability statement: marketing boilerplate ('online and offline operations'), deactivating a location ('takes it offline'), aggregator mapping ('carried out offline, with assistance from the Zomato team'), a cloud printer being 'offline or unreachable', and three aggregator rejection strings ('Your outlet is currently offline due to high number of rejections'). There is no offline-mode article, no supported/unsupported table, no degraded-operation page and no per-feature availability matrix; the four legal pages at www.urbanpiper.com/legal/ contain none either. The vendor publishes no such list. https://help.urbanpiper.com/llms.txt · retrieved 2026-09-01

reliability-public-status-page

Both limbs verified, and the page itself was fetched rather than taken on the documentation's word. status.urbanpiper.com returns 200 with no login and renders per-component state: Atlas Portal, "Online Delivery Service Providers (DSP) 5 components", "Store operations 4 components", "Direct Ordering Channel (Meraki) 4 components" and "Integrations 4 components", each with a 90-day uptime figure over a "Jun 2026 - Aug 2026" window and a per-day incident calendar, above a "We are fully operational" banner. History is therefore present as well as current state. The help centre documents the same surface and what it is for: it shows "Integrations (e.g., with POS and delivery platforms) / Dashboard performance / API availability / Scheduled maintenance / Known incidents or outages", and "You can subscribe to receive status alerts via email or SMS directly from the status page." https://help.urbanpiper.com/basics/urbanpiper-status · retrieved 2026-08-31

reliability-contractual-uptime-sla differentiator

The standard agreement is published in full and warrants the opposite. Clause 13.2: 'YOU ACKNOWLEDGE AND AGREE THAT URBANPIPER DOES NOT WARRANT THAT THE ACCESS TO THE SERVICES WILL BE UNINTERRUPTED, TIMELY, SECURE, ERROR-FREE OR FREE FROM VIRUSES... URBANPIPER DOES NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED AS THE SERVICES ARE PROVIDED OVER THE INTERNET'; cl. 13.1 puts the Services on an 'AS IS' and 'AS AVAILABLE' basis. No uptime percentage appears anywhere in the agreement, and the only remedy structure is a liability cap -- cl. 14.1 limits aggregate liability to 'ONE (1) MONTH OF THE FEES PAID BY YOU' -- with no service-credit mechanism of any kind; cl. 16.10 further excuses unavailability caused by matters beyond UrbanPiper's control. Clause 16.9 makes this text prevail over an Order Form except where the Order Form expressly amends it. CAVEAT recorded rather than hidden: cl. 3.2 says 'We shall take responsibility for certain aspects of the Services including support and resolution timelines as set forth in the Order Form', and Order Forms are per-merchant and unpublished, so a negotiated support commitment may exist. What the claim asks is whether an uptime percentage plus a credit remedy is published or sits in the standard agreement, and it is not: the standard agreement disclaims uptime instead. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

reliability-incident-postmortems

The vendor documents that it publishes root-cause summaries: during "any system degradation or outage" the status page carries "Issue identification and investigation / Ongoing resolution progress / Final incident resolution and root cause (post-mortem)." SHORTFALL, and it is why this is not a `yes`: the status page was fetched on 2026-08-31 and every component reads 100% uptime across its whole Jun-Aug 2026 window, so there is no incident on it and therefore NO PUBLISHED POST-MORTEM TO INSPECT. What is established is the vendor's stated practice, not an artefact; a written post-incident report has not been seen. That distinction is the difference between documenting a policy and evidencing its output, and it is recorded here so a later pass with an incident in the window can settle the cell either way. https://help.urbanpiper.com/basics/urbanpiper-status · retrieved 2026-08-31

reliability-247-live-support

Live human support is included with no premium tier documented, but neither the phone limb nor the 24/7/365 limb is met. The vendor's whole published support-channel statement is the Contact Us article: 'If you couldn't find what you were looking for in our Help Center, our Support Team is ready to assist you. Click the chat icon at the top right corner of your Manager Portal to connect with one of our support agents... Our agents can use screen sharing or call you, if needed, to help resolve your issue quickly. Prefer email? You can also reach us at support@urbanpiper.com.' In-portal chat with a human agent is available to any account, and no paid support tier, ticket allowance or premium plan appears anywhere in the help centre or the Merchant Agreement. SHORTFALL: no support telephone number is published at all -- a call is an agent-initiated callback 'if needed' -- and no coverage window is stated anywhere, let alone 24/7/365; the Merchant Agreement instead defers the commitment to a private document, cl. 3.2, 'We shall take responsibility for certain aspects of the Services including support and resolution timelines as set forth in the Order Form.' A separate pos.support@urbanpiper.com queue exists for POS partners, also with no hours. https://help.urbanpiper.com/basics/contact-us · retrieved 2026-09-01

reliability-onsite-install differentiator

2026-09-02: re-grepped all 116 help.urbanpiper.com pages on word boundaries for 'onsite', 'on-site', 'site visit', 'field engineer', 'installation', 'installer', 'technician', 'dealer' and 'reseller'. There is exactly ONE hit in the entire help centre and it points the other way -- 'No additional installation is needed -- it runs entirely in your browser' (store-manager/prime-web). The most complete onboarding document, pos-integrations/foodics/integrate-your-foodics-account-with-urbanpiper, 'outlines the onboarding steps, timelines, and key operational guidelines' in three phases (Authorization, Menu Setup, Menu Pull and Aggregator Mapping) and assigns a named human -- 'An UrbanPiper Onboarding Manager will be assigned to work alongside the Foodics team and support you throughout the entire integration process' -- with published go-live timelines (Deliveroo 24-48 hours; Talabat requests Sunday/Tuesday, go-live Wednesday/Thursday), but every documented step is performed in a console or by email. The Merchant Agreement, re-read 2026-09-02, describes a 'DIY approach' with remote assistance (cl. 2.8), puts training in Value Added Services -- 'We may provide training to You and Your Users as a part of the Value Added Services' (cl. 6) -- and defers 'support and resolution timelines' to the Order Form (cl. 3.2). help.urbanpiper.com/basics/partner-with-us and www.urbanpiper.com/integrations enumerate partners only as POS, delivery, fulfilment, online-ordering, payment and marketing categories, with no implementation-partner or certified-dealer category. UNRESOLVED because the Order Form catalogue that would price an on-site option is private, so an on-site programme cannot be excluded.

reliability-menu-build-service differentiator

The vendor does put its own people on the initial build, but not on the menu itself. Documented as a staffed process: 'An UrbanPiper Onboarding Manager will be assigned to work alongside the Foodics team and support you throughout the entire integration process', the onboarding runs in three phases ending in 'Menu Pull and Aggregator Mapping', and 'After the menu pull, the UrbanPiper Onboarding Manager will coordinate with the various aggregators to map the brand's locations. This is a manual process, and timelines differ by aggregator' -- with a published timeline table. Account creation is also done for the operator: 'Once you decide to signup with UrbanPiper, the onboarding team will take care of setting up your account and share with you an administrator access' (basics/editor). The aggregator-side menu mapping is likewise vendor-assisted: 'This mapping is carried out offline, with assistance from the Zomato team.' SHORTFALL: the initial menu is not built by UrbanPiper, it is imported from the operator's existing POS -- 'Choose Import Menu from the dropdown... It usually takes 2 to 5 minutes for the menu to be updated. Once the menu is pulled from the POS, you can make the necessary changes and publish the menu on the DSPs' -- and every catalogue task after that (items, modifier groups, charges, taxes, publishing) is documented as the operator's own work in Atlas, in a product the Merchant Agreement describes as built 'keeping a Do-It-Yourself (DIY) approach in mind' (cl. 2.8). For a merchant with no POS menu to pull, no vendor menu-build service is documented at all. https://help.urbanpiper.com/pos-integrations/foodics/integrate-your-foodics-account-with-urbanpiper · retrieved 2026-09-01

reliability-hardware-replacement-sla

2026-09-02: re-read the Merchant Agreement at www.urbanpiper.com/legal/merchant-agreement and re-grepped all 116 help.urbanpiper.com pages on word boundaries for 'warranty', 'warranties', 'replacement', 'repair', 'RMA' and 'technician' -- ZERO hits in the help centre for every one of them. UrbanPiper does issue hardware to some merchants: the agreement defines 'Hardware' as 'the thermal printer and other items including but not limited to a tablet, stand, modem and computer cables provided to Merchant by UrbanPiper', it 'shall remain the exclusive property of UrbanPiper', and cl. 8.7 prices it on exit at '$350.00 per printer, $150.00 per tablet, and $250.00 per cellular modem', refunded if returned in good operating condition within five business days. NEW this pass, and the clause the 2026-09-01 rationale missed: cl. 2.7 supplies it with no warranty at all -- 'Hardware is provided to You Merchant AS IS' -- and its only repair term runs toward the merchant: 'If damages to the Hardware are caused by the Merchant's misuse, the Merchant agrees to reimburse UrbanPiper for the full cost of repairing or replacing the damaged Hardware plus shipping costs.' No advance exchange, no loaner, no turnaround time and no hardware SLA appears anywhere in the agreement, and help.urbanpiper.com/basics/compatible-hardware is a buy-your-own minimum-specification page ('minimum specification requirements for buying hardware to use UrbanPiper products', with a device-certification path taking '20-25 working days') rather than a replacement programme. UNRESOLVED rather than no because the claim admits a PURCHASABLE programme and cl. 3.2 places 'support and resolution timelines' in the per-merchant Order Form, which is not published.

reliability-backup-restore

Half of the claim's first limb is met and the rest is not. Retrieval is genuinely self-serve: Merchant Agreement cl. 10.1 states 'You will have access to the dashboards of the Services and all the Customer Data or order-related data which can be downloaded from the Services. In the event You require such data in a format which is not available, a request can be made to Us', and the Central Report UI exports to 'CSV or XLSX formats' on demand or on a daily schedule. The same clause makes self-backup the merchant's own job in as many words: 'You are advised to take regular data backups to ensure all historical data is available with them at all times.' SHORTFALL on everything else. There is no restore path at all -- nothing in the help centre or the API reference lets an operator upload a backup or roll an account back -- no account-level backup artifact exists (only per-report downloads), and no RPO or RTO figure is published anywhere. The DPA's Schedule B describes the vendor-side capability without numbers: infrastructure 'spans multiple fault-independent availability zones', with orchestration tooling 'that has the ability to regenerate hosts, building them from the latest backup', and no objective attached. Reach is capped too: cl. 10.2 warns 'data preceding more than one (1) year may not be available for some data sets', releasable at UrbanPiper's discretion 'subject to a reasonable fee as determined by Us'. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

reliability-pci-dss-4-attestation

No PCI attestation is published, and the vendor's own certification sentence limits how any such report is released. Privacy policy s.9 (last updated 11 Aug 2026, re-read 2 Sep 2026): 'We maintain an information security programme aligned to recognised standards and hold ISO/IEC 27001 certification and a SOC 2 attestation... The scope and currency of Our certifications, and copies of relevant reports, are available to Merchants on request... subject to appropriate confidentiality undertakings.' That is a stated limitation on publication -- reports go to merchants under confidentiality, not to the public -- and this claim asks whether a current v4.0/4.0.1 AoC or validated P2PE listing is PUBLISHED. NOT RELIED ON: that the same sentence exhaustively lists every attestation the vendor holds. It does not, and an audit on 2 Sep 2026 refuted that reading; the cell no longer rests on it. What carries it instead is measured absence of any publication surface plus a positive allocation of PCI to others: 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki.' www.urbanpiper.com/sitemap.xml enumerates exactly four legal pages and no security, trust, compliance or pricing page; /security, /trust and /pricing all return a genuine HTTP 404 (identical 39,423-byte 404 body, re-probed 2 Sep 2026) and trust.urbanpiper.com and security.urbanpiper.com do not resolve. The string PCI does not occur once in the 285,626 bytes of the help centre's two-page llms-full dump (re-fetched 2 Sep 2026), nor in the API reference, the Merchant Agreement or the DPA Schedule B measures. A third-party press release for the Payarc integration says only 'Built-in security with PCI-compliant processing', which is Payarc's compliance and not a published UrbanPiper attestation. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-02

reliability-mfa-role-based-access

Role-based permissions are documented in more depth than most records in this corpus can show, and MFA is not documented at all. Prime ships six standard roles -- Captain, Online Order Processor, Online Order Supervisor, Cashier, Manager, Administrator -- with duties separated at a useful granularity (Captains "cannot settle bills; that's handled by Cashiers"), location-scoped assignment, and custom roles: "Prime gives you the flexibility to create custom roles tailored to your specific needs... assign very specific permissions." Atlas ships ten, including data-scoped variants -- "Non-HQ Analytics: Provides access to analytics data, but strictly limited to specific locations. Users cannot download full business data or reports without a location filter." SHORTFALL: no multi-factor authentication appears anywhere in the help centre for either back-office or store login. The only one-time code documented is a password-RESET PIN sent to a registered email, and the store-operations PIN is a shared-device unlock, not a second factor. https://help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas · retrieved 2026-08-31

reliability-self-serve-training

The public free-training half is met generously. help.urbanpiper.com is open to an ordinary user agent, publishes its whole corpus as a single 231,780-byte llms-full.txt, and the operator-facing articles are built around embedded video walkthroughs -- roughly forty trainn.co tutorial embeds across menu building, publishing, 86ing, store status, printer setup, user access and order management, several with an Arabic-language version linked beside the English one. SHORTFALL: the claim's second limb is a practice or training MODE on the terminal, and nothing of the sort is documented. Prime has no sandbox, demo or training-mode article; the closest the documentation comes is telling an operator to acknowledge a real incoming order to test the Scan and Pack flow, which is live production. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

reliability-failover-terminal-role differentiator

2026-09-02: re-checked basics/compatible-hardware (which specifies standalone Android and iOS devices, printers and a Chrome laptop, with no server, controller or master class, and warns only that 'Devices that do not meet these requirements may or may not work properly'), every Prime app and Prime web article, and the 87-page POS-partner API reference. There is no master/server terminal role in this product to fail over: Prime Web is reached 'directly through the Atlas management console' and 'No additional installation is needed -- it runs entirely in your browser', the Prime app is a client of the same cloud, each device authenticates independently, and no primary/secondary designation, local-server election or terminal-role setting appears anywhere in either corpus. Vendor-side resilience is described instead, in DPA Schedule B: infrastructure that 'spans multiple fault-independent availability zones which are physically separated from one another' and 'is able to detect and route around issues experienced by hosts in real time' -- cloud failover, which is not the claim. UNRESOLVED rather than negative on this project's bar: the absence of a role model is inferred from the hardware and app documentation rather than stated, no page says that no terminal can assume a server role, and the doc surface is not closed -- support.urbanpiper.com, a Freshdesk solutions centre in neither dumped corpus, has no obtainable robots.txt (its /robots.txt 301s to itself endlessly under ClaudeBot, Googlebot and a browser UA) so it was not fetched, and developers.urbanpiper.com is Clerk-gated.

reliability-cellular-backup

First-party cellular hardware is documented; automatic failover is not. The Merchant Agreement defines Hardware as 'the thermal printer and other items including but not limited to a tablet, stand, modem and computer cables provided to Merchant by UrbanPiper' and prices a cellular modem explicitly on exit: 'UrbanPiper shall charge a Hardware Fee of $350.00 per printer, $150.00 per tablet, and $250.00 per cellular modem' (cl. 8.7). So UrbanPiper does issue a cellular modem to merchants under contract, which is the first-party half of the claim. SHORTFALL: nothing states what it is for. No page in the 116-page help centre mentions cellular, LTE, 4G or a data SIM -- the connectivity article is prime-app/connecting-your-tablet-to-wifi, and the cloud-printing prerequisites assume 'a Wi-Fi router using a LAN cable' -- so the modem is documented only as a billable asset, with no configuration article, no automatic switchover behaviour, and no statement that it is a backup path rather than a store's primary connection. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

commercial-month-to-month-contract differentiator

The cancellation article establishes monthly billing and self-serve exit without a sales call: an operator raises the request from Atlas Settings > Profile > Cancel Subscription, and "You can cancel from the current billing month or a future one. The full month in which the cancellation takes effect will be charged." No minimum term, notice period, early-termination charge or remaining-term liability appears anywhere in the article, and the only stated cost of leaving is the current month. SHORTFALL: the claim asks for a PUBLICLY OFFERED month-to-month subscription for the core tier, and that is an inference here rather than a statement. UrbanPiper publishes no pricing page and no terms of service in this help centre, no article states the contract length, and the exit is not fully self-serve either -- "After you submit the form, a member of our team will get in touch with you to complete the process." https://help.urbanpiper.com/business-manager/cancel-your-subscription · retrieved 2026-08-31

commercial-no-early-termination-fee differentiator

The exit terms are published and carry no termination charge, but they do not state the claim's proposition and one clause cuts against it. In favour: termination for convenience is bilateral and cheap -- 'Either Party may terminate this Agreement at any time and without cause, by giving not less than one (1) month's prior written notice' (cl. 8.2) -- and cl. 7.9 spells out the exit cost as the notice period only: 'Merchants can cancel their subscription (applicable for the whole Account or to a specific outlet) at any time by providing UrbanPiper a 30 days prior notice... Merchant's cancellation will take effect at the end of the notice period of 30 days and the Merchant shall be billed accordingly for the notice period term.' No early-termination fee, no liquidated damages clause and no acceleration of remaining-term fees appears anywhere in the agreement; the help centre says the same operationally ('The full month in which the cancellation takes effect will be charged'). SHORTFALL: the agreement never states that there is no ETF, and cll. 7.3 and 7.9 impose the economic equivalent on a prepaid term -- 'all Fees are non-refundable. No refunds shall be issued for partial use or non-use of the Services', while 'All subscriptions (monthly, quarterly and yearly) renew automatically' -- so a merchant on the marketed annual plan forfeits the unused balance. Two further exit charges exist: a Hardware Fee of $350 per printer, $150 per tablet and $250 per cellular modem collected at cancellation (refundable on return within five business days, cl. 8.7) and a reactivation fee after suspension (cl. 7.5). https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

commercial-autorenew-terms-published

No publicly accessible contract terms, auto-renewal term, or cancellation notice window; the pricing URL itself returns 404. https://www.urbanpiper.com/ · retrieved 2026-08-01

commercial-processing-not-bundled differentiator

This is the strongest form of the claim: UrbanPiper takes no processing position at all, so there is nothing to lock. The operator brings their own gateway account -- 'You can configure payment gateways on Meraki to enable online payments for your customers'; configuration is Atlas > Meraki > Payments > Add Gateway, where 'Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard.' Twelve gateways are published as a region matrix across India, MENA, KSA, UK, LATAM and USCAN: RAZORPAY, PAYMENTOS, PHONEPE, INSTAMOJO, PAYSTACK, PAYTABS, STRIPE, PAYTMBLINK, PAYTABS_V2, PAYULATINAMERICA, MERCADOPAGO and FREEDOMPAY, configurable 'globally for all outlets, or per outlet if needed'. The legal documents corroborate that no in-house processing exists: 'We do not store, retain or process Your credit card or other payment information' (customer terms cl. 1.1) and 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS)' (privacy policy s.9). On marketplace orders the aggregator collects. No UrbanPiper merchant-acquiring product appears anywhere in 203 pages of documentation or in the Merchant Agreement's Charges and Payment clause, which prices subscription fees only. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-01

commercial-interchange-plus-published differentiator

The vendor sells no card processing, so it publishes no processing rate of any structure -- interchange-plus or blended. Affirmatively stated: 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki' (privacy policy s.9, updated 11 Aug 2026), and 'We do not store, retain or process Your credit card or other payment information' (customer terms cl. 1.1). The operator supplies their own gateway credentials in Atlas and contracts the rate with that gateway directly (help.urbanpiper.com/direct-ordering/configuring-payment-gateway). Consistent with that, no basis-point figure, per-transaction figure or discount rate appears anywhere in the 116-page help centre, the 87-page API reference or the four legal pages; the Merchant Agreement's Charges and Payment clause 7 locates every fee in a private Order Form and describes subscription fees only, the sole percentage in the document being late-payment interest at 1.5% per month. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-01

commercial-rate-increase-clause differentiator

Scored against the nearest thing this vendor has: there is no processing agreement at all, since merchants bring their own gateway and UrbanPiper states it does not process card payments, so the subject is the software subscription. The agreement does constrain price changes, in one region block: 'We may on a mutually agreed basis change prices at any time' (cl. 7.10, headed 'Applicable for the Merchants in USA, LATAM and other applicable regions'), which is a mutual-consent formulation rather than a unilateral right; and exit is always available without cause on one month's notice (cl. 8.2), which is the escape route the claim's second limb contemplates. SHORTFALL on every other element: no cap, index or percentage limit is stated; that mutual-agreement sentence is expressly scoped to one set of regions and no equivalent appears for India, MENA or the UK; nothing addresses pass-through interchange or network fees, because the vendor has no processing position to pass them through; cl. 16.2 lets UrbanPiper amend the agreement itself unilaterally on ten days' notice with continued use deemed acceptance; and the exit is not penalty-free in substance, since cl. 7.3 makes all fees non-refundable 'for partial use or non-use of the Services' and annual subscriptions auto-renew (cl. 7.9). https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

commercial-pricing-published

The published /pricing page returns HTTP 404 and no dollar figures appear anywhere on the site; quote-only. https://www.urbanpiper.com/ · retrieved 2026-08-01

commercial-module-unbundling differentiator

2026-09-02: read a vendor pricing page the 2026-09-01 pass concluded did not exist. https://www.urbanpiper.com/uk/free-trial states 'Plans from GBP 79', 'No one-time set-up fee', 'Unlimited orders; No per order charges', 'No additional costs', and -- directly on the unit of sale -- 'The pricing for Hub depends on the type of Hub integration you are opting for and the overall scale of your business based on both the number of physical locations and the number of brands you operate. To know the specific pricing for your restaurant, contact us.' So the published pricing units are integration type, physical location and brand, and there is no module or add-on menu anywhere on it. The Merchant Agreement, re-read the same day, agrees on the unit: 'Your access and use of the Services is restricted to the specified number brand outlets or stores as specified in the relevant Order Form' (cl. 2.1); 'UrbanPiper shall charge the Merchant only for the brand locations which are considered Live Location / Active Location' (cl. 7.2); and cancellation is scoped to the account or the outlet -- 'Merchants can cancel their subscription (applicable for the whole Account or to a specific outlet) at any time by providing UrbanPiper a 30 days prior notice' (cl. 7.9), with cl. 8.4 permitting termination of 'one or more of Your Account(s)'. Every price is nevertheless deferred to a private document (cl. 7.1: 'All charges associated with Your Account and use of our services (Fees)... shall be mentioned in an Order Form'; cl. 6 the same for Value Added Services). The vendor does sell three separately branded products (Hub, Meraki and Orderline AI, each with its own marketing page and its own Atlas surface), which is suggestive of modular purchase. UNRESOLVED: no clause or page states that a module may be added or cancelled independently, none states that it may not, no repricing rule is published, and the Order Form that would settle it is private.

commercial-hardware-purchase-outright

UrbanPiper sells no hardware, so no lease or rental is possible: the Compatible Hardware page publishes 'the minimum specification requirements for buying hardware to use UrbanPiper products' — commodity Android and iOS devices, receipt printers and laptops the operator sources independently. The shortfall against the claim's letter: there is no vendor-published price list and no first-party purchase channel, and no KDS hardware is specified at all. https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-08-04

commercial-hardware-not-locked differentiator

The vendor publishes minimum specifications rather than a device list, which is the strongest form of this claim. "Please find below the minimum specification requirements for buying hardware to use UrbanPiper products", followed by RAM/storage/CPU/screen/OS tables for generic Android handhelds, phones, tablets and terminals (Android 9+) and for iOS phones and tablets, a laptop row reading "Google Chrome / latest / 13 inch or above", and a printer matrix listing the ESC/POS, STAR LINE and STAR GRAPHIC command modes over USB, Bluetooth, Ethernet, parallel and serial, in 58 mm, 80 mm and custom widths. The governing sentence is explicit that nothing is vendor-locked: "Any device that adheres to the Minimum Specification Requirements (MSR) will work fine with our products." The vendor even documents a certification path for a device it has not tested, needing "20-25 working days to complete the testing and provide certification." https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-08-31

commercial-implementation-fee-published

Nothing is published, and the agreement says where the numbers live instead. 'All charges associated with Your Account and use of our services (Fees) and any other details about such Fees including payment specifics shall be mentioned in an Order Form' (cl. 7.1), and onboarding-adjacent services are routed the same way: 'At Your option, We may provide training to You and Your Users as a part of the Value Added Services. The charges for Value added Services shall be as set forth in the Order Form' (cl. 6). Order Forms are per-merchant and unpublished. On the public side there is no pricing page at all -- www.urbanpiper.com/pricing returns HTTP 404 and the site's own sitemap.xml lists no pricing, implementation or onboarding-fee page -- and no currency figure of any kind appears in the 116-page help centre. The only amounts UrbanPiper publishes anywhere are the returnable hardware deposits in cl. 8.7 ($350 printer, $150 tablet, $250 cellular modem), which are not implementation fees. No implementation, menu-build, onboarding or training fee is stated as an amount, and none is stated as $0. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

commercial-data-export-self-serve

STRENGTHENED WITHIN THIS SESSION from a role-model inference to the article that documents the export itself, found on page 1 of a paginated llms-full.txt. Export is self-serve, unticketed and free so far as anything published says: "Navigate to the All Apps section and select Central Report", pick a report, "Choose a pre-defined time range (daily, yesterday's, this week's, monthly) or select a custom date", "Apply filters to sort by brand, location, or aggregator", then "click the download button to export it directly. You can download the report in either CSV or XLSX formats." Depth is real: orders at one row per order with payment mode and payment transaction ID, line items in the Item-wise report, modifiers in the Option-wise report, and a daily scheduled email. The role model corroborates that this is governed rather than absent -- "Non-HQ Report... Users cannot download reports that cover the entire business." SHORTFALL, and it is why this is not a `yes`: the claim asks for FULL transactional history including labour, and no labour data exists in this product at all -- there is no time clock, no hours and no payroll object anywhere in the help centre. No retention window is published either, so how much history a download can reach is undocumented. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

commercial-export-customer-and-loyalty differentiator

Guest identity is exportable as a by-product of order data; loyalty and gift-card balances are not exportable at all. What works: Central Report exports are self-serve and machine-readable -- pick a report, 'Choose a pre-defined time range... or select a custom date', 'click the download button to export it directly. You can download the report in either CSV or XLSX formats' -- and the Order Transactions Report carries Customer Name and Customer ID columns per order. The contract backs the general right: 'You will have access to the dashboards of the Services and all the Customer Data or order-related data which can be downloaded from the Services. In the event You require such data in a format which is not available, a request can be made to Us' (Merchant Agreement cl. 10.1). SHORTFALL, and it is threefold. The published report catalogue is eight reports -- order transactions, order status transitions, item-wise, items summary across locations, option-wise, menu snapshot across locations and store action -- and not one is a customer list, so there is no guest-record export as such, only orders that happen to carry two customer columns. No loyalty point ledger or balance export exists anywhere: the only loyalty balance in the documentation is a campaign merge field, '{{user_points}} -- Shows the customer's current loyalty points balance', with no report behind it. And gift cards do not exist in this product at all -- the string occurs zero times in 116 help pages and 87 API pages -- so no gift-card liability balance can be exported. Reach is capped as well: cl. 10.2 warns 'data preceding more than one (1) year may not be available for some data sets', released at the vendor's discretion 'subject to a reasonable fee'. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-09-01

commercial-post-termination-export-window differentiator

A defined window is documented, and the same article contradicts it, so the cell records both. Portal access outlives the cancellation date by a stated period: "A week after the cancellation date, you won't be able to access your portal any longer", and the request itself is reversible up to that point -- "you can always Withdraw your request by going to same place you went to cancel your subscription." That is a defined number of days rather than an immediate cutoff, which is what the claim asks. SHORTFALL: the warning at the top of the same article says the opposite about the DATA -- "Download any reports or data you need from UrbanPiper before your subscription ends, as your data will be permanently removed after cancellation" -- so the operator is told both that access persists for a week and that the data is already gone. No retention period, export format, bulk export mechanism or API is named, and the documented exit path for the data is manual report downloads before the end date. https://help.urbanpiper.com/business-manager/cancel-your-subscription · retrieved 2026-08-31

commercial-data-ownership-clause differentiator

Both limbs are stated expressly in the published Merchant Agreement. Ownership, cl. 4.2: 'You own the rights to the Customer Data that You provide to Us. We do not claim ownership over such Customer Data. You hereby grant Us a royalty-free licence and right to use Customer Data solely to provide, support, maintain and improve the Services.' Customer Data is defined broadly enough to cover the claim's subject matter -- 'all electronic data, text, messages, personal data or other materials, including without limitation Personal Data of Users and Customers, submitted to the Services'. The constraint on vendor use is the word 'solely' in that licence, reinforced by cl. 9.4 ('We shall Process Customer Data only to provide, maintain and improve the Services, or prevent or address any technical problems, or at Your request in connection with support requests') and by the controller/processor allocation in cl. 9.6 ('We shall Process any Personal Data only on Your behalf and as Your data processor and that You are deemed to be the data controller'). The carve-out is exactly the one the claim permits and it is fenced: aggregated data 'which does not identify Your Users, Customers or any other identifiable individual' may be used for any lawful purpose (cl. 9.10), and cl. 4.5(a) adds 'UrbanPiper will only disclose aggregate/anonymous Data externally in a de-identified (anonymous) form that does not identify Merchant or its customers, and that is stripped of all persistent identifiers.' The privacy policy adds 'We do not sell Your Personal Data for money.' The two extractions outside guest data are disclosed rather than hidden: feedback assignment (cl. 4.3) and a logo and case-study publicity licence (cl. 16.7). https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

commercial-source-available-selfhost

The licence is the opposite of source-available and self-hosting is excluded by the grant itself. The merchant receives only 'the limited, non-exclusive, non transferable, revocable right to access and use the Services for Your internal business purposes' during the subscription term (cl. 1.1), and cl. 2.2(a)-(b) forbids exactly what a source-available licence permits: the merchant may not 'license, sublicense, sell, resell, rent, lease, transfer, assign, distribute, timeshare disassemble, reverse engineer, decompile or make the Services available to any third party', nor 'modify, adapt, or hack the Services'. Clause 4.1 reserves everything: 'all rights, title and interest in and to all intellectual property... including patents, inventions, copyrights, trademarks, domain names, trade secrets, know-how Code, visual interface, graphic designs, user interface, user experience, associated with the Service shall belong to and remain exclusively with Us', and cl. 4.4 adds 'All rights not expressly provided to You herein are reserved by Us.' The deployment is vendor-hosted SaaS: 'UrbanPiper's production environment is hosted on Amazon Web Services' (DPA Schedule B), and Prime Web 'runs entirely in your browser' with 'no additional installation'. No repository, licence file, self-hosting guide or distributable component appears in the 116-page help centre or the 87-page API reference. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

commercial-pci-p2pe-tokenization

There is no card-entry surface to encrypt and no SAQ is named anywhere. The vendor states it handles no card data: 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki' (privacy policy s.9, updated 11 Aug 2026), and the customer terms put it flatly -- 'We do not store, retain or process Your credit card or other payment information' (cl. 1.1). Payments on the vendor's own channel are online gateway transactions against credentials the operator supplies (Atlas > Meraki > Payments), and marketplace orders are collected by the aggregator; basics/compatible-hardware specifies only Android and iOS devices, receipt printers and a Chrome laptop, with no PIN pad, card reader or encrypting terminal in the matrix. Consequently no validated P2PE solution or listing, no hardware-encrypted entry path, no tokenization service and no SAQ type -- A, A-EP or P2PE-HW -- appears in the 116-page help centre, the 87-page API reference, the Merchant Agreement, the DPA (including its Schedule B technical measures) or the privacy policy. The string PCI occurs once on any first-party surface, in the sentence quoted above, and it assigns the obligation to someone else. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-01

commercial-pci-dss-4-controls

Neither limb is documented, and the vendor's own security enumerations are where they would be. The DPA's Schedule B is the SCC annex whose explanatory note requires measures to be described 'in specific (and not generic) terms'; it details encryption ('AES-256, applied at the storage layer across databases, object storage and backups, with encryption keys managed through AWS Key Management Service', 'TLS v1.2 or higher'), availability zones, VAPT audits and centralised log retention -- and mentions no multi-factor authentication at all, for a cardholder data environment or otherwise. The privacy policy's security section lists 'encryption of Personal Data in transit and at rest, role-based access controls, network and infrastructure protection, regular security testing, and confidentiality obligations on Our personnel', again without MFA, and names ISO/IEC 27001 and SOC 2 as the programme's frames rather than PCI DSS. Nothing anywhere addresses payment-page script integrity, Requirement 6.4.3 or 11.6.1, or tamper detection for the hosted Meraki checkout. The string PCI appears exactly once across all first-party surfaces, assigning compliance to third-party processors, and the vendor states it holds no card data around which to define a CDE. No PCI DSS version, requirement number or future-dated control is documented in 203 documentation pages or four legal pages. https://www.urbanpiper.com/legal/data-processing-agreement · retrieved 2026-09-01

commercial-soc2-attestation

Stated verbatim, including the on-request-under-confidentiality mechanism the claim asks for. Privacy policy section 9 (Effective 14 Mar 2023, last updated 11 Aug 2026): 'We maintain an information security programme aligned to recognised standards and hold ISO/IEC 27001 certification and a SOC 2 attestation, and We operate a data protection programme designed to meet the requirements of the EU and UK General Data Protection Regulation (GDPR). The scope and currency of Our certifications, and copies of relevant reports, are available to Merchants on request through (by contacting Us at the details in the Contact section) subject to appropriate confidentiality undertakings.' That is a present-tense assertion of a current ISO/IEC 27001 certification -- which satisfies the claim's disjunction on its own -- plus a SOC 2 attestation, and an undertaking to hand over the reports under confidentiality. Corroborating detail rather than marketing: the DPA grants audit rights over 'the TOMs (including data Processing systems, policies, procedures and records)' and its Schedule B names specific controls (AES-256 at rest with AWS KMS, TLS v1.2+, multi-AZ infrastructure, VAPT). Recorded limits: the SOC 2 is not stated to be Type II rather than Type I, no report date, auditor or scope boundary is published, and there is no trust portal to self-serve them -- www.urbanpiper.com/security, /trust and /compliance all return HTTP 404 and trust.urbanpiper.com does not resolve. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-01

commercial-privacy-dsar-tooling

The paper half is fully met and the product half is absent. A DPA is published and executable rather than available on request -- www.urbanpiper.com/legal/data-processing-agreement, incorporated by Merchant Agreement cl. 9.5, carrying the EU SCCs (Modules 2 and 3), the UK Addendum, Swiss variations, a sub-processor change process with fifteen days' notice and an objection right, a 48-hour breach-notification commitment and audit rights. Data-subject requests are addressed contractually: 'In case the Merchant receives any request or communication from Data Subjects which relate to the Processing of Personal Data (Request), UrbanPiper shall reasonably provide the Merchant with full cooperation, information and assistance in relation to any Request', with identification within a stated number of business days; the privacy policy commits to access, correction, deletion and erasure, objection, restriction and portability rights exercisable at infosec@urbanpiper.com and names CCPA/CPRA plus the Virginia, Colorado, Connecticut, Utah and Texas regimes. SHORTFALL: none of that is in-app tooling. Across the 116-page help centre there is no guest-lookup, guest-export or guest-delete function -- no article documents locating an individual customer's records, exporting them or deleting them, and the eight published reports are order-level with no per-guest erasure action; the Atlas surfaces documented for customer data are campaign segments and order reports. The mechanism is an email to the vendor, and the DPA makes it chargeable: UrbanPiper may levy 'reasonable charges for providing the assistance... to the extent that such assistance cannot be reasonably accommodated within the normal provision of the Services'. https://www.urbanpiper.com/legal/data-processing-agreement · retrieved 2026-09-01

commercial-wcag-kiosk-accessibility differentiator

No accessibility conformance report exists on any first-party surface, and there is no kiosk product for the claim's second limb. Checked, all on 2026-09-01: www.urbanpiper.com/sitemap.xml, which lists the marketing, blog, product and legal trees and enumerates exactly four legal pages (privacy-policy, customer-terms-and-conditions, data-processing-agreement, merchant-agreement) with no accessibility statement among them; www.urbanpiper.com/accessibility and /legal/accessibility, both HTTP 404 on a host whose 404s are genuine; the 116-page help centre and 87-page POS-partner API reference, in which WCAG, VPAT, ACR, 'accessibility conformance' and 'screen reader' occur zero times ('accessible' appears twice, once about a GitBook docs site and once about Prime Web being reachable from Atlas); and all four legal pages, which contain no accessibility clause. The kiosk limb has no subject at all: 'kiosk' occurs zero times across both corpora, and the vendor's published product set is Hub, Meraki and Orderline AI -- middleware, a self-branded consumer ordering site and app, and a voice agent -- with no self-order kiosk and therefore no tactile or audio non-visual access mode to document. https://www.urbanpiper.com/sitemap.xml · retrieved 2026-09-01

commercial-dual-pricing-compliant differentiator

The charge configuration screen is the entire configurable surface for adding money to an order, and it has no payment-method dimension. Creating a charge in Atlas (Catalog > Charges > Add Charge) offers exactly three applicable modes, enumerated in the article: 'Item Quantity: Based on the quantity of items ordered by the customer. Order Subtotal: Based on the order-level packaging charges. Item Price: Option to include a percentage-based packaging charge for the items', after which the operator sets an amount and scopes it to item groups and location groups. There is no condition on tender type, card brand, debit versus credit, or prepaid status, and no automatic exclusion mechanism could be built from those three modes. The payment side is equally flat: Atlas > Meraki > Payments lets the operator 'Enable/disable the methods you want to accept' (online payments, COD, wallets or loyalty points) with no per-method pricing. The word surcharge appears once in the corpus, as a pass-through charge item to be created in a POS back office for aggregator-originated charges (Lightspeed K-Series guide), and 'Cash Discount' appears only as a Meraki coupon type -- 'Applies a fixed amount discount on the order subtotal', targeted by customer group and explicitly 'not item-specific' -- which is a promotional discount, not a tender-based dual price. No receipt or menu-board fee-disclosure feature is documented anywhere. https://help.urbanpiper.com/business-manager/creating-a-menu/create-and-manage-charges · retrieved 2026-09-01