Lebenszyklus einer Zahlung

Überblick

Jede Zahlung in tikento durchläuft eine bestimmte Abfolge von Statuse. Übergänge zwischen Statusen erfolgen automatisch auf Basis von Webhook-Benachrichtigungen des Zahlungs-Gateways. Der Veranstalter sieht den aktuellen Status im Bereich Teilnehmer und in den Registrierungsdetails.

Zahlungsstatuse

Übergangsdiagramm

         Zahlung erstellt
               │
               ▼
           ┌────────┐
           │pending │
           └───┬────┘
               │
       ┌───────┼───────┐
       ▼       ▼       ▼
   ┌──────┐ ┌────┐ ┌───────┐
   │failed│ │paid│ │expired│
   └──────┘ └─┬──┘ └───────┘
              │
       ┌──────┴──────┐
       ▼             ▼
┌──────────┐  ┌──────────────────┐
│refunded  │  │partially_refunded│
└──────────┘  └──────────────────┘

Übergänge sind unwiderruflich: paid kann nicht zu pending zurückkehren, und refunded nicht zu paid.

Reservierung (Reservation)

Vor der Zahlungserstellung erstellt tikento eine Reservierung — eine temporäre Sicherung des Tickets, damit es nicht an einen anderen Teilnehmer geht, während der erste bezahlt.

So funktioniert die Reservierung

1. Der Teilnehmer klickt "Bezahlen" — tikento erstellt eine Reservierung mit TTL 15 Minuten.
2. Vom verfügbaren Ticketkontingent wird der reservierte Platz abgezogen.
3. Der Teilnehmer wird auf die Zahlungsseite des Gateways weitergeleitet.
4. Bei erfolgreicher Zahlung wird die Reservierung zur bestätigten Registrierung.
5. Bei Ablauf des TTL wird die Reservierung automatisch freigegeben, das Ticket wird wieder verfügbar.

Die Reservierung verhindert die Situation, dass zwei Teilnehmer gleichzeitig das letzte Ticket bezahlen.

Webhook-Verarbeitung

tikento erfährt das Zahlungsergebnis über einen Webhook — eine HTTP-Anfrage des Zahlungs-Gateways an die tikento-Server.

Ablauf

1. Das Gateway (YooKassa, Tochka, Telegram) sendet eine POST-Anfrage an die Webhook-URL von tikento.
2. tikento überprüft die Signatur der Anfrage (jedes Gateway verwendet seinen eigenen Signaturmechanismus).
3. Die Zahlung aktualisiert den Status in der Datenbank.
4. Bei Status paid wird die Teilnehmerregistrierung bestätigt, eine E-Mail mit dem Ticket gesendet.
5. Bei Status failed oder expired wird die Reservierung freigegeben.

Wiederholte Zustellungen

Wenn tikento den Webhook nicht verarbeiten konnte (z. B. 5xx zurückgegeben hat), wiederholt das Gateway die Anfrage:

• YooKassa: bis zu 10 Versuche mit exponentiellem Backoff
• Tochka: bis zu 5 Versuche mit 5-Minuten-Intervall

Dank Idempotenzschlüsseln ist die wiederholte Verarbeitung desselben Webhooks sicher und erzeugt keine Duplikate.

Idempotenz-Schutz

Jede Zahlungsoperation in tikento ist durch einen Idempotenzschlüssel geschützt — eine eindeutige Kennung, die garantiert, dass die Operation genau einmal ausgeführt wird.

Warum das nötig ist

• Teilnehmer hat versehentlich zweimal auf "Bezahlen" geklickt — es wird nur eine Zahlung erstellt
• Webhook kam wegen Timeout erneut an — der Status wird nur einmal aktualisiert
• Netzwerkausfall hat die Anfrage unterbrochen, Client hat erneut gesendet — Geld wird nicht doppelt abgebucht

So funktioniert es

1. Bei der Zahlungserstellung generiert tikento einen Idempotency-Key (UUIDv7).
2. Der Schlüssel wird im Header der Anfrage an das Gateway gesendet.
3. Wenn das Gateway eine wiederholte Anfrage mit demselben Schlüssel erhält, gibt es das Ergebnis der ersten Operation zurück.
4. tikento speichert den Schlüssel in Redis mit TTL 24 Stunden.

Zusammenhang zwischen Zahlungs- und Registrierungsstatus

Der Zahlungsstatus beeinflusst direkt den Registrierungsstatus des Teilnehmers:

Bei aktivierter Moderation kann zwischen Zahlung und dem endgültigen Status registered ein Zwischenschritt der Prüfung durch den Veranstalter liegen.

Zahlungshistorie einsehen

Alle Zahlungen und ihre Statuse sind im Bereich Teilnehmer Ihrer Veranstaltung verfügbar. Für jeden Eintrag werden angezeigt:

• Aktueller Zahlungsstatus
• Zahlungsmethode (Karte, SBP, Stars)
• Betrag und Währung
• Datum und Uhrzeit der Erstellung / Zahlung / Erstattung
• Idempotenzschlüssel (für die Diagnose)
• Historie der Statusübergänge

Zum Export von Zahlungsdaten — Zahlungsexport und Berichte.