#R02 — Card-Present Payments & PCI for RestaurantBrain

Status: research / decision input. Date: 2026-08-18. Label key: [verified] = checked this session with a URL · [known] = confident from training data (≤ May 2026) · [estimate] = reasoned guess, stated as such.

#0. Bottom line

1. Do not touch card data, ever. Semi-integrated only. Every architecture where our software sees a PAN adds EUR 150k–400k/yr of PCI + EMV L3 cost and 18–24 months of certification for zero product value. This is not a close call.
2. Stripe Terminal is available in all four beachhead countries except Ukraine — PL, CZ, RO, HU, BG, HR, SI, SK, EE, LT, LV, PT, IT, plus all of Western EU + CH/NO [verified]. Ukraine is absent, and so are Adyen, SumUp, Zettle, and Square. Ukraine is a hard architectural fork: it needs a separate, locally-acquired payments layer (mono / PrivatBank / A-Bank Android terminals) plus PRRO fiscalization, sharing nothing with the EU stack except the abstraction boundary.
3. Payments funds a POS company in the US. In the EU it funds roughly half of one. In Ukraine it funds nothing. IFR interchange caps (0.2% debit / 0.3% credit) compress the whole EU merchant-service-charge pool to ~1/3 of the US. Modelled below: a 20-site chain yields ~USD 200k/yr payments gross profit in the US vs ~EUR 32k in Poland vs ~EUR 8k in Ukraine. Plan as a SaaS company with a payments attach, not a payments company with a SaaS wrapper.
4. Never become a payfac. Break-even against a managed payfac is ~EUR 330M/yr TPV ≈ 400–600 sites. Below that the licence + compliance + scheme membership fixed cost (EUR 700k–1.2M/yr [estimate]) exceeds the 25–40 bps of incremental margin.
5. The single highest-value technical asset in this whole domain is PAR (Payment Account Reference) — the EMVCo 29-char identifier that links a physical tap, an Apple Pay token, and an online card-on-file to one funding account without ever storing a PAN. It is the legal, PCI-clean CRM↔payments bridge. Whether our processor exposes it is a must-verify before architecture lock (§4.6).
6. The flows that will actually hurt are not "take a card payment". They are: tip semantics differing per country, timeout/unknown-state reconciliation, referenced-refund-after-batch-close, VAT treatment of service charge vs gratuity, and cash rounding on the fiscal receipt. Budget 8–12 eng-months for these alone.

#1. Commercial models

#1.1 The four models

#1.2 What being an EU payfac actually requires

Regulatory horizon: PSD3 + PSR reached political agreement 27 Nov 2025; final texts expected in the Official Journal in H2 2026; application H2 2027, possibly slipping to early 2028, with an 18-month Member State transposition window for PSD3 [verified]. PSD3 merges the EMI regime into a single PI regime and tightens fraud/APP rules. Practical effect on us: any licensing decision taken before 2027 is being taken against a regime that is about to change. Another argument for renting someone else's licence.

Verdict: EUR 1.0–1.6M of first-year cost and 18–30 months for something a managed payfac gives us in 3–8 months. Break-even math in §7.4.

#1.3 Revenue share reality — bps we actually keep

Card-present, EEA consumer cards, per EUR 100 of volume:

The German column is the important one: girocard runs at ~0.2–0.3% MSC and still carries the majority of debit volume in DE restaurants [known]. A German restaurateur already pays 0.3%. There is no 1.4% flat-rate story to sell there. This is why SumUp/Zettle-style flat pricing works in PL/RO/IT/PT (fragmented SMB, weak bank offers) and fails in DE/FR/NL (strong domestic schemes, sharp bank pricing).

Referral model reality: 10–30% of acquirer net revenue on a 0.35% net = 3.5–10 bps. On a 20-site Polish chain (EUR 12.6M card volume) that is EUR 4,400–12,600/yr. It is not a business line; it is a rounding error. Use it only to de-risk v1.

#2. Terminal integration options

#2.1 Integration topologies

Recommendation: build one internal PaymentTerminal port with local + cloud adapters, and never let restaurant flow logic know which one it is talking to. Every acquirer will differ; the abstraction is where the reuse lives.

#2.2 Vendor / device matrix

Device-availability caveat: BBPOS WisePOS E is documented as available in AT, BE, DK, FR, DE, IE, NL, ES, SE, UK [verified] — i.e. the country is Terminal-supported in PL/CZ/RO but the device roster per country is narrower. Action: pull the per-country device matrix from Stripe before committing to a hardware SKU for the CEE beachhead.

#2.3 The single highest-leverage decision

Stripe Terminal with S700/S710 running our own Android POS app (Apps on Devices) is the strongest available all-in-one story without manufacturing. One SDK, one commercial contract, one certification burden (theirs), covering every EU beachhead country. It collapses "tablet + reader + stand + cabling" into one device, which halves install time and support surface.

Counter-arguments to weigh:

• Stripe Terminal per-transaction economics are worse than a direct acquirer relationship in low-MSC markets (DE girocard: Stripe does not support girocard acceptance [known, verify] — if true this is disqualifying for Germany on its own).
• Vendor concentration: one supplier controls our payment margin, our hardware, and our merchant relationship.
• SumUp is a competitor, not just a supplier — they own Goodtill/Tiller/Shore POS products. Building on SumUp Cloud API means our roadmap is hostage to a company selling against us. Stripe does not sell restaurant POS. That asymmetry is worth 15–20 bps.

Recommendation: Stripe Terminal for EU. SumUp Cloud API as a cheap second adapter for merchants who already own Solo readers (retention play, not a primary path). mono + PrivatBank for Ukraine. Adyen only when a 20+ site chain demands it.

#2.4 Do not manufacture hardware — and rent, don't sell

The framing assumption (certify + resell commodity hardware) is correct. Additionally:

• Rent terminals, don't sell them. EU norm is EUR 15–29/terminal/month [known]. Device cost EUR 200–350; 36 months at EUR 19 = EUR 684. Renting also keeps the RMA/firmware relationship with us, which is where support quality lives.
• Peripherals: Epson TM-m30III (LAN, ePOS-Print XML), Star mC-Print3, cash drawers via RJ11 kick-out from the printer. These are §R0x-hardware's problem, not payments', except that the receipt printer is where the payment slip, the fiscal receipt, and the tip line all collide.
• Certify a short list: 2 readers, 2 printers, 1 KDS display, 1 router. Every additional SKU is permanent support debt.

#3. Restaurant payment flows that break naive integrations

#3.1 Tips — the biggest cross-market divergence

Implication: tips cannot be a boolean on a payment. Model them as a first-class TipAllocation with {collector: merchant|employee|pool, source: terminal|post_auth|cash, taxability, fiscal_receipt_inclusion}. Not all EU protocols return a split tip field — Nexo/SaleToPOI has AmountsResp.TipAmount; ZVT variants have a tip field; some do not. Where the protocol does not return the tip separately, tips are unusable for payroll and must be disabled.

VAT trap: a voluntary gratuity is outside the scope of VAT in the EU; a mandatory service charge is part of the taxable consideration and is VATable [known]. The fiscal receipt must treat these differently. Getting this wrong is a tax-audit generator for every customer simultaneously.

#3.2 Bar tabs — pre-auth + incremental authorization

• Flow: estimated authorization (Visa Estimated Auth / Mastercard preauth, MCC 5812/5813 eligible) → incremental authorization as the tab grows → capture the final amount.
• Stripe Terminal supports incremental_authorization — US only [known, verify]. In the EU, most acquirers do not expose card-present incremental auth via partner APIs. ZVT has Reservation (06 22) / Book-Total (06 24); Nexo has PreAuthorisation/Completion.
• SCA: the pre-auth is a card-present transaction with PIN or contactless-under-limit, so SCA is satisfied at auth time. A capture materially above the authorized amount (beyond the tip tolerance) requires a fresh authorization with the cardholder present.
• The US pattern of holding the physical card behind the bar is not viable in the EU (data protection + the card must be returned). EU pattern: pre-auth EUR 50–100, card returned, top-up requires the guest to return to the terminal.
• Product decision: ship bar tabs as (a) pre-auth where the acquirer supports it, (b) "open check, settle at end" with no financial hold elsewhere, and (c) an explicit walk-out/unpaid-check write-off workflow. Do not pretend (b) is a hold.

#3.3 Splitting

#3.4 Voids, refunds, and the batch boundary

Restaurants close batches nightly, so almost every "fix yesterday's mistake" is a refund, not a void. Consequences:

• Staff must be told the money will not "come back today". Build the copy into the UI; it is the #1 support ticket in every POS.
• Referenced refunds are increasingly mandatory. Many EU acquirers have disabled standalone/unreferenced card-present refunds for fraud reasons [known]. Our data model must persist the acquirer transaction reference on every payment forever, or refunds become impossible.
• Partial refund after a tip adjust must be allocatable across {food, service charge, tip} — refunding a tip that has already been paid out to staff is a payroll clawback. Model it; do not let it be implicit.
• Refund windows: Stripe ~90–180 days [estimate], Adyen longer [estimate]. Beyond the window the only remedy is a bank transfer — build a "manual refund" record type so the books still balance.

#3.5 Offline / store-and-forward — and its real liability

What SAF actually is: the terminal approves offline using EMV terminal risk management (floor limits, issuer action codes, offline data authentication SDA/DDA/CDA), stores the encrypted transaction, and forwards it when connectivity returns.

Who eats the loss: the merchant, always. Stripe's offline mode states this explicitly [known]. Expected forward-failure rate: 1.5–4% of SAF transactions [estimate] — much higher than the online decline rate because the offline population skews toward cards the issuer would have declined.

Regulatory friction: SCA is still required. An offline PIN or a contactless tap under the CVM limit satisfies it at the terminal, but the cumulative contactless counters (EUR 150 / 5 consecutive transactions, RTS Art. 11) are tracked by the issuer, not the terminal [known]. A guest whose counter is already exhausted will be approved offline and declined on forward.

Recommendation: ship SAF as opt-in, off by default, with:

• per-transaction cap EUR 50–100,
• per-terminal aggregate cap EUR 500–1,000,
• contact chip + PIN only (no contactless SAF),
• a signed liability acknowledgement in onboarding,
• a mandatory "unforwarded transactions" dashboard tile that goes red.

Honestly: most restaurants would rather take cash for 15 minutes. SAF is a sales-demo feature that generates real losses. Sequence it late.

#3.6 Reversals, timeouts, and reconciliation

The canonical double-charge: the terminal approves, the response is lost, the POS shows "failed", staff re-run, the guest is charged twice. This will happen in production and it is the fastest way to lose a customer.

Mandatory mitigations:

• Idempotency keys on every payment initiation, keyed to {check_id, attempt_seq}.
• Explicit unknown state. A payment attempt has states {pending, approved, declined, unknown}. unknown is never rendered as "failed".
• Transaction-status query on reconnect — Nexo/SaleToPOI has TransactionStatus; Stripe: re-fetch the PaymentIntent; ZVT has status enquiry.
• Automatic reversal of any auth still unknown after N seconds.
• Nightly settlement reconciliation: pull the acquirer's settlement/batch file and three-way match POS check ↔ terminal journal ↔ acquirer settlement. Report unmatched.

Budget 2–3 eng-months for reconciliation alone. It is invisible in a demo and it is the difference between a toy and a product.

#3.7 EMV CVM limits and contactless

UI consequence: you cannot assume a tap is a one-second interaction. The flow must gracefully become "insert card → enter PIN" mid-payment, on the terminal, without the POS timing out or the server thinking the payment failed. This breaks naive implementations constantly.

Tap to Pay on iPhone / Android: PIN entry on the phone screen is now permitted under PCI MPoC [known]. This is a genuinely useful line-busting / patio / delivery-driver device, and it costs zero hardware. Ship it — but not as the primary counter device (battery, no printer, no cash drawer).

#3.8 DCC and surcharging

DCC: real revenue in tourist-heavy sites (merchant rebate commonly 0.5–1.5% of DCC volume [estimate]), but Regulation (EU) 2019/518 requires full transparency and an ECB-rate comparison, and schemes require a genuine cardholder choice on the terminal. Get DCC from the acquirer/terminal side; never build it. Our only job is (a) tolerate 3–8 extra seconds of terminal dialogue without timing out, (b) record both currencies and the applied rate on the receipt and in the ledger.

Surcharging:

• EU: assume it is illegal. PSD2 Art. 62(4) bans surcharging on EEA-issued consumer cards covered by the IFR; Art. 62(5) let Member States ban it entirely and many did (DE, FR, IT, NL, and others) [known]. Surcharging commercial or non-EEA cards may be legal in some states — not worth the product surface.
• US: legal in most states, banned/restricted in CT, MA, PR [known]; Visa caps at 3%; debit may never be surcharged; requires 30-day scheme registration and signage at entrance and POS. Restaurants increasingly use 3–4% "service fees" instead, which are under active state-AG and junk-fee scrutiny (CA SB 478 / SB 1524 carve-out with disclosure requirements) [known, verify].
• Build a jurisdiction-gated surcharge/service-fee engine, default OFF, with correct VAT/sales-tax treatment. 1–2 eng-months and a permanent legal liability sink. Do not ship it in EU v1.

#3.9 Cash rounding

Rule that breaks naive implementations: rounding applies to the cash tender, not to the card tender, not to the check total, and not to the VAT base. The receipt carries a non-taxable rounding line. In a mixed-tender split (EUR 20.03 check, EUR 10.00 card + EUR 10.03 cash → EUR 10.05 cash) the rounding is computed on the residual cash amount only. Fiscal printers in RO/PL enforce this; get it wrong and receipts are rejected by the device.

#4. PCI DSS v4.0.1

Status: all assessments in 2026 are against v4.0.1. The 51 previously "future-dated" requirements became mandatory on 31 March 2025; all 64 new/changed requirements are now in scope and require ~12 months of continuous operational evidence [verified].

#4.1 SAQ landing zone by architecture

Target: SAQ P2PE for in-store, SAQ A for online. Anything else is a per-merchant onboarding tax we pay in support time.

Our own status is separate from the merchant's. Even touching zero PAN, we route transactions, store tokens, and can affect the security of the CDE → we are a Service Provider. Expect acquirers and schemes to demand our AOC. Realistic path:

• Year 1–2: SAQ D-Service Provider self-assessment. EUR 20–40k with a QSA-assisted readiness pass [estimate].
• Once we exceed the Level 1 SP threshold (>300,000 transactions/yr as an SP, or a scheme designates us): annual ROC, EUR 40–90k/yr QSA + EUR 60–150k first-year remediation + ~0.5 FTE security engineering [estimate].

#4.2 "PCI-listed P2PE" vs "P2PE-equivalent" — the distinction that costs money

Only a solution on the PCI SSC P2PE listing entitles the merchant to SAQ P2PE. Vendors routinely market "P2PE-grade" or "point-to-point encrypted" without a listing. Stripe describes its readers as providing strong encryption and minimal merchant PCI burden but is not, to my knowledge, a PCI-listed P2PE solution provider [known — verify]. Listed P2PE solutions exist from Verifone, Ingenico, Bluefin, and ID TECH — ID TECH announced a PCI-validated P2PE solution with an EMV-L3-certified application engine covering Chase, Elavon, Fiserv, Global Payments and Worldpay in March 2026 [verified].

Action item with a real dollar value: for every acquirer we sign, demand the PCI SSC listing URL for their P2PE solution and the P2PE Instruction Manual (PIM). If there is no listing, our merchants land on SAQ B-IP or SAQ C instead of SAQ P2PE, and our onboarding gets 3–5 hours longer per site.

#4.3 Keeping PAN out of our stack — concrete controls

Note: last4 + expiry + cardholder name without the PAN is not cardholder data under PCI, but it is personal data under GDPR. Different regime, still obligations (§4.6).

The restaurant network reality: one flat network, guest WiFi on the same SSID, a EUR 40 consumer router, the POS on DHCP. Segmentation is not a compliance checkbox for us — it is a field-services cost line. Either we ship a certified router with a pre-baked VLAN config (~EUR 120 hardware, EUR 5/mo managed) or we accept 2–4 hours of remote troubleshooting per site. Budget it explicitly.

#4.4 Tokenization

Use network tokens wherever the processor provisions them (Stripe and Adyen both do [known]). The auth uplift alone pays for itself on order-ahead and reservation deposits, where CNP decline rates are the silent revenue killer.

Lock-in warning: processor tokens are the reason POS companies cannot switch acquirers. Design a payment_method table with provider, provider_token, and a stable internal payment_method_id from day one, and treat a processor migration as a re-tokenization project (processors do support token migration to a competitor under scheme rules, but it takes 6–12 weeks of paperwork [estimate]).

#4.5 PSD2 SCA and MIT for order-ahead

The classic failure: losing the initial network_transaction_id in the CIT→MIT chain produces a slow, mysterious decline-rate climb months later. Persist it on the payment_method record from the first transaction; make it non-nullable for anything flagged mit_eligible.

No-show / cancellation fees are MITs and additionally face EU unfair-contract-terms law. They need: the initial CIT with SCA, a recorded affirmative consent artefact (timestamp, IP, T&C version), and a cancellation window that a national consumer authority would accept. This is a real, sellable CRM feature (reservation deposits) — but it is a legal feature as much as a technical one.

#4.6 The CRM ↔ payments bridge: PAR, and what is actually legal

PAR (Payment Account Reference) is an EMVCo-defined 29-character alphanumeric identifier that is the same value across the physical PAN, every network token, and every wallet token for a given funding account [known]. Issuers are mandated to supply it; Visa and Mastercard return it in authorization responses to acquirers.

This is exactly the primitive a restaurant CRM needs:

• Recognize a returning walk-in guest across visits, without asking who they are.
• Link "the card they tapped at the counter" to "their Apple Pay in the app" to "their card-on-file for delivery" — one guest, three payment instruments, one profile.
• Attribute an in-store visit to an online marketing campaign.
• Do all of the above with zero PAN in our systems and therefore zero PCI scope change.

Card-linked-loyalty vendors sell precisely this. It is the difference between a CRM that knows 15% of covers (the ones who scanned a loyalty QR) and one that knows 70%.

The must-verify: does our processor expose PAR?

• Adyen: believed to expose additionalData.paymentAccountReference [estimate — verify, high value].
• Stripe: exposes payment_method_details.card_present.fingerprint (stable per card per Stripe account, not across accounts) and network_transaction_id. PAR exposure is not confirmed [known — verify].
• If neither exposes PAR, the fallback is the processor fingerprint, which works within one processor account but breaks on processor migration and does not unify a physical card with its wallet tokens. That is a materially weaker CRM.

This single API field should be a gating question in every acquirer conversation. It is worth more to the product than 20 bps.

GDPR reality — say this to the customer plainly:

Scheme rules additionally restrict acquirer/merchant use of PAR for marketing without cardholder consent [known]. Design the enrolment moment: a one-tap "link this card to your rewards" on the terminal or receipt QR, producing a recorded consent artefact. Everything else stays anonymous and aggregate.

#5. EMV L1 / L2 / L3 and scheme certification

How vendor SDKs eliminate this: Stripe, Adyen, SumUp and Zettle hold the L2/L3 certifications for their entire reader estate, per scheme, per country. We call collectPaymentMethod() and do zero EMV certification, forever, in exchange for the take rate. In a semi-integrated configuration the terminal manufacturer or acquirer owns EMV certification; the POS needs only acquirer integration certification, which "takes far less time" [verified].

Distinguish these two clearly in planning, because people conflate them:

• EMV L3 — expensive, slow, per acquirer, per country. Only if we own the payment application. Answer: never.
• ECR/POI integration cert — cheap, weeks, per acquirer, per country. Unavoidable for semi-integrated. Budget 3–6 eng-weeks per new acquirer/country including their test queue.

Pre-certified escape hatches exist if we ever want a direct acquirer relationship without our own L3 — ID TECH's Payment Application Engine ships EMV-L3-certified against Chase, Elavon, Fiserv, Global Payments, Worldpay [verified]. That is a US-centric list. In the EU, the same role is played by the terminal vendor's certified payment application (Verifone, Ingenico, Castles) plus the acquirer's estate certification.

Hard rule for a 3-person team: if a payments conversation ever contains the phrase "your L3", walk out of it.

#6. Gift cards / stored value, and tips-distribution law

#6.1 Gift cards and the e-money boundary

Design rule: make the merchant the issuer and obligor of the gift card; we are only the ledger and the redemption rail. Put it in the contract, and make sure the float sits in the merchant's account, not ours. The moment we hold customer float or make a card multi-merchant, we are an EMI.

Other gift-card obligations that are real work:

• EU Voucher Directive (EU) 2016/1065 — SPV vs MPV. A single-purpose voucher (VAT rate and place of supply known at issuance) is taxed at issuance; a multi-purpose voucher is taxed at redemption [known]. A restaurant selling food at 8% and alcohol at 23% issues an MPV. Our gift-card module must classify the voucher type and drive VAT accordingly, or the customer's VAT return is wrong. This is genuinely non-obvious, ~3–6 eng-weeks, and a real differentiator versus generic POS.
• Expiry / validity: national consumer law varies (PL general 3-year limitation; IT/FR minimum validity rules) [estimate]. Make expiry configurable and jurisdiction-defaulted.
• Breakage: unredeemed balances are revenue under IFRS 15 only on a defensible expected-breakage basis. In the US, state escheat law may claim unredeemed value — a genuine reason to defer US gift cards.
• Ukraine: gift certificates are advance payments; the PRRO must fiscalize the redemption, not the sale (or both, depending on treatment) [estimate — verify with a UA tax adviser].

#6.2 Tips distribution — we become the system of record for a statutory duty

Product consequences:

• Tips must be modellable as either direct-to-employee (not merchant revenue, not on the fiscal receipt, no payroll event) or merchant-collected-then-distributed (payroll event, taxable in DE/PL/UA). This is a per-country, per-merchant configuration, not a global setting.
• A real tips engine is required: pooling rules, tip-out percentages by role (server → busser → bar → kitchen), shift/hours weighting, service charge vs gratuity distinction, audit trail, payroll export, and a worker-facing record view (UK statutory).
• If we distribute tips, we are the evidentiary record for a statutory obligation. That is a liability, and it is also a moat — it is exactly the kind of thing a customer will not rip out.

#7. Payment economics

#7.1 A 20-site chain, three markets

Assumptions: [estimate] throughout, sourced from typical casual-dining unit economics.

#7.2 Why payments funds a POS company — and where it doesn't

Toast is the canonical case: ~140,000 locations, ~USD 150B+ annualized GPV, FY2024 revenue ~USD 5.0B of which ~75–78% is "financial technology solutions" [known, approximate]. Net payments take ≈ 0.55–0.60% of GPV → ~USD 6,000–6,500 of payments gross profit per location per year, against ~USD 3,000–3,500 of subscription gross profit. Payments delivers roughly 2× the gross profit of the software, and it scales with the restaurant's revenue rather than with seat count, which means it grows without a sales motion.

That model does not transplant to the EU, because the IFR caps the interchange that inflates the US merchant service charge. The EU pool is ~1/3 the size. Concretely: the same 20-site chain that funds USD 203k of payments gross profit in the US funds EUR 32k in Poland and EUR 13k in Germany.

Strategic consequences:

1. In the EU we are a SaaS business. Price accordingly: EUR 150–350/site/month in Western EU, EUR 60–120 in CEE, with module-based expansion (CRM/loyalty, online ordering, reservations, inventory). Payments is a 20–40% revenue kicker and a retention mechanism, not the engine.
2. Push volume to CNP, not CP. Online ordering, reservation deposits, gift cards, and pay-at-table QR all carry 1.4–1.9% MSC against the same IFR-capped interchange. EU online-ordering margin is 3–5× in-store margin. This is the single most actionable economic insight in this document.
3. Germany is the worst payments market and the best SaaS market. Do not lead with a payments pitch there.
4. Ukraine has effectively no payment margin (interchange ~0.9% cap against a ~1.4% acquiring ceiling [known — verify current NBU/Law 3498-IX figures]). Ukraine must be won on product and price, with payments as pure integration, not revenue.

#7.3 Adjacent payment revenue lines worth more than the interchange spread

#7.4 The payfac break-even, decided

• Managed payfac (Stripe Connect / Adyen for Platforms) net to us: ~26 bps in the Poland model.
• True payfac net to us: ~55–65 bps in the same model (we keep the provider's 35 bps minus our own processing/gateway cost of ~5–10 bps).
• Incremental margin: ~30 bps.
• Fixed cost of being a payfac: EUR 700k–1.2M/yr (§1.2) [estimate].
• Break-even TPV = EUR 1,000,000 ÷ 0.0030 ≈ EUR 333M/yr, ≈ 400–600 restaurant sites at EU volumes, or ~1,500 sites in Ukraine.

Decision: do not consider a PI licence below EUR 300M annual TPV. Under scenario S1 (bootstrapped, 24 months' runway) it is not remotely reachable. Under S2 (EUR 5–10M seed/A) it is a year-4+ conversation, and by then PSD3/PSR will have changed the regime anyway.

#8. Recommended architecture and sequencing

Design invariants from day one, regardless of phase:

1. A single PaymentTerminal port. Adapters: stripe-terminal, sumup-cloud, adyen-terminal-api, ua-mono, ua-privat. Restaurant flow logic never branches on provider.
2. payment_attempt has an explicit unknown state and an idempotency key. Non-negotiable.
3. Acquirer transaction reference persisted forever on every payment (referenced refunds).
4. TipAllocation is a first-class entity with a collector, a taxability flag, and a fiscal-receipt-inclusion flag.
5. payment_method carries provider, provider_token, network_token_id, par, network_transaction_id, fingerprint — all nullable except the first two.
6. Nightly three-way reconciliation (POS check ↔ terminal journal ↔ acquirer settlement) with an unmatched-items report.
7. Zero PAN. Enforced by an edge validator and a log scanner, tested in CI.

#9. Honest risks

#Build effort

Engineer-months. "Variance drivers" is what makes the number move. Assumes senior engineers with heavy AI assistance; multiply by 1.4–1.8 for a team new to payments.

Scenario read:

• S1 (founder + 3 engineers, ~24 months): ~72–96 available eng-months across the whole product. Payments alone consumes 37–42 if we chase UA + PL + RO + Western EU. This does not fit. S1 must pick one fiscal regime plus one payment rail — realistically Ukraine only (mono/Privat + PRRO, ~15 eng-months for payments) or Poland + Czechia only (Stripe Terminal + PL fiscalization; CZ has no fiscalization since EET was repealed in 2023 [known], so CZ is nearly free — CZ is the cheapest EU country to enter and should be the first EU market).
• S2 (15–30 people, EUR 5–10M): 37–42 eng-months over 4–5 payments engineers is 9–11 calendar months. Feasible, and the binding constraint becomes acquirer certification queues and fiscal-device homologation (calendar, not engineering).

#Open questions / what would change this answer

1. Does Stripe Terminal support girocard in Germany? If no, Germany requires a Nexi/Concardis ZVT adapter (+6–10 eng-weeks) before the first German sale, and the German payments margin (already the worst at 0.08%) goes to roughly zero. Would change: German go-to-market timing and the P2 device strategy.
2. Does Stripe (or Adyen) expose PAR (paymentAccountReference) on card-present authorizations? This is the single most valuable API field for the CRM thesis. Would change: whether "recognize the guest by their card, anonymously, with no PCI scope" is a real feature or marketing. Verify by reading the card-present response schema and, if ambiguous, running a live test transaction in each processor's sandbox.
3. What is the current Ukrainian interchange and acquiring-fee cap regime? Law 3498-IX and subsequent NBU resolutions capped interchange (0.9–1.0%) and merchant acquiring (1.4%) with a stepped reduction schedule [known — unverified figures for 2026]. Would change: whether Ukraine has any payment margin at all, and whether a UA acquiring partnership is worth negotiating.
4. Per-country Stripe Terminal device roster for PL/CZ/RO/HU. Country support is confirmed [verified] but WisePOS E availability is documented only for 10 Western markets [verified]. If S700/S710 are also unavailable in CEE, the Apps-on-Devices single-device strategy collapses there. Would change: the entire P1 hardware plan.
5. Do we need our own PCI AOC, and at what level, before the first 50 merchants? Acquirer-dependent. Stripe may accept us as a platform without a formal SP AOC at low volume; Adyen and bank acquirers will not. Would change: EUR 20–90k/yr of cost and 2–4 eng-months, timing unclear.
6. Is a white-labelled merchant cash advance (YouLend/Liberis) licence-free for us as a referrer in PL/CZ/RO/DE? If yes, it is the highest-margin adjacent revenue line available and may exceed the interchange spread. Would change: the "payments doesn't fund an EU POS company" conclusion — MCA commission could add EUR 300–600/site/yr, doubling per-site payment economics in CEE.