Abrechnung, Organisationen & Rückerstattungen
Abrechnungseinstellungen
Modell
- Ein aktives Gateway für die gesamte Plattform (kein Warenkorb mit mehreren Anbietern).
- Anmeldedaten und aktiver Fahrer: Admin → Einstellungen → Zahlungen.
- Webhooks: POST /webhooks/{driver} (CSRF-ausgenommen).
Verfügbare Anbieter
| Driver | Implemented | Best for |
|---|---|---|
| stripe | Yes | Global cards, Checkout, mature subscriptions |
| paddle | Yes | Merchant of Record, tax-heavy SaaS |
| mollie | Yes | European methods + recurring mandates |
| airwallex | No (credentials UI only) | Future multi-currency; not selectable yet |
| fake | Tests only | PHPUnit; blocked by launch-check in production |
Betreiber-Checkliste
- Wählen Sie den aktiven Zahlungsanbieter.
- Fügen Sie die API-Schlüssel und das Webhook-Geheimnis für diesen Anbieter ein.
- Registrieren Sie die Produktions-Webhook-URL im Dashboard des Anbieters.
- Führen Sie einen Test-Checkout mit Testschlüsseln durch, bevor Sie live gehen.
- Lass „Fake“ niemals als stummen Fallback stehen – Konfigurationsfehler sollen laut auftreten.
Abonnementmodell (Zusammenfassung)
- Ein Abonnement pro Installation (nicht pro Organisation).
- Add-ons werden an dieses Installationsabonnement / diese Berechtigung angehängt.
- Der Provider-Client-Objekt wird dem Organisationsabrechnungsprofil zugeordnet.
- Verlängerung stornieren: bis zum Ende des Zeitraums nutzbar, danach Soft-Delete-Pfad (Geschäftsregeln).
- Zahlungsfehler: Mahnung → Gnadenbanner → Aussetzen → Soft-Delete → Hard-Delete nach Aufbewahrungsdauer.
Gnade und Bindung : Admin → Einstellungen → Abrechnung
Geplante Aufgabe: billing:process-lifecycle (Compose-Scheduler).
Rückerstattungen
Kundenfluss
- Im Tab „Installation Billing“ übermittelt ein berechtigtes Organisationsmitglied eine „Erstattungsanfrage“ (optional mit Rechnungsreferenz).
- Pro Installation jeweils nur eine ausstehende Anfrage (durch den Dienst erzwungen).
- Der Kunde wird per E-Mail über die Genehmigung bzw. Ablehnung benachrichtigt, wenn SMTP funktioniert.
Admin-Flow
- Admin → Rückerstattungen zeigt ausstehende Anfragen an.
- Genehmigen oder ablehnen.
Screenshot-Platzhalter: Liste der Admin-Rückerstattungsanfragen mit „Genehmigen/Ablehnen“
Was passiert bei „Genehmigen“?
Ungefähre Abfolge (BillingService::approveRefund + Gateway):
- Rufen Sie den Zahlungsanbieter auf, um die Rückerstattung für die neueste Zahlung auszuführen (vollständig oder teilweise, je nach Implementierung).
- Abonnement des Anbieters kündigen.
- Markieren Sie die Installation für die sofortige Beendigung / die Soft-Löschung.
- Setze hard_delete_after mithilfe von refund_hard_delete_days (Standard: 7 Tage, nicht das normale 30-Tage-Soft-Delete-Fenster).
- Deaktivieren Sie den Zugriff auf die Edge, sodass der Storefront offline ist.
- Benachrichtigen Sie den Kunden.
- Wenn hard_delete_after abläuft, löscht der Lifecycle-Job hart: löscht Backups, zerstört Host-Ressourcen und entfernt Mandantendaten wie implementiert.
Nebenwirkungen (Operator-Messaging)
| Topic | Effect |
|---|---|
| Money | Provider refund of the latest payment path (gateway-specific). |
| Access | Installation stops being usable quickly (soft-deleted / suspended). |
| Data retention | Short window (default 7 days) then hard delete. |
| Backups | Purged on hard delete path. |
| Re-open | Not a simple “undo”; customer would need a new installation/checkout. |
Im Gegensatz zu anderen Ausgängen
| Action | Typical effect |
|---|---|
| Cancel renewal | Runs until period end; then soft-delete with longer retention |
| Approved refund | Immediate terminate path; shorter hard-delete (default 7 days) |
| ToS suspend (admin) | Offline; no automatic refund |
| Payment failure | Grace banner → suspend → soft-delete rules |
Organisationen und Sitze
Persönliche Organisation
Automatisch erstellt bei der Anmeldung. Der Benutzer ist der Eigentümer. Die Limits stammen von:
- Admin → Einstellungen → Deployments → Standard: maximale Installationen / maximale Seats
- Oder Admin-Überschreibungen im Organisationsdatensatz
Teamorganisationen
Inhaber/Administratoren können Team-Organisationen erstellen (siehe Kunden-Organisationsoberfläche). Sitzplätze und Installationskontingente gelten pro Organisation.
Rollen
| Role | Typical powers |
|---|---|
| Owner | Full org control, billing, members |
| Admin | Manage members & installs |
| Member | Work on installations (no full billing admin) |
| Billing | Billing-focused access |
„Exakte Gates folgen den Richtlinien in der App; behandle Besitzer/Admins als privilegiert.“
Einladungen
- Lädt bestehende Nutzer der Plattform ein (die E-Mail muss bereits ein Konto haben).
- Es gibt keine MVP-„Einladung per E-Mail, die ein Konto von Grund auf neu erstellt“.
- Sitzprüfung: Einladungen können nicht über die maximale Anzahl der Sitze hinaus gesendet werden.
Admin-Überschreibungen
Plattformadministratoren können in der Admin-Organisationen-UI, wenn verfügbar, die Werte für „max_seats“ und „max_installations“ pro Organisation erhöhen oder senken.