Cycle de vie du paiement

Apercu

Chaque paiement dans tikento passe par une sequence definie de statuts. Les transitions entre statuts se produisent automatiquement sur la base des notifications webhook de la passerelle de paiement. L'organisateur voit le statut actuel dans la section Participants et dans le detail de l'inscription.

Statuts du paiement

Diagramme des transitions

         creation du paiement
               |
               v
           +--------+
           |pending |
           +---+----+
               |
       +-------+-------+
       v       v       v
   +------+ +----+ +-------+
   |failed| |paid| |expired|
   +------+ +-+--+ +-------+
              |
       +------+------+
       v             v
+----------+  +------------------+
|refunded  |  |partially_refunded|
+----------+  +------------------+

Les transitions sont irreversibles : paid ne peut pas revenir a pending, et refunded ne peut pas revenir a paid.

Reservation (Reservation)

Avant la creation du paiement, tikento cree une reservation -- un verrouillage temporaire du billet pour qu'il ne soit pas pris par un autre participant pendant que le premier paie.

Comment fonctionne la reservation

1. Le participant clique sur "Payer" -- tikento cree une reservation avec TTL 15 minutes.
2. Le nombre de billets disponibles est reduit du nombre de places reservees.
3. Le participant est redirige vers la page de paiement de la passerelle.
4. Si le paiement est effectue -- la reservation se transforme en inscription confirmee.
5. Si le TTL expire -- la reservation est automatiquement liberee, le billet redevient disponible.

La reservation empeche la situation ou deux participants paient le dernier billet en meme temps.

Traitement des webhooks

tikento est informe du resultat du paiement par un webhook -- une requete HTTP de la passerelle de paiement vers les serveurs tikento.

Sequence

1. La passerelle (YooKassa, Tochka, Telegram) envoie une requete POST a l'URL webhook d'tikento.
2. tikento verifie la signature de la requete (chaque passerelle utilise son propre mecanisme de signature).
3. Le paiement met a jour son statut dans la base de donnees.
4. Si le statut est paid -- l'inscription du participant est confirmee, un email avec le billet est envoye.
5. Si le statut est failed ou expired -- la reservation est liberee.

Delivrances repetees

Si tikento n'a pas pu traiter le webhook (par exemple, a renvoye un 5xx), la passerelle repete la requete :

• YooKassa : jusqu'a 10 tentatives avec delai exponentiel
• Tochka : jusqu'a 5 tentatives avec un intervalle de 5 minutes

Grace aux cles d'idempotence, le traitement repete d'un meme webhook est sans danger et ne cree pas de doublons.

Protection par idempotence

Chaque operation de paiement dans tikento est protegee par une cle d'idempotence -- un identifiant unique qui garantit que l'operation n'est executee qu'une seule fois.

Pourquoi c'est necessaire

• Le participant a accidentellement clique deux fois sur "Payer" -- un seul paiement est cree
• Le webhook est arrive en double a cause d'un timeout -- le statut n'est mis a jour qu'une fois
• Une panne reseau a interrompu la requete, le client a renvoye -- l'argent n'est pas debite deux fois

Comment cela fonctionne

1. Lors de la creation du paiement, tikento genere un Idempotency-Key (UUIDv7).
2. La cle est envoyee dans l'en-tete de la requete a la passerelle.
3. Si la passerelle recoit une requete repetee avec la meme cle, elle renvoie le resultat de la premiere operation.
4. tikento met en cache la cle dans Redis avec un TTL de 24 heures.

Lien entre statuts du paiement et de l'inscription

Le statut du paiement affecte directement le statut d'inscription du participant :

Si la moderation est activee, entre le paiement et le statut final registered, il peut y avoir une etape intermediaire de verification par l'organisateur.

Consultation de l'historique des paiements

Tous les paiements et leurs statuts sont disponibles dans la section Participants de votre evenement. Pour chaque enregistrement sont affiches :

• Le statut actuel du paiement
• La methode de paiement (carte, SBP, Stars)
• Le montant et la devise
• La date et l'heure de creation / paiement / remboursement
• La cle d'idempotence (pour le diagnostic)
• L'historique des transitions entre statuts

Pour l'export des donnees de paiement -- Export des paiements et rapports.