Payment Lifecycle

Overview

Every payment in tikento goes through a specific sequence of statuses. Transitions between statuses happen automatically based on webhook notifications from the payment gateway. The organizer can see the current status in the Attendees section and in the registration details.

Payment Statuses

Transition Diagram

         payment creation
               |
               v
           +--------+
           |pending |
           +---+----+
               |
       +-------+-------+
       v       v       v
   +------+ +----+ +-------+
   |failed| |paid| |expired|
   +------+ +-+--+ +-------+
              |
       +------+------+
       v             v
+----------+  +------------------+
|refunded  |  |partially_refunded|
+----------+  +------------------+

Transitions are irreversible: paid cannot return to pending, and refunded cannot return to paid.

Reservation

Before creating a payment, tikento creates a reservation — a temporary hold on a ticket to prevent it from being taken by another attendee while the first one is paying.

How Reservation Works

1. The attendee clicks "Pay" — tikento creates a reservation with a TTL of 15 minutes.
2. The reserved spot is subtracted from the available ticket quantity.
3. The attendee is redirected to the gateway payment page.
4. If payment succeeds — the reservation becomes a confirmed registration.
5. If the TTL expires — the reservation is automatically released, and the ticket becomes available again.

Reservation prevents the situation where two attendees pay for the last ticket simultaneously.

Webhook Processing

tikento learns about payment results through webhooks — HTTP requests from the payment gateway to tikento's servers.

Sequence

1. The gateway (YooKassa, Tochka, Telegram) sends a POST request to tikento's webhook URL.
2. tikento verifies the request signature (each gateway uses its own signing mechanism).
3. The payment status is updated in the database.
4. If the status is paid — the attendee's registration is confirmed, and an email with the ticket is sent.
5. If the status is failed or expired — the reservation is released.

Retry Deliveries

If tikento could not process the webhook (e.g., returned a 5xx), the gateway retries the request:

• YooKassa: up to 10 attempts with exponential backoff
• Tochka: up to 5 attempts at 5-minute intervals

Thanks to idempotency keys, reprocessing the same webhook is safe and does not create duplicates.

Idempotency Protection

Every payment operation in tikento is protected by an idempotency key — a unique identifier that guarantees the operation is executed exactly once.

Why This Is Needed

• The attendee accidentally clicked "Pay" twice — only one payment is created
• A webhook arrived again due to a timeout — the status is updated only once
• A network failure interrupted the request, the client sent a retry — money is not charged twice

How It Works

1. When creating a payment, tikento generates an Idempotency-Key (UUIDv7).
2. The key is sent in the request header to the gateway.
3. If the gateway receives a repeated request with the same key, it returns the result of the first operation.
4. tikento caches the key in Redis with a TTL of 24 hours.

Relationship Between Payment and Registration Statuses

The payment status directly affects the attendee's registration status:

When moderation is enabled, there may be an intermediate review step by the organizer between payment and the final registered status.

Viewing Payment History

All payments and their statuses are available in the Attendees section of your event. For each record, the following is displayed:

• Current payment status
• Payment method (card, SBP, Stars)
• Amount and currency
• Creation / payment / refund date and time
• Idempotency key (for diagnostics)
• Status transition history

For exporting payment data — Payment Export and Reports.