INCIDENT SETTLEMENT | Délai reversement 4 septembre / 4th of September settlement delay

Update timeline

1. identified Sep 04, 2025, 09:23 AM UTC

   TSR-2228 - Début / Start : 04/09/2025 - Fin / End : En-cours / Ongoing - Catégorie / Category : Reversement / Settlement - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR Le reversement de certaines opérations de paiement e-commerce et magasin qui aurait dû être effectué aujourd'hui n'a pas pu être effectué dans les temps. La réconciliation financière correspondante sera mise à disposition aujourd'hui. L’origine de l’incident a été identifiée et les virements non exécutés seront automatiquement reportés et traités demain, sans qu’aucune action ne soit nécessaire de votre part. EN The payout of certain e-commerce and in-store payment transactions that should have been carried out today could not be completed on time. The corresponding financial reconciliation will be made available today. The cause of the incident has been identified, and the payments not executed will be automatically postponed and processed tomorrow, with no action required on your part.

2. monitoring Sep 04, 2025, 12:35 PM UTC

   TSR-2228 - Début / Start : 04/09/2025 - Fin / End : En-cours / Ongoing - Catégorie / Category : Reversement / Settlement - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR Nous confirmons le rattrapage des virements qui seront reversés demain. Nous continuons de monitorer le service. EN We confirm the recovery of the transfers, which will be paid out tomorrow. We continue to monitor the service.

3. resolved Sep 05, 2025, 08:43 AM UTC

   TSR-2228 - Début / Start : 04/09/2025 - Fin / End : 05/09/2025 - Catégorie / Category : Reversement / Settlement - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR Les opérations de paiement e-commerce et magasin non reversées hier ont été reversées aujourd'hui. La réconciliation financière correspondante intègre bien les transactions rattrapées. EN The e-commerce and in-store payment operations that were not settled yesterday have been settled today. The corresponding financial reconciliation accurately includes the recovered transactions.

4. postmortem Sep 05, 2025, 12:16 PM UTC

   # _English version below_ # Post Mortem **Référence incident** TSR-2228 **Service concerné** Reversement des paiements e-commerce et magasin. **Impact client** Reversement partiel des transactions. **Synthèse de l’incident** * **4 septembre 7h30 :** début de saturation des files traitant différents flux. **Début de l’incident.** * **4 septembre 8h50 :** détection d’un retard dans le traitement des virements. Création d’une cellule de crise dédiée et début des analyses. * **4 septembre 8h53 :** identification de la saturation de flux dû à une tâche qui tourne en boucle sans succès. * **4 septembre 8h56 :** tests pour répartir certains flux sur des routes secondaires pour éviter la saturation. * **4 septembre 9h09 :** déplacement de certains flux non affectés par l’incident sur d’autres routes. Poursuite des analyses pour tenter de relancer les virements dans la journée. * **4 septembre 10h :** relance des traitements des virements après plusieurs actions menées pour s’assurer d’éviter des effets de bords. * **4 septembre 11h57 :** fin des traitements après l’heure limite. Certains virements seront réalisés le lendemain. * **5 septembre :** reversement des transactions. **Fin de l’incident.** **Contexte** N/A **Root cause** Une mise en production a entraîné une interruption de connexion entre deux API. Une tâche est entrée en boucle et a saturé les différentes routes traitant les flux. ‌ **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence de détection d’alerte. | Amélioration du monitoring pour une meilleure identification en cas d’incident. | | Blocage des traitements causés par une erreur. | Révision de l’architecture des files d’attentes pour s’assurer qu’une tâche en erreur ne puisse pas bloquer l’ensemble des traitements. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-2228 **Payment services affected by the incident** E-commerce & in-store payments settlement. **Client impact** Partial settlement of transactions. **Incident Overview** * **4 September 7:30am –** start of queue saturation processing different flows. **Start of the incident.** * **4 September 8:50am –** detection of a delay in transfer processing. Dedicated crisis unit created and analysis started. * **4 September 8:53am –** identification of flow saturation caused by a task looping unsuccessfully. * **4 September 8:56am –** tests to reroute certain flows through secondary paths to avoid saturation. * **4 September 9:09am –** transfer of some flows not affected by the incident to other routes. Further analysis to attempt to restart transfers during the day. * **4 September 10:00am –** transfer processing restarted after several actions taken to ensure side effects were avoided. * **4 September 11:57am –** processing completed after the cut-off time. Some transfers will be carried out the following day. * **5 September –** transactions paid out. **End of the incident.** **Context** N/A **Root cause** A production deployment caused a connection interruption between two APIs. A task entered a loop and saturated the different routes processing the flows. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | No alert detection. | Improved monitoring for better identification in the event of an incident. | | Blocking of processing caused by an error. | Review of the queue architecture to ensure that a failed task cannot block all processing. |