INCIDENT PROCESSING | Perturbations plateforme de paiement / Payment platform disruptions

Update timeline

1. identified Jan 22, 2025, 04:25 PM UTC

   FR Nous avons identifié des difficultés sur le processing des paiements e-commerce. Pas d'impact sur les paiements sur TPE. Une action est en cours pour rétablir le service EN We have identified ongoing difficulties on the e-commerce payment processing. No impact on the POS terminals payments. An action is ongoing to resume service

2. monitoring Jan 22, 2025, 04:38 PM UTC

   TSR-1177 - Début / Start : 22/01/2024 16h54 CET - Fin / End : 22/01/2024 17h28 CET - Catégorie / Category : Production - Processing - Responsabilité / Responsibility : Payplug FR L'incident est en cours de résolution. Il y a eu un impact sur le service e-commerce entre 16h54 et 17h09 puis entre 17h13 et 17h28 Le service est rétabli depuis 17h28. Nous continuons à surveiller la reprise du service. EN Incident is being resolved. There was an impact on e-commerce service between 4.54pm and 5.09pm then between 5.13pm and 5.28pm. Service is restored since 5.28pm. Service recovery is still under monitoring.

3. resolved Jan 22, 2025, 07:36 PM UTC

   This incident has been resolved.

4. postmortem Jan 24, 2025, 04:57 PM UTC

   _English version below_ **Référence incident** TSR-1177 **Service concerné** Paiements e-commerce. **Impact client** Service interrompu sur deux plages de 15 minutes. **Synthèse de l’incident** * **22 janvier - 16h54 : début de l’incident.** * **22 janvier - 16h57 :** création de la cellule incident majeur. * **22 janvier - 17h04 :** décision de rollback du service API. * **22 janvier - 17h07 :** redémarrage d’une instance. * **22 janvier - 17h09 : reprise du service sur l’instance redémarrée.** * **22 janvier - 17h10 :** redémarrage des autres instances. * **22 janvier - 17h12 :** temporisation du rollback vu que le redémarrage semble suffisant. * **22 janvier - 17h13 : réplique de l’incident.** Décision de rollback sur toutes les instances. * **22 janvier - 17h28 :** **reprise du service.** * **22 janvier - 17h32 :** rollback effectif sur toutes les instances. **Fin de l’incident.** **Contexte** Les flux de paiements sont répartis sur plusieurs instances sur lesquelles des actions peuvent être prises de manière individuelle. Une livraison du service API opérée la veille de l’incident a engendré une augmentation du nombre de messages transitant sur la plateforme, ce qui était anticipé. **Root cause** Le service de gestion des messages transitant sur la plateforme est arrivé à saturation. Les tentatives de connexion du service API à ce service de gestion des messages sont toutes tombées en échec, ce qui a fini par faire tomber tout le service. ‌ **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Saturation du service de gestion des messages. | Court terme - Montée vers une version pouvant encaisser une charge plus importante. Moyen terme - Comprendre les raisons de la saturation. | | Interruption du service API provoqué par la saturation du service de gestion des messages. | Reproduire ce comportement en environnement hors production pour analyser la stabilité du service API. Des actions seront prises en conséquence pour améliorer la résilience du service API vis à vis d’une saturation du service de gestion des messages | | Mise en production non conforme au processus défini. | Faire des rappels de processus aux équipes. | | Délai de résolution trop long. | Analyse de la chronologie de l’incident et élaboration d’actions en conséquence. | ‌ ==============ENGLISH VERSION============== **Incident reference** TSR-1177 **Payment services affected by the incident** E-commerce payments. **Client impact** Service interrupted for two periods of 15 minutes. **Incident Overview** * **January 22nd - 4:54pm : incident beginning.** * **January 22nd - 4:57pm :** major incident response team created. * **January 22nd - 5:04pm :** decision to rollback API service. * **January 22nd - 5:07pm :** restart of one instance * **January 22nd - 5:09pm : service restored on restarted instance.** * **January 22nd - 5:10pm :** restart of the other instances. * **January 22nd - 5:10pm :** rollback on hold on other instances since restart seems to fix the incident. * **January 22nd - 5:13pm : incident restart.** Decision to rollback all instances. * **January 22nd - 5:28pm : service restored.** * **January 22nd - 5:28pm :** All instances rollbacked. **Incident ending.** **Context** Payment flows are distributed across multiple instances, on which actions can be taken individually. A delivery of the API service performed the day before the incident caused an increase in the number of messages transiting on the platform, which was anticipated. **Root cause** The message management service on the platform reached saturation. All connection attempts from the API service to the message management service failed, ultimately bringing down the entire service **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Saturation of the message management service. | Short term - Upgrade to a version capable of handling a higher load. Medium term - Understand the reasons for the saturation. | | API service interruption caused by the saturation of the message management service. | Reproduce this behavior in a non-production environment to analyze the stability of the API service. Actions will be taken accordingly to improve the API service's resilience to saturation of the message management service. | | Production deployment not compliant with defined process. | Remind teams of the defined processes. | | Resolution delay too long. | Analyze the incident timeline and develop actions accordingly. |