PayPlug Outage History

# _English version below_ # Post Mortem **Référence incident** TSR-3011 **Service concerné** Paiements e-commerce, 3DS et en magasins. **Impact client** Impossibilité pour les porteurs d’effectuer des paiements. **Synthèse de l’incident** * **2 mars 12h26 :** déploiement d’une mise en production. * **2 mars 12h28 : début de l’incident.** * **2 mars 12h29 :** première remontée d’alerte. * **2 mars 12h33 :** création d’une cellule de crise dédiée. Début des investigations. * **2 mars 12h37 :** identification d’erreurs sur un service. * **2 mars 12h56 : identification de l’origine de l’incident.** * **2 mars 13h :** mise en place d’actions correctives. * **2 mars 13h01 : reprise du trafic e-commerce & 3DS.** * **2 mars 13h38 :** remontée d’erreurs sur certains paiements en magasins. Poursuite des investigations. * **2 mars 13h50 :** identification et redémarrage des services en erreur. **Fin de l’incident.** ‌ **Contexte** N/A **Root cause** Une mise en production a entraîné la mise en pause des points d’entrées des services acceptant les transactions. Ces points d’entrées étant en pause, ils n’acceptaient plus les transactions et ont causé l’interruption du trafic. ‌ **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Déploiement d’une mise en production sur un horaire critique. | Rappel du processus de déploiement pour éviter les mises en production sur un horaire critique. | | Monitoring défaillant sur les points d’entrées des services acceptant les transactions. | Renforcement du monitoring sur les points d’entrées et sur les services répartissant les transactions. | | Absence de contrôle sur un certificat spécifique suite déploiement d’une mise en production. | Ajout de contrôle pour vérifier l’état du certificat après déploiement d’une mise en production. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3011 **Payment services affected by the incident** E-commerce payments, 3DS and in-store payments. **Client impact** Cardholders were unable to make payments. **Incident Overview** * **2 March 12:26pm:** production deployment. * **2** **March 12:28pm:** **start of the incident.** * **2 March 12:29pm:** first alert raised. * **2 March 12:33pm:** dedicated crisis team established. Investigations begin. * **2 March 12:37pm:** errors identified on a service. * **2 March 12:56pm:** **root cause of the incident identified.** * **2 March 1:00pm:** corrective actions implemented. * **2 March 1:01pm: resumption of e-commerce and 3DS traffic.** * **2 March 1:38pm:** errors reported on certain in-store payments. Investigations continue. * **2 March 1:50pm:** identification and restart of the affected services. **End of the incident.** ‌ **Context** N/A **Root cause** A production deployment resulted in the pausing of the entry points of the services handling transactions. As these entry points were paused, they no longer accepted transactions, which caused the interruption of traffic. ‌ **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Production deployment carried out during a critical time window. | Reminder of the deployment process to avoid production deployments during critical time windows. | | Insufficient monitoring on the entry points of the services accepting transactions. | Strengthening of monitoring on the entry points and on the services distributing transactions. | | Lack of verification of a specific certificate following a production deployment. | Addition of checks to verify the status of the certificate after a production deployment. |

# _English version below_ # Post Mortem **Référence incident** TSR-2981 **Service concerné** Paiements E-commerce et 3DS. **Impact client** Impossibilité d’effectuer des paiements pour les porteurs. **Synthèse de l’incident** * **21 février 5h : début de l’incident.** * **21 février 6h23 :** remontée d’alerte. Le seuil d’erreur est trop faible à ce stade pour déclencher l’astreinte. * **21 février 8h32 :** création d’une cellule de crise dédiée par l’astreinte. Début des investigations. * **21 février 8h34 :** identification d’échecs de paiements provenant d’un réseau bancaire spécifique. * **21 février 9h-13h :** poursuite des analyses. * **21 février 13h30 : fin de l’incident.** * **21 février 14h41 :** confirmation par le réseau d’un incident chez eux. **Contexte** N/A **Root cause** Incident externe provenant d’un réseau bancaire. ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-2981 **Payment services affected by the incident** E-commerce payments & 3DS. **Client impact** Cardholders were unable to make payments. **Incident Overview** * **21 February 5:00am: start of the incident.** * **21 February 6:23am:** alert raised. The error threshold is too low at this stage to trigger the on-call escalation team. * **21 February 8:32am:** dedicated crisis team established by the on-call team. Investigations begin. * **21 February 8:34am:** payment failures identified originating from a specific banking network. * **21 February 9:00am – 1:00pm:** ongoing analysis. * **21 February 1:30pm: end of the incident.** * **21 February 2:41pm:** confirmation from the network of an incident on their side. **Context** N/A **Root cause** External incident originating from a banking network.

# _English version below_ # Post Mortem **Référence incident** TSR-2951 **Service concerné** Portail **Impact client** Problèmes de connexion pour accéder au Portail et messages d’erreurs intempestifs une fois connecté. **Synthèse de l’incident** * **16 février 15h15 :** déploiement d’une mise en production. * **16 février 15h18 :** des problèmes de connexions - déconnexions ainsi que des messages d’erreurs apparaissent sur le Portail. **Début de l’incident.** * **16 février 15h34 :** remontée d’alerte. Début des investigations. * **16 février 15h53 :** création d’une cellule incident majeur. * **16 février 15h58 :** communication Statuspage. Identification d’une mise en production concordant avec le début de l’incident. Lancement de l’annulation de la mise en production. * **16 février 16h08 :** échec de l’annulation de la mise en production. * **16 février 16h25 : identification de l’origine de l’incident.** * **16 février 16h33 :** des problèmes de connexions persistent. Lancement du retour à une version précédente de certains services défaillants identifiés. * **16 février 16h54 :** redémarrage des services avec la version précédente. * **16 février 16h59 :** fin des problèmes de connexions sur le Portail. * **16 février 17h06 :** fin des messages d’erreurs sur le Portail. **Fin de l’incident.** * **17 février 16h16 :** **résurgence des erreurs.** * **17 février 16h29-18h35 :** création d’une cellule de crise et reprise des analyses. * **17 février 18h40 : identification de l’origine de l’incident et déploiement d’un correctif.** * **17 février 18h52 : Fin de l’incident.** **Contexte** N/A **Root cause** Une mise en production a généré des problèmes d’accès entre nos services internes. Ces problèmes ont engendré une déconnexion forcée de l’utilisateur qui revenait sur sa page d’authentification. La seconde occurrence a été provoquée suite à une nouvelle mise en production qui a récupéré les mauvais identifiants suite au rollback de la veille. ‌ **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Désynchronisation de certains paramètres d’une clef API. | Mise à jour de l’ensemble des paramètres désynchronisés. | | Renouvellement automatique de la clef API. | Investigations en cours pour empêcher le renouvellement automatique de la clef API. | | Absence d’alerte concernant la désynchronisation de certains paramètres de l’API. | Ajout de messages d’erreurs en cas de désynchronisation des paramètres & amélioration de l’alerting. | | Complexités sur un service de déploiement. | Améliorer les déploiements sur le service gérant les secrets \(API KEY, mots de passe internes...\). | | Déconnexion forcée si un service sur l’ensemble est indisponible. | Améliorations en cours pour éviter de déconnecter les utilisateurs dès qu’un service est indisponible. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-2951 **Payment services affected by the incident** Portal **Client impact** Connection issues when accessing the Portal and unexpected error messages once logged in. **Incident Overview** * **16 February 3:15pm:** deployment to production. * **16 February 3:18pm:** connection issues – disconnections as well as error messages appear on the Portal. **Start of the incident.** * **16 February 3:34pm:** alert raised. Investigations begin. * **16 February 3:53pm:** major incident team established. * **16 February 3:58pm:** Statuspage communication issued. A production deployment coinciding with the start of the incident is identified. Rollback of the deployment initiated. * **16 February 4:08pm:** rollback of the production deployment unsuccessful. * **16 February 4:25pm: root cause of the incident identified.** * **16 February 4:33pm:** connection issues persist. Rollback to a previous version of certain identified faulty services initiated. * **16 February 4:54pm:** services restarted with the previous version. * **16 February 4:59pm:** end of connection issues on the Portal. * **16 February 5:06pm:** end of error messages on the Portal. **Incident resolved.** * **17 February 4:16pm: Recurrence of errors.** * **17 February 4:29pm–6:35pm:** crisis team established and investigations resumed. * **17 February 6:40pm: root cause identified and fix deployed.** * **17 February 6:52pm: incident resolved.** **Context** N/A **Root cause** A production deployment caused access issues between our internal services. These issues resulted in users being forcibly logged out and redirected back to the authentication page. The second occurrence was triggered by a subsequent production deployment that retrieved incorrect credentials following the rollback carried out the previous day. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Desynchronisation of certain API key parameters. | Update of all desynchronised parameters. | | Automatic renewal of the API key. | Investigations ongoing to prevent the automatic renewal of the API key. | | No alert triggered regarding the desynchronisation of certain API parameters. | Addition of error messages in the event of parameter desynchronisation & improvement of alerting. | | Complexities within a deployment service. | Improvements to deployments on the service managing secrets \(API keys, internal passwords, etc.\). | | Forced logout if any service within the ecosystem becomes unavailable. | Improvements underway to prevent users from being logged out as soon as a service becomes unavailable. |