#Payments, fiscalisation, privacy and security

This document is the single place compliance numbers live. Where another doc quotes a fiscal cost, a PCI scope, a lawful basis, a payments bps figure or a regulatory fine amount (§4.2), it must match this file. Deviations belong in 08 — Pros, cons, difficulties and risks, not here.

Label key: [verified] = checked against a live source on 2026-08-18 · [known] = training data ≤ May 2026 · [estimate] = reasoned guess. Legal-confidence key on every legal claim: H = statute/primary source read, low interpretation risk · M = statute known, application to our fact pattern untested · L = inference, needs counsel before it is relied on.

TL;DR

• We never touch a PAN, ever. Semi-integrated only, Stripe Terminal (S700 + S710), zero EMV L2/L3 work forever. Our merchants land on SAQ B-IP, not SAQ P2PE — every "P2PE" claim is struck from sales material today (Stripe is not on the PCI SSC P2PE listing) [known] H. We self-assess as SAQ D-Service Provider with evidence collection starting month 1, because v4.0.1 wants ~12 months of continuous operational evidence and the first chain deal will ask [verified] H.
• Payments SaaS economics do not save us; the payments contract does. The rail is Stripe Terminal; the money is a separate ISV/referral agreement (Viva.com first, then Nexi/Worldline/Global Payments via ČSOB-KB/Nuvei/Adyen). A2 is a hard gate: ≥25 bps residual, no merchant-ownership clause, in writing, at P0 exit — or stop. We never become a payfac (break-even ≈ EUR 333M TPV; PSD3/PSR applies H2 2027–early 2028) [verified] H.
• Czechia is the only market in v1 because it is the only market with zero fiscalisation and zero producer liability. EET abolished 1 Jan 2023 [known] H. The binding rule everywhere else: enter only markets whose time-to-first-legal-invoice is under 60 days. That permanently excludes Spain — RD-ley 15/2025 postponed the taxpayer dates, not the 29 Jul 2025 producer deadline, and LGT art. 201 bis fines the producer [verified] H.
• Buy the fiscal signing layer, and say why in the risk register: co-defendant risk transfer, not price. FiscalProvider is ours; fiskaly / Deutsche Fiskal / EFSTA sit behind it in every signing market; UA goes through Checkbox or Vchasno so we never hold a merchant's КЕП key; PL drives a GUM-homologated kasa-online printer (Posnet/Elzab/Novitus), never our own GUM certification.
• The CRM's highest-volume capture channel is a legal question, not an engineering one. A neutral "join here" line inside a transactional e-receipt is assumption A4 (CZ counsel, EUR 3–5k, due M2). It is already assumed unlawful in Poland under PKE art. 398, where fines scale to 3% of the sender's prior-year turnover or PLN 1,000,000, whichever is higher [verified] H. PL e-receipts are fiscal-only, and we never aggregate one Viber/SMS sender across PL tenants.
• Two guaranteed production failures, budgeted now, not later: SCA soft-declines (online_or_offline_pin_required) appear at ~1:1 with successful PIN transactions and will manufacture double charges if rendered as "failed" [verified] H; and in the CEE beachhead the PIN path is the common path, not the fallback (CZ no-CVM floor ≈ CZK 500 / ~EUR 20 against a EUR 8–12 café ticket) [known] M.

#1. Payments architecture

#1.1 The invariant

One PaymentTerminal port. Adapters: stripe-terminal (v1), adyen-terminal-api (hedge), ua-mono, ua-privat (P3). Check flow logic never branches on provider. Zero PAN in any API surface, log, ticket, screenshot or backup — enforced by an edge validator (reject Luhn-passing 13–19 digit sequences), a log-shipper scanner, a second scanner in the SIEM, and a CI test that fails the build on a leaked test payload.

Stored on payment_method: provider, provider_token, network_token_id, par (nullable), network_transaction_id, fingerprint, last4, brand, exp_month, exp_year, issuer_country, funding_type. Never pan, never cvv, never track data. Note last4 + expiry + name is not cardholder data under PCI but is personal data under GDPR (§6) H.

Topology: semi-integrated, server-driven with a local SDK fallback. Our backend creates the PaymentIntent; the reader owns the card data and the host link. Latency 1.5–4 s local, 3–7 s cloud [estimate].

#1.2 Card sale with tip (the canonical flow)

Non-negotiables visible in that diagram (canon §3.1 invariants 6, 7, 8): the local write and the outbox row are in one transaction; payment_attempt has an explicit unknown state that is never rendered as "failed"; the idempotency key is {check_id, attempt_seq}; the acquirer transaction reference is persisted forever; terminal ownership is a lease carrying the same durable monotonic epoch as print dispatch, reconciled nightly against the PSP by idempotency key.

#1.3 The flows that break naive integrations

Reconciliation is the hidden cost. Three-way match (Check ↔ terminal journal ↔ acquirer settlement) with tip-on-terminal rows, cash rounding on the residual tender, offline Checks landing hours late and phantom soft-declines. r02 budgeted 2.5 eng-months; c02 corrects to 4.5–6.0 for two acquirers, and it never finishes [estimate]. Canon absorbs this inside Domain E.

#2. Acquirer and terminal decision, per market

Recommended default: Stripe Terminal, two SKUs (S700 + S710), semi-integrated, plus a separately negotiated ISV/referral agreement for the economics. Reasons, in order: one SDK across every market we will ever enter under the 60-day rule; Stripe holds L2/L3 for the whole estate so our EMV certification cost is permanently zero; Stripe does not sell restaurant POS — SumUp does (Goodtill/Tiller/Shore), which is why SumUp Cloud API is a retention adapter at best and never the primary rail.

Two structural facts that constrain the choice:

Germany's girocard adds three problems the DE decision must carry (all [verified], H): (1) girocard has no native refund — Stripe refunds by SEPA transfer to the IBAN behind the card, which can fail if the account is closed, so refund_pending_sepa / refund_failed are real terminal states plus a remediation workflow and cashier copy (+0.75–1.0 eng-months); (2) no S710 in DE, so the hardware matrix is permanently two SKUs; (3) girocard does not support off-session payments, so SetupIntents route to the international network — one German Guest generates a girocard in-store authorisation and an international-network card-on-file token, and no PSP fingerprint will unify them. Only PAR could, and it is not established that a domestic girocard authorisation carries one.

Never: true payfac (EUR 1.0–1.6M year-one cost, 18–30 months, break-even ≈ EUR 333M TPV ≈ 400–600 sites) [estimate]; own EMV L3 (USD 120k–250k, 18–24 months per scheme per acquirer per region) [verified]; any conversation containing the phrase "your L3". Domestic-rail ECR/POI certification is not free either — c02 corrects r02's 0.75 eng-months to 2–4 eng-months and 3–6 months wall clock per acquirer per country, because you are queuing for a bank's quarterly certification window [estimate].

Unmodelled payments liabilities to price before P3 (A23): sub-merchant KYB stalls 10–20% of SMB applications, rejects 2–5% [estimate] — a signed Customer who cannot take cards for 9 days is a churn event; and under a platform-liable model, merchant negative balances and chargebacks land on us at EUR 15–40k/yr at 300 sites [estimate] given a 4–8%/yr restaurant failure rate. Both need an ops owner, not an engineer.

#3. PCI DSS v4.0.1 scope statement

All assessments in 2026 are against v4.0.1. The 51 previously future-dated requirements became mandatory 31 Mar 2025; all 64 new/changed requirements are in scope and expect ~12 months of continuous operational evidence [verified] H.

SAQ P2PE is not achievable with this stack and is struck from every document and sales asset (canon §3, A19). Only a solution on the PCI SSC P2PE listing entitles a merchant to SAQ P2PE; Stripe is not on that listing [known] H. Vendors market "P2PE-grade" without a listing. For every acquirer we sign, demand the PCI SSC listing URL and the P2PE Instruction Manual, or plan for B-IP.

What we must do

1. Start SAQ D-SP evidence collection in month 1 — logging, key management, change-control records, quarterly ASV scans, annual pen test, segmentation testing. You cannot buy 12 months of evidence in the quarter a chain asks.
2. Ship a network posture as a field-services deliverable, not a checklist: terminals + KDS + printers on a dedicated VLAN/SSID off guest Wi-Fi. Canon already makes the Teltonika RUT241 router and a validated AP a hard requirement of the install — that is the PCI segmentation story and the peer-sync story in one line item (see 03 — Hardware, peripherals and the device fleet).
3. Get a written QSA scoping opinion (EUR 5–10k) before the first Apps-on-Devices deployment, not after (A19). PA-DSS retired 28 Oct 2022 and was replaced by the PCI Software Security Framework; "our app runs on the payment terminal" is exactly the fact pattern where an assessor or an enterprise procurement team invokes it [known] M.
4. Bind Tech E&O + Cyber, EUR 1–2M limit, EUR 8–25k/yr before Customer #1 (A18) [estimate]. It is a procurement gate for any chain — and it never covers producer-side fiscal fines.

What we must never do

• Never accept a keyed PAN in our UI. Any MOTO/phone-order requirement is entered on the PIN pad, or the feature does not exist. This is an institutional rule, not a code-review preference: one careless field converts SAQ D-SP into a CDE.
• Never store PAN, CVV or track data. Never put a card number in a support ticket, a screenshot, or a log line.
• Never claim P2PE, "PCI compliant" without naming the SAQ, or "we're out of PCI scope".

#4. Fiscalisation

#4.1 The rule that generates the market list

Enter only markets whose time-to-first-legal-invoice is under 60 days.

Under S1, a market whose certification calendar exceeds the remaining runway is disqualified, not expensive. The failure mode is precise: start certification at month 12, spend 9 months of authority calendar, reach first revenue at month 21 with 3 months of runway — and you cannot pivot, because the dossier binds a software version you may no longer deploy over.

#4.2 The table

Cost = cash to first legal invoice, excluding our engineering. Eng-months are for that market's fiscal work only and sit inside canon Domain F.

Penalty exposure — the three figures the risk register quotes. These are the only fine amounts anywhere in the deliverable; they live here and 08 — Pros, cons, difficulties and risks cites this table rather than restating them. Each carries a legal-confidence grade and a named owner who must close it before the figure is used in a contract, a board pack or an investor deck.

None of these are insurable. Tech E&O (§8) covers neither a producer-side fiscal fine levied on us nor a regulatory fine levied on a Customer by our defect. The ES row is the reason Spain is a permanent exclusion rather than a deferral; the DE and FR rows are why the signing vendor sits in the chain as a co-defendant.

#4.3 Recommended market sequence

Buy the signing layer. The argument is co-defendant risk transfer, not price. Spain fines the producer; France makes a false attestation the éditeur's liability; BE/PT/SK bind the certificate to us. A middleware vendor with its own certification in the chain is a named party in any dispute. At EUR 10–15/register/month in DE/AT that is 15–25% of a EUR 59/month subscription price (subscription-only, per canon §5.4 — not a blended or total-recurring figure) [verified] on the EUR 10–15 input — which is why Germany is priced at EUR 89–129, never EUR 59. Reconsider building per country only above ~2,000 registers.

The certification mechanics nobody budgets (relevant the moment we ever enter a certifying market): elapsed ≈ 3× engineering time; the dossier is 40–150 pages of a senior engineer's writing (3–6 weeks) plus EUR 8–25k local counsel and a named 12-month relationship owner; and the certificate names a software version. That is why canon invariant 12 exists: fiscal logic lives in a slow-release, separately-versioned module, architecturally isolated from the fast app (see 02 — System architecture).

#4.4 The five gates before we quote a German date

All five true, or no date: (1) girocard live on S700 in production; (2) refund_pending_sepa / refund_failed states and cashier copy shipped; (3) DSFinV-K 2.3 export passing a real conformance test; (4) a signed fiskaly or Deutsche Fiskal contract; (5) a written insurance position. ~5 eng-months plus 6–8 weeks of vendor onboarding. Germany's permanent 7% VAT on all Speisen from 1 Jan 2026 is a genuine reason to talk to every operator — but it is a reason to be ready, not early.

#4.5 The unpriced liability: the fiscal archive after churn (A24)

Nothing in the research models it. If we hold a merchant's fiscal records, in Germany we sit inside their §147 AO retention duty (8–10 years) and their Verfahrensdokumentation; in France we hold the signed archives; in Ukraine we may hold their КЕП. A churned Customer's data cannot simply be deleted at contract end. Define and price a handover artefact and an export format before Customer #1, or we inherit a decade of unbounded availability obligation per churned merchant [estimate] M.

#5. VAT, eat-in vs takeaway, and Receipt rules

The universal data-model mistake is one VAT rate per product. The rate is f(item, channel, packaging, temperature, container, on-premise?, customer_type, date). Canon invariant 2: unit_price_minor, tax_rate_bp and menu_snapshot_id are snapshotted onto the Line at order time and never recomputed. (The field is menu_snapshot_id, matching the Menu Snapshot entity in canon §6 and the schema in 02 — System architecture; "menu version" is not a schema name.)

Service Charge vs Tip is a schema decision, not a label. A voluntary Tip is outside the scope of VAT; a mandatory Service Charge is part of the taxable consideration and is VAT-able [known] H. They are distinct, non-convertible entities from commit one (canon §6). If both are called "tip", every Customer's VAT return is wrong simultaneously.

Germany's tip nuance is sharper than "make it a config field" (relevant only at DE entry): §3 Nr. 51 EStG exempts amounts paid voluntarily by a third party to the employee. Passing through the employer's account does not by itself destroy the exemption — pooling does. The moment the employer runs an allocation scheme, entitlement derives from the employer, not the Guest, and it is wages: payroll tax, social contributions, employer withholding liability. Offering tip pooling in Germany is offering a payroll-tax event. Either hard-disable pooling in DE, or generate a payroll export that treats it as wages [known] M — re-verify with a German Steuerberater before any DE tips feature ships. This is a second reason canon ships tip capture and per-employee attribution only, never distribution.

Receipt rules. The Receipt renderer is a per-country template engine with a golden-file test suite, not string concatenation (~1.5 eng-months framework + ~2 eng-days per country). Every country requires at minimum: merchant name + tax ID, date/time, sequential document number, per-rate VAT breakdown, Tender method. CZ adds nothing fiscal — which is the whole point of CZ. UA adds the PRRO fiscal number and QR. PL's paragon is printed by the homologated printer, not by us.

Two renderers, gated on consent state. This is a real feature nobody costed until c02: a fiscal-only template with zero promotional content, and a promotional template carrying the join invitation. Poland and Germany get fiscal-only, always. +0.5–0.75 eng-months [estimate].

Canon invariants that bind the Receipt (see 02 — System architecture): Fiscal Document numbers are allocated only by the certified fiscal component, never by application code; Check numbers come from Coordinator-leased blocks; kitchen Ticket numbers are cosmetic; Business Day is leased from the Coordinator and a Device more than 5 minutes from Coordinator HLC-physical time may take orders but may not close or tender; the fiscal adapter refuses to sign outside a trusted-time threshold; rendered ticket bitmaps are never persisted beyond a 24h retry window.

#6. GDPR and ePrivacy design

#6.1 Controller model

Model A: per-tenant silo. The Customer (restaurant Org) is controller; we are processor under an Art. 28 DPA. The schema is partitioned so a consumer-network model (B) is addable, via a nullable network_identity_id, but cross-brand network behaviour is never built in v1–v2 (canon). Silently sharing Guest data across Orgs would be an unlawful disclosure in several EU DPAs' view H — and a commercial betrayal that surfaces in every chain's security review.

#6.2 Lawful basis, per processing purpose

Art. 7(4) — the loyalty-discount problem, structured in three layers: (1) join = contract, Art. 6(1)(b); points and Member prices are the consideration, and this is allowed to be conditional. (2) Marketing consent = separate, optional, unbundled, per channel and per purpose — and the Member discount must not depend on it. (3) Profiling = a third, separate consent. A Member who ticks nothing still earns points and still receives transactional messages. Get layer 2 wrong and several EU DPAs invalidate the consent retroactively, which invalidates every campaign already sent H.

Also required from day one: Art. 30 records of processing, a subprocessor register, and an Art. 35 DPIA — systematic profiling of Guests at scale is a plausible trigger (EUR 3–8k external counsel per major market) [estimate] M.

#6.3 Consent capture at the counter

The Consent Record is append-only (never UPDATE), stores the SHA-256 of the exact wording shown plus locale and ui_surface, keeps withdrawal proof as carefully as grant proof, and chains via prev_record_id. Every outbound message checks consent at send time, not at audience-build time — a 4-hour-old Audience can contain someone who unsubscribed 3 hours ago.

Provenance suppression (canon invariant 11): the migration importer sets marketing suppression by provenance, and the segment builder cannot clear it. Concrete failure this prevents: a restaurant migrates from Dotypos, we import 18 months of Glovo Orders, the segment builder includes them, the first winback SMS goes to people who only ever ordered through an aggregator — an unlawful-processing complaint with the Customer's name on it and our infrastructure underneath.

#6.4 Erasure across offline Devices

This requirement dictates the sync architecture; retrofitting it into an immutable event log is a rewrite, not a sprint.

Rules that make this defensible: erase vs pseudonymise — financial event rows survive (Art. 17(3)(b) + tax law); we null the guest_id FK and delete the Identity and Profile rows, which works because canon invariant 9 already puts Guest PII in a separate crypto-shreddable store keyed by guest_id, with the financial event log holding only guest_id. Suppression lists survive erasure (documented in the privacy notice; deleting them means the person gets marketed to again). Backups are excluded from immediate erasure, purged by rotation within N ≤ 35 days, with erasure re-applied on any restore — write that in the DPA. Erasure is Org-scoped: a request to Brand A must not touch Brands B–L.

Effort: r06 said 3.0 eng-months; c02 corrects to 5–6 because it touches the sync core, the fiscal store, the analytics replica, the ESP and every terminal [estimate]. It is inside canon Domain G, and it is the item every EU chain's security questionnaire asks about.

#6.5 Retention schedule

#6.6 DSAR flow

Art. 15/20 export = one JSON + one CSV: Profile, Consent Records with the exact wording shown, loyalty ledger, transaction summary, and campaign sends with the reason the Guest was targeted (Audience name + rule). Target: ≤24h automated, statutory ceiling 30 days. The same export code, run in reverse, is the EU Data Act switching/exit artefact (Reg. (EU) 2023/2854, applicable 12 Sep 2025, switching charges withdrawn by 12 Jan 2027) [known] H — build it once, ~0.5–1.0 eng-months.

DORA (Reg. (EU) 2022/2554, applying since 17 Jan 2025) [known] H: we are not a financial entity, but every EU PSP now pushes Art. 30 contractual clauses onto ISVs in their service chain — register of information, audit and access rights, exit strategy, incident-reporting timelines, subcontracting restrictions. It is a standard blocker in PSP onboarding today. First-time cost EUR 8–20k counsel + ~0.5 eng-months [estimate]. It belongs in P0, not in a later phase.

#7. Security programme

#8. Compliance cost roll-up (canonical)

Engineering effort lives in canon §5.1 and is restated here so no other doc re-derives it. AI-assist multipliers are already baked in (E/F/G legal-and-correctness rows compress by 0–10% only; certification queues, field install and trust compress by 0%).

Read the v2 delta column as the full v2 delta — the S2 figure. Under S1, P3 ships v2 core only (T2 LAN multi-station, UA PRRO, PL kasa-online + KSeF + JPK_V7M, guest ordering + QR PWA + Wallet passes, card-linked identity, Brand Vouchers, WhatsApp/Viber, segmentation and the payments-attach machinery); table service, handheld, customer-facing display, Apps-on-Devices, the HubRise-resold delivery module and DE+AT fiscal move to v3 (P4 and later). So of Domain F's +11.0, the DE+AT ~4.5 (§4.3) sits in v3, leaving the UA (1.75) and PL (3.5) market lines plus the shared receipt/compliance framework work inside S1's P3. See 07 — Roadmap, Team and Budget for the phase arithmetic.

One tension, stated rather than smoothed: Domain E's 11.0 (S1 cut) must simultaneously carry reconciliation at 4.5–6.0 (§1.3) and the PCI programme at ~1.2 eng-months/yr, which leaves 2–3.5 for the terminal port, Stripe adapter, splits, voids/refunds, tips capture and tokenisation. It fits only at the bottom of both ranges. Flagged for the P0 re-plan, not resolved here.

A 10-country European footprint carries 2.5–3.0 FTE of permanent compliance engineering. Under S1 that is mathematically impossible past three or four countries. This, not market size, is why the plan is CZ → UA → PL. See 07 — Roadmap, Team and Budget for how that lands in the phase plan and 01 — Feasibility verdict for the go/no-go.

#9. Standing "verify with local counsel before commit" list

Nothing below may be relied on in a contract, a sales claim or a schema decision until the named owner closes it. Each maps to a canon assumption where one exists.

Related: 01 — Feasibility verdict · 02 — System architecture · 03 — Hardware, peripherals and the device fleet · 05 — The CRM Product and Scope Tiers · 06 — Integrations · 07 — Roadmap, Team and Budget · 08 — Pros, cons, difficulties and risks