Stripe Terminal

The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator

payments-processor-choice

Stripe Terminal is Stripe's own acquiring product and the published pricing is a Stripe processing rate (2.7% + 5c card-present domestic). No bring-your-own-acquirer or alternate-processor path is offered; Terminal transactions settle through Stripe. https://stripe.com/pricing · retrieved 2026-08-02

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

payments-published-rates

Shortfall: one blended rate is published, the rate a real merchant ends up on may not be. Published openly and itemised with no sales call: the in-person Cards and wallets row reads '2.7% + 5¢' above the separate line 'per successful transaction for domestic cards', with '1.5%' added 'for international cards'; Tap to Pay, P2PE, cellular connectivity and Instant Payouts each carry their own itemised add-on. But no interchange-plus schedule is published, custom and volume pricing is quote-only through Stripe sales, and the only evidence is the vendor's own pricing page - first-party but written to sell, which is grade C and below the bar this dataset sets for a differentiator yes. QUOTE FIDELITY CORRECTED 2026-09-11: the prior note presented the amount, a lower-case letter c in place of the cent sign, and the qualifier clause as a single quoted span. The page renders the amount and the qualifier as two separate layout cells and uses the cent sign, so that span is not verbatim anywhere. The figures are unchanged. https://stripe.com/pricing · retrieved 2026-09-11

Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator

payments-dual-pricing

Terminal holds no item or price catalog: an amount is a single PaymentIntent amount, and Stripe's own no-code POS surface disclaims being a cash register. Stripe does document surcharging, but a surcharge is one amount on one transaction: payments/cards/surcharge adds amount_details.surcharge to a PaymentIntent and payments/advanced/surcharge automates it in Checkout and the Payment Element. No second per-item price is stored anywhere and no cash-versus-card total is printed on a check or receipt. https://docs.stripe.com/terminal/payments/standalone-mode · retrieved 2026-09-06 adversarially verified

Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator

payments-surcharge-guardrails

Two of the claim's three conjuncts are documented and one is not. (1) Debit/prepaid exclusion: Stripe resolves `surcharge.status` from the card country and funding type, the availability table gives United States and Canada as 'Credit cards only', and the page states that disabling amount validation 'doesn’t disable any other restrictions on availability, including restrictions on card funding type and other regional restrictions' - so funding-type exclusion is enforced by Stripe, not by the integrator. (2) Cap: Stripe returns `surcharge.maximum_amount` and validates against it by default, but NAMED SHORTFALL - the page says that value 'is a technical restriction, not a Stripe suggested amount' and that 'The surcharge limits imposed by laws or card network requirements in your jurisdiction might differ from the `surcharge.maximum_amount`', and the merchant can switch it off entirely with `enforce_validation: disabled`. What is enforced is a Stripe technical ceiling the merchant may disable, not the network percentage cap. (3) NAMED SHORTFALL, now confirmed on the recovered fleet prose rather than inferred - Stripe's per-location settings mechanism is the Configuration object applied at location level: 'Because these settings are hierarchical, you can apply a configuration at either the account level or at the individual location level', and 'You can override account-level settings with location-level settings.' The Dashboard walkthroughs enumerate the configuration types an operator can override per location - splash screen, tipping, offline mode, reboot time, admin passcode, WiFi, cellular - and surcharge is not among them, matching the Configuration object's own attribute list, which carries `tipping` and `offline` and no surcharge object. The Location object carries only `configuration_overrides`. Surcharge is set per request (PaymentIntent `amount_details[surcharge]`, or the reader's `collect_config` / `confirm_config` overrides), never per location. (4) Further shortfall - not generally available: 'Your integration must be on API version' 2026-03-25.preview, and public preview SDKs are required; the Checkout automatic-surcharge variant is private preview, US-only, and delegates calculation to third-party apps (Yeeld, InterPayments). Verbatim: 'indicates whether surcharging is available based on the country and the funding type of the payment method.' https://docs.stripe.com/payments/cards/surcharge · retrieved 2026-09-11 adversarially verified

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

payments-emv-nfc

Stripe documents brand and method support per reader: Visa and Mastercard in every Terminal country, American Express everywhere except Malaysia, Discover/Diners, China UnionPay, JCB, Maestro and the regional schemes (eftpos, girocard, Cartes Bancaires, Interac), and explicitly 'Terminal supports NFC-based mobile wallets (Apple Pay, Google Pay, and Samsung Pay).' One documented exception: on the WisePOS E, UnionPay and JCB work only as inserted EMV chip transactions and contactless is not supported. Terminal itself is available in 38 countries, not the 39 markets the marketing page implies. https://docs.stripe.com/terminal/payments/collect-card-payment/supported-card-brands.md · retrieved 2026-08-02 adversarially verified

Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator

payments-softpos-tap-to-pay

Documented rather than merely priced: Tap to Pay on iPhone requires an iPhone XS or later on a one-year-or-later iOS version and accepts Visa, Mastercard, American Express and Discover contactless cards, NFC-based mobile wallets and QR-based payment methods, plus eftpos in Australia, Interac in Canada and Cartes Bancaires in France. PIN entry is supported on iOS 16.4 or later for transactions requiring additional cardholder verification. Generally available in 20 countries with 18 more in public preview. Priced on the pricing page at '+ $0.10 per authorization'. Tap to Pay on Android does not support offline mode. https://docs.stripe.com/terminal/payments/setup-reader/tap-to-pay.md?platform=ios · retrieved 2026-08-02 adversarially verified

Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.

payments-pay-at-table

Shortfall: the hardware half exists, the software half does not. The S710 mobile smart reader with on-reader tip prompts takes payment anywhere in the venue, but there is no check retrieval, no seat or course model and no split-check logic — the integrator must build all of it. Terminal has no check object to fetch tableside. https://docs.stripe.com/terminal/features/collecting-tips/on-reader · retrieved 2026-08-02

Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator

payments-qr-guest-pay

The only open-check flow documented anywhere in the corpus is the Stripe Payments for Simphony Pay at Table app, and it affirmatively describes a DIFFERENT mechanism from the claim: the check lives in Oracle Simphony and is retrieved over Simphony's STS Gen2 API, the server logs into a Stripe S700/S710 reader, selects the check, and HANDS THE READER TO THE GUEST - exactly the handheld-hardware path the claim is meant to avoid. Every QR code Stripe documents for Terminal points the other way round, and docs.stripe.com/terminal/payments/additional-payment-methods (read across its reader-type and SDK variant bodies) confirms it beyond the index stub that previously stood in their place: 'After confirming the payment, the QR code is displayed for the customer to scan with their mobile device.' and 'For smart readers, the reader displays the QR code on its screen.' and, for screenless readers, 'the app on your POS device must show the QR code for supported payment methods'. The QR is therefore rendered by the merchant's own hardware at the moment of payment, selects a wallet payment method (WeChat Pay, Affirm, PayNow, with Klarna in Private Preview), and is bound to a PaymentIntent - never printed on a check or a table tent, and never used to look a check up. Stripe's other QR surface, Payment Links, is a static Dashboard-generated code for a pre-built link, not bound to a per-table check. Stripe Terminal carries no check or tab object: the POS partner guide's object table lists PaymentIntent, SetupIntent, PaymentMethod and Customer, and the Terminal API namespace is configuration, connection tokens, hardware orders/products/shipping-methods/SKUs, locations, onboarding links and readers. ONE NEAR-MISS, NAMED SO NOBODY MISTAKES IT LATER: stripe.com/resources/more/restaurant-embedded-payments-infrastructure-benefits-and-trade-offs does contain the phrase 'Pay-at-table and quick response (QR) code ordering with embedded checkout can help reduce the time between a guest finishing their meal and the table being reset' - but that is a Stripe thought-leadership article about what an embedded-payments platform's restaurant customers might build, not a statement that Stripe Terminal ships the feature, and it names no Stripe product. Verbatim: 'The Stripe Payments for Simphony Pay at Table app enables servers at Oracle Simphony restaurants to log in to a Stripe Terminal device, select their open checks, and hand the device to guests to pay, tip, and receive a receipt in one flow.' https://docs.stripe.com/use-stripe-apps/oracle/simphony/overview · retrieved 2026-09-11 adversarially verified

Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.

payments-tip-adjust

Shortfall: tips are collected before authorization, not adjusted after it. Stripe documents smart tips (fixed amounts below a threshold, percentages at or above it), three configurable percentage or fixed options, a separate amount_eligible basis and skip_tipping; after confirmation the tip lands in amount_details.tip.amount. No post-authorization tip-adjust batch window and no manager unadjusted-tips screen are documented — the restaurant tip-adjust workflow is absent. https://docs.stripe.com/terminal/features/collecting-tips/on-reader · retrieved 2026-08-02

Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator

payments-tip-pooling

The whole Terminal tipping surface is on-reader and on-receipt collection. The Configuration object's tipping field enumerates percentages, fixed_amounts and smart_tip_threshold and nothing else; the tip lands in PaymentIntent.amount_details. No employee, shift or allocation concept exists: 'tip pool', 'tip-out' and 'tip distribution' return 0 hits across all 6,134 frozen pages. https://docs.stripe.com/terminal/features/collecting-tips/overview · retrieved 2026-09-06 adversarially verified

Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator

payments-offline-store-and-forward

Shortfall: store-and-forward is real, configurable limits are not - the offline controls Stripe ships are SDK primitives the integrator must assemble into a limit, not limit parameters. Offline collection is documented for Bluetooth and internet readers, with payments written to disk, surviving a reader reboot and forwarded on reconnect. The merchant-configurable surface is a single boolean in both places it is exposed: the Dashboard offers an on/off 'Offline mode' toggle per location, and the Configuration object's entire offline schema is 'offline.enabled (boolean, nullable)'. The SDK adds a per-PaymentIntent CreateConfiguration enum, offlineBehavior = REQUIRE_ONLINE | PREFER_ONLINE | FORCE_OFFLINE, and two read-only status properties, Terminal.offlineStatus.reader.offlinePaymentsCount and offlinePaymentAmountsByCurrency. None of those is a limit: Stripe's own text assigns the threshold to the developer - 'you might want to disallow transactions above a certain amount or disallow all offline transactions if the reader has stored a set of transactions whose sum exceeds a certain amount' - and its sample code hardcodes the ceiling in the merchant's app ('we block the payment if the amount is over 1000 usd'). The only Stripe-enforced ceiling is a fixed, non-configurable 10,000 USD per transaction, now quotable first-party. https://docs.stripe.com/terminal/features/operate-offline/collect-card-payments.md?terminal-card-present-integration=terminal&reader-type=internet&terminal-sdk-platform=ios · retrieved 2026-08-12 adversarially verified

Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator

payments-offline-decline-liability

Shortfall: the liability half is now fully evidenced; the failed-payment report does not exist. Stripe states the risk position plainly - 'You, as the user, assume all decline and tamper-related risks associated with an offline transaction' and 'Payment liability is your responsibility when operating your reader offline' - on the collect-card-payments page, which does render once requested with the real variant parameters ('terminal-card-present-integration=terminal', 'terminal-sdk-platform='); the three prior passes that called it unrenderable were using 'platform=' and got the variant index, which was the correct answer to the question asked. What still does not exist is a post-reconnect report of failed offline payments. Forwarding outcomes surface only as SDK callbacks - OfflineDelegate's didForwardPaymentIntent(intent, error) and didReportForwardingError - plus PaymentIntent webhooks, and the one documented reporting affordance, 'Examine payments collected offline', identifies AUTHORIZED offline charges via payment_method_details.card_present.offline. There is no Stripe-supplied report, Dashboard view or export of offline payments that failed on forward; the integrator builds it. https://docs.stripe.com/terminal/features/operate-offline/collect-card-payments.md?terminal-card-present-integration=terminal&reader-type=internet&terminal-sdk-platform=ios · retrieved 2026-08-12 adversarially verified

First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.

payments-gift-cards

A real reader surface exists - redeem, activate, reload, cash out, check balance - but every distinguishing conjunct of the claim fails. The cards are not first-party: Stripe's own page says accept third-party closed-loop gift cards, the merchant onboards an external provider (SVS only), and settlement happens off Stripe. Cross-location redemption scope is set by the provider's program, not by Stripe. There is no online-ordering channel to redeem through. The whole surface is a US-only, magstripe-only private preview reached by emailing an account executive. https://docs.stripe.com/terminal/features/gift-cards · retrieved 2026-09-06 adversarially verified

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

payments-house-accounts

Terminal's enumerated tender set is cards, wallets and selected local payment methods; no on-account/house tender, no per-account credit limit, no statement run. 'house account' returns 0 hits in the frozen 6,134-page corpus; 'credit limit' hits only Issuing and Capital. Sibling Invoicing generates invoices but is not a POS tab tender and carries no credit limit. https://docs.stripe.com/terminal/overview · retrieved 2026-09-06 adversarially verified

A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.

payments-split-tender

There is no check, seat or line-item object in Terminal to split, so split-by-seat, by-item or by-even-shares cannot exist; the POS partner owns the check. Stripe's only documented multi-tender mechanism, partial authorization (pay the balance with another method), is explicitly restricted to online card payments, so Stripe documents the capability for a different channel than Terminal. https://docs.stripe.com/payments/partial-authorization · retrieved 2026-09-06 adversarially verified

Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.

payments-refund-void-controls

One conjunct is met: on-reader refunds can be set to enabled_with_passcode, and only Super Administrator, Administrator, Terminal Specialist or Developer roles may view or modify that passcode. The rest fails: the passcode is shared per configuration, not per user, so no approver is identified; Refund create parameters include no approver field; discounts and no-sales are not Terminal concepts. https://docs.stripe.com/terminal/payments/standalone-mode/customization · retrieved 2026-09-06 adversarially verified

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

payments-chargeback-tooling

Documented in-product dispute response: a Dashboard flow with structured evidence assembly and file upload, auto-populated transaction and 3DS data, Visa Compelling Evidence 3.0 evaluation, plus dispute API endpoints for programmatic response. https://docs.stripe.com/disputes/responding · retrieved 2026-08-01

Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator

payments-card-on-file

Documented, with a nuance worth stating: 'When you create a PaymentIntent or SetupIntent with a card-present payment method, you can't save the PaymentMethod directly.' Stripe instead creates a reusable generated_card PaymentMethod from the in-person presentment, which the integrator attaches to a Customer or Account for later reuse - and if it is not attached, reuse is lost. Cardholder consent is an explicit documented step (opt-in terms, disclosure of timing, frequency and amount, written agreement). Reuse is online-only: 'Payments with generated cards are online payments and can't be processed with Terminal SDK methods.' https://docs.stripe.com/terminal/features/saving-payment-details/overview.md · retrieved 2026-08-02 adversarially verified

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

payments-payout-timing

Documented in product documentation rather than merely priced: selectable manual, daily, weekly or monthly payout schedules with named days of the week or month, weekend and holiday roll-forward, and per-country settlement timing (US and Australia 2 business days, most EU 3 business days after a 7-calendar-day initial, Japan 4 business days after 7). Initial payout is typically scheduled 7-14 days after the first successful payment. Instant Payouts is separately available at a published 1.5% of volume, 50c minimum. https://docs.stripe.com/payouts · retrieved 2026-08-02

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

payments-multi-entity-routing

Shortfall: not native to Terminal. Terminal itself does not route settlement to legal entities; the Terminal overview only notes that you can use Terminal with Connect to support connected accounts. Delivering it requires adopting Stripe Connect — a separate, separately-priced product that requires the buyer to become a platform and onboard each entity as a connected account. Real capability, but a different product bolted on rather than a Terminal feature. https://docs.stripe.com/terminal/overview · retrieved 2026-08-01 adversarially verified

Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.

payments-p2pe-pci4

Shortfall: the certification is Stripe's, not the merchant's, and the version is unstated. Stripe documents that 'A PCI-certified auditor evaluated Stripe and certified us to PCI Service Provider Level 1', and sells point-to-point encryption as a priced add-on (+$0.05 per authorization). No merchant-facing Attestation of Compliance, no PCI-listed P2PE solution reference, and no PCI DSS version number appear in the security documentation. https://docs.stripe.com/security · retrieved 2026-08-02

Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.

digital-first-party-web

Terminal is card-present infrastructure; Stripe's only no-code guest-facing web surface is Payment Links, which Stripe describes as a way to take payments *without* a storefront. A payment link carries fixed Prices, not a restaurant menu, and there is no order object to write into a POS. Nothing in the 6,134-page manifest documents a branded ordering site. https://docs.stripe.com/payment-links/share · retrieved 2026-09-06 adversarially verified

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

digital-menu-single-source

Stripe holds no menu record for Terminal at all. Its no-code reader mode explicitly has no product catalog and requires the amount to be keyed per transaction; in every other integration the item/modifier catalogue lives in the partner POS, which pushes amounts and cart display to the reader. With no source menu there is nothing to propagate to digital channels. https://support.stripe.com/questions/standalone-mode-for-terminal · retrieved 2026-09-06 adversarially verified

Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator

digital-native-app

Stripe's own POS-partner guide puts the application on the partner's side of the boundary: Stripe ships SDKs (iOS, Android, React Native, JS) that the partner embeds in their app. Stripe publishes no consumer ordering app of its own, branded or otherwise; the only Stripe-published mobile app in the corpus is the merchant-facing Dashboard app. https://docs.stripe.com/extensibility/terminal-for-pos-partners · retrieved 2026-09-06 adversarially verified

Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.

digital-account-saved-payment

Terminal delivers only the tokenization leg: a card or wallet tapped at the reader can become a reusable generated_card PaymentMethod that the merchant attaches to a Customer or Account for later online charging. That is a merchant-held saved credential, not a guest-created account - the guest never creates, sees or manages it - and Stripe holds no order object, so a one-tap reorder of a previous order has nothing to reorder. The first-party digital channels the claim scopes itself to do not exist. https://docs.stripe.com/terminal/features/saving-payment-details/overview · retrieved 2026-09-06 adversarially verified

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

digital-upsell-engine

Stripe's only documented 'upsell' is a Checkout affordance for upgrading a subscription plan, plus 'optional items' (complementary Prices) - neither is a rules-based or history-personalized food add-on engine, and neither exists in the Terminal PaymentIntent flow. Embedded Checkout analytics enumerates its six events with no suggestion-attach metric. https://docs.stripe.com/payments/checkout/promotions · retrieved 2026-09-06 adversarially verified

Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.

digital-scheduled-pacing

Terminal's documented scope is in-person payment acceptance: readers, Dashboard fleet tools, payment-method support and encryption. The Terminal API namespace is configuration, connection_tokens, hardware_*, locations, onboarding-link and readers - no order, cart, time-slot or capacity resource - so there is nothing to schedule and nothing to throttle, and no scheduling, slot or capacity concept appears anywhere in the 6,134-page manifest. https://docs.stripe.com/terminal/overview · retrieved 2026-09-06 adversarially verified

Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.

digital-fulfillment-modes

There is no Stripe ordering flow with fulfillment modes. Checkout's closest construct is shipping-address collection plus Shipping Rates for physical goods; the corpus documents no pickup, curbside/arrival check-in, dine-in or delivery mode, no mode-specific fees and no prep timing. 'curbside' appears exactly once in 6,134 pages, as a deployment example for a mobile card reader. https://docs.stripe.com/payments/checkout · retrieved 2026-09-06 adversarially verified

Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.

digital-qr-table

The only QR flow Stripe documents on a Terminal reader is a Klarna next_action: the reader shows a QR the guest scans to finish that one PaymentIntent in the Klarna app. Payment Links can render as a QR, but that is a fixed link, not a handle on an open check. Nothing opens or attaches to a POS check, and there is no split-the-check surface. https://docs.stripe.com/changelog/dahlia/2026-04-22/klarna-payments-with-terminal-readers-qr-code-support · retrieved 2026-09-06 adversarially verified

Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator

digital-kiosk

Stripe supplies only the payment leg: unattended EMV is real (Location attended_type=UNATTENDED, on/off-premise, UX700 and smart readers). But Stripe's guidance is that the integrator's hardware or an on-device app owns the kiosk interface. Stripe ships no self-order kiosk, no menu/modifier logic and no accessible ordering UI - three of four legs fail. https://docs.stripe.com/terminal/payments/setup-reader · retrieved 2026-09-06 adversarially verified

Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.

digital-group-ordering

Group ordering requires a shared multi-participant cart with per-person spend caps — objects Stripe does not have. 'group order' returns zero hits across the 6,134-page publisher manifest, and the Terminal API namespace (configuration, connection_tokens, hardware_*, locations, onboarding, readers) has no cart, order or participant resource. Terminal's documented scope is in-person acceptance only. https://docs.stripe.com/terminal · retrieved 2026-09-06 adversarially verified

Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator

digital-catering-portal

Sibling products supply isolated legs - Quotes for proposals, Invoicing with ACH terms, manual capture for deposits - but there is no catering ordering flow, catering menu, order minimum or lead-time rule anywhere; 'catering' returns zero hits across 6,134 pages. Stripe's role in a POS deployment is explicitly the acceptance layer. https://docs.stripe.com/extensibility/terminal-for-pos-partners · retrieved 2026-09-06 adversarially verified

Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator

digital-voice-ai-phone

Stripe does document telephone orders on Terminal, and the doc shows what it is: staff answer the call and hand-key card number, CVC, expiry and postal code into the reader UI. No call answering, no speech recognition, no order injection - the transcription the claim asks Stripe to remove is what MOTO requires. 'voice order': zero hits. https://docs.stripe.com/terminal/features/mail-telephone-orders/overview · retrieved 2026-09-06 adversarially verified

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

digital-drivethru-ai

Stripe's enumeration of what Terminal includes is readers and Tap to Pay devices, Dashboard fleet tools, payment-method support and encryption — no lane hardware, no speech stack, no menu/modifier model and no escalation-to-human handoff. 'drive-thru' (any spelling) returns zero hits across the 6,134-page manifest. https://docs.stripe.com/terminal/overview · retrieved 2026-09-06 adversarially verified

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

digital-sms-ordering

Stripe documents texting a customer a Payment Link, which is the 'text-a-link' shape of a payment request — but the link resolves to a fixed-Price Checkout page, not a conversational ordering session, and nothing lands in a POS because Stripe holds no order. There is no chat/SMS ordering surface in the corpus; Stripe's messaging story is link distribution only. https://docs.stripe.com/payment-links/share · retrieved 2026-09-06 adversarially verified

Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator

digital-google-order

'Order with Google' and 'Google Business Profile' return zero hits across the 6,134-page publisher manifest; Stripe's documented Google relationship is Google Pay as a wallet. Provisioning an ordering link to a listing presupposes a first-party ordering flow Terminal lacks - its scope is in-person acceptance. Bounded absence plus scope. https://docs.stripe.com/terminal · retrieved 2026-09-06 adversarially verified

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

digital-apple-business-connect

Stripe's Apple surface is documented as a wallet: Apple Pay as a payment credential online and in person. 'Apple Business Connect' and 'Apple Maps' return zero hits across the 6,134-page manifest, and there is no place-card, listing or custom-action integration anywhere in it — nor a first-party ordering flow for an 'Order Food' action to point at. https://docs.stripe.com/payments/wallets · retrieved 2026-09-06 adversarially verified

Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.

digital-loyalty-attach

There is no first-party digital ordering flow for loyalty to sit inside (see digital-first-party-web), and Stripe ships no loyalty product at all: across the 6,134-page manifest 'loyalty' occurs only in dispute categories, an Issuing credit example, a metadata worked example, a Radar custom-model example and a dynamic-updates example. With no loyalty balance and no guest identity beyond a merchant-attached Customer, there is nothing to accrue or redeem in any channel, in-store or online. https://docs.stripe.com/terminal · retrieved 2026-09-06 adversarially verified

Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.

digital-subscriptions

Genuine sibling-product delivery: Stripe Billing runs recurring membership billing with Entitlements (features granted/revoked with a subscription) and a customer portal, and Terminal documents starting one from an in-person tap. Missing is the restaurant framing - no fee waiver, no per-period item entitlement, no channel in which to redeem one. https://docs.stripe.com/terminal/features/saving-payment-details/overview · retrieved 2026-09-06 adversarially verified

Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.

digital-promo-parity

Stripe's coupon/promotion-code engine is bound to the Checkout Sessions API (and Billing/Payment Links). For the Payment Intents API - the whole of the Terminal flow - Stripe's documented answer is to compute the discount yourself and pass an adjusted amount. A promotion defined once is not honored at the reader; no channel-eligibility controls. https://docs.stripe.com/payments/advanced/discounts · retrieved 2026-09-06 adversarially verified

Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator

digital-guest-data-ownership

Shortfall: exportable in practice, but not owned outright in contract. Customer and payment records export via Dashboard CSV, the API and Data Pipeline, yet the Stripe Services Agreement grants Stripe 'a perpetual, worldwide, non-exclusive, irrevocable, royalty-free license to use the Content to develop, improve, and provide Services and Stripe Technology', and states that Stripe and its affiliates 'own all IP Rights in the Services, the Stripe Technology, Stripe Data'. https://stripe.com/legal/ssa · retrieved 2026-08-02

Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.

digital-checkout-pci-sca

Shortfall: the primitives are Stripe's, the checkout is the buyer's. Stripe provides hosted fields and hosted pages, 3DS/SCA support and PCI Service Provider Level 1 certification, but applies them to the developer's own checkout — Stripe does not ship a restaurant ordering checkout whose PCI and SCA posture could be assessed as a product. https://docs.stripe.com/security · retrieved 2026-08-02

Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator

digital-surcharge-transparency

CORRECTED ON AUDIT 2026-09-11: the prior proposal answered a different question. This claim is the final subfeature of the taxonomy section keyed `digital-ordering` and titled Digital ordering and guest-facing channels, so its subject is a guest-facing ORDERING channel, not a payment page. Substituting Checkout, Payment Links and Payment Element - which are digital PAYMENT surfaces - supplies a second term the claim does not ask about. On the section's own meaning Stripe publishes no first-party digital ordering channel: the cited page describes a payment link as a way to accept payments without a digital storefront, it carries fixed Prices rather than a menu, and this record accordingly scores digital-first-party-web, digital-menu-single-source, digital-native-app, digital-kiosk, digital-qr-table and eleven further first-party ordering cells `no`. With no digital ordering channel in existence there is nothing that could carry the POS's surcharge, service-fee or dual-pricing configuration, so the claim fails outright rather than partially. Recorded so the finding is not lost: Stripe genuinely has no service-fee or dual-pricing construct at all - `dual pricing`, `cash discount`, `cash discounting` and `service fee` are each 0 in text-docs, text-variants, text-variants2 and text-extra - and its card-surcharge engine is gated on API version 2026-03-25.preview, with the Checkout automatic variant in private preview, United States only, and delegating calculation to third-party provider apps. Verbatim: 'share it with your customers to accept payments without a digital storefront' https://docs.stripe.com/payment-links/share · retrieved 2026-09-11 adversarially verified

Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.

guest-loyalty-unified-profile

Shortfall: one identity across channels is possible, but the integrator builds it and nothing merges automatically. Documentation shows the real mechanism - an in-person presentment yields a generated_card PaymentMethod that the integrator attaches to a Customer or Account, after which the same identity can be charged online. That is a genuine in-store-to-online link. What the claim asks for and Stripe does not document is automatic merging by phone or email match, identity resolution or dedup behaviour; attachment is manual, and there is no kiosk or first-party web-ordering channel to merge from. The earlier citation for this cell was the Terminal marketing page, which promotes unified customer data without documenting it. https://docs.stripe.com/terminal/features/saving-payment-details/overview.md · retrieved 2026-08-02 adversarially verified

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

guest-loyalty-thirdparty-identity-attach

Stripe's own integration guide for POS/PMS partners scopes Terminal to card-present payment acceptance and enumerates the only Stripe objects a POS partner uses: PaymentIntent, SetupIntent, PaymentMethod, Customer. There is no order, ticket or marketplace-ingestion object, so no third-party marketplace order can attach to a guest profile. DoorDash/Uber Eats/Grubhub appear in the corpus only in Connect 1099 tax-form articles. https://docs.stripe.com/extensibility/terminal-for-pos-partners · retrieved 2026-09-06 adversarially verified

Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.

guest-loyalty-accrual-models

The API reference enumerates the complete attribute set of the Customer object (id, address, balance, business_name, cash_balance, currency, description, discount, email, invoice_*, metadata, name, phone, preferred_locales, shipping, sources, subscriptions, tax*, test_clock). There is no points, visits, punch, tier or accrual field, and the only balance is an invoice credit balance. No accrual model is configurable. https://docs.stripe.com/api/customers/object · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-tiers

Stripe's own worked example of recording a loyalty program is a free-text metadata key on a Customer (metadata[loyalty_program]=yes|no), a 50-key store Stripe explicitly does not compute on. There is no tier object, no rolling-window spend/visit aggregation and no promotion/demotion mechanism anywhere in the Customer schema. https://docs.stripe.com/metadata · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-offline-behavior

Stripe documents offline behaviour for Terminal in detail across five pages, and exclusively for card payments: store-and-forward on the reader, a 24-hour POS reconnection window, and a per-SDK offline support matrix. The publisher is answering a different question - nothing in the offline documentation addresses loyalty lookup, accrual or redemption, because no loyalty surface exists to have offline semantics. https://docs.stripe.com/terminal/features/operate-offline/network-transitions · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-offer-stacking-rules

Coupons/promotion codes are a Checkout and Billing surface; Stripe instructs Payment Intents integrators (which is what Terminal card-present is) to compute the discounted amount themselves server-side. The PaymentIntent object's complete attribute list has no discount, coupon or promotion_code field. Checkout allows at most one coupon, and Billing's stackable discounts expose no exclusive/combinable or order-of-application configuration. https://docs.stripe.com/payments/advanced/discounts · retrieved 2026-09-06 adversarially verified

Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator

guest-loyalty-targeted-offers

The Promotion Code object enumerates its complete restriction set: a single named customer, first_time_transaction, minimum_amount, expires_at, max_redemptions. There is no audience, segment or rules-over-behaviour construct - no recency, frequency, spend or items-purchased targeting - and no issuance mechanism. Stripe's only behaviourally targeted offers (Link cash back) are funded and defined by Stripe, not the operator. https://docs.stripe.com/api/promotion_codes/object · retrieved 2026-09-06 adversarially verified

Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator

guest-loyalty-rfm-segmentation

The only automatic cohorting Stripe publishes is Billing subscriber cohorts, assigned by the month a subscriber first generated positive MRR and measured as subscription churn - not recency/frequency/monetary guest segments, and inapplicable to card-present Terminal customers who have no subscription. Stripe's answer for marketing segmentation is to sync data out to Mailchimp via a third-party Stripe App. https://support.stripe.com/questions/subscriber-cohorts-and-cohort-retention-in-billing · retrieved 2026-09-06 adversarially verified

Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.

guest-loyalty-lifecycle-automation

Stripe's only always-on trigger/action automation product is Billing automations, and it publishes a closed list of five triggers: invoice due date upcoming, invoice finalized, invoice overdue, subscription canceled, subscription payment fails. All are invoice/subscription dunning events. There is no birthday, first-visit or lapsed-guest trigger anywhere in the corpus (birthday and win-back return effectively zero hits over 6,134 pages). https://docs.stripe.com/billing/automations · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-native-email-sms

Stripe's documented marketing-messaging story is precisely the excluded one: synchronise customer and purchase data out to Mailchimp through a third-party-built Stripe App. Stripe itself sends only transactional mail (receipts, invoices, dunning). Across all 6,134 pages, SMS appears only as two-step-authentication codes, Issuing cardholder alerts and Express dashboard notifications - there is no campaign send surface of either kind. https://docs.stripe.com/stripe-apps/embedded-apps/marketing-integrations · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-consent-management

Stripe's one marketing-consent primitive is Checkout's consent_collection/consent pair - online-only, a single channel (promotional email), with no per-channel record, no source-of-consent field and no revocation handling: Stripe states it will not act on a revocation it receives. Terminal's only consent parameter, customer_consent_collected, was removed in 2024-09-30 and replaced by allow_redisplay, which governs card re-display, not marketing. https://docs.stripe.com/payments/checkout/compliant-promotional-emails · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-10dlc-registration

Stripe's entire published messaging-compliance guidance is about email: consent capture, sender identification, unsubscribe handling and privacy-policy disclosure. It never addresses SMS. Consistently, the strings 10DLC and A2P return zero hits across all 6,134 pages of Stripe's own sitemap-enumerated docs and support corpus. Stripe neither handles nor documents brand/campaign registration because it provides no SMS sending path. https://docs.stripe.com/payments/checkout/compliant-promotional-emails · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-campaign-attribution

Stripe's only campaign-attribution product imports ad-platform performance data and attributes online customers and revenue to ad campaigns; it is waitlist-gated (the preview registration call is the whole page body). It reports ROAS over subscriptions, trials, refunds and disputes - not offer redemption tied to check totals, and no offer or campaign object exists to redeem against. https://docs.stripe.com/reports/marketing-analytics · retrieved 2026-09-06 adversarially verified

Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator

guest-loyalty-data-export-portability

Shortfall: what exports is payments data, not guest data. Customer and transaction records export self-serve via the API and (for full raw delivery) the paid Data Pipeline product into a customer-controlled warehouse. There is no loyalty ledger, points balance or offer history to export because none exists. https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

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

guest-loyalty-cdp-event-api

Shortfall: the events are payment events, not guest or order events. Signed, retried webhooks stream payment and customer lifecycle changes that any CDP can subscribe to, but a CDP wanting visit frequency, basket contents or dwell behaviour will find none of it — Stripe never sees an item. https://docs.stripe.com/webhooks · retrieved 2026-08-02

Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator

guest-loyalty-review-capture-routing

The API reference enumerates every Terminal Reader endpoint: create/update/retrieve/list/delete, four gift-card operations, collect_inputs, cancel_action, confirm/collect/process payment intent, process_setup_intent, print_content, refund_payment, set_reader_display and three test helpers. collect_inputs can render a selection form on the reader, but nothing triggers a post-transaction feedback request, scores a response or routes by score. Nothing elsewhere in the 6,134-page corpus provides a feedback, survey, NPS or review-site surface either. https://docs.stripe.com/api/terminal/readers · retrieved 2026-09-06 adversarially verified

Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.

guest-loyalty-referral-program

The API reference enumerates 236 public event types across every Stripe resource; none names a referral, reward, loyalty, offer, campaign or segment. Correspondingly the API's 106 top-level resource namespaces contain no referral object, and the strings referral program, refer-a-friend and referral code return zero hits across all 6,134 corpus pages. There are no per-guest codes, no referred-order attribution and no two-sided rewards. https://docs.stripe.com/api/events/types · retrieved 2026-09-06 adversarially verified

Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator

guest-loyalty-wallet-pass

Every wallet surface Stripe documents is payment-credential tokenisation: wallets let a customer pay online or in person with Apple Pay or Google Pay, Issuing covers push-provisioning a payment card into those wallets, and card.wallet on Card/PaymentMethod records how a card number was tokenised. There is no pass-issuance resource of any kind - PassKit, .pkpass and 'wallet pass' return no relevant hits across 6,134 pages - and Stripe holds no loyalty balance for a pass to push-update. https://docs.stripe.com/payments/wallets · retrieved 2026-09-06 adversarially verified

Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.

guest-loyalty-privacy-rights-tooling

Shortfall: process, not tooling. Stripe publishes a DPA and documents a deletion-request intake process, but no in-product tool was found that lets a merchant locate, export or delete an individual guest's records on demand. https://stripe.com/legal/privacy-center · retrieved 2026-08-01

Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.

guest-loyalty-redemption-fraud-controls

Stripe's audit log publishes a closed list of tracked action types covering only API key lifecycle, user invitations and user-role changes, retained six months - no point adjustment, redemption or staff-transaction events. Radar, the only rules engine, is payment-scoped with four actions (request 3DS, allow, block, review) over card and transaction attributes. No manager-approval workflow on adjustments and no employee self-redemption flagging exist, because there is no loyalty balance to adjust. https://docs.stripe.com/activity-logs · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-ai-offer-recommendation

Stripe ships a documented ML Recommendations product, but it recommends payment-acceptance and fraud-protection configuration changes in the Dashboard - not offer content, target audience or send timing. Every other machine-learning claim in the corpus is Radar risk scoring, Smart Retries, Smart Disputes or Adaptive Pricing. No AI offer/audience/timing recommendation is documented as shipped or as roadmap. https://docs.stripe.com/payments/analytics/recommendations · retrieved 2026-09-06 adversarially verified

Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.

guest-loyalty-stored-value-gift

Terminal does ship stored value at the reader - activate, reload, check balance, cashout, and redemption as a gift_card PaymentIntent - but every conjunct of the claim fails. It is not native: Stripe is a passthrough to a third-party closed-loop provider (SVS), funds settle off Stripe, and the surface is a US-only magstripe private preview. The balance explicitly cannot be tied to a guest profile. Brand-wide redemption scope is defined by the card provider's program, not by Stripe. https://docs.stripe.com/terminal/features/gift-cards · retrieved 2026-09-06 adversarially verified

Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.

reporting-realtime-dashboard

Shortfall: it is a payments dashboard, not a restaurant dashboard. The Stripe Dashboard (web and mobile) shows payments in near real time, including Tap to Pay taken from the mobile app, but reports payments volume — never covers, item mix, voids, comps or labour, because Stripe holds none of that data. https://docs.stripe.com/terminal · retrieved 2026-08-01

Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.

reporting-eod-closeout

The Reports API page enumerates the complete report family list: Balance, Payout reconciliation, Fees, Tax, Connect platforms, Commerce. None is a daily close-out. Balance summary reconciles gross/fee/net/refunds for payments only; there is no tips, discounts, comps or tender-type breakdown and no expected-cash-deposit figure, and Terminal takes no cash tender. https://docs.stripe.com/reports/api · retrieved 2026-09-06 adversarially verified

Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.

reporting-pmix-modifier-level

Sigma's transactional schema is Payment Tables and Transfer Tables (charges, refunds, balance_transactions, payouts, fee details) - ledger rows, not line items. No product-mix, item or modifier table exists, and no daypart or revenue-center dimension. 'modifier' occurs in the corpus only as a Connect fee modifier. https://docs.stripe.com/data/query-transactions · retrieved 2026-09-06 adversarially verified

Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.

reporting-comps-voids-audit

Stripe's only audit trail tracks a closed set of action types: api_key_created/deleted/updated/viewed, user_invite_*, user_roles_updated/deleted, retained 6 months. No comp, void, discount or price-override action is tracked - Terminal has no check to comp - and refunds carry no reason code or approving-manager field. https://docs.stripe.com/activity-logs · retrieved 2026-09-06 adversarially verified

Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.

reporting-cash-over-short

The single occurrence of 'cash drawer' in the 6,134-page corpus is hardware: the S700/S710 Hub's USB ports can attach a drawer as a peripheral. Stripe records no cash tender, no paid-out, no drawer session and no counted-cash entry, so expected-vs-counted cash per drawer, shift or employee cannot be computed or reported. https://docs.stripe.com/terminal/payments/stripe-reader-s700-s710/accessories · retrieved 2026-09-06 adversarially verified

Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.

reporting-labor-productivity

The Analytics API page is an explicit complete metric enumeration: revenue.mrr/arr, revenue_growth.*, revenue_growth_rate.mrr, usage_based_billing.gross_usage_revenue, metered_usage.total_aggregate_usage and four connect_* metrics. No labor-hour, wage or employee metric exists, and Terminal has no time clock to source clocked hours from. https://docs.stripe.com/data/analytics/supported-metrics · retrieved 2026-09-06 adversarially verified

Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator

reporting-server-scorecards

Tips are recorded only as an amount on the PaymentIntent (amount_details) or folded into amount_to_capture; no server or employee identity is attached to a Terminal payment. With no check, item lines or categories there is no average check, items per check or attachment rate to report. https://docs.stripe.com/terminal/features/collecting-tips/overview · retrieved 2026-09-06 adversarially verified

Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator

reporting-channel-profitability

The Balance report can expose payment_method_type (so card_present separates from online) but the column enumeration has no fulfillment-channel, revenue-center or marketplace dimension and no commission field; the only cost modelled is Stripe's own processing fee. Uber Eats, Grubhub and delivery marketplaces appear nowhere in the corpus. https://docs.stripe.com/reports/report-types/balance · retrieved 2026-09-06 adversarially verified

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

reporting-multiloc-drilldown

Shortfall: possible, but you build it. Terminal Location objects tag payments by site and Sigma or Data Pipeline let an analyst aggregate across locations and drill to an individual payment in SQL. There is no prebuilt store-versus-store comparison view, and the measures available are payments measures only. https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

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

reporting-custom-report-builder

Shortfall: SQL, not a builder, and paid. Stripe Sigma is a SQL query surface aimed at analysts rather than a drag-and-drop report builder an operator could use, and it is a separately priced add-on at $15.00 per month (from $10.00 per month on a 1-year contract). https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.

reporting-scheduled-delivery

Shortfall: analyst-authored and paid rather than operator-facing. Sigma scheduled queries run daily, weekly or monthly, email named subscribers a link to a CSV of results, and emit a sigma.scheduled_query_run.created webhook — but the report must first be written in SQL, and Sigma is a $15.00/month add-on. https://docs.stripe.com/data/schedule-queries · retrieved 2026-08-01 adversarially verified

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

reporting-raw-warehouse-export

Data Pipeline delivers Stripe's raw data into a customer-controlled destination - Snowflake, Amazon Redshift, Databricks, BigQuery, Google Cloud Storage, Azure Blob Storage or Amazon S3 - 'without writing code', explicitly positioned as a replacement for third-party ETL or home-built API integrations. The initial load completes within 12 hours and a full load is delivered every 3 hours thereafter. The documentation page publishes no price; the $65.00/month list price (from $50.00/month on a 1-year contract) is on the pricing page. https://docs.stripe.com/data/access-data-in-warehouse.md · retrieved 2026-08-02 adversarially verified

Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator

reporting-public-api

Fully public REST API covering payments, customers, readers, locations, zones and configurations, with self-serve keys and no partner agreement. It returns no menu or labour data because those objects do not exist in the product. https://docs.stripe.com/terminal · retrieved 2026-08-01

Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator

reporting-webhooks

Signed webhooks for the payment lifecycle with documented retry and replay: HMAC-SHA256 in the Stripe-Signature header, live-mode delivery attempted for up to three days with exponential back off, and an Event deliveries tab showing Delivered, Pending or Failed. https://docs.stripe.com/webhooks · retrieved 2026-08-02

API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator

reporting-api-not-upcharged

Shortfall: the core API is free but raw-data access is a paid add-on. There is no API fee, no per-location fee and no software subscription for the Terminal API itself; Sigma ($15.00/month) and Data Pipeline ($65.00/month) are separately priced. Both list prices are published rather than quote-only, so this is an upcharge with transparent terms. https://stripe.com/pricing · retrieved 2026-08-02

Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator

reporting-tier-paywall

Positive evidence of absence: Stripe's published pricing has no subscription tiers at all for Terminal, so there is no higher plan behind which reporting could be withheld. Advanced data access is a separately priced add-on rather than a tier gate. https://stripe.com/pricing · retrieved 2026-08-02

Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator

reporting-history-retention

unknown rather than partial. The claim's central requirement is what is QUERYABLE in the reporting UI with no silent truncation, and no document in the corpus addresses it; a storage-retention figure published under a foreign tax statute answers a different question. A partial would assert a finding the evidence does not carry. Tokenised over all seven directories with the control `payment` firing in every one (2,835 / 1,000 / 482 / 5,079 / 991 / 158 / 264): `retention window` is 1, in docs.stripe.com/activity-logs where it bounds the 6-month IAM log, and 0 in the other six. Bound: seven directories in which the docs sitemap is a FLOOR, and in which text-extra contributes 138 genuinely new bodies, not 335 - 197 of its files are byte-identical to a text-docs body by md5. What would settle it: a published queryable date range for the Dashboard Transactions list, the financial reports date picker or the Sigma payments tables. || 321st: NEW SURFACE, NO MOVE: Stripe public OpenAPI spec (github stripe/openapi via api.github.com + raw.githubusercontent.com, commit 706785daca8b, spec3.json 8,028,700 bytes, 419 paths, version 2026-08-26.dahlia). It is an enumeration of the API, not of the Dashboard reporting UI the claim names. It bounds only events: GET /v1/events "List events, going back up to 30 days." The list descriptions for /v1/charges, /v1/payment_intents, /v1/balance_transactions and /v1/refunds state no time window at all. reporting.report_type carries data_available_start ("Earliest time for which this Report Type is available") as a per-account dynamic value, not a published figure; docs.stripe.com/reports/api.md likewise says interval_start must fall between data_available_start and data_available_end without stating any length. No 24-month (or any) queryable UI window found on this surface; unknown held. Retrieved 2026-09-17. || 329th: 329th, NEW SURFACE, NO MOVE: a 100% census of the support.stripe.com KB, which no prior pass held. support.stripe.com/robots.txt allows / (Content-Signal: ai-train=yes, search=yes) and names its sitemap; /sitemap.xml (36,436 bytes) lists 1,869 URLs of which 1,830 are /questions/ pages, and EVERY ONE of the 1,830 was fetched at HTTP 200 as its `.md` twin (4,072,325 bytes total; the 429s on a first run all succeeded on retry). Nonsense control: /questions/zz-nonsense-control-slug.md returns 404 with a distinct 4,483-byte body, so the 200s are real. Href fixpoint over the 1,830 bodies: only 20 support /questions/ URLs are referenced at all and the 15 not in the sitemap are trailing-punctuation and percent-escaped duplicates of ones held, so the sitemap is the publisher's own list, not a floor. Also fetched the whole docs.stripe.com/terminal section as .md (100 URLs from the docs sitemap, 1.2 MB). WHAT THE CENSUS HOLDS ON THIS CELL: Stripe publishes Dashboard query windows only for adjacent objects - "In live mode, users can only access events created within the last 13 months from the Dashboard. Events older than 30 days will only provide a summary view" (questions/stripe-event-retention-period) and "The Dashboard allows users to view GET request logs from the past 31 days and non-GET request logs (including POST) from the past 15 months" (questions/stripe-request-log-retention-period). For transaction-level detail there is still NO published queryable window: questions/data-retention-policy says only that regulation requires Stripe "to retain transactional records for a prescribed period" and links the Privacy Policy; questions/exporting-a-report-of-all-transactions says the Balance Summary Report provides "an CSV and PDF export of your complete transaction history" without any date bound; docs/data/how-sigma-works states only that reports "follow the same availability rules as the Stripe Dashboard" and that Sigma exposes data_load_time; the Analytics API publishes limits per granularity, not a transaction-detail retention figure. Controls over the 1,830-article census (tokenised, word-boundary, case-insensitive): retention 60, '24 months' 2 (both Klarna financing pages - POISON), 'two years' 2 (same shape), 'how far back' 0, 'going back' 0, truncat* 3 (all statement-descriptor truncation - POISON), archiv* 4 (none a retrieval fee); positive control payment 6,182. So no archive retrieval fee is published anywhere in the KB, but the >=24-month queryable-UI conjunct is still unevidenced, so partial would still assert what the corpus does not carry. Retrieved 2026-09-18. adversarially verified

Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator

reporting-anomaly-alerts

Both halves of the claim exist at Stripe, on two different surfaces, and neither surface combines them - that is the shortfall. (a) DEVIATION DETECTION, not operator-configured: Stripe health alerts reach operators by email, webhook and a Workbench Health tab, and the anomaly table includes a 'Terminal authorization decline' row described as 'A sudden decline in successful Terminal payments', plus a 'Payment volume decline' row that notifies on volume declines 'while accounting for weekly fluctuations and seasonal variations'. The operator configures nothing but opt-in and the recipient list; the metrics are Stripe-defined payment-health metrics; the anomaly category is restricted to accounts on a 'Growth, Premium or Enterprise Support plan' and Payment volume decline is marked Private preview. (b) OPERATOR-CONFIGURED METRIC WITH EMAIL DELIVERY, but unconditional: Sigma scheduled queries run arbitrary operator-authored SQL over the operator's own Stripe data and, per docs.stripe.com/data/schedule-queries, 'You can automate your Sigma queries by scheduling them to run on a daily, weekly, or monthly basis.' and that results for each scheduled run are sent by email to specified team members or as webhook events. NAMED SHORTFALL: that email fires on a calendar, not on a condition - the schedule is 'daily, weekly, or monthly', results are sent every run, and the page describes no threshold, no suppression and no fire-only-on-breach behaviour, so it is a scheduled report rather than an alert. The claim needs one mechanism that is both operator-defined and threshold-triggered, and neither surface is. Stripe Billing Alerts are threshold-triggered and operator-defined but fire on a Billing usage meter, 'when a certain usage threshold on a meter is crossed', which is not Terminal sales. Verbatim: 'Anomaly alerts use machine learning (ML) to detect sudden drops or changes in payment performance in near-real time.' https://docs.stripe.com/health-alerts · retrieved 2026-09-11 adversarially verified

Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.

reporting-nl-query

Stripe documents a natural-language assistant that queries the merchant's OWN account data, not merely a docs-search bot. docs.stripe.com/assistant is framed 'Manage your account with natural language in the Dashboard' and separates three abilities: summarising docs and support articles via RAG, acting in the Dashboard, and answering questions about the merchant's own payments performance. Its own worked examples are tenant-data queries, including 'How has my payment success rate changed recently?' and 'What caused my authentication success rate to drop last week?'. A second surface is the Sigma query editor: docs.stripe.com/data/write-queries states 'Stripe's query editor has a built-in LLM assistant that outputs standard ANSI SQL from a natural language prompt' with Generate and Edit modes over the merchant's own Sigma tables. A third is the Stripe MCP server's execute_analytics tool, which docs.stripe.com/data/analytics says lets you 'retrieve metrics by describing what you want in natural language rather than constructing API requests manually' - developer-aimed, but it does query the merchant's own account, so it is not a docs assistant either. NAMED SHORTFALLS: (1) LABOR DATA IS ABSENT ENTIRELY - Stripe holds no labor, timeclock or scheduling dataset, so nothing can answer the labor half of the claim; (2) OUTPUT IS NOT A DOCUMENTED FIGURE OR CHART - the assistant page promises only to 'provide insights in natural language' and the Sigma assistant emits SQL for the operator to run; neither commits to returning a figure or a chart; (3) NO DOCUMENT TIES THE ASSISTANT TO CARD-PRESENT DATA - it is a Dashboard-wide feature over payments analytics, and neither the Sigma overview nor how-Sigma-works mentions Terminal at all, so its coverage of in-person sales is documented nowhere. The variant and href-fixpoint material added under Addendum 2 introduced no fourth surface: `natural language` is 0 across text-variants, text-variants2 and text-extra. Verbatim: 'Answer questions about your payments performance. The assistant can query data from the [Payments analytics](https://docs.stripe.com/payments/analytics.md) page, analyze your payments performance, and provide insights in natural language.' https://docs.stripe.com/assistant · retrieved 2026-09-11 adversarially verified

Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator

reporting-guest-cohorts

Card-present payments produce no identifiable guest by default - saving requires an explicit generated_card PaymentMethod attached to a Customer. Stripe publishes no new-vs-returning, visit-frequency or lifetime-spend cohort report (the Analytics metric list has none), and Terminal has no loyalty or online-ordering guest record to tie to. https://docs.stripe.com/terminal/features/saving-payment-details/overview · retrieved 2026-09-06 adversarially verified

Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator

reporting-sales-forecast

The complete Analytics metric list contains only realized historical measures and its finest granularity is a day, so no hourly or daypart forecast is available. No forward-looking metric is published anywhere in the corpus, and Terminal has no scheduling or ordering workflow for a forecast to feed. https://docs.stripe.com/data/analytics/supported-metrics · retrieved 2026-09-06 adversarially verified

Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.

reporting-tip-tax-compliance

Tips exist only as an amount on one PaymentIntent; Stripe models no employee, no declared-tip entry, no tip pool and no tip-out distribution, so declared-versus-charged tips per employee cannot exist. Stripe's Tax report family covers sales tax on Stripe-processed transactions, not payroll tip liability by jurisdiction. https://docs.stripe.com/terminal/features/collecting-tips/overview · retrieved 2026-09-06 adversarially verified

Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.

multi-location-org-hierarchy

Shortfall: a real hierarchy that scopes only devices. Stripe documents Zones as 'the top-level groups that can consist of either more zones or locations', nestable for additional levels, giving Account > Zone > Location > Reader, with the constraint that 'You must still assign readers to a location, and you can assign a location to only one zone.' What it scopes is reader grouping and regional reader configuration — there is no menu, price, tax, role or permission scoping at any level. https://docs.stripe.com/terminal/fleet/locations-and-zones · retrieved 2026-08-02 adversarially verified

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

multi-location-central-menu-publish

Read the full parameter enumeration for creating a Terminal Configuration, the only object Stripe pushes down to readers: per-device settings (7 reader models), cellular, name, offline, reader_security, reboot_window, tipping, wifi. No menu, item, catalog or price parameter exists, and no publish/version-history construct. Stripe Terminal has no menu entity to author or publish. https://docs.stripe.com/api/terminal/configuration/create · retrieved 2026-09-06 adversarially verified

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

multi-location-local-override-policy

Location's complete attribute list is address(+kana/kanji), configuration_overrides, display_name(+kana/kanji), livemode, metadata, phone. The only override mechanism is swapping an entire Configuration for a location; there are no corporate item records, no per-field override rules and no lockable attributes, because no catalog object exists. https://docs.stripe.com/api/terminal/locations/object · retrieved 2026-09-06 adversarially verified

Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.

multi-location-price-zones

Terminal's own overview states what locations/zones are for: applying regional and payment-method settings to registered readers. There is no price list, price tier, location-group price, order channel or daypart concept anywhere; the charged amount is supplied per transaction by the integrator's PaymentIntent. https://docs.stripe.com/terminal/overview · retrieved 2026-09-06 adversarially verified

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

multi-location-scheduled-publish

The only staged central rollout Stripe documents pushes reader APP binaries to deploy groups across accounts, with rollout percentages and pause/resume. It is not menu, price or promo, there is no future-dated activation interpreted in each location's timezone (the Location object carries no timezone), and no post-activation price rollback. https://docs.stripe.com/terminal/fleet/organization-deployments · retrieved 2026-09-06 adversarially verified

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

multi-location-new-store-template

Shortfall: templates cover readers only. Terminal Configuration objects (tipping settings among them) are reusable and assignable to readers and locations, so a new site can inherit reader behaviour — but a new-store template that carried menu, taxes, roles, printers or tenders does not exist because none of those objects exist. https://docs.stripe.com/terminal/features/collecting-tips/on-reader · retrieved 2026-08-02

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

multi-location-corp-vs-franchisee-roles

Shortfall: an analogy, not a franchise product. Stripe Connect separates a platform from independently-owned connected accounts with their own banking and onboarding, which maps loosely onto franchisor and franchisee — but there is no franchise product, no corporate-versus-franchisee permission model, and Connect is a separate product the buyer must adopt and operate as a platform. https://docs.stripe.com/connect · retrieved 2026-08-01

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

multi-location-royalty-calculation

Stripe's only automatic fee-calculation primitive is a Connect application fee evaluated per transaction (fixed, variable or blended on the payment amount, up to 125 conditional rules). There is no royalty, ad-fund or marketing-fee construct, no net-sales basis, no gross-vs-net-of-discounts/comps/third-party option and no periodic royalty schedule. https://docs.stripe.com/connect/platform-pricing-tools/pricing-schemes · retrieved 2026-09-06 adversarially verified

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

multi-location-royalty-collection

Stripe documents a generic primitive for debiting a connected account's Stripe balance (and Billing subscriptions for charging connected accounts), gated on platform negative-balance responsibility and explicit consent. But there is no calculated royalty or ad-fund amount for it to collect and no franchisee-visible royalty/fee statement; any amount must be computed outside Stripe. https://docs.stripe.com/connect/account-debits · retrieved 2026-09-06 adversarially verified

Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.

multi-location-consolidated-reporting

Shortfall: consolidation is payments-only and self-assembled. Data Pipeline can land multiple Stripe accounts into a single warehouse, but the consolidated view must be built in the customer's own BI layer, and the only measures available are payments measures — no sales mix, labour or cost roll-up. https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

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

multi-location-normalized-item-rollup

Read the itemized Balance report column enumeration: balance_transaction_id, charge_id, card_*, customer_*, fees, metadata. It is transaction-level and carries no product, item or SKU identifier at any version, so there is nothing to roll up under a shared corporate item ID. Stripe Terminal stores no item catalog to normalize. https://docs.stripe.com/reports/report-types/balance · retrieved 2026-09-06 adversarially verified

Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.

multi-location-cross-location-giftcard

Stripe gift cards are a private-preview pass-through to an external provider (SVS). Redemption scope is the provider's program, not Stripe's; Stripe states funds settle off-platform, publishes no outstanding-liability balance, no inter-store settlement or redemption reconciliation, and gift card operations can't even be listed. https://docs.stripe.com/payments/gift-cards · retrieved 2026-09-06 adversarially verified

A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.

multi-location-cross-location-loyalty

The most Stripe shares across accounts in an organization is customer contact records and payment methods (public preview, irreversible, consent-gated). That is not a loyalty profile: no points/stored-value balance and no stored order history, because Terminal has no order or check object. 'loyalty' appears in the corpus only in dispute-category and metadata examples. https://docs.stripe.com/get-started/account/orgs/sharing/customers-payment-methods · retrieved 2026-09-06 adversarially verified

A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator

multi-location-multi-brand

A reader resolves to exactly one Configuration (account default, or a Location's configuration_overrides). The Configuration attribute enumeration has no brand, receipt-branding-set, revenue-center or menu field, so one terminal cannot present two brands with separate menus and separately reportable revenue. Separate brands would need separate Stripe accounts. https://docs.stripe.com/api/terminal/configuration/object · retrieved 2026-09-06 adversarially verified

Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.

multi-location-multi-tax-jurisdiction

The prior rationale is right that Terminal itself carries no tax model - terminal/readers/set_reader_display takes a caller-supplied cart[tax] integer that is a display value only - but wrong that no documentation links Stripe Tax to in-person sales. Stripe Tax ships a performance location: a saved address attached to individual line items so tax is assessed at the place of sale instead of the business or customer address, on docs.stripe.com/tax/location-sales, whose actual title is Tax location-based sales and which covers in-person sales of goods and services, supported on Payment Intents, which is the object a Terminal payment is. The per-jurisdiction material opened by Addendum 2 is substantial and supports the claim: 52 US state and territory bodies, one per jurisdiction, each giving the supported tax types, the remote-seller threshold, the sourcing rule and the filing and location-report cadence for that state - California adds local Admission and Parking taxes that must be registered separately, Florida adds the Miami Parking Facilities Surcharge, Illinois names eight local amusement, lease and streaming taxes that file to the local jurisdiction on a different report. Prepared-food vs grocery is real but lives elsewhere, in the product tax codes: txcd_40060003 'Food for Immediate Consumption' is described as prepared foods, ready-to-eat foods or meals, against txcd_40040000 'Food for Non-Immediate Consumption' for retail grocery-type establishments. Inclusive vs exclusive is a first-class tax_behavior on a Price, with an Automatic default selecting exclusive for USD and CAD and inclusive otherwise. NAMED SHORTFALLS: (1) tax is not configured per Terminal Location - per-location tax is achieved by passing a performance_location per line item, and the Terminal fleet model has no tax in it at all; (2) exemptions are per-CUSTOMER, scoped to a jurisdiction and date range, and are in PRIVATE PREVIEW, not per-location, and Stripe states it does not let you upload, store, validate or track exemption certificates; (3) performance locations are in PUBLIC PREVIEW and cannot be combined with Stripe Tax customizations; (4) no document states that Stripe Tax applies to a card-present PaymentIntent confirmed by a reader - the link is the shared PaymentIntent object, not an explicit statement. Verbatim: 'Performance location support works with existing Stripe payment integrations. You can provide performance locations through the Tax Calculations API, Checkout Sessions, and Payment Intents.' https://docs.stripe.com/tax/location-sales · retrieved 2026-09-11 adversarially verified

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

multi-location-multi-currency-locale

Shortfall: locations can span many countries and currencies, but each one transacts only in its own local currency and Terminal itself converts nothing. The regional-considerations doc states: 'To process Terminal payments, both the Stripe account receiving the funds and the location associated with the reader must be in the same country, accepting local currency only.' The Connect article adds: 'Connected accounts are only able to process card present charges in their local currency. For example, US-based Connect Accounts can only process card_present payments in USD', with on_behalf_of on a destination charge used to settle in the connected account's local currency - so a multi-country estate is built as one account or connected account per country, not as one account presenting several currencies. Breadth is real: the global-availability page lists 37 countries each with its local currency (US, Mexico, Singapore and UAE appear in the regional reader-availability table). No consolidated reporting converted to a single reporting currency is offered by Terminal; that falls to Sigma or Data Pipeline and the customer's own FX logic. Supersedes the previous citation to support.stripe.com/questions/stripe-terminal-country-and-currency-availability, which now redirects to a page carrying only the country table - the multi-currency-presentment/DCC sentence the record quoted is no longer retrievable there. https://docs.stripe.com/terminal/payments/regional · retrieved 2026-08-09 adversarially verified

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

multi-location-config-audit-log

The prior rationale's IAM-only enumeration is FALSIFIED. Activity Logs is a preview API over one slice; the Dashboard surface is Security history, and docs.stripe.com/get-started/account/orgs/team says of it: 'Here, you can filter your security history by date or action.' That page goes on to say the Action filter includes hundreds of actions across different categories including User security, Team, API and a number of Stripe products, and that the entire security history can be exported as a CSV file. docs.stripe.com/security adds 'Users can export historical information from the logs.' So an exportable who-did-what-when change log exists and is broader than IAM. NAMED SHORTFALLS, with (1) now RESOLVED against the real article rather than a stub: (1) no location dimension — the Manage locations article documents creating, renaming, moving between zones and deleting locations, and carries no change history, no audit trail and no record of who made a location or zone change; the v1 event-type list contains no Terminal Location, Zone or Configuration event either; (2) retention is short — docs.stripe.com/get-started/account/teams states Stripe logs the account activity of team members during the past 180 days, and docs.stripe.com/activity-logs states Stripe retains activity logs for 6 months; (3) immutability is asserted nowhere; (4) the action list is a floor, not a ceiling, because it is introduced with 'including', so price, tax and discount object edits cannot be confirmed as covered. Verbatim: 'These audit logs contain records of sensitive account activity, such as logging in or changing bank account information.' https://docs.stripe.com/security · retrieved 2026-09-11 adversarially verified

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

multi-location-enterprise-sso

Stripe's security documentation states it supports 'single sign-on through Security Assertion Markup Language (SAML) 2.0, allowing you to mandate sign-in requirements, configure access control, and instantly onboard team members through just-in-time (JIT) account provisioning', and adds that 'If you use SSO with SCIM, you can enforce authentication policies centrally through your identity provider.' Dashboard MFA covers passkeys, hardware security keys, TOTP and SMS. SCIM's provisioning scope is referenced rather than fully specified. https://docs.stripe.com/security · retrieved 2026-08-02 adversarially verified

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

multi-location-enterprise-api

One authenticated API key returns transaction-level data across every Terminal Location on the account, with no per-location key or per-location fee; Data Pipeline extends the same reach across multiple accounts into one warehouse. https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.

multi-location-central-labor-policy

Terminal's scope statement enumerates readers, Dashboard fleet tools, payment-method support and encryption. Bounded over the 6,134-page publisher manifest, 'time clock', 'timeclock', 'clocked hours' and 'labor cost' return zero pages and no employee/shift/break entity exists, so no overtime, break or predictive-scheduling rule can be configured per location or enforced at the reader. https://docs.stripe.com/terminal/overview · retrieved 2026-09-06 adversarially verified

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

extensibility-public-api-docs

Complete public API and SDK reference at docs.stripe.com, readable without an NDA, a partner agreement or a sales call, and machine-readable — every documentation page is retrievable as Markdown by appending .md, which is how several claims in this record were verified. https://docs.stripe.com/terminal · retrieved 2026-08-01

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

extensibility-api-access-cost

Shortfall: the transactional API is free, bulk data access is not. No API fee, no per-location fee and no software subscription appear in Stripe's published Terminal pricing — Stripe monetises the processing rate instead. But getting your own data out in bulk requires paid add-ons (Sigma $15.00/month, Data Pipeline $65.00/month), and the sole evidence is the vendor pricing page, which is grade C. Scored consistently with reporting-api-not-upcharged, which describes the same arrangement. https://stripe.com/pricing · retrieved 2026-08-02

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

extensibility-partner-revshare

Stripe runs at least four partner commercial programmes and states in public that each one pays, while stating in the same breath that the rate lives in a credential-gated document. (1) The Affiliate Terms set commission rates in a per-affiliate insertion order on the gated Platform, and elsewhere refer to 'a lower commission than our standard rate' without ever stating the standard rate. (2) The Stripe Partner Ecosystem Agreement, section 2.5, says Stripe 'may, at its discretion, provide incentives for Partner to submit referrals for potential users of Stripe Services' and makes access 'subject to this Agreement, including all eligibility requirements and other additional terms made available to Partner in the Portal, if any'; section 2.4 defers marketing funding the same way, and section 2.6 refers to 'amounts payable to Partner' without naming any. (3) docs.stripe.com/partners/platforms lists 'Eligible for Stripe Connect revenue sharing' as a benefit of both the Partner and Premier tiers and describes a 'Stripe Connect revenue sharing program' with no rate. (4) stripe.com/connect/pricing offers 'Earn a portion of each online card transaction with a revenue share' and renders the corresponding pricing cells as 'Varies'. Stripe Capital's platform page likewise promises 'Earn a revenue share on all loans or merchant cash advances' with no percentage. Verbatim: 'Stripe and Affiliate agree to the commission rate(s) for Qualified Leads and Qualified Opportunities set forth in an electronic insertion order that will be made available on the Platform.' https://stripe.com/legal/affiliate-terms · retrieved 2026-09-11 adversarially verified

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

extensibility-free-sandbox

A free sandbox plus a built-in simulated reader in every SDK and in the server-driven API, so a developer can integrate and test the full payment flow with no hardware and no paid account. Documented test scenarios cover declines, PIN entry, reader software updates and offline behaviour. https://docs.stripe.com/terminal/references/testing · retrieved 2026-08-01

Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).

extensibility-oauth-partner-apps

Stripe Connect provides OAuth-based, account-holder-granted, revocable authorization for third-party platforms to act on an account, and restricted API keys give scoped, least-privilege permissions. https://docs.stripe.com/connect · retrieved 2026-08-01

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

extensibility-webhooks-push

Shortfall: payment lifecycle only. Real-time push webhooks cover PaymentIntent creation, success, cancellation, refund and dispute, but there is no order object, so order-lifecycle events — placed, fired, ready, completed — must be modelled entirely in the integrator's own system. https://docs.stripe.com/webhooks · retrieved 2026-08-02

Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator

extensibility-webhook-reliability

Documented to an unusual level of precision: HMAC-SHA256 signatures in the Stripe-Signature header carrying a timestamp (t=) and versioned schemes (v1 live, v0 test) with explicit guidance to ignore non-v1 schemes; live-mode delivery attempted 'for up to three days' with exponential back off against three retries over a few hours in sandbox; an Event deliveries tab listing Delivered, Pending and Failed; manual resend up to 15 days from the Dashboard and up to 30 days via the Stripe CLI. https://docs.stripe.com/webhooks · retrieved 2026-08-02 adversarially verified

A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.

extensibility-order-injection-api

Positive evidence of absence: the Terminal write API is enumerated in the reference and creates PaymentIntents, Readers, Locations, Zones and Configurations. There is no order or ticket resource, so nothing can be injected that would fire to a kitchen or print a chit. https://docs.stripe.com/terminal · retrieved 2026-08-01

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

extensibility-menu-write-api

Terminal has no catalog: the reader's cart is pushed inline per transaction by the integrator and is not stored by Stripe, and the Terminal API namespace (configuration, connection_tokens, hardware_*, locations, onboarding-link, readers) contains no item, menu or modifier resource. Stripe does expose writable catalogs elsewhere - Products and Prices on /v1, and a full product/variant/inventory feed through the Commerce product-catalog-import API - but neither carries a modifier concept and neither is ever read by a reader, so no menu that the POS charges from is writable. https://docs.stripe.com/terminal/features/display · retrieved 2026-09-06 adversarially verified

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

extensibility-data-symmetry

Shortfall: symmetric over a much smaller object model. Everything Stripe models — payments, customers, readers, locations, zones, configurations — is both readable and writable through the same public API. But the restaurant object model that this claim is really asking about (orders, menu, employees, inventory) does not exist to be read or written. https://docs.stripe.com/terminal · retrieved 2026-08-01

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

extensibility-published-rate-limits

Numeric limits published openly: 100 requests per second live mode, 25 per second in sandbox, 25 per second default per individual endpoint, HTTP 429 on exceedance with a Stripe-Rate-Limited-Reason header taking global-rate, endpoint-rate, global-concurrency, endpoint-concurrency or resource-specific, plus resource-specific ceilings such as 1,000 update requests per PaymentIntent object per hour. Among the most precisely documented cells in this record. https://docs.stripe.com/rate-limits · retrieved 2026-08-02 adversarially verified

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

extensibility-doordash-preferred

RE-SOURCED ON AUDIT, 2026-09-11, OUTSIDE THE FROZEN CORPUS, because DPIP membership is published by DoorDash and a sweep of Stripe's corpus is a sweep of the wrong publisher. robots.txt was checked first: merchants.doordash.com/robots.txt answers User-agent: * then Allow: /, disallowing only /cdn-cgi/ and /monitoring. THE INSTRUMENT THIS ROW PREVIOUSLY USED WAS A FLOOR AND HAS BEEN DISCARDED: the preferredPartnerDescriptions map in the integrations page's __NEXT_DATA__ sits under a heading that introduces the section as a selection of partners, and it mixes quality tiers, so absence from it proves nothing. The instrument now cited is the registry the program page means when it says the roster is tracked in real time: merchants.doordash.com/api/partner-integrations returns 64 provider entries anonymously at HTTP 200, each carrying a qualityMetadata object with qualityStatus, featuresCompleted, featureCollectionsList, providerAggregationType, providerPortalLink and countriesSupportedList. The 64 split 12 QUALITY_STATUS_PREFERRED, 47 QUALITY_STATUS_CERTIFIED and 5 QUALITY_STATUS_AT_RISK_OF_SUSPENSION. Because the registry enumerates the failing tier alongside the passing ones it is the complete provider roster rather than a promotional subset, so a provider's absence from it is positive. The tokens stripe, terminal, verifone and bbpos each occur zero times in the entire 158,095-byte payload, under any provider id or friendly name. The 12 PREFERRED entries are deliverect, toast, square_v2_production, chowly, urbanpiper_production, partech_menu_production, stream, otter_production, shift4, meal_co_production, qubeyond_v2 and checkmate. That matches what Stripe Terminal is: a card-present payment-acceptance layer whose documented objects are PaymentIntent, SetupIntent, PaymentMethod and Customer, with no menu, item-availability or order-injection API for DoorDash to certify. GRADE: the auditor set E on the reasoning that the rubric grades by the publisher's relationship to the scored vendor. Harmonised to B for the corpus, because the same URL now backs this claim in 47 records and one URL on one claim cannot carry two grades: 39 of those rows already graded a DoorDash-published document B before today, and E is unworkable here because nine of the 47 are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The auditor's dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11 adversarially verified

Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator

extensibility-first-party-delivery-integrations

Stripe's partner program enumerates four open tracks - Services, SaaS platforms, Apps, Payment methods - plus invitation-only Technology. There is no delivery-marketplace track and no certified delivery integration. 'Uber Eats' and 'Grubhub' return zero pages across the whole corpus; DoorDash appears only as a 1099 filing customer. https://docs.stripe.com/partners · retrieved 2026-09-06 adversarially verified

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

extensibility-middleware-compatibility

Deliverect, Chowly, Otter, Checkmate and ItsaCheckmate return zero pages across the 6,134-page publisher manifest. More decisively, order-injection middleware needs an order/menu endpoint and Terminal publishes none - its documented surface is readers, payment methods, fleet management and SDKs for card-present payments. Bound: the middleware vendors publish their own POS lists. https://docs.stripe.com/terminal/overview · retrieved 2026-09-06 adversarially verified

Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.

extensibility-accounting-connectors

The claim is a conjunction of four requirements - QuickBooks Online, one other GL, vendor-maintained, mapped rather than CSV-only - and no single connector satisfies all four. Stripe builds and maintains exactly one GL connector, the Stripe Connector for NetSuite, documented across roughly 30 first-party pages including field mappings, invoice automation, deposit automation, multiple subsidiaries and multiple currencies, and automatic reconciliation of charges, refunds, disputes, payouts and Connect activity - mapped records, not CSV. NAMED SHORTFALL: there is no native, Stripe-maintained QuickBooks Online connector. Stripe's own QuickBooks path is a QuickBooks Desktop-compatible IIF export from Legacy exports, creating nine named QuickBooks accounts, and for QuickBooks Online Stripe affirmatively directs the merchant to a third-party integration. The QBO path Stripe does surface, on docs.stripe.com/stripe-apps/embedded-apps/accounting-integrations, is stated on the page itself to be an integration to Quickbooks Online and Xero through Connect embedded components for Stripe Apps built by 3rd party developers - the QBO app is Quickbooks Sync by Acodei and the Xero app is Xero. That page settles the CSV half of the claim in the vendor's favour - it lists 'Configure and map all object types to the Quickbooks Online accounts' and mapping product types sold to Quickbooks Online accounts, i.e. mapped, not CSV - while settling the vendor-maintained half against it, and it is itself a preview aimed at Connect platforms embedding the app for their users rather than at a single-location merchant. Verbatim: 'You can’t import IIF-formatted files into QuickBooks Online.' https://docs.stripe.com/accounting-integrations · retrieved 2026-09-11 adversarially verified

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

extensibility-payroll-export

Stripe's integration/export documentation covers accounting only - QuickBooks IIF, the NetSuite connector, marketplace accounting apps. No payroll provider is documented as an export target; Gusto appears in the corpus only as an Atlas perk and a partner-rewards discount, and ADP/Paychex/Paylocity not at all. Terminal records no labor hours to export. https://docs.stripe.com/accounting-integrations · retrieved 2026-09-06 adversarially verified

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

extensibility-bi-data-warehouse

Data Pipeline delivers Stripe data on a scheduled refresh into Snowflake, Redshift, BigQuery, Databricks, S3, GCS or Azure Blob with no code required, at a published $65.00 per month. This is a genuine first-party warehouse pipeline rather than a CSV export dressed up as one. https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

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

extensibility-app-marketplace

Shortfall: a real marketplace, but not for this market. Stripe's documentation states that 'Stripe Apps allows you to develop and distribute apps privately or publish them on the global Stripe Apps Marketplace', so a public catalogue of named third-party apps that an account holder can browse and install does exist. It is oriented to finance, commerce and operations tooling; no restaurant-specific listing could be verified, and the marketplace site itself renders client-side and returns no listing content to retrieval. https://docs.stripe.com/stripe-apps.md · retrieved 2026-08-02 adversarially verified

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

extensibility-custom-fields-scripting

Shortfall: customisation attaches to payment objects, not POS objects. Metadata fields exist on core Stripe objects and Stripe Apps provide hosted extension logic, but there is no order, item or check to add a custom field to, and the depth of the scripting surface was not verified.

The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.

extensibility-headless-embedded

This is precisely what the product is. Stripe documents that Apps on Devices lets you 'run your point-of-sale (POS) application along with other apps on your device', deploying your own POS app to Stripe smart readers as an all-in-one solution or as a customer-facing app driven by a POS on another device. It runs on Android 10 on the S700/S710 and on Verifone readers, with a 200MB APK limit. Constraints are documented too: Google Play Services are not available, production devices have a disabled USB port with no adb or debugging, and 'Stripe manages updates over the air for all apps and software components that run on the device.' https://docs.stripe.com/terminal/features/apps-on-devices/overview · retrieved 2026-08-02 adversarially verified

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

extensibility-api-versioning-deprecation

Stripe publishes dated API versions with a public changelog and a documented upgrade and deprecation path; SDKs pin to a version so an unrequested upgrade does not break an integration. https://docs.stripe.com/upgrades · retrieved 2026-08-01

A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator

extensibility-data-portability-exit

Shortfall: excellent while you are a customer, undefined once you are not. Export runs self-serve through the API, Dashboard CSV and Data Pipeline for the life of the account, but the Stripe Services Agreement states that 'Upon termination of this Agreement, User's rights to use the Services and the Stripe Technology immediately cease' and requires deleting Stripe technology — with no defined post-termination retrieval window. https://stripe.com/legal/ssa · retrieved 2026-08-02

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

reliability-offline-order-entry

Stripe documents offline behaviour in detail and exactly one thing survives: card payment capture, stored encrypted on the reader and forwarded later. Order entry, ticket routing and check printing are not Terminal functions online either - this page defines a deployment as the partner's own POS app plus a backend, a reader and the SDK - so none of the claim continues offline. https://docs.stripe.com/extensibility/terminal-for-pos-partners · retrieved 2026-09-06 adversarially verified

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

reliability-offline-card-auth

Store-and-forward offline card acceptance is documented for Bluetooth readers (Chipper 2X BT, Stripe Reader M2, WisePad 3) and internet readers (S700/S710, WisePOS E), with payments written to disk and forwarded on reconnection: 'You can safely reboot the reader, even with stored offline payments... The reader then resumes forwarding any remaining stored payments.' Tap to Pay on iPhone offline is marked (Private preview) rather than generally available, and 'Tap to Pay on Android doesn't support offline mode.' https://docs.stripe.com/terminal/features/operate-offline/overview.md?reader-type=internet&platform=ios · retrieved 2026-08-02 adversarially verified

The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator

reliability-offline-decline-liability

Both halves are published first-party, on a page three earlier passes recorded as unrenderable because they asked for it with a parameter name the docs do not use ('platform=' rather than 'terminal-sdk-platform=', and without 'terminal-card-present-integration=terminal'). Who bears the loss, verbatim: 'You, as the user, assume all decline and tamper-related risks associated with an offline transaction. If your tampered reader can’t forward payments to Stripe, or the issuer declines the transaction, there’s no way to recover the funds, and you might not receive payment from the customer for goods or services already provided.' and, on the collect step, 'Payment liability is your responsibility when operating your reader offline.' The per-transaction cap, verbatim: 'your integration must handle offline-specific error cases, such as when the transaction exceeds the Stripe-enforced offline maximum of 10,000 USD or equivalent in your operating currency.' Identical language appears on the bluetooth/ios, internet/ios and internet/android variants. No cumulative cap is published, but this claim asks for a per-transaction OR cumulative cap and the per-transaction one is stated. https://docs.stripe.com/terminal/features/operate-offline/collect-card-payments.md?terminal-card-present-integration=terminal&reader-type=internet&terminal-sdk-platform=ios · retrieved 2026-08-12 adversarially verified

Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator

reliability-lan-degraded-multi-terminal

Now settled on the offline article itself. Stripe's degraded mode is per-device store-and-forward: each smart reader stores its own payments to disk, the SDK stores its own on the POS device, and forwarding is per device. Its sibling integration page docs.stripe.com/terminal/features/operate-offline/collect-card-payments?terminal-card-present-integration=terminal&reader-type=internet&terminal-sdk-platform=android adds that to collect with a smart reader while offline you must have previously connected to the same reader using a valid connection token within the last 24 hours, on the same local network, and that your reader and POS device must be on the same local network used to connect online - the first of those two sentences also appears at docs.stripe.com/extensibility/terminal-for-pos-partners — so the LAN link that survives a WAN outage is POS-device-to-reader, one pairing at a time. Nothing in any of the seven directories documents reader-to-reader communication or a check, tab or table object held by Stripe at all, so there is no shared state for two terminals to contend over. THE ONE COUNTERVAILING SURFACE, and why it does not carry the claim: docs.stripe.com/use-stripe-apps/oracle/simphony/overview describes a Pay at Table app on S700 and S710 readers whose servers 'select their open checks' — but the checks are Oracle's, not Stripe's, retrieved through Oracle's STS Gen2 API along with push notifications for check and configuration changes, and the app's own prerequisites begin by telling you to order an internet-connected Terminal device. No document states that check retrieval or check sharing survives a WAN outage on a LAN-only network. Verbatim: 'If you have internet connectivity issues, Stripe Terminal allows you to store payments locally on your POS device or smart reader.' https://docs.stripe.com/terminal/features/operate-offline/overview?reader-type=internet · retrieved 2026-09-11 adversarially verified

The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator

reliability-local-transaction-engine

Shortfall: local persistence, not a local engine. There is no on-premise server and no local authorization — the reader and SDK store offline payments to disk and forward them when connectivity returns, and authorization happens only at Stripe once online. That is durable local buffering rather than a transaction engine that can run the business standalone. https://docs.stripe.com/terminal/features/operate-offline/overview · retrieved 2026-08-02

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

reliability-offline-kds-printing

Terminal's entire printing surface is an embedded thermal receipt printer on one reader model (Verifone V660p), driven by sending an image to that reader. There is no kitchen printer and no kitchen display: 'kitchen' appears on a single page of the 6,134-page frozen corpus (a tax-code list), and no routing rules exist that could keep running offline. https://docs.stripe.com/terminal/features/print-content · retrieved 2026-09-06 adversarially verified

The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.

reliability-printer-fallback

The API reference gives the complete parameter list for printing: a single image, posted to one reader id. No backup destination, no routing group, no fallback parameter, and no second printer to fail over to (only the V660p has one). Failure surfaces as a terminal.reader.action_failed webhook - a developer notification, not automatic re-routing and not a staff alert. https://docs.stripe.com/api/terminal/readers/print_content · retrieved 2026-09-06 adversarially verified

The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).

reliability-sync-conflict-handling

Read on the recovered HTML variant bodies, the offline model rules the claim's scenario out by construction and Stripe documents each step of it affirmatively. (1) The offline record is IMMUTABLE until it reaches Stripe - the quoted line means an offline payment cannot be edited, voided or reversed by any device while the partition lasts, so there is no second write to reconcile. (2) It is bound to ONE reader on ONE network: 'To collect payments with a smart reader while offline, you must have previously connected to the same reader using a valid connection token within the last 24 hours, on the same local network', and 'You can’t switch networks while offline.' A second POS cannot reach that reader's queue. (3) It has no server identity to collide on: 'While operating offline, `PaymentIntent` objects have a null `id`.' (4) Stripe assigns cross-system reconciliation to the INTEGRATOR and names the mechanism - adding a custom identifier to the PaymentIntent metadata 'to help reconcile `PaymentIntent` objects created offline in your database', plus webhooks on forwarding to associate them with the real PaymentIntent ID. (5) The only concurrency controls Stripe offers are risk gates, not merge rules: a `CreateConfiguration` with `offlineBehavior` of `REQUIRE_ONLINE`, `PREFER_ONLINE` or `FORCE_OFFLINE`, and the counters `offlinePaymentsCount` and `offlinePaymentAmountsByCurrency`. Stripe Terminal holds no check, order line, item or void record that two devices could edit, and the offline object it does hold cannot be edited at all until forwarded. NAMED ABSENCE: no last-write-wins, merge or operator-prompt policy is stated anywhere in the corpus, because no divergent-edit scenario exists to state one for. Verbatim: 'You can’t cancel or refund a PaymentIntent that was created and confirmed offline until it’s forwarded to Stripe.' https://docs.stripe.com/terminal/features/operate-offline/collect-card-payments?terminal-card-present-integration=terminal&reader-type=internet&terminal-sdk-platform=android · retrieved 2026-09-11 adversarially verified

The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).

reliability-offline-feature-matrix

Stripe publishes an explicit per-reader-type matrix of what does not work offline rather than a vague reassurance: tipping, running a custom POS app and collecting input on-screen are unsupported offline on Bluetooth and Tap to Pay readers and supported on internet readers, while incremental authorizations are unsupported on all three. Two corrections to the prior record: the 10,000 USD offline maximum is not on this page - the overview carries no limit or liability statement of any kind - and the '24-hour connection token' and '30-day reader software' windows an earlier pass cited could not be located in the documentation across three passes and are not reproduced. https://docs.stripe.com/terminal/features/operate-offline/overview.md?reader-type=internet&platform=ios · retrieved 2026-08-02 adversarially verified

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

reliability-public-status-page

status.stripe.com is public and requires no login. Per-component granularity and any published historical uptime percentages were not confirmed because the page renders client-side. https://status.stripe.com/ · retrieved 2026-08-01

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

reliability-contractual-uptime-sla

CORRECTED ON AUDIT 2026-09-11. The standard agreement does not merely omit an availability SLA; across the legal corpus Stripe EXPRESSLY REFUSES service levels, service by service, in sections headed Availability. The term `service levels` occurs in 44 of the 486 legal documents and every occurrence is a refusal - for the Treasury Services, the Beta Services, the Multicurrency Settlement Services, the Next-Day Settlement Services, the FX Quotes Services, the Currency Conversion in Dashboard Service, the Instant Settlement Services, the Global Financial Account Services and the Console Services. The Stripe Services Agreement separately disclaims that use of the Services and Stripe Technology will be uninterrupted or error-free. `service credit` occurs zero times in all 486 legal documents. The only availability figure Stripe publishes is a marketing statistic on stripe.com, stripe.com/enterprise and stripe.com/support-plans, captioned retrospectively as historical uptime for Stripe services; a measurement is not a commitment and carries no remedy. Two guards. First, stripe.com/support-plans does publish a 15-minute response SLA - a SUPPORT response target, not an availability commitment, and it would not satisfy this claim even if it were richer. Second, `uptime` also occurs in Terminal hardware documentation in the opposite sense, where docs.stripe.com/terminal/fleet/reboot-time describes a Stripe-enforced 24-hour maximum uptime for smart readers, i.e. a mandatory daily reboot. Verbatim: 'Stripe does not offer service levels for the Stripe Treasury Services.' https://stripe.com/legal/connect · retrieved 2026-09-11 adversarially verified

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

reliability-incident-postmortems

Stripe HAS published written root-cause analyses, at a dedicated path, and the prior rationale missed them because it looked only at the status page. stripe.com/rcas/2019-07-10 is a full postmortem of the 2019-07-10 API degradation, dated July 12 2019 and bylined to CTO David Singleton, with a Summary, two minute-by-minute timelines, a 'Root cause analysis' section naming two database failure modes and a bad interaction with a configuration change, and a 'Remediations' section. stripe.com/rcas/2020-01-06 is a second one, on Stripe Atlas founder data potentially accessible through guessable URLs. NAMED SHORTFALL: the practice is not current and does not cover the outages the claim is about. Exactly 2 URLs under /rcas/ exist anywhere in the corpus, both from 2019 and 2020, and nothing in the status-page era carries one: across the 152 non-maintenance incident pages on www.stripestatus.com the token `postmortem` occurs 0 times in the stripped text, and all 7 critical incidents are one- or two-sentence notices - 6 of the 7 state no cause at all, and the seventh attributes the outage to an expired certificate at Klarna, a third party. Where a cause does appear it is a single clause inside a resolution update; 29 of the 2,201 status entries carry one and nearly all attribute the fault to an upstream partner rather than to Stripe. Verbatim: 'In response to these events, we implemented additional monitoring to alert us when nodes stop reporting replication lag, and if a shard enters a state that could trigger this election fault in the database failover system.' https://stripe.com/rcas/2019-07-10 · retrieved 2026-09-11 adversarially verified

24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.

reliability-247-live-support

Stripe's support-plans page states all customers receive 24x7 phone, email and chat support plus the support centre and developer Discord at no cost, with paid Premium and Enterprise plans adding response-time SLAs (15-minute critical), a dedicated technical account manager and proactive monitoring. This establishes entitlement from a vendor page; operator reports of actual responsiveness are a separate and less flattering signal recorded in the narrative. https://stripe.com/support-plans · retrieved 2026-08-01 adversarially verified

The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator

reliability-onsite-install

Stripe's own enumeration of recommended Terminal resources and partners has four categories - development agencies, off-the-shelf POS/PMS integrations, third-party hardware and accessories, and go-to-market/Professional Services for integration strategy. None is in-person installation. Deployment is self-service: order readers in the Dashboard, then self-register by pairing code. https://support.stripe.com/questions/recommended-resources-and-partners-for-stripe-terminal · retrieved 2026-09-06 adversarially verified

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

reliability-menu-build-service

Not applicable rather than merely unprovided: there is no menu or item catalog in Terminal for anyone to build. Stripe's list of what a Terminal setup consists of is an account, a physical location, a reader, a way to start a payment and Dashboard fleet tools - no product or price data. Onboarding is registering hardware and setting a Configuration. https://docs.stripe.com/terminal/overview · retrieved 2026-09-06 adversarially verified

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

reliability-hardware-replacement-sla

A replacement programme is included rather than absent: stripe.com/legal/terminal-purchase section 8.a gives a one-year limited warranty under which Stripe will, at its option, either repair the product or replace it with a new or refurbished device, and docs.stripe.com/terminal/fleet/submitting-warranty-claim gives a self-service Dashboard claim flow that collects a shipping address for the replacement and issues a return label where Stripe requires the defective unit back. NAMED SHORTFALL: no turnaround time is stated anywhere for the replacement itself. The only published interval is a claim-review target — Stripe's support team reviews a submitted claim within 48 business hours — which is not a time-to-working-reader. Delivery is expressly disclaimed twice: the Hardware Shipping Method object says the estimated dates are not guaranteed, and Purchase Terms section 7.a says that if Stripe provides an estimated shipping or delivery date, that date is not guaranteed, and that Stripe is not liable for late shipment or delivery even if the buyer paid an additional fee for expedited shipping. There is also no advance exchange: nothing documents a replacement shipping before the defective unit is returned, and no expedited or guaranteed-turnaround replacement tier is offered for purchase. Verbatim: 'The estimated delivery period containing the estimated minimum and maximum delivery dates. These dates are not guaranteed.' https://docs.stripe.com/api/terminal/hardware_shipping_methods/object · retrieved 2026-09-11 adversarially verified

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

reliability-backup-restore

The retrieve half of the claim is met and the restore half and the RPO/RTO half are not. Operators can trigger and retrieve their own full copy of their Stripe data without writing code: Data Pipeline 'allows you to send all your Stripe data to a variety of data storage destinations without writing code' to Snowflake, Redshift, Google Cloud Storage, Amazon S3 or Azure Blob, with a private-preview real-time Postgres sync; Sigma scheduled queries deliver CSV results by email or webhook on a daily, weekly or monthly schedule; the Dashboard exports payment, payout and refund reports. NAMED SHORTFALLS: (a) there is no restore path - no documented way to push a retrieved copy back into a Stripe account, and no operator-triggered rollback of Terminal Location or Configuration objects. The recovered fleet prose confirms this shape rather than softening it: a Configuration can be created, edited and deleted per location, and on deletion 'the readers in the location default back to the account’s default configuration within 10 minutes' - a fallback to account default, not a restore of what was there. (b) No RPO or RTO figure is published anywhere. The nearest Stripe comes is the DPA's Availability Controls, which name 'database replication', 'backup procedures', 'hardware redundancy' and 'a disaster recovery plan' as internal measures, with no number attached and no customer-facing trigger. Pointedly, Stripe's own buyer-side guidance treats these figures as something to demand of a vendor: its payments security and compliance guide tells readers to ask a provider 'what its key data recovery objectives are' naming Recovery Time Objective and Recovery Point Objective, and Stripe publishes neither for itself. Verbatim: 'Stripe implements measures to ensure the ability to restore the availability and access to Personal Data in a timely manner in the event of a physical or technical incident, including' https://stripe.com/legal/dpa · retrieved 2026-09-11 adversarially verified

The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.

reliability-pci-dss-4-attestation

Shortfall: the level is stated, the version and the merchant's own attestation are not. Stripe documents that 'A PCI-certified auditor evaluated Stripe and certified us to PCI Service Provider Level 1. This is the most stringent level of certification available in the payments industry,' and links its Visa Global Registry listing. No PCI DSS version number (4.0 or 4.0.1) appears, and no merchant-facing Attestation of Compliance is offered on the page. https://docs.stripe.com/security · retrieved 2026-08-02

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

reliability-mfa-role-based-access

Shortfall: back-office only. Stripe documents Dashboard MFA across passkeys, hardware security keys, TOTP and SMS, plus team roles and SAML SSO — but all of it governs back-office Dashboard access. POS-side login, shift login and action-level authorisation are the integrator's application to build, because Stripe ships no POS. https://docs.stripe.com/security · retrieved 2026-08-02

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

reliability-self-serve-training

Shortfall: developer training, not staff training. Extensive free public developer documentation plus a sandbox and simulated reader give an integrator a genuine practice environment, but there is no staff-facing video library, LMS, certification path or terminal training mode for the people who would actually run a shift. https://docs.stripe.com/terminal/references/testing · retrieved 2026-08-01

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

reliability-failover-terminal-role

Terminal has no master/server terminal to fail over to: each reader connects independently to Stripe and each POS device talks to a reader over the LAN, with no local server in the documented architecture. The failover Stripe does document is network-level on the reader (Ethernet, then WiFi, then cellular, then store-and-forward offline), not a peer promotion. https://docs.stripe.com/terminal/features/operate-offline/network-transitions · retrieved 2026-09-06 adversarially verified

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

reliability-cellular-backup

Automatic failover is documented, not just priced. The S710 prioritises Ethernet, then WiFi, then cellular: 'When primary connectivity (Ethernet or WiFi) is lost, the reader falls back to cellular. When primary connectivity returns, the reader switches back automatically.' The POS-to-reader connection survives both transitions with no reconnection required. It is not seamless - 'Online payments may fail during the fallback window while the reader transitions from WiFi or Ethernet to cellular (typically 15 seconds to 2 minutes, depending on cellular signal strength).' Cellular data is sold separately at a published $10.00 per reader per month. https://docs.stripe.com/terminal/features/operate-offline/network-transitions.md · retrieved 2026-08-02 adversarially verified

Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator

commercial-month-to-month-contract

Better than month-to-month — there is no term at all. The Stripe Services Agreement states it 'is effective when User first accesses or uses the Services or Stripe Technology (the Effective Date) and continues until User or Stripe terminates it (the Term)', and users may terminate at any time by closing the account. Pricing is pay-as-you-go with no software subscription. The only term commitment anywhere in the stack is the optional 1-year annual pricing on the Sigma and Data Pipeline add-ons. https://stripe.com/legal/ssa · retrieved 2026-08-02 adversarially verified

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

commercial-no-early-termination-fee

No early termination fee or liquidated-damages clause appears in the Stripe Services Agreement. The only related constraint is that 'payment obligations are non-cancelable and Fees paid are non-refundable' — you owe what you have already incurred, but nothing for leaving. https://stripe.com/legal/ssa · retrieved 2026-08-02 adversarially verified

The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.

commercial-autorenew-terms-published

The full agreement is public and the question resolves trivially: there is no fixed term and no renewal cycle for the core service, so no auto-renewal window or cancellation notice period applies. Nothing is hidden behind an order form. https://stripe.com/legal/ssa · retrieved 2026-08-02

The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator

commercial-processing-not-bundled

Positive evidence of absence: Terminal is Stripe's own acquiring product and its published price is a Stripe processing rate. Card-present transactions run on Stripe with no third-party processor option, so processing and platform are inseparable by design. https://stripe.com/pricing · retrieved 2026-08-02

Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator

commercial-interchange-plus-published

Positive evidence of absence: the published card-present price is a single blended rate. The in-person Cards and wallets row reads '2.7% + 5¢' above the separate line 'per successful transaction for domestic cards'. No interchange-plus schedule appears anywhere in Stripe's public pricing; if IC+ is available at volume it is quote-only through Stripe sales. QUOTE FIDELITY CORRECTED 2026-09-11: the prior note presented the amount, a lower-case letter c in place of the cent sign, and the qualifier clause as a single quoted span. The page renders the amount and the qualifier as two separate layout cells, so that span is not verbatim anywhere. The figure is unchanged. https://stripe.com/pricing · retrieved 2026-09-11

The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator

commercial-rate-increase-clause

A published notice protection exists: 'Stripe will provide User with at least 30 days notice (or longer period if Law requires) of any increase in a Fee or any new Fees for any Service provided to User.' Qualify it — 30 days advance notice only, no cap on the magnitude of an increase and no price lock. Combined with a no-term agreement, the merchant's remedy is to leave. https://stripe.com/legal/ssa · retrieved 2026-08-02 adversarially verified

Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).

commercial-pricing-published

Fully public and itemised: processing rate, per-authorization add-ons for Tap to Pay and P2PE, per-reader cellular at $10.00/month, per-SKU hardware (M2 $59.00, S700 $299.00, S710 $299.00) and add-on software list prices (Sigma $15.00/month, Data Pipeline $65.00/month). No per-terminal software fee exists to publish. https://stripe.com/pricing · retrieved 2026-08-02

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

commercial-module-unbundling

Shortfall: every module unbundles except the one that matters. Terminal, Radar, Sigma, Data Pipeline and Instant Payouts are independently adoptable and separately priced, and dropping one does not reprice anything else because there is no base subscription. But card processing itself cannot be unbundled — Terminal only settles through Stripe, so the largest line in the three-year cost is mandatory. Evidence is the vendor pricing page (grade C). https://stripe.com/pricing · retrieved 2026-08-02

All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.

commercial-hardware-purchase-outright

Readers are sold outright at published per-SKU prices — Stripe Reader M2 $59.00, Stripe Reader S700 $299.00, Stripe Reader S710 $299.00 — with no mandatory lease, rental or financing programme in the published pricing. https://stripe.com/pricing · retrieved 2026-08-02

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

commercial-hardware-not-locked

Shortfall: genuinely open at one end, firmly closed at the other. Tap to Pay runs on standard iPhones and Android phones the merchant already owns, and Verifone readers are supported alongside Stripe's own. But card readers must come from Stripe's supported list, the S700/S710 run Stripe's Android build with Google Play Services unavailable, a disabled USB port and no adb, and 'Stripe manages updates over the air for all apps and software components that run on the device'. There is no ESC/POS printer or generic cash-drawer support at all. https://docs.stripe.com/terminal/features/apps-on-devices/overview · retrieved 2026-08-02

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

commercial-implementation-fee-published

Shortfall: absence rather than an explicit statement. No implementation, onboarding, setup or professional-services fee appears anywhere in Stripe's published Terminal pricing, which is consistent with a self-integrate product — but Stripe never states an explicit $0 implementation line, so this reads as inferred from silence rather than published. https://stripe.com/pricing · retrieved 2026-08-02

Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.

commercial-data-export-self-serve

Payments, customers and payouts export self-serve through Dashboard CSV and the public API with no support ticket and no fee. Two caveats worth carrying: line-item, labour and menu data do not exist in Stripe to export, and full raw warehouse delivery requires the paid Data Pipeline add-on at $65.00/month. https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator

commercial-export-customer-and-loyalty

Shortfall: half the object is missing. Customer records and tokenised payment-method metadata are exportable, and Stripe supports PAN migration to another processor on request — genuinely strong on the payments half. There are no loyalty point ledgers, gift-card balances or offer histories to export, because Stripe ships none. https://docs.stripe.com/data/access-data-in-warehouse · retrieved 2026-08-01

Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator

commercial-post-termination-export-window

Positive evidence of absence, in the contract's own words: 'Upon termination of this Agreement, User's rights to use the Services and the Stripe Technology immediately cease. User must immediately cease accessing the Services and delete all license keys, access keys and copies of Stripe Technology.' No post-termination retrieval window is defined anywhere in the agreement. https://stripe.com/legal/ssa · retrieved 2026-08-02 adversarially verified

Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator

commercial-data-ownership-clause

Positive evidence of absence: the agreement runs the other way. The user 'grants to Stripe, on behalf of itself and its Affiliates, a perpetual, worldwide, non-exclusive, irrevocable, royalty-free license to use the Content to develop, improve, and provide Services and Stripe Technology', and Stripe and its affiliates 'own all IP Rights in the Services, the Stripe Technology, Stripe Data'. There is no clause affirming merchant ownership of their transaction data. https://stripe.com/legal/ssa · retrieved 2026-08-02 adversarially verified

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

commercial-source-available-selfhost

Positive evidence of absence: Stripe's client SDKs are open source, but the platform is proprietary hosted SaaS with no self-hosting option, and the agreement requires the user to 'delete all license keys, access keys and copies of Stripe Technology' on termination — the opposite of a source-available escrow. https://stripe.com/legal/ssa · retrieved 2026-08-02

Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.

commercial-pci-p2pe-tokenization

Shortfall: the mechanism is documented, the merchant's SAQ is not. Encrypted card entry on EMV-certified readers plus tokenisation is documented and Stripe is certified to PCI Service Provider Level 1, with point-to-point encryption sold as a +$0.05 per authorization add-on. Stripe does not name which SAQ (A, or P2PE-HW) the merchant becomes eligible for, which is the practical question a buyer is asking. https://docs.stripe.com/security · retrieved 2026-08-02

Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.

commercial-pci-dss-4-controls

Some controls are documented and enforceable; the version framing and the script-integrity half of the claim are not. WHAT IS DOCUMENTED. MFA on back-office logins: docs.stripe.com/security documents Dashboard support for passkeys, hardware security keys, TOTP and SMS, recommends passkeys or hardware keys, warns that SMS is vulnerable to SIM-swapping, and adds SAML 2.0 SSO with SCIM so authentication policy can be enforced at the identity provider; the cited support article documents the account-level toggle that makes it mandatory, with existing users forced to enrol at next sign-in and new invitees before joining. A Terminal-specific PCI control, readable only once the variant bodies were recovered: docs.stripe.com/terminal/fleet/reboot-time states 'Daily reboots are required for PCI compliance.' and that 'Stripe enforces a 24-hour maximum uptime for smart readers to ensure security patches and updates are applied regularly', adding that you cannot disable daily reboots. NAMED SHORTFALLS: (1) NO DSS VERSION IS EVER STATED - docs.stripe.com/security/guide says only that Stripe 'is certified annually by an independent PCI Qualified Security Assessor (QSA)' as a Level 1 Service Provider, and support.stripe.com/questions/pci-compliance-for-stripe-terminal routes the merchant to an SAQ C, or an SAQ P2PE, without naming a version. The regional compliance variants were the place a version would most plausibly be named, and they are now readable: the 41 per-country bodies of docs.stripe.com/terminal/payments/regional contain the token `PCI` zero times. (2) THE FUTURE-DATED SCRIPT-INTEGRITY REQUIREMENTS ARE NOT ADDRESSED AT ALL - the nearest thing Stripe publishes is a Content Security Policy directive list in docs.stripe.com/security/guide, an allowlist for loading Stripe's own frames and scripts, not the payment-page script inventory, authorisation and integrity monitoring 6.4.3 and 11.6.1 require. (3) THE DOCUMENTED MFA IS BACK-OFFICE ONLY - it covers Stripe Dashboard team logins, and the device-side control points the other way: docs.stripe.com/terminal/fleet/admin-menu-passcode, another page readable only from the variant bodies, documents reader administration as a single 5-digit passcode with a published default, 'The default passcode to access the admin menu on your smart reader is', account-level or per-location, role-gated but with no second factor. Verbatim: 'Stripe offers the option to require two-step authentication for every user on a team.' https://support.stripe.com/questions/require-two-step-authentication-for-your-team · retrieved 2026-09-11 adversarially verified

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

commercial-soc2-attestation

Stripe's security documentation states that 'SOC 1 and SOC 2 Type II reports are produced annually and can be provided upon request', and publishes a public SOC 3 report as a linked PDF covering internal controls over security, availability and confidentiality. ISO 27001 is not mentioned on the page and is not claimed here. https://docs.stripe.com/security · retrieved 2026-08-02 adversarially verified

Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.

commercial-privacy-dsar-tooling

Shortfall: contracts and an intake process, not in-product tooling. Stripe publishes executable DPAs (Stripe, LLC for the Americas, Stripe Payments Europe elsewhere) and documents a deletion-request intake path, but no in-product tool was found that lets a merchant locate, export or delete an individual guest's records to satisfy a DSAR on their own. https://stripe.com/legal/privacy-center · retrieved 2026-08-01

Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator

commercial-wcag-kiosk-accessibility

unknown rather than no. A `no` requires positive evidence of absence, and this absence is bounded to a corpus that Addendum 2 declares a FLOOR - the docs sitemap misses live pages and 397 of its entries are variant indexes - so it cannot establish that a document is not published. Two specific holes make that decisive rather than formal. First, support.stripe.com/questions/pci-compliance-faq affirmatively states that Stripe publishes its compliance documents behind credentials at dashboard.stripe.com/settings/compliance/documents, a document shelf this corpus cannot see and exactly where a conformance report would sit. Second, on audit 2026-09-11 stripe.com/accessibility, stripe.com/trust and stripe.com/legal/accessibility all 404, but trust.stripe.com answers HTTP 200 with a live shell whose Last-Modified is 2026-09-10; its JS bundle only redirects to stripe.com and its robots.txt returns an S3 AccessDenied, so that host is UNMEASURED rather than empty. What would settle this cell: a readable Stripe trust or compliance portal, or the gated compliance-documents shelf. Grade F, no url, because the value rests on a measurement rather than on any one document. || 321st: NEW PROBES, NO MOVE: Stripe OpenAPI spec3.json (stripe/openapi @706785daca8b, 419 paths): WCAG 0, VPAT 0, kiosk 0, screen reader 0. trust.stripe.com re-probed 2026-09-17: root 200 with a 238-byte shell, /robots.txt 403, nonsense path 403, so the host is still unmeasured (a refusal, not an absence). stripe.com/accessibility and stripe.com/legal/accessibility 404; docs.stripe.com guessed .md slugs terminal/features/accessibility, payments/checkout/accessibility, elements/accessibility all 404 (guessed slugs, not evidence of absence). Also recorded: under the 321st merge policy the claim scopes self-order kiosk and consumer web-ordering surfaces, and this record scores Stripe as publishing no first-party ordering channel, so this is a hold-unknown, not a no. Retrieved 2026-09-17. || 329th: 329th, NEW SURFACES, NO MOVE, plus one measurement that retires the 'trust.stripe.com is UNMEASURED' hole. (1) trust.stripe.com re-fetched with curl + browser UA: the root is a 238-byte Vite shell loading /index-kn153rri.js, which is 852 bytes and whose entire behaviour is `window.location.href="https://stripe.com"` (its sourceMappingURL points at the internal sourcemaps.corp.stripe.com). The host is therefore MEASURED and holds no document shelf - it is a redirect stub, not a trust portal; the S3 AccessDenied on its robots.txt is bucket config, not a bar naming us. stripe.com/accessibility, /legal/accessibility and stripe.com/sitemap.xml all return the same 370,272-byte 'Page not found' shell as a nonsense path, i.e. soft-404s on a catch-all. (2) A 100% census of support.stripe.com (1,830/1,830 sitemap /questions/ pages at HTTP 200, 4,072,325 bytes, 404 nonsense control distinct) plus the complete docs.stripe.com/terminal section (100 .md pages, 1.2 MB): wcag 0, vpat 0, conformance 0, 'screen reader' 0, 'section 508' 0, tactile 0, accessibility 2 across the whole support KB; positive control payment 6,182. (3) What Stripe DOES publish on accessibility is device-level and is in the reader release notes, not a conformance report: "Added support for Accessible PIN payments" and "Fixed a bug where accessibility mode didn't read out the 'Incorrect PIN entered' message" (2024-07 firmware) and "Fixed the text size and made copy changes and UI modifications for AAA accessibility compliance" (2024-03), on both docs/terminal/readers/stripe-reader-s700-s710 and docs/terminal/readers/bbpos-wisepos-e; the S700/S710 spec table lists "Audio jack | Supported". (4) The kiosk scope is confirmed third-party: questions/using-terminal-in-attended-semi-attended-and-unattended-retail-environments describes Terminal readers being placed in someone else's kiosk ("Self-service kiosk with roaming employees nearby", "standalone kiosk at a quick-service restaurant") and names the Verifone UX700 as "the only unattended device offered through Terminal" - Stripe supplies the payment device, not the self-order or web-ordering UI the claim scopes. Held unknown (no first-party kiosk/ordering surface to conform, and the ACR shelf Stripe says it keeps at dashboard.stripe.com/settings/compliance/documents is credentialed), not no. Retrieved 2026-09-18. adversarially verified

POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator

commercial-dual-pricing-compliant

Two of the claim's three parts are documented and the third is half-implemented. (1) A compliant surcharge engine exists on the PaymentIntent through amount_details.surcharge, with a Stripe-enforced maximum_amount and a published per-country cap table (United States 3 percent, Canada 2.4 percent, Australia 4 percent, New Zealand 4 percent). (2) Automatic debit and prepaid exclusion is genuinely automatic: the page documents the surcharge.status attribute as indicating whether surcharging is available based on the country and the funding type of the payment method, and the United States and Canada rows of the availability table read 'Credit cards only'. That this is live card-present rather than card-not-present only is corroborated by docs.stripe.com/use-stripe-apps/oracle/simphony/overview, which lists 'Collect surcharges' among the actions its Stripe Terminal app performs. (3) Disclosure is the shortfall. Stripe implements the receipt half only for its own prebuilt receipts, as the quoted sentence shows, and the card-network receipt field table on docs.stripe.com/terminal/features/receipts — the fields Stripe supplies for compliance-ready in-person receipts — contains no surcharge field. NAMED SHORTFALLS: (a) menu-board and pre-purchase disclosure is assigned to the merchant rather than implemented, the compliance list requiring the merchant to 'Conspicuously disclose surcharge amounts that apply to each transaction and the total costs to the cardholder ahead of purchase'; the only Stripe-implemented pre-purchase surface is a JavaScript SDK reader consent screen carrying a message the integrator writes; (b) the engine is a public preview gated on 'Your integration must be on API version' 2026-03-25.preview; (c) the network cap is defeasible by the integrator, since passing enforce_validation as disabled removes the maximum_amount validation entirely; (d) proportional refund of the surcharge is left to the integrator to implement. Verbatim: 'Stripe prebuilt receipts automatically display the surcharge. If you build custom receipts, show the applied surcharge amount separately.' https://docs.stripe.com/payments/cards/surcharge · retrieved 2026-09-11 adversarially verified