Go-live-Checkliste

Arbeiten Sie diese Checkliste vor der ersten echten Zahlung durch. Jeder Punkt verweist auf die Anleitung mit den Details — schlägt ein Punkt fehl, beheben Sie ihn und testen Sie erneut im Testmodus, bevor Sie etwas auf Live umstellen.

Konto und Zahlungsmethoden#

• Die Kontoverifizierung (KYC) ist abgeschlossen und Live-Zahlungen sind freigeschaltet (FlowAlp Pay Konto erstellen).
• Alle beworbenen Zahlungsmethoden sind mit Live-Verträgen aktiviert (Zahlungsmethoden aktivieren).
• Zahlungsmethoden und Provider sind vom Testmodus zurück auf Live gestellt (Testing für Entwickler).

Zugangsdaten und Konfiguration#

• Das Produktions-API-Secret liegt in einem Secret Manager oder in Umgebungsvariablen — nicht im Code oder in Repositories (API-Zugangsdaten).
• Test- und Staging-Secrets sind aus der Produktionskonfiguration entfernt.
• Kein Secret erreicht jemals Browser, mobile Apps oder Logs.
• API-Version v1.16 wird in allen Aufrufen konsistent verwendet (API-Versionen und Changelog).
• SignatureCheck gelingt aus der Produktionsumgebung mit den Produktions-Zugangsdaten.

Checkout und Redirect-URLs#

• Die Redirect-URLs für success, failed und cancel zeigen auf Ihre Produktionsdomain und sind über HTTPS erreichbar.
• Jede Bestellung sendet eine eindeutige referenceId, damit Zahlungen immer Bestellungen zugeordnet werden können (Erste API-Anfrage).
• Eingebettete Checkouts (iFrame oder Modal) sind auf den Zielbrowsern und -geräten getestet, inklusive Zahlungsmethoden, die einen Redirect aus dem Frame erzwingen (Checkout-Embedding im Überblick).

Webhooks#

• Ein öffentlicher HTTPS-Webhook-Endpoint ist konfiguriert (Webhooks konfigurieren).
• Die Signaturprüfung ist aktiv, unsignierte oder ungültige Zustellungen werden abgelehnt (Webhook-Signaturen prüfen).
• Der Handler ist idempotent: Wiederholte Zustellungen desselben Ereignisses verarbeiten eine Bestellung nie doppelt.
• Der Endpoint bestätigt Zustellungen schnell — innerhalb von 20 Sekunden — und verlagert schwere Arbeit in eine Queue.
• Der Bestellstatus ändert sich nur nach einem verifizierten Webhook oder einem API-Abruf — nie allein aufgrund des Redirects.

Fehlerbehandlung und Resilienz#

• Retries mit begrenztem exponentiellem Backoff und Jitter decken 5xx-Antworten und das Rate-Limit-Muster 405-dann-403 ab (Rate Limits).
• Die Zahl der Wiederholungen ist begrenzt; anhaltende Fehler lösen einen Alarm aus statt einer Schleife.
• Ausgehende API-Aufrufe haben sinnvolle Timeouts.
• Logs erfassen Statuscodes und Korrelationsreferenzen — niemals Secrets oder vollständige Kartendaten (Errors).

Abstimmung und Betrieb#

• Transaktionen werden mit Ihren Bestellungen abgestimmt, Auszahlungen mit Ihrem Bankkonto (Transactions auflisten und abrufen, Auszahlungen und Abstimmung).
• Der Prozess für Rückerstattungen und Stornierungen ist definiert und getestet (Charge, Capture, Refund und Cancel).
• Ein Plan zur Rotation der API-Schlüssel existiert, und Schlüssel lassen sich ohne Ausfallzeit tauschen (API-Zugangsdaten).
• Ihr Team weiss, wo die Request-Logs im Dashboard zu finden sind und an wen intern eskaliert wird.