Postmortem: # English version below
Post Mortem
Référence incident
TSR-3440
Service concerné
Paiements en magasins Magellan, Nexo.
Impact client
Impossibilité pour les porteurs d’effectuer des paiements en magasins.
Synthèse de l’incident
- 29 juin 10h40 : mise en production.
- 29 juin 14h38 : début de l’incident.
- 29 juin 15h03 : création d’une cellule de crise dédiée. Début des investigations.
- 29 juin 15h17 : déploiement d’une première action corrective suite aux analyses. Baisse des erreurs mais le problème est toujours présent. Poursuite des investigations.
- 29 juin 15h27 : annulation de la mise en production.
- 29 juin 15h28 - 16h56 : déploiement de diverses actions correctives suites aux analyses.
- 29 juin 16h56 : reprise du trafic.
- 29 juin 17h32 : fin de l’incident.
Root cause
L'incident est survenu à la suite d'une mise en production ayant entraîné une évolution dans les échanges avec un prestataire externe.
À cette occasion, un paramètre technique, documenté comme étant facultatif par le prestataire externe, pour les paiements en magasin n'était plus transmis dans les requêtes. Contrairement au comportement attendu, l'absence de ce paramètre a conduit le système du partenaire à rejeter systématiquement les demandes d'autorisation des paiements en magasin.
Actions à entreprendre par Payplug
| Symptômes |
Actions |
| Paramètre facultatif rendu obligatoire et rejeté par le prestataire externe. |
Correctif en cours chez le prestataire externe. |
| Prise en compte différée des changements de configuration après une mise à jour de certaines instances. |
Ajout d'une étape systématique de redémarrage du service à l'issue des mises à jour des instances afin de garantir l'application immédiate de la nouvelle configuration. |
==============ENGLISH VERSION==============
Post Mortem
Incident reference
TSR-3440
Payment services affected by the incident
Magellan and Nexo in-store payments.
Client impact
Cardholders were unable to make in-store payments.
Incident Overview
- 29 June, 10:40am: production deployment.
- 29 June, 2:38pm: incident began.
- 29 June, 3:03pm: a dedicated crisis management team was established. Investigations commenced.
- 29 June, 3:17pm: a first corrective action was deployed following the initial analysis. The error rate decreased, but the issue persisted. Investigations continued.
- 29 June, 3:27pm: the production deployment was rolled back.
- 29 June, 3:28pm – 4:56pm: various corrective actions were deployed following the analysis.
- 29 June, 4:56pm: traffic resumed.
- 29 June, 5:32pm: incident resolved.
Root cause
The incident occurred following a production deployment that introduced changes to the interactions with an external service provider.
As part of these changes, a technical parameter for in-store payments, documented by the external service provider as optional, was no longer included in the requests. Contrary to the expected behaviour, the absence of this parameter caused the partner's system to systematically reject in-store payment authorisation requests.
Actions to be taken by Payplug
| Symptoms |
Actions |
| An optional parameter was treated as mandatory by the external service provider, resulting in rejected requests. |
A fix is currently being implemented by the external service provider. |
| Configuration changes were not applied immediately following updates to certain instances. |
A mandatory service restart step will be added after instance updates to ensure that the new configuration is applied immediately. |
