Mobilität & Autovermietung · Vertiefung
Zahlungsabwicklung, Anzahlung & Rückerstattung
Zahlungen sind der sensibelste technische Block: doppelte Hooks, Race Conditions bei parallelen Tabs oder manuelle Korrekturen im Backoffice erzeugen operative Albträume. Wir modellieren den Zahlungsstatus als integralen Teil des Buchungsobjekts, nicht als lose Zusatzspalte – inklusive dokumentierter Übergänge (authorized → captured → partially_refunded).
Anbindung PSP & Webhook-Sicherheit
Wir signieren und validieren Webhook-Payloads, speichern Rohereignisse kurzzeitig für forensische Prüfungen und vermeiden doppelte Mutationen über Idempotenz-Keys. Fallback-Polling ist dokumentiert für Ausfall-Szenarien Ihres Providers.
Geschäftsregeln statt harter Sonderfälle
Kaution vs. Anzahlung vs. Schlussrechnung definieren wir als Zustandsdiagramm; Refund-Mechanismen koppeln an dokumentierte Storno- und Schadensflows. So bleibt Reporting glättbar für Finanzen ohne Excel-Korrekturen.
Compliance-Hinweise
PCI-Relevantes bleibt wenn möglich Hosted Fields / Redirect-Flows beim PSP. Smartforward vermeidet unkontrollierte PAN-Speicherung und dokumentiert Token-Lifecycle klar im Betriebshandbuch.
Praktische Checkliste
- Mapping Buchungsstatus ↔ PaymentIntent Status dokumentiert.
- Timeout & Retry Regeln für langsames Mobilnetz definiert.
- Monatsabschluss Exportformat für Finanz definiert vor Go-live.
- Support-Playbook: wie man hängende Authorizations manuell löst.
Häufige Fragen
Welchen PSP empfehlen wir?
Das hängt von Gebührenstruktur, Kartentypen-Anteil, Apple/Google Pay Bedarf und SLA. Wir führen Vergleichstabellen; Vertragsverhandlung bleibt bei Ihnen oder Ihrem Payment-Berater.
Supporten wir SEPA Lastschrift?
Wo regulatorisch und PSP-seitig möglich, ja – mit verlängerten Clearing-Zyklen in UX transparent gemacht.
Was passiert bei Chargebacks?
Events werden geloggt und optional mit CRM getaggt. Strategische Beantwortung liegt beim operativen Team; technisch liefern wir Datenextrakt.
Können Gutscheine oder Corporate Billing greifen?
Ja mittels separater Zahlungsklassen im gleichen Zustandsmodell – jedoch nur nach klarem Business-Entscheid für Fraud-Risiko.