Billing & Zahlungs-gesteuerter Zugang — Design

Status: Design (kein Code) — Entwurf 23.06.2026, Diskussionsergebnis der Strategie-Session 22./23.06., gemäß Way-of-Working „Optionen zuerst, dann bauen" (docs/konventionen/agents.md §5.1). Priorität: die SevDesk-Integration ist zurückgestellt (kommt später, nicht die nächste Iteration) — damit auch der davon abhängige zahlungs-gesteuerte Zugang (§5/OP-ACCESS-1); die Entscheidungen bleiben gültig, nur der Bau wartet. · Bezug: OP-BILLING-1 · OP-ACCESS-1 · OP-AUTH-1/2 · OP-I18N-1 (HANDOFF §4) · Zielgruppe: Business/Management · IT-Dev/Architektur · CISO/Security · True North: nur indirekt — Zugangs-/Billing-Rahmen; der Zugang darf die drei Leitfragen nicht verstellen, beantwortet aber selbst keine

Kernaussage. Entscheidungs- und Design-Stand für Abrechnung, Bezahlung, Auth und den zahlungs-gesteuerten Zugang zu Taktano (reines B2B, Markteintritt DE → DACH → EU). Entschieden (§2): SevDesk ist System-of-Record für Rechnung/Mahnwesen/E-Rechnung — keine eigene Billing-Plattform; der Zugang bei Zahlungsverzug folgt einem Stufenmodell (Banner → eingeschränkt → gesperrt), server-seitig erzwungen und fail-open bei Sync-Ausfall (§5); Auth-Ziel ist Better Auth (self-host, EU-D1, §7).

1. Rahmen

• Reines B2B. Kunden = Betriebe (Werkstätten). Kein B2C → kein OSS, kein Merchant-of-Record nötig.
• Markteintritt gestuft: Deutschland → DACH → EU. „DACH" ist nicht „EU-light": die Schweiz bricht Annahmen (Nicht-EU, CHF, TWINT, Swiss-QR-Rechnung, eigenes Datenschutzrecht).
• Leitplanken: Everything-as-Code, EU-Datenresidenz/DSGVO, Selbsterklärbarkeit, Audit-Trail, „Derived State nie speichern" (externe Stati werden bewusst gespiegelt, s. §5).

2. Entscheidungen (getroffen)

Thema	Entscheidung	Warum / Alternativen verworfen
Rechnung + Mahnwesen	SevDesk als System-of-Record	Deutsches Tool, kann E-Rechnung (XRechnung/ZUGFeRD) + Mahnstufen. Ersetzt eine eigene Billing-Plattform.
Abo-/Billing-Plattform	keine (SevDesk genügt für B2B)	Stripe Billing · Clerk Billing · RevenueCat · MoR (Paddle/Polar) verworfen — für reines B2B + SevDesk überflüssig; RevenueCat nur bei Mobile-IAP, MoR nur bei B2C-global.
Zahlungs-Rail	Kauf auf Rechnung / Überweisung über SevDesk; PSP optional	Online-Karte/SEPA-Lastschrift nur falls gewünscht → dann Stripe (beste DX) oder Mollie/GoCardless (EU-Zahlarten). Offen (§8).
Steuer	B2B-Reverse-Charge + VAT-ID-Prüfung (VIES) + ZM-Meldung	B2B intra-EU = Reverse-Charge; kein VAT-Einsammeln, daher kein MoR.
Auth / Identity	Better Auth (self-host, EU-D1) als Ziel-IdP	EU-Datenresidenz + EaC + kein per-MAU/Lock-in; Clerk/WorkOS als Fallback (s. OP-AUTH-1/2). Cloudflare Access bleibt Interim/intern.
Zugang bei Zahlungsverzug	Stufenmodell Banner → eingeschränkt → gesperrt, gesteuert aus SevDesk	s. §5 (OP-ACCESS-1).

3. Architektur (Schichten)

• Identität: Better Auth (Org-Modell trägt die SevDesk-Kontakt-ID).
• Geld/Rechnung/Mahnung: SevDesk (SoR).
• Zugangs-Steuerung: Taktano reagiert auf SevDesk-Status, sendet selbst keine Mahnungen.

4. SevDesk als System-of-Record

• REST-API liefert je Kontakt die Mahnstufe offener Rechnungen und (sofern abfragbar) einen Sperr-Status. Webhook nutzen, falls verfügbar, sonst geplantes Polling (Cron Trigger) als verlässliche Basis.
• E-Rechnung: SevDesk erzeugt XRechnung/ZUGFeRD → erfüllt die deutsche B2B-E-Rechnungs-Pflicht (ab 2025) ohne Eigenbau.
• Taktano speichert je Org einen gespiegelten zahlungsstatus + zugangsstufe mit Sync-Zeitstempel (externe Daten, daher bewusst zwischengespeichert — Staleness sichtbar, vgl. Solver-Status „vor X").

5. Zahlungs-gesteuerter Zugang (OP-ACCESS-1)

Stufenmodell — Mahnstufe → Taktano-Zugang (Schwellen admin-editierbar, G-1):

SevDesk-Zustand	Taktano-Zugang
bezahlt / kein Verzug	voll, kein Banner
Zahlungserinnerung / 1. Mahnung	voller Zugang + dezenter Banner „Zahlungsverzug: Rechnung #… offen"
2. Mahnung	eingeschränkt (Default: nur lesend / keine neuen Aufträge) + deutlicher Banner
3. Mahnung oder in SevDesk gesperrt	gesperrt (Sperrseite mit Betrag · Rechnung · Weg zum Begleichen)

Durchsetzung — server-seitig: Das Durable Object prüft die zugangsstufe je Verbindung/Request; „eingeschränkt"/„gesperrt" werden am API/WebSocket erzwungen, der Angular-Banner ist nur Anzeige (ein reiner Client-Banner wäre umgehbar).

Sicherheitsnetze (verbindlich):

• Fail-open bei Sync-Ausfall: Ist SevDesk nicht erreichbar oder der Status veraltet/unbekannt, niemals automatisch sperren — nur auf bestätigten Mahnstatus reagieren (kein Aussperren eines zahlenden Kunden durch einen Integrationsfehler). Staleness sichtbar machen.
• Manueller Override / Kulanz: Admin kann eine Einschränkung mit Grund aufheben (Zahlung unterwegs, Streitfall).
• Audit (OP-AUDIT-1): jeder Stufenwechsel (Banner → eingeschränkt → gesperrt) und jeder Override ist ein Audit-Log-Eintrag (wer · was · wann · Auslöser = SevDesk-Sync).
• Selbsterklärbarkeit: Banner/Sperrseite in Werkstatt-Sprache mit konkreter Rechnung + Lösungsweg, nicht nur „gesperrt".

6. Steuer, E-Rechnung, Währung (Phasenbezug)

Phase	Zahlart/Währung	Steuer & Rechnung	Daten/Recht
DE	SEPA/Überweisung, Kauf auf Rechnung · EUR	USt 19 % · E-Rechnung XRechnung/ZUGFeRD (2025)	DSGVO, AVV je Kunde
+ DACH	AT: EPS · CH: CHF, TWINT, QR-Rechnung	CH = Nicht-EU (Export, ggf. CH-MwSt)	+ CH revDSG
+ EU	iDEAL/Bancontact/BLIK …, Multi-Currency	Reverse-Charge + VIES + ZM · ViDA (~2030)	EU-weit DSGVO

Jetzt schon mitdenken (Umbau sparen): Preise/Abos multi-currency-fähig modellieren (CHF kommt in DACH), VAT-ID-Feld an Org von Anfang an, EU-Datenresidenz ab Tag 1, i18n-Layer vorsehen (OP-I18N-1).

7. Auth — Better Auth (Ziel)

• Better Auth (OSS, self-host auf dem Worker, Identitätsdaten in eurer EU-D1) → Datenresidenz als Compliance + Verkaufsargument; Organizations-Plugin für Mandanten/Seats; JWT/JWKS zur Edge-Verifizierung (auch für den SevDesk-Sync-/Feedback-Pfad).
• Cloudflare Access bleibt Interim/intern; Übergang + Mandanten-Trennung in OP-AUTH-1/2.
• Kein First-Party-Angular-Client → Vanilla-Client in einen Angular-Service wrappen.

8. Offene Punkte (vor dem Bauen zu klären)

1. Was heißt „eingeschränkt" funktional? (nur lesend · keine neuen Aufträge/Optimierung · QS/Kiosk noch erlaubt?)
2. Schwellen-Default (Mahnstufe → Stufe) + Pro-Kunde-Override.
3. Sync-Takt (täglich genügt meist) + Webhook ja/nein (SevDesk-Fähigkeit prüfen).
4. Fail-safe bestätigen: „im Zweifel offen" (empfohlen) vs. „nach X Tagen Stale sperren".
5. PSP optional ja/nein (Online-Zahlung Stripe/Mollie/GoCardless vs. rein Überweisung).
6. Sperr-Status in SevDesk per API verfügbar? Sonst rein aus Mahnstufe + offene-Rechnung-Alter ableiten.

9. Bezug

OP-AUTH-1/2 (IdP/Mandanten) · OP-BILLING-1 (SevDesk/Steuer/E-Rechnung) · OP-ACCESS-1 (Zugangs-Steuerung) · OP-I18N-1 (Mehrsprachigkeit/Multi-Currency) · OP-AUDIT-1 (Audit) · OP-DOCS-5/OP-AI-4 §5 (Berechtigung) · G-1 (konfigurierbare Schwellen) · True-North (Zugang darf die 3 Leitfragen nicht verstellen).

---

↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)