Startseite
NexoPOS

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

  1. Wählen Sie den aktiven Zahlungsanbieter.
  2. Fügen Sie die API-Schlüssel und das Webhook-Geheimnis für diesen Anbieter ein.
  3. Registrieren Sie die Produktions-Webhook-URL im Dashboard des Anbieters.
  4. Führen Sie einen Test-Checkout mit Testschlüsseln durch, bevor Sie live gehen.
  5. Lass „Fake“ niemals als stummen Fallback stehen – Konfigurationsfehler sollen laut auftreten.
billing-settings

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

  1. Im Tab „Installation Billing“ übermittelt ein berechtigtes Organisationsmitglied eine „Erstattungsanfrage“ (optional mit Rechnungsreferenz).
  2. Pro Installation jeweils nur eine ausstehende Anfrage (durch den Dienst erzwungen).
  3. Der Kunde wird per E-Mail über die Genehmigung bzw. Ablehnung benachrichtigt, wenn SMTP funktioniert.
refund-request

Admin-Flow

  1. Admin → Rückerstattungen zeigt ausstehende Anfragen an.
  2. Genehmigen oder ablehnen.

Screenshot-Platzhalter: Liste der Admin-Rückerstattungsanfragen mit „Genehmigen/Ablehnen“

Was passiert bei „Genehmigen“?

Ungefähre Abfolge (BillingService::approveRefund + Gateway):

  1. Rufen Sie den Zahlungsanbieter auf, um die Rückerstattung für die neueste Zahlung auszuführen (vollständig oder teilweise, je nach Implementierung).
  2. Abonnement des Anbieters kündigen.
  3. Markieren Sie die Installation für die sofortige Beendigung / die Soft-Löschung.
  4. Setze hard_delete_after mithilfe von refund_hard_delete_days (Standard: 7 Tage, nicht das normale 30-Tage-Soft-Delete-Fenster).
  5. Deaktivieren Sie den Zugriff auf die Edge, sodass der Storefront offline ist.
  6. Benachrichtigen Sie den Kunden.
  7. 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
organizations

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.
invitation

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.