#c02 — Compliance reality check: payments, fiscal, privacy, partner terms
Reviewer stance: payments/compliance operator who has taken POS live in several EU countries. This attacks r02, r03, r06, r07 specifically.
Date: 2026-08-18. Label key: [verified] = checked this session with a URL · [known] = training data ≤ May 2026 · [estimate] = reasoned guess.
#Verdict
The fiscal research (r03) is the strongest document in the set and its two headline 2026 claims — the French reversal and the Spanish delay — both survive verification. The payments research (r02) is directionally right on the big calls (never a payfac, never L3, semi-integrated only, EU margin is ~1/3 of US) but its two self-declared blockers are both wrong: Stripe does support girocard in Germany, and S700/S710 are available across the CEE beachhead. In exchange it missed three girocard-specific problems that are worse than the one it was worried about. The privacy research (r06) contains the single most dangerous design in the whole corpus — using a transactional receipt SMS as the primary marketing-consent capture channel — which is unlawful as specified in Poland, the largest EU market in the beachhead, and it contradicts its own §6.2 table. Spain is not a "rare arrive-compliant opportunity": the delay applied to taxpayers, not to software producers, and we are the producer.
Roughly 80% of this research survives. What does not survive is concentrated in exactly the places that convert a plan into a liability: producer-side fiscal exposure in Spain, consent capture in Poland, the PSP choice being made on payments criteria when it is actually a CRM criterion, and an S1 market list that still contains markets whose certification calendar is longer than the runway.
#Corrections (claim → correction → confidence)
#C1. Spain — "a rare arrive-compliant opportunity" is wrong for us specifically
| Claim | r03 §2.5, §9 rank 7: Verifactu moved to 1 Jan 2027 / 1 Jul 2027, "we have a full extra year, and a rare chance to be compliant on day one rather than retrofitting". ES compliance cost EUR 0 cert + EUR 3-6k legal review. |
| Correction | The taxpayer dates moved. The producer obligation did not. RD-ley 15/2025 postponed the obligation on obligados tributarios; producers and commercialisers of invoicing software retain the 29 July 2025 deadline to offer fully adapted products [verified, multiple ES tax sources 2026-08]. Combined with LGT art. 201 bis, which fines the producer per product per exercise, this means: from today, offering a non-compliant invoicing product into the Spanish market is already the sanctionable act, regardless of whether any customer is yet obliged to use it. |
| Consequence | Spain flips from "rank 7, defer, arrive compliant in 2027" to "do not sell one licence in Spain until RD 1007/2023 conformance is built and a Spanish counsel opinion is signed." The declaración responsable is not a formality; it is the artefact the fine attaches to. r09 already reached this conclusion from the insurance angle; r03 did not. |
| Confidence | High on the producer date and its non-postponement. Medium on how AEAT treats a non-resident producer selling remotely — must be re-verified with Spanish tax counsel before any ES activity, including a website that offers the product in Spanish. |
#C2. Germany — Stripe Terminal does support girocard. The blocker is dead; three new ones replace it
| Claim | r02 §2.3, §9, open question 1: "Stripe does not support girocard acceptance [known, verify] — if true this is disqualifying for Germany on its own", blocking DE go-to-market, +6-10 eng-weeks for a Nexi/Concardis ZVT adapter. |
| Correction | [verified, docs.stripe.com/terminal/payments/regional?integration-country=DE]: Stripe supports girocard in Germany on BBPOS WisePad 3 and Stripe Reader S700. The WisePOS E does not support girocard (it falls back to the Visa/Mastercard co-badge). No ZVT adapter is required. Delete the DE blocker and the 6-10 eng-weeks. |
| New problem 1 — refunds | "The girocard network doesn't natively support refunds. As a workaround, Stripe sends the refund by SEPA transfer to the customer's bank account, using the IBAN associated with their girocard… the refund might fail — for instance, if the customer closes their bank account" [verified, same page]. r02 §3.4's entire refund model (referenced refund, persist the acquirer reference forever, batch boundary) does not describe Germany's dominant debit rail. You need new terminal states (refund_pending_sepa, refund_failed), a remediation workflow, and cashier-facing copy that says "the guest will see this in 1-3 business days by bank transfer". +0.75-1.0 eng-months on top of r02 item 7, plus a permanent support class. |
| New problem 2 — no S710 in Germany | The DE smart-reader roster is WisePOS E + S700 only [verified]. S710 is not available in DE. So the single-SKU Apps-on-Devices plan is at minimum a two-SKU plan (S700 for DE/PL/CZ, S710 where S700 is absent). Contradicts r01's "certify a short list" cost model by one extra device family in the lab and in spares. |
| New problem 3 — identity | "SetupIntents… are always routed to the international network. This is because girocard doesn't support off-session payments" and co-badge routing is per-transaction and cardholder-overridable (card brand choice) [verified]. So one German guest generates a girocard-network in-store authorisation and an international-network card-on-file token. A PSP fingerprint is network/token-scoped; r06 §1.3's rule "same PSP fingerprint and both card-enrolled → 0.92, auto-merge" will silently fail to unify a German guest's in-store and online payments. Only PAR could unify them, and it is not established that a domestic girocard authorisation carries a PAR at all. Must be verified before promising card-linked identity in DE. |
| Confidence | High (primary source, fetched this session). |
#C3. CEE reader availability — r02's open question 4 resolves, but not into one SKU
Claim: r02 §2.2 caveat and open question 4 — WisePOS E documented only for 10 Western markets; "if S700/S710 are also unavailable in CEE, the Apps-on-Devices single-device strategy collapses there."
Correction [verified, Stripe regional availability table, 2026-08-18]:
| Countries | Smart readers available |
|---|---|
| PL | WisePOS E, S710, S700 |
| AT, CH, CZ, DK, FI, LU, PT | WisePOS E, S710, S700, Verifone V660p/UX700/P630 (public preview) |
| DE | WisePOS E, S700 only |
| FR | S710, S700, Verifone (private preview) — no WisePOS E |
| RO, SK, SI, HU, BG, HR, EE, LV, LT | WisePOS E, S710 only — no S700 |
| BE, IT, NL, NO, ES, SE | WisePOS E, S710, S700, Verifone (public preview) |
Apps-on-Devices survives everywhere in the beachhead. But the hardware plan is S700 + S710, not one device, and Czechia has the widest roster in CEE while Romania has the narrowest. Confidence: high.
#C4. PAR — Adyen exposes it, Stripe does not appear to. This inverts the PSP recommendation
| Claim | r02 §2.3/§8: Stripe Terminal for EU from phase P1 (months 6-14); Adyen deferred to P3 (months 26-40) "only when a 20+ site chain demands it". r02 §4.6 and r06 §1.5 both call PAR availability a gating question "worth more than 20 bps". |
| Correction | [verified, docs.adyen.com/unified-commerce/collect-data]: Adyen returns PAR for Visa and Mastercard "when available", for e-commerce and for Terminal API payment and card-acquisition requests, once enabled under Developers → Additional data. Stripe's card_present object documents fingerprint and network_transaction_id; no payment_account_reference field is documented [verified — absence of documentation, not proof of absence; a sandbox test settles it in one day]. |
| Consequence | The PSP decision is a CRM decision, not a payments decision. r06 says the CRM is "the only defensible part of this product"; r07 says identity coverage (10-25% vs 45-70%) is the entire business case for owning the POS; the primitive that unifies a physical tap, an Apple Pay DPAN and a card-on-file token is PAR. If Stripe does not emit it, choosing Stripe on payments ergonomics quietly caps the defensible half of the product at per-PSP fingerprints that break on migration and do not unify wallets. Either run the sandbox test in week one, or start on Adyen. |
| Confidence | High on Adyen. Medium-high on Stripe's absence. Cheap to resolve — do not architect around it unresolved. |
#C5. Poland — the CRM's primary consent mechanism is unlawful there as specified
| Claim | r06 §2.3: "capture identity at the POS, then move the consent step to the guest's own device via the transactional SMS/email you just earned the right to send. 'Here's your receipt. Tap to join |
| Correction | Poland's PKE art. 398 prohibits using terminal equipment and automated calling systems to send commercial information, including direct marketing, to a subscriber or end user without prior consent, with consent meeting GDPR standards [verified]. There is no soft opt-in. An SMS whose payload is "join the club — first coffee free" is informacja handlowa; the receipt was the lawful basis for the receipt, not for the invitation. The fine is imposed by the President of UKE and can reach 3% of the sender's prior-year revenue or PLN 1,000,000, whichever is higher [verified]. |
| Internal contradiction | r06 §6.2 already says "Poland's PKE… tightened direct-marketing consent. Treat PL as consent-only". §2.3 then builds the capture model on the opposite assumption. Nobody reconciled them. |
| Consequence | (a) In PL and DE the e-receipt must be a fiscal-only template with zero promotional content; the join invitation moves to the paper receipt QR (r06 rates that at 1-4% scan, ~50% completion), the CFD, or the guest's own ordering session. (b) The 52% blended capture figure in §2.2 is optimistic; a PL-legal version is closer to 35-42% [estimate]. (c) The product needs two receipt renderers gated on consent state — a real feature nobody specified. |
| Confidence | High on the statute and the penalty. Medium on whether a strictly neutral "you can join here" service line survives — that single question is worth a EUR 3-5k Polish counsel opinion and it decides the economics of the highest-volume capture channel. |
#C6. Poland — the virtual cash register question resolves positively
Claim: r03 open question 1 calls "is gastronomy still on the kasy wirtualne list?" the single highest-value unknown in the document.
Correction: Gastronomy and accommodation are on the permitted list under the Rozporządzenie MF of 26 May 2020; GUM performs the certification; the catalogue expands again from 1 Apr 2026 (vending, self-service devices, e-parking) [verified, PL tax/industry sources 2026-08]. The software route is open. What does not change: GUM certification remains a real gate (r03's PLN 50-150k / 6-12 months [estimate] is plausible), and the certificate binds a software version — the same continuous-deployment conflict as FR/PT/BE. Confidence: high on eligibility, unchanged (unverified) on cost and elapsed time.
#C7. Ukraine payments revenue is zero for us, not EUR 410/site/yr
Claim: r02 §7.1 models Ukraine at ~EUR 8.2k/yr net payments gross profit on a 20-site chain, EUR 410/site/yr, 0.14% take.
Correction: In the recommended UA architecture the merchant contracts directly with monobank or PrivatBank; we integrate a terminal, we are not in the money flow, and neither bank publishes an ISV referral programme [known]. Our UA payments revenue is EUR 0 unless a referral agreement is negotiated, and the table's interchange/scheme/provider rows are the bank's P&L, not ours. This does not change r02's conclusion (it strengthens it) but it removes EUR 8k/yr from any UA model built on that table. Confidence: high on the structure; the NBU cap figures (Law 3498-IX) remain unverified for 2026 and are not load-bearing once our share is zero.
#C7b. Germany tips — §3 Nr. 51 EStG is more nuanced, and the nuance is the product decision
Claim: r02 §3.1/§6.2 and r03 §4: "Tips routed through the employer's bank account become taxable wages (§3 Nr. 51 EStG exempts only tips given directly by the guest to the employee)."
Correction: §3 Nr. 51 exempts amounts paid voluntarily by a third party to the employee, in addition to the amount owed for the service [known]. Passing through the employer's account does not by itself destroy the exemption — the employer can act as a mere paying agent provided each amount is attributable to an identifiable employee and the employee has the claim. What kills the exemption is pooling. The moment the employer runs an allocation scheme (tip-out matrices, role weightings, kitchen shares), the employee's entitlement derives from the employer, not the guest, and it is wages: payroll tax, social contributions, and the employer becomes liable for the withholding.
Product consequence, which is sharper than "make it a config field": in Germany, offering tip pooling is offering a payroll-tax event. The product must either (a) support only direct attribution in DE, with pooling hard-disabled and an explanatory tooltip, or (b) support pooling and generate a payroll export that treats it as wages. Shipping a global "tip pool" feature that a German operator can switch on without warning is how you create simultaneous tax liability across your whole German base. Confidence: high on the mechanism, must be re-verified with a German Steuerberater before any DE tips feature ships.
#C7c. Contactless CVM limits are national-currency amounts, and CEE limits are much lower than EUR 50
Claim: r02 §3.7 table: EEA no-CVM contactless limit EUR 50 per transaction, EUR 150 or 5 consecutive cumulative.
Correction: RTS Art. 11 sets the exemption ceilings; the operative contactless floor limits are set per country in local currency and are materially lower outside the eurozone — Poland PLN 100 (EUR 23), Czechia CZK 500 (EUR 20) [known]. The cumulative counters are local-currency equivalents of EUR 150.
Consequence: on a EUR 22 average Polish ticket (r02's own §7.1 assumption), a large share of taps will prompt for PIN, not the minority the doc implies. r02's UI warning ("you cannot assume a tap is a one-second interaction") is right but under-weighted: in the CEE beachhead the PIN path is the common path, not the fallback, and every timeout, cancel and card-removal branch is exercised daily. Budget the terminal-state machine accordingly and test PIN-path latency, not tap-path latency, for the r08 adoption thresholds.
#C8. PCI — SAQ P2PE is not achievable with the recommended stack, and it is still in the plan
Claim: r02 §4.1 and §8 target "Merchant SAQ P2PE or B-IP"; §0 bullet 10 says "target SAQ P2PE in-store".
Correction: r02 §4.2 correctly states that only a solution on the PCI SSC P2PE listing entitles a merchant to SAQ P2PE, and that Stripe is not believed to be listed — then the plan keeps SAQ P2PE anyway. The realistic landing zone with Stripe Terminal or Adyen Terminal API is SAQ B-IP (80 requirements), and where our own POS app runs on the reader (Apps on Devices) an assessor can reasonably push to SAQ C (140-160 requirements plus quarterly ASV scans). That is 3-5 extra hours per site of onboarding, exactly as the doc says — but it is the base case, not the downside case. Remove "SAQ P2PE" from all sales material. Confidence: high.
#C8b. Partner terms — r07 analyses the wrong risk on Toast, and misses the one that matters on aggregators
Toast. r07 §2.3 treats the "for the benefit of any competitor of Toast" clause as a litigation risk and concludes it "bites when your product starts looking like a POS". The sharper reading: an API Documentation License Agreement is a unilateral, amendable click-through, not a negotiated contract, and partner access is typically terminable at will on short notice with no cure period [known]. The realistic outcome is never a lawsuit; it is de-certification with 30 days' notice, which strands every installed customer simultaneously. Litigating the clause is irrelevant because there is nothing to litigate.
The missing mitigation is contractual with our customer, not with Toast. Nothing in nine documents specifies our own MSA terms around connector availability. Required from the first sale: third-party connector availability is expressly not warranted, is excluded from the SLA, and is never a condition of the subscription; if a platform revokes access we owe migration assistance, not refunds. Absent that, every platform revocation converts into refund liability and SLA credits across the affected base at once. ~EUR 3-5k of drafting; it should be in the MSA template before the first invoice.
Clover. r07 §2.1 records the 70/30 App Market split as an economics line. The structural point it misses: on a marketplace, the merchant contracts with the marketplace, not with us. We may not be able to invoice the merchant directly, we do not own the billing relationship, and — for a CRM — our GDPR position (processor under whose Art. 28 DPA?) is not the one we assumed. For a product whose thesis is "own the guest data relationship", marketplace distribution is structurally wrong, independent of the 30%.
Aggregators — the contradiction r07 does not see. §5.3 correctly notes aggregator terms "typically restrict onward use" of guest data, and then, three bullets later, recommends the in-parcel QR to "win your customers back from Glovo" at 2-6% conversion per campaign as "a legitimate, sellable feature". Aggregator partner agreements standardly prohibit using the integration to solicit the platform's customers or to divert orders off-platform [known — must be re-verified against the actual Glovo/Wolt/Bolt partner agreements before this feature ships]. That feature is plausibly a breach, and the penalty is not a warning letter — it is connector revocation across every one of our sites at once, in the exact market where r07 says aggregators are 15-40% of revenue. The feature and the connector cannot both be safe. Pick one, in writing, before either is built. Confidence: medium-high on the term's existence, high on the consequence if it exists.
#C9. France — the reversal is correct; the residual risk is who signs the attestation
Claim: r03 §2.3 — LOI n° 2026-103 du 19 février 2026 art. 125 restored éditeur self-attestation effective 21 Feb 2026; NF525 optional; entry gate EUR 0.
Verification: Confirmed [verified, multiple FR sources 2026-08]. The LF2025 abolition (deadline extended to 1 Sep 2026 by BOFiP) is cancelled. No correction.
Residual risk r03 understates: an attestation is a legal representation by the éditeur, and the merchant still faces EUR 7,500 per non-compliant software with 60 days to remedy. It is untested whether a French auditor accepts an attestation from a non-resident editor with no French establishment and no French-language documentation. Must be re-verified with French counsel before the first FR sale — the risk is not the certificate, it is standing to attest.
#C10. France e-reporting — the most time-critical unverified item in the corpus
r03 §2.3 marks the B2B reception obligation for all businesses at 1 Sept 2026 as [known — verify current calendar] and budgets item 7 (PDP integration, B2C e-reporting) at 2.0 eng-months as deferrable. That date is roughly two weeks from now. If it is live, every French customer onboarded from that point needs PDP reception on day one and the item is not deferrable. This is the single highest-urgency verification in the whole research set and it was left open. Confidence: cannot resolve without a fresh DGFiP check.
#Underestimated effort
| Item | Doc estimate | Realistic | Why |
|---|---|---|---|
| ECR/POI acquirer certification | r02 item 21: 0.75 eng-mo per acquirer per country, EUR 0-15k, 2-8 weeks | 0 with Stripe/Adyen SDKs; 2-4 eng-months and 3-6 months wall clock per acquirer per country the moment you touch a domestic rail (ZVT for Nexi/Concardis, a Polish acquirer's ECR protocol, an RT-linked terminal in IT) | You are queuing for a test slot with a bank, not an API company. Banks schedule certification windows quarterly. r02's "including their test queue" is optimistic ~3x on calendar. |
| Reconciliation | r02 item 8: 2.5 eng-mo | 4.5-6.0 for two acquirers, and it never finishes | Three-way match (POS check ↔ terminal journal ↔ acquirer settlement) with per-country variants: tip-on-terminal vs post-auth, DCC dual-currency rows, German girocard SEPA refunds that settle off-rail, cash rounding on the residual tender, offline checks landing 4h late. Plus a UI a non-accountant can act on. |
| Italy (POS↔RT linkage) | r03 item 8: 3.0 eng-mo | 4.5-5.5 plus a permanent ops task | The 45-day registration clock is per merchant. Someone must register each terminal-RT pair and track expiry. That is a back-office feature plus a runbook plus an owner, and it depends on the acquirer exposing linkage data — a joint dependency, not a build. |
| DSAR / erasure with offline propagation | r06 item 13: 3.0 eng-mo | 5-6 if the sync layer already exists; more if not | It touches the sync core, the fiscal store, ClickHouse, the ESP, and every terminal. r04 separately says retrofitting erasure into an immutable log is a "3-month nightmare"; the two numbers are never reconciled. This is also the item every EU chain's security questionnaire asks about. |
| Certification dossiers | r03 §3: "3-6 weeks of a senior engineer's writing time per country" | Right for the engineer; add EUR 8-25k local counsel per certifying market and a named 12-month relationship owner | Authorities ask questions requiring a company officer's signature. BE, SK, HU, GR additionally require notifying the authority of every customer installation — an ongoing operational process, not a project. |
| Our own PCI posture | r02: SAQ D-SP EUR 20-40k; ROC EUR 40-90k/yr + EUR 60-150k remediation | Cash figures plausible; add 3-5 eng-months of diverted engineering (logging, key management, change-control evidence, quarterly ASV, pen test, segmentation testing) | v4.0.1 requires ~12 months of continuous operational evidence. You cannot buy your way out in the quarter a chain asks. Start evidence collection 12 months before the first chain deal, i.e. now. |
| UK tips | r03 item 20 / r02 item 4 (bundled) | 1.5-2.0 for the Tipping Act piece alone | Written policy, tronc, fairness allocation, 3-year records, statutory worker record requests with a response duty, tribunal exposure to GBP 5,000 per worker. Do not build it until a UK customer is paying for it. |
| Germany refunds | not budgeted | +0.75-1.0 | See C2. |
| Consent-gated dual receipt renderer | not budgeted | +0.5-0.75 | See C5. Fiscal-only template vs promotional template, per country, with a golden-file test suite. |
Net effect on r02+r03+r06 compliance-adjacent totals: roughly +10 to +14 eng-months against the S1 recommended scope, before any of the missing items below.
#Over-engineering to cut
| Cut | Saving | Reasoning |
|---|---|---|
| Store-and-forward offline card payments (r02 item 19) | 1.5 eng-mo | The doc already argues against it and still lists it. The merchant eats every loss, forward-failure is 1.5-4%, and the SCA cumulative counters live at the issuer so a guest who is already over the EUR 150 / 5-transaction limit is approved offline and declined on forward. "Cash for 15 minutes + a printed IOU" is the correct product. Delete the line. |
| Surcharge / service-fee engine (r02 item 22) | 1.5 eng-mo | Illegal on EEA consumer cards under PSD2 Art. 62(4)-(5). The only EU use case is a mandatory service charge, which you must model as a distinct VAT-able entity anyway for r03 §4 reasons. Fold it into the tax model; delete the engine. |
| Gift cards / stored value in v1 (r02 item 11 + r06 deferred 2.0) | 2.0-4.0 eng-mo | SPV/MPV VAT classification, national expiry law, breakage under IFRS 15, the PSD2 Art. 37(2) EUR 1m limited-network counter, UA advance-payment fiscalisation, US escheat. Three legal opinions before a line of code. Ship instead a brand voucher: a signed offline voucher with a face value, no top-up, no cash-out, single-brand. That is the r06 §3.3 primitive you are already building and it stays entirely outside the e-money perimeter. |
| Payfac evaluation phase (r02 P4) | Planning overhead | Break-even is EUR 333M TPV; PSD3/PSR applies H2 2027-early 2028 [verified per r02]. Any licence work started before the final text is wasted. Cut the phase; the option survives without a placeholder. |
| Probabilistic identity matching in v1 (r06 item 1) | 1.5 eng-mo (4.0 → 2.5) | r06 itself says a false merge is "a reportable personal-data breach". Shipping a 0.90-threshold auto-merger before you have a labelled evaluation set is buying regulator exposure to save cashiers a lookup. Deterministic tiers only; queue everything else for manual review. |
| SAQ P2PE ambition | onboarding effort | Not achievable with the stack (C8). Design for SAQ B-IP and stop paying for the aspiration. |
| Tips distribution engine outside UK/US (part of r02 item 4, 3.5 eng-mo) | ~1.5 eng-mo | Pooling, tip-out matrices by role, shift weighting and payroll export are only required by law in the UK (Tipping Act) and useful in the US. In DE it manufactures a payroll-tax event (C7b); in CZ/UA/PL the common pattern is direct-to-employee or cash. Ship tip capture and per-employee attribution in v1; ship distribution only when a UK or US customer pays for it. |
| Basque TicketBAI, permanently (r03 item 10, 3.0 eng-mo) | 3.0 eng-mo | Three provincial XSDs plus Navarra, four registries, for ~15k venues. It is a fourth country's worth of work for a rounding error of TAM. There is no version of this plan where it is correct. Delete the line rather than deferring it. |
| Build-vs-buy on fiscal middleware, reframed | — | r03 frames it on price (EUR 10-15/register/mo vs 18-22 eng-mo). The stronger argument is co-defendant risk transfer: 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 absorbs part of that exposure and is a named party in any dispute. That alone justifies 11-25% of ARPU. r09 spotted this; r03 did not. Buy, and say why in the risk register, not just the cost model. |
#Missing failure modes
M1. Nobody asked who controls the fiscal archive after churn. If we hold the merchant's fiscal records in our cloud, 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 КЕП key. A churned customer's data cannot be deleted at contract end. We owe a defined handover artefact and possibly continued availability for a decade. Nothing in nine documents models the cost of holding a churned merchant's fiscal archive for 10 years. Design the exit obligation and an escrow/export format before the first sale.
M2. UA КЕП server-side custody is an incident-liability question, not a legal-opinion question. r03 open question 5 frames it as "get a lawyer's opinion". The sharper version: if we hold a merchant's qualified signature key and it is misused or stolen, the signature is legally theirs, the custody failure is ours, and Ukrainian qualified-signature law generally presumes sole control by the signatory. "Every UA cloud POS does it" is not a defence in an incident. Resolve this before P0, not before P1. If the answer is negative, the architecture changes to client-side signing or a hardware token per venue and r03's 3.5 eng-months becomes 5-6.
M3. WhatsApp/Meta transfer risk has no fallback. r06 §4.2 and r07 §6 both make WhatsApp Cloud API a primary CRM channel in PL/RO/UA. That means guest phone numbers go to Meta: a US transfer relying on the EU-US Data Privacy Framework (under active litigation, and its two predecessors were struck down), plus Meta asserting controller status over parts of the processing. No transfer impact assessment, no subprocessor analysis, no fallback appears anywhere. Design the channel abstraction so WhatsApp is removable per market, and keep an EU-only path (local SMS aggregator) for every automation.
M4. Telegram has no DPA story. r07 rates a Telegram mini-app "high for UA" at 1.75 eng-months. Telegram does not offer an Art. 28 DPA an EU chain's procurement will accept. Acceptable for UA-only tenants; must be blocked at the tenant level for EU tenants, which is a schema constraint, not a policy note.
M5. Aggregated sender IDs make us the respondent. r06 §4.2 recommends aggregating one Viber sender across all tenants to beat the EUR 100-150/month minimum. Under PKE art. 398 the fine scales to the sender's revenue (3% or PLN 1m, whichever is higher) [verified]. Aggregating makes RestaurantBrain the sender of record for hundreds of merchants' direct marketing in a strict-consent regime. Do not aggregate in Poland. Either the tenant holds its own sender or we do not offer the channel there.
M6. "Do not build the cashier-consent button" is not enforceable as a policy. r06 §6.5 is right that a cashier ticking a box is worthless evidence. What is missing is that every customer will ask for it in week two and a sales engineer will ship it as a custom field. The defence must be structural: consent_record.ui_surface is an enum with no pos_staff value, and the API rejects it. Put it in an ADR with a test, not in a style guide.
M7. The importer will launder aggregator data into the marketing base. r07 §9.3 recommends read-only importers pulling "guest list and 12-24 months of check history" from Poster/iiko/r_keeper. r06 §6.4 correctly requires delivery-platform guests to be marketing-suppressed. Nobody connected the two. Concrete failure: a restaurant migrates from Poster, we import 18 months of Glovo orders, the segment builder includes them, the first winback SMS goes to people who only ever ordered via Glovo, and it is an unlawful-processing complaint with the restaurant's name on it and our infrastructure underneath. The importer must set the suppression flag by provenance, and the segment builder must not be able to clear it.
M8. Chargeback and negative-balance liability under a managed payfac is unmodelled. r02 §1.1 notes "chargeback/fraud loss often flows to us contractually" and never returns. Under Stripe Connect or Adyen for Platforms with a platform-liable model, we are on the hook when a merchant's balance is insufficient — the realistic case is a restaurant that closes owing pending refunds and unredeemed prepaid value. At 300 sites and a 4-8%/yr restaurant failure rate that is 12-24 events a year. Budget a rolling reserve on new merchants, delayed payout on prepaid sales, and a bad-debt line of EUR 15-40k/yr at 300 sites [estimate].
M9. Sub-merchant KYB friction is a sales problem nobody costed. Under Connect/Adyen for Platforms we own onboarding: UBO collection, sanctions screening, document upload. Realistically 10-20% of SMB restaurant applications stall on documentation and 2-5% are rejected [estimate]. The customer has signed and cannot take cards for 9 days. That needs an ops person, not an engineer, and r09's 16.5-41 hour onboarding model does not include it.
M10. DORA lands on us as an ICT third party. Regulation (EU) 2022/2554, applying since 17 Jan 2025 [known]. We will not be 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 strategies, incident-reporting timelines, subcontracting restrictions. This is a standard blocker in EU PSP onboarding today. First-time cost: EUR 8-20k counsel + ~0.5 eng-months of documentation. Absent from all nine appendices.
M11. EU Data Act cloud-switching obligations. Regulation (EU) 2023/2854, applicable 12 Sep 2025, with switching charges to be withdrawn by 12 Jan 2027 [known]. As a data processing service we owe contractual switching support, exit assistance, and functional export. For a POS holding a restaurant's whole history this is a real, dated obligation. ~0.5-1.0 eng-months — and it is the same code as the migration importer, run in reverse, so build it once.
M12. Tech E&O with a regulatory-fine exclusion is the standard policy, and it is a procurement gate. r09 notes producer-side fines are uninsurable. The missing item is the insurance conversation itself: any chain will ask for a certificate of insurance, and a POS vendor operating in fiscalised markets should budget EUR 8-25k/yr for EUR 1-2M of cover [estimate] from the first EU sale, with the knowledge that Spanish producer fines sit outside it.
M13. PCI Software Security Framework is not mentioned anywhere. PA-DSS was retired 28 Oct 2022 and replaced by the SSF (Secure Software Standard + Secure SLC) [known]. Not mandatory for a semi-integrated POS that never touches account data — but "our Android app runs on the payment terminal" (Apps on Devices) is precisely the fact pattern where an assessor or an enterprise procurement team asks. Get a written QSA scoping opinion (EUR 5-10k) before the first Apps-on-Devices deployment, not after.
M14. SCA soft-declines will manufacture the canonical double-charge, and they are guaranteed, not rare. Stripe's own German documentation: "You see two charges associated with SCA-authenticated transactions. The first is a soft-declined charge with an error message online_or_offline_pin_required or offline_pin_required… The second is the authorised or hard-declined charge" [verified, docs.stripe.com]. This is not an edge case; it happens on every PIN-authenticated transaction. Two failure modes r02 §3.6 does not name:
- If the POS surfaces the first soft-decline to the cashier as "declined", staff re-run the payment and the guest is charged twice. This is r02's own canonical double-charge, arriving by a guaranteed route rather than a network timeout.
- Nightly reconciliation and any per-transaction reporting will see phantom declined charges at roughly 1:1 with successful PIN transactions. A naive "decline rate" dashboard will read ~50% and generate a support escalation from every customer in week one.
The error taxonomy must classify
*_pin_requiredas an in-flight state, never as a terminal failure, and reconciliation must filter soft-declines before matching. ~0.5 eng-months and it is not optional.
M15. Germany has a language obligation on the point-of-sale service itself. "Language regulations require that services, including point-of-sale services, be provided in German unless English has been agreed upon by the cardholder and their card issuer" [verified, docs.stripe.com]. This reaches custom reader screens, receipts, and by extension our cashier and guest-facing surfaces. r08 budgets i18n at 1,400-1,800 strings across 8 CEE locales; German is not optional polish, it is a condition of operating. Minor cost, but it removes "we'll launch DE in English first" from the option set.
M16. The sequencing trap, stated as a rule rather than a ranking. r03 ranks markets by opportunity/cost. Under S1 that is the wrong axis: a market whose certification calendar exceeds the remaining runway is disqualified, not expensive. BE 6-12 months, PT 3-6 + entity, SK 3-6, HU 6-12, GR 6-12, PL GUM 6-12. 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. Hard rule for S1: only enter markets where time-to-first-legal-invoice is under 60 days. That is CZ, NL, UK, UA, DE, AT, FR (self-attest) — and not Spain, which C1 removes.
#What I would do instead
Objective: a paid, VAT-charged, legally clean invoice inside ~5 months, with no certification body anywhere in the path.
#Market: Czechia first, not Ukraine
| Criterion | CZ | UA |
|---|---|---|
| Fiscalisation | None since 1 Jan 2023 | PRRO: no product cert, but КЕП custody unresolved (M2) |
| Stripe Terminal | Widest CEE roster: WisePOS E + S710 + S700 + Verifone [verified] | Not available; two bank integrations, ~5.5 eng-mo |
| Our payments revenue | Thin but non-zero | Zero (C7) |
| Producer liability | None | None |
| Local entity required | No | No |
| Privacy regime | GDPR + zák. 480/2004, ÚOOÚ proportionate | Thin, light enforcement |
Ukraine stays as the engineering and support base and as customers #2-10 — no certification, cheapest sales motion, and PRRO forces the offline-first architecture that pays off everywhere. It is not the market that produces a defensible first invoice.
#PSP: decide on the CRM criterion, in week one
Run the PAR sandbox test against both Stripe and Adyen before writing the adapter. If Stripe does not emit PAR on card-present, start on Adyen Terminal API — the CRM is the defensible half of the product (r06) and PAR is its key. Either way, payment_method carries par as a first-class nullable field from commit one, and the PaymentTerminal port never leaks provider identity into flow logic.
#PCI: land merchants on SAQ B-IP, honestly
Our own posture: SAQ D-Service Provider self-assessment, with evidence collection started in month 1, because v4.0.1 wants ~12 months of continuous operational evidence and the first chain deal will ask. No P2PE claims in any material. Semi-integrated only; any feature needing keyed PAN entry happens on the PIN pad (MOTO) or does not exist.
#CRM v1, consent-safe shape
- Primary capture = QR table ordering + own-channel web ordering. Contract basis natively, consent captured on the guest's own device with IP, user agent, timestamp and policy-text hash. This is also the only channel where r06's 60-90% capture claim is credible.
- POS phone capture is allowed; the resulting SMS is a fiscal receipt with no offer, no brand imagery and no join link in PL and DE. The invitation lives on the printed receipt QR, the customer-facing display, or the ordering session.
- Deterministic matching only in v1. No probabilistic auto-merge.
- Card-linked identity is v1.1, enrolment-only, PAR-first. Never for a guest who has not enrolled — r06 §1.5 is correct and the temptation to "just count anonymous repeat visits" will be strong.
- Erasure tombstones, per-device revocable keys and ack tracking go into the sync layer at commit one. r04 is right that this is a rewrite if retrofitted. It is the one CRM line item that cannot be deferred.
- Loyalty structured as three layers (join = contract; marketing consent = separate and unbundled; profiling = a third consent), with the member discount not conditional on layers 2 or 3.
#Timeline to first invoice
| Month | Work | Cash |
|---|---|---|
| 0-1 | Operating entity (EE or CZ; no local entity needed for CZ sales). One Czech opinion covering: is a neutral "join here" line in an e-receipt obchodní sdělení under zák. 480/2004, and does the existing-customer exception reach it; loyalty T&C structure under Art. 7(4); VAT treatment of points redemption vs free item on the CZ receipt. DPA template, subprocessor register, Art. 30 record, DORA-ready contract addendum. PAR sandbox test on both PSPs. | EUR 12-20k |
| 1-4 | Single-station POS (r04 T0 scope, ~13 eng-months of work, not 34). One terminal adapter. One printer SKU (Epson TM-m30III all-interface). CZ VAT + receipt template. Deterministic identity, points/stamps, signed offline vouchers, consent ledger, DSAR/erasure with tombstones. | — |
| 4-5 | Three design partners in Prague/Brno at a discounted but invoiced, VAT-charged price. That invoice is the milestone, not the pilot. | — |
Explicitly not in this path: Poland (GUM certification + PKE consent regime), Germany (DSFinV-K + girocard SEPA refunds — month 12+, and enter with fiskaly or Deutsche Fiskal in the chain as a co-defendant), Spain (producer liability — do not sell), Italy (RT-POS linkage), any market with a certification body, gift cards, store-and-forward, kiosks, surcharging, US.
#Gate before Germany
Do not quote a German customer a date until all five are true: girocard working on S700 in production; SEPA-refund states and cashier copy shipped; DSFinV-K 2.3 export passing a real conformance test; a signed fiskaly/Deutsche Fiskal contract; a written insurance position. That is ~5 eng-months plus 6-8 weeks of vendor onboarding. Germany's 1 Jan 2026 permanent 7% VAT on all Speisen is a genuine sales trigger — but it is a reason to be ready, not a reason to be early.
#The three questions that must be answered before any code
- Does our PSP return PAR on card-present, in the beachhead countries, in writing? (One day of sandbox work; decides the CRM's ceiling.)
- Is a neutral join invitation inside a transactional receipt lawful in CZ, and definitively not in PL? (EUR 3-5k of counsel; decides whether the highest-volume capture channel exists.)
- Is the French B2B reception obligation live on 1 Sep 2026? (One DGFiP check; decides whether France is a 2026 or a 2028 market.)
Everything else in this research is good enough to build on.