Postmortem: # English version below

Post Mortem

Référence incident

TSR-3752

Service concerné

Paiements e-commerce, 3DS et en magasins.

Impact client

Impossibilité pour les porteurs d'effectuer des paiements.

Synthèse de l’incident

• 17 septembre 19h03 : début de l’incident.
• 17 septembre 19h05 : premières remontées d’erreurs.
• 17 septembre 19h10 : création d’une cellule de crise dédiée et début des investigations.
• 17 septembre 19h14 : communication Statuspage.
• 17 septembre 19h27 : identification de l’origine externe de l’incident chez un hébergeur réseau.
• 17 septembre 19h30 : contact de notre hébergeur réseau pour obtenir la résolution de l’incident.
• 17 septembre 19h52 : lancement des premières actions correctives chez l’hébergeur réseau. Rétablissement partiel des services et poursuite des investigations.
• 17 septembre 20h30 : identification de l’origine de l’incident par l’hébergeur réseau. Lancement de nouvelles actions correctives.
• 17 septembre 20h33 : fin de l’incident.
• 17 septembre 20h34-21h15 : monitoring des différents services.

Root cause

L’incident a été causé par une interruption réseau chez notre hébergeur rendant indisponibles les services nécessaires à la sécurisation et au traitement des transactions de paiement. Cette indisponibilité a empêché le traitement des paiements, aussi bien en ligne qu’en point de vente.

‌

‌Actions à entreprendre par Payplug

Actions à court terme : 

• Sécurisation des interventions firewall : mise en place d’une procédure avec notre hébergeur réseau pour encadrer les modifications de règles réseau avec une mise à jour progressive des datacenters réalisée en heures ouvrées avec information préalable de Payplug.
• Amélioration de l’identification des équipements : mise à jour du nommage des équipements réseau afin de faciliter leur identification et les interventions en cas d’incident.
• Clarification des impacts liés à l’indisponibilité du dernier équipement de sécurité disponible et formalisation de la procédure de bascule vers les nouveaux équipements afin de garantir la continuité des services.
• Amélioration de la documentation technique : centralisation et partage des informations nécessaires à la connexion et à l’administration de l’infrastructure afin de faciliter les interventions de l’équipe.

Actions à moyen terme :

• Simplification de la gestion des accès réseau : utilisation de plages d’adresses IP plutôt que d’adresses individuelles afin de faciliter l’ajout de nouveaux équipements.
• Mise en place d’un accès d’administration alternatif afin de disposer d’un second moyen d’intervention sur l’infrastructure de notre hébergeur réseau et de renforcer la capacité de reprise en cas d’indisponibilité du canal d’administration principal.
• Simplification de l’architecture réseau : suppression des accès directs devenus inutiles entre certaines infrastructures afin de réduire les dépendances et les risques associés.

‌

Actions à entreprendre par l’hébergeur réseau

• Doubler l'infrastructure de pare-feu : déploiement d'un second cluster de pare-feu indépendant, avec adaptation de l'architecture réseau associée afin de limiter l'impact d'une erreur de configuration et renforcer la résilience de l'infrastructure. 

• Mise en place d'une supervision de bout en bout du flux entre les infrastructures applicatives et les équipements critiques articulée autour de trois dispositifs :

  • Déploiement d'une sonde de monitoring au sein de l'environnement applicatif, pour une visibilité directe sur l'état de la plateforme.
  • Intégration d'un mécanisme d'alerte automatique depuis les systèmes de supervision Payplug vers l’hébergeur réseau.
  • Mise en place d'une alarme dédiée à la détection de toute baisse anormale de flux à destination des équipements critiques avec des seuils tenant compte de la temporalité des usages.

‌

==============ENGLISH VERSION==============

Post Mortem

Incident reference

TSR-3752

Payment services affected by the incident

E-commerce, 3DS, and in-store payments.

Client impact

Cardholders were unable to make payments.

Incident Overview

• 17 September, 7:03pm: incident began.
• 17 September, 7:05pm: first errors reported.
• 17 September, 7:10pm: dedicated crisis management team established and investigations commenced.
• 17 September, 7:14pm: Statuspage communication published.
• 17 September, 7:27pm: external root cause identified at a network hosting provider.
• 17 September, 7:30pm: our network hosting provider was contacted to resolve the incident.
• 17 September, 7:52pm: initial corrective actions initiated by the network hosting provider. Partial service restoration and continued investigations.
• 17 September, 8:30pm: root cause identified by the network hosting provider. Further corrective actions initiated.
• 17 September, 8:33pm: incident resolved.
• 17 September, 8:34–9:15pm: monitoring of the various services.

Root cause

The incident was caused by a network outage at our hosting provider, making the services required to secure and process payment transactions unavailable. This unavailability prevented payments from being processed, both online and at points of sale.

‌

Actions to be taken by Payplug

Short-term actions:

• Securing firewall interventions: implementation of a procedure with our network hosting provider to govern network rule changes, with a phased update of the data centres carried out during business hours and prior notification to Payplug.
• Improved equipment identification: updating the naming convention for network equipment to facilitate identification and intervention in the event of an incident.
• Clarification of the impact of the unavailability of the last available security device: formalisation of the procedure for switching over to the new equipment to ensure service continuity.
• Improved technical documentation: centralisation and sharing of the information required to connect to and administer the infrastructure, to facilitate interventions by the team.

Medium-term actions:

• Simplification of network access management: use of IP address ranges rather than individual IP addresses to facilitate the addition of new equipment.
• Implementation of an alternative administration access: provision of a second means of accessing and intervening on the network hosting provider’s infrastructure, strengthening recovery capabilities in the event of unavailability of the primary administration channel.
• Simplification of the network architecture: removal of direct access between certain infrastructures where no longer required, in order to reduce dependencies and associated risks.

‌

Actions to be taken by the network hosting provider

• Duplicate the firewall infrastructure: deployment of a second independent firewall cluster with corresponding adaptation of the associated network architecture in order to limit the impact of a configuration error and strengthen the resilience of the infrastructure.

• Implementation of end-to-end monitoring of the flow between the application infrastructure and critical equipment structured around three components:

  • Deployment of a monitoring probe within the application environment, providing direct visibility into the state of the platform.
  • Integration of an automatic alerting mechanism from Payplug's monitoring systems to the network hosting provider.
  • Implementation of a dedicated alarm to detect any abnormal drop in flow to critical equipment with thresholds that take account of usage patterns over time.

Resolved: This incident has been resolved.

Monitoring: TSR-3752

• Début / Start : 17/09/2026 19:08 CEST
• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR Le retour arrière (rollback) chez notre hébergeur réseau est finalisé et le service est désormais pleinement rétabli. Nos équipes maintiennent une surveillance attentive pour s'assurer de la stabilité globale de la plateforme.

EN The rollback at our network hosting provider has been completed and service is now fully restored. Our teams continue to closely monitor the system to ensure the overall stability of the platform.

Identified: FR Le retour arrière (rollback) chez notre hébergeur réseau est toujours en cours d'exécution. Nous vous tiendrons informés dès le service est rétabli. Veuillez nous excuser pour la gêne occasionnée.

EN The rollback at our network hosting provider is still in progress. We will keep you updated as soon as service is fully restored. We sincerely apologize for any inconvenience caused.

Identified: - Début / Start : 17/09/2026 19:08 CEST

• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR L'origine de l'incident a été identifiée : il s'agit d'un problème réseau chez l'un de nos hébergeurs externes. Un rollback est en cours de leur côté, le service devrait être rétabli très rapidement. Nous vous tiendrons informés.

EN The root cause of the incident has been identified: it is related to a network issue at one of our external hosting providers. A rollback is currently underway on their end, and service should be restored very shortly. We will keep you updated.

Investigating: FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans les meilleurs délais .

EN Investigations are still ongoing. We'll get back to you as soon as possible.

Investigating: FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins depuis 19h03. L'incident est en cours d'analyse.

EN We have identified issues affecting online and in-store payments since 7:03 PM (CEST). An investigation is in progress.

Postmortem: # English version below

Post Mortem

Référence incident

TSR-3752

Service concerné

Paiements e-commerce, 3DS et en magasins.

Impact client

Impossibilité pour les porteurs d'effectuer des paiements.

Synthèse de l’incident

• 17 septembre 19h03 : début de l’incident.
• 17 septembre 19h05 : premières remontées d’erreurs.
• 17 septembre 19h10 : création d’une cellule de crise dédiée et début des investigations.
• 17 septembre 19h14 : communication Statuspage.
• 17 septembre 19h27 : identification de l’origine externe de l’incident chez un hébergeur réseau.
• 17 septembre 19h30 : contact de notre hébergeur réseau pour obtenir la résolution de l’incident.
• 17 septembre 19h52 : lancement des premières actions correctives chez l’hébergeur réseau. Rétablissement partiel des services et poursuite des investigations.
• 17 septembre 20h30 : identification de l’origine de l’incident par l’hébergeur réseau. Lancement de nouvelles actions correctives.
• 17 septembre 20h33 : fin de l’incident.
• 17 septembre 20h34-21h15 : monitoring des différents services.

Root cause

L’incident a été causé par une interruption réseau chez notre hébergeur rendant indisponibles les services nécessaires à la sécurisation et au traitement des transactions de paiement. Cette indisponibilité a empêché le traitement des paiements, aussi bien en ligne qu’en point de vente.

‌

‌Actions à entreprendre par Payplug

Actions à court terme : 

• Sécurisation des interventions firewall : mise en place d’une procédure avec notre hébergeur réseau pour encadrer les modifications de règles réseau avec une mise à jour progressive des datacenters réalisée en heures ouvrées avec information préalable de Payplug.
• Amélioration de l’identification des équipements : mise à jour du nommage des équipements réseau afin de faciliter leur identification et les interventions en cas d’incident.
• Clarification des impacts liés à l’indisponibilité du dernier équipement de sécurité disponible et formalisation de la procédure de bascule vers les nouveaux équipements afin de garantir la continuité des services.
• Amélioration de la documentation technique : centralisation et partage des informations nécessaires à la connexion et à l’administration de l’infrastructure afin de faciliter les interventions de l’équipe.

Actions à moyen terme :

• Simplification de la gestion des accès réseau : utilisation de plages d’adresses IP plutôt que d’adresses individuelles afin de faciliter l’ajout de nouveaux équipements.
• Mise en place d’un accès d’administration alternatif afin de disposer d’un second moyen d’intervention sur l’infrastructure de notre hébergeur réseau et de renforcer la capacité de reprise en cas d’indisponibilité du canal d’administration principal.
• Simplification de l’architecture réseau : suppression des accès directs devenus inutiles entre certaines infrastructures afin de réduire les dépendances et les risques associés.

‌

Actions à entreprendre par l’hébergeur réseau

• Doubler l'infrastructure de pare-feu : déploiement d'un second cluster de pare-feu indépendant, avec adaptation de l'architecture réseau associée afin de limiter l'impact d'une erreur de configuration et renforcer la résilience de l'infrastructure. 

• Mise en place d'une supervision de bout en bout du flux entre les infrastructures applicatives et les équipements critiques articulée autour de trois dispositifs :

  • Déploiement d'une sonde de monitoring au sein de l'environnement applicatif, pour une visibilité directe sur l'état de la plateforme.
  • Intégration d'un mécanisme d'alerte automatique depuis les systèmes de supervision Payplug vers l’hébergeur réseau.
  • Mise en place d'une alarme dédiée à la détection de toute baisse anormale de flux à destination des équipements critiques avec des seuils tenant compte de la temporalité des usages.

‌

==============ENGLISH VERSION==============

Post Mortem

Incident reference

TSR-3752

Payment services affected by the incident

E-commerce, 3DS, and in-store payments.

Client impact

Cardholders were unable to make payments.

Incident Overview

• 17 September, 7:03pm: incident began.
• 17 September, 7:05pm: first errors reported.
• 17 September, 7:10pm: dedicated crisis management team established and investigations commenced.
• 17 September, 7:14pm: Statuspage communication published.
• 17 September, 7:27pm: external root cause identified at a network hosting provider.
• 17 September, 7:30pm: our network hosting provider was contacted to resolve the incident.
• 17 September, 7:52pm: initial corrective actions initiated by the network hosting provider. Partial service restoration and continued investigations.
• 17 September, 8:30pm: root cause identified by the network hosting provider. Further corrective actions initiated.
• 17 September, 8:33pm: incident resolved.
• 17 September, 8:34–9:15pm: monitoring of the various services.

Root cause

The incident was caused by a network outage at our hosting provider, making the services required to secure and process payment transactions unavailable. This unavailability prevented payments from being processed, both online and at points of sale.

‌

Actions to be taken by Payplug

Short-term actions:

• Securing firewall interventions: implementation of a procedure with our network hosting provider to govern network rule changes, with a phased update of the data centres carried out during business hours and prior notification to Payplug.
• Improved equipment identification: updating the naming convention for network equipment to facilitate identification and intervention in the event of an incident.
• Clarification of the impact of the unavailability of the last available security device: formalisation of the procedure for switching over to the new equipment to ensure service continuity.
• Improved technical documentation: centralisation and sharing of the information required to connect to and administer the infrastructure, to facilitate interventions by the team.

Medium-term actions:

• Simplification of network access management: use of IP address ranges rather than individual IP addresses to facilitate the addition of new equipment.
• Implementation of an alternative administration access: provision of a second means of accessing and intervening on the network hosting provider’s infrastructure, strengthening recovery capabilities in the event of unavailability of the primary administration channel.
• Simplification of the network architecture: removal of direct access between certain infrastructures where no longer required, in order to reduce dependencies and associated risks.

‌

Actions to be taken by the network hosting provider

• Duplicate the firewall infrastructure: deployment of a second independent firewall cluster with corresponding adaptation of the associated network architecture in order to limit the impact of a configuration error and strengthen the resilience of the infrastructure.

• Implementation of end-to-end monitoring of the flow between the application infrastructure and critical equipment structured around three components:

  • Deployment of a monitoring probe within the application environment, providing direct visibility into the state of the platform.
  • Integration of an automatic alerting mechanism from Payplug's monitoring systems to the network hosting provider.
  • Implementation of a dedicated alarm to detect any abnormal drop in flow to critical equipment with thresholds that take account of usage patterns over time.

Resolved: This incident has been resolved.

Monitoring: TSR-3752

• Début / Start : 17/09/2026 19:08 CEST
• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR Le retour arrière (rollback) chez notre hébergeur réseau est finalisé et le service est désormais pleinement rétabli. Nos équipes maintiennent une surveillance attentive pour s'assurer de la stabilité globale de la plateforme.

EN The rollback at our network hosting provider has been completed and service is now fully restored. Our teams continue to closely monitor the system to ensure the overall stability of the platform.

Identified: FR Le retour arrière (rollback) chez notre hébergeur réseau est toujours en cours d'exécution. Nous vous tiendrons informés dès le service est rétabli. Veuillez nous excuser pour la gêne occasionnée.

EN The rollback at our network hosting provider is still in progress. We will keep you updated as soon as service is fully restored. We sincerely apologize for any inconvenience caused.

Identified: - Début / Start : 17/09/2026 19:08 CEST

• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR L'origine de l'incident a été identifiée : il s'agit d'un problème réseau chez l'un de nos hébergeurs externes. Un rollback est en cours de leur côté, le service devrait être rétabli très rapidement. Nous vous tiendrons informés.

EN The root cause of the incident has been identified: it is related to a network issue at one of our external hosting providers. A rollback is currently underway on their end, and service should be restored very shortly. We will keep you updated.

Investigating: FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans les meilleurs délais .

EN Investigations are still ongoing. We'll get back to you as soon as possible.

Investigating: FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins depuis 19h03. L'incident est en cours d'analyse.

EN We have identified issues affecting online and in-store payments since 7:03 PM (CEST). An investigation is in progress.

Postmortem: # English version below

Post Mortem

Référence incident

TSR-3752

Service concerné

Paiements e-commerce, 3DS et en magasins.

Impact client

Impossibilité pour les porteurs d'effectuer des paiements.

Synthèse de l’incident

• 17 septembre 19h03 : début de l’incident.
• 17 septembre 19h05 : premières remontées d’erreurs.
• 17 septembre 19h10 : création d’une cellule de crise dédiée et début des investigations.
• 17 septembre 19h14 : communication Statuspage.
• 17 septembre 19h27 : identification de l’origine externe de l’incident chez un hébergeur réseau.
• 17 septembre 19h30 : contact de notre hébergeur réseau pour obtenir la résolution de l’incident.
• 17 septembre 19h52 : lancement des premières actions correctives chez l’hébergeur réseau. Rétablissement partiel des services et poursuite des investigations.
• 17 septembre 20h30 : identification de l’origine de l’incident par l’hébergeur réseau. Lancement de nouvelles actions correctives.
• 17 septembre 20h33 : fin de l’incident.
• 17 septembre 20h34-21h15 : monitoring des différents services.

Root cause

L’incident a été causé par une interruption réseau chez notre hébergeur rendant indisponibles les services nécessaires à la sécurisation et au traitement des transactions de paiement. Cette indisponibilité a empêché le traitement des paiements, aussi bien en ligne qu’en point de vente.

‌

‌Actions à entreprendre par Payplug

Actions à court terme : 

• Sécurisation des interventions firewall : mise en place d’une procédure avec notre hébergeur réseau pour encadrer les modifications de règles réseau avec une mise à jour progressive des datacenters réalisée en heures ouvrées avec information préalable de Payplug.
• Amélioration de l’identification des équipements : mise à jour du nommage des équipements réseau afin de faciliter leur identification et les interventions en cas d’incident.
• Clarification des impacts liés à l’indisponibilité du dernier équipement de sécurité disponible et formalisation de la procédure de bascule vers les nouveaux équipements afin de garantir la continuité des services.
• Amélioration de la documentation technique : centralisation et partage des informations nécessaires à la connexion et à l’administration de l’infrastructure afin de faciliter les interventions de l’équipe.

Actions à moyen terme :

• Simplification de la gestion des accès réseau : utilisation de plages d’adresses IP plutôt que d’adresses individuelles afin de faciliter l’ajout de nouveaux équipements.
• Mise en place d’un accès d’administration alternatif afin de disposer d’un second moyen d’intervention sur l’infrastructure de notre hébergeur réseau et de renforcer la capacité de reprise en cas d’indisponibilité du canal d’administration principal.
• Simplification de l’architecture réseau : suppression des accès directs devenus inutiles entre certaines infrastructures afin de réduire les dépendances et les risques associés.

‌

Actions à entreprendre par l’hébergeur réseau

• Doubler l'infrastructure de pare-feu : déploiement d'un second cluster de pare-feu indépendant, avec adaptation de l'architecture réseau associée afin de limiter l'impact d'une erreur de configuration et renforcer la résilience de l'infrastructure. 

• Mise en place d'une supervision de bout en bout du flux entre les infrastructures applicatives et les équipements critiques articulée autour de trois dispositifs :

  • Déploiement d'une sonde de monitoring au sein de l'environnement applicatif, pour une visibilité directe sur l'état de la plateforme.
  • Intégration d'un mécanisme d'alerte automatique depuis les systèmes de supervision Payplug vers l’hébergeur réseau.
  • Mise en place d'une alarme dédiée à la détection de toute baisse anormale de flux à destination des équipements critiques avec des seuils tenant compte de la temporalité des usages.

‌

==============ENGLISH VERSION==============

Post Mortem

Incident reference

TSR-3752

Payment services affected by the incident

E-commerce, 3DS, and in-store payments.

Client impact

Cardholders were unable to make payments.

Incident Overview

• 17 September, 7:03pm: incident began.
• 17 September, 7:05pm: first errors reported.
• 17 September, 7:10pm: dedicated crisis management team established and investigations commenced.
• 17 September, 7:14pm: Statuspage communication published.
• 17 September, 7:27pm: external root cause identified at a network hosting provider.
• 17 September, 7:30pm: our network hosting provider was contacted to resolve the incident.
• 17 September, 7:52pm: initial corrective actions initiated by the network hosting provider. Partial service restoration and continued investigations.
• 17 September, 8:30pm: root cause identified by the network hosting provider. Further corrective actions initiated.
• 17 September, 8:33pm: incident resolved.
• 17 September, 8:34–9:15pm: monitoring of the various services.

Root cause

The incident was caused by a network outage at our hosting provider, making the services required to secure and process payment transactions unavailable. This unavailability prevented payments from being processed, both online and at points of sale.

‌

Actions to be taken by Payplug

Short-term actions:

• Securing firewall interventions: implementation of a procedure with our network hosting provider to govern network rule changes, with a phased update of the data centres carried out during business hours and prior notification to Payplug.
• Improved equipment identification: updating the naming convention for network equipment to facilitate identification and intervention in the event of an incident.
• Clarification of the impact of the unavailability of the last available security device: formalisation of the procedure for switching over to the new equipment to ensure service continuity.
• Improved technical documentation: centralisation and sharing of the information required to connect to and administer the infrastructure, to facilitate interventions by the team.

Medium-term actions:

• Simplification of network access management: use of IP address ranges rather than individual IP addresses to facilitate the addition of new equipment.
• Implementation of an alternative administration access: provision of a second means of accessing and intervening on the network hosting provider’s infrastructure, strengthening recovery capabilities in the event of unavailability of the primary administration channel.
• Simplification of the network architecture: removal of direct access between certain infrastructures where no longer required, in order to reduce dependencies and associated risks.

‌

Actions to be taken by the network hosting provider

• Duplicate the firewall infrastructure: deployment of a second independent firewall cluster with corresponding adaptation of the associated network architecture in order to limit the impact of a configuration error and strengthen the resilience of the infrastructure.

• Implementation of end-to-end monitoring of the flow between the application infrastructure and critical equipment structured around three components:

  • Deployment of a monitoring probe within the application environment, providing direct visibility into the state of the platform.
  • Integration of an automatic alerting mechanism from Payplug's monitoring systems to the network hosting provider.
  • Implementation of a dedicated alarm to detect any abnormal drop in flow to critical equipment with thresholds that take account of usage patterns over time.

Resolved: This incident has been resolved.

Monitoring: TSR-3752

• Début / Start : 17/09/2026 19:08 CEST
• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR Le retour arrière (rollback) chez notre hébergeur réseau est finalisé et le service est désormais pleinement rétabli. Nos équipes maintiennent une surveillance attentive pour s'assurer de la stabilité globale de la plateforme.

EN The rollback at our network hosting provider has been completed and service is now fully restored. Our teams continue to closely monitor the system to ensure the overall stability of the platform.

Identified: FR Le retour arrière (rollback) chez notre hébergeur réseau est toujours en cours d'exécution. Nous vous tiendrons informés dès le service est rétabli. Veuillez nous excuser pour la gêne occasionnée.

EN The rollback at our network hosting provider is still in progress. We will keep you updated as soon as service is fully restored. We sincerely apologize for any inconvenience caused.

Identified: - Début / Start : 17/09/2026 19:08 CEST

• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR L'origine de l'incident a été identifiée : il s'agit d'un problème réseau chez l'un de nos hébergeurs externes. Un rollback est en cours de leur côté, le service devrait être rétabli très rapidement. Nous vous tiendrons informés.

EN The root cause of the incident has been identified: it is related to a network issue at one of our external hosting providers. A rollback is currently underway on their end, and service should be restored very shortly. We will keep you updated.

Investigating: FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans les meilleurs délais .

EN Investigations are still ongoing. We'll get back to you as soon as possible.

Investigating: FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins depuis 19h03. L'incident est en cours d'analyse.

EN We have identified issues affecting online and in-store payments since 7:03 PM (CEST). An investigation is in progress.

Postmortem: # English version below

Post Mortem

Référence incident

TSR-3752

Service concerné

Paiements e-commerce, 3DS et en magasins.

Impact client

Impossibilité pour les porteurs d'effectuer des paiements.

Synthèse de l’incident

• 17 septembre 19h03 : début de l’incident.
• 17 septembre 19h05 : premières remontées d’erreurs.
• 17 septembre 19h10 : création d’une cellule de crise dédiée et début des investigations.
• 17 septembre 19h14 : communication Statuspage.
• 17 septembre 19h27 : identification de l’origine externe de l’incident chez un hébergeur réseau.
• 17 septembre 19h30 : contact de notre hébergeur réseau pour obtenir la résolution de l’incident.
• 17 septembre 19h52 : lancement des premières actions correctives chez l’hébergeur réseau. Rétablissement partiel des services et poursuite des investigations.
• 17 septembre 20h30 : identification de l’origine de l’incident par l’hébergeur réseau. Lancement de nouvelles actions correctives.
• 17 septembre 20h33 : fin de l’incident.
• 17 septembre 20h34-21h15 : monitoring des différents services.

Root cause

L’incident a été causé par une interruption réseau chez notre hébergeur rendant indisponibles les services nécessaires à la sécurisation et au traitement des transactions de paiement. Cette indisponibilité a empêché le traitement des paiements, aussi bien en ligne qu’en point de vente.

‌

‌Actions à entreprendre par Payplug

Actions à court terme : 

• Sécurisation des interventions firewall : mise en place d’une procédure avec notre hébergeur réseau pour encadrer les modifications de règles réseau avec une mise à jour progressive des datacenters réalisée en heures ouvrées avec information préalable de Payplug.
• Amélioration de l’identification des équipements : mise à jour du nommage des équipements réseau afin de faciliter leur identification et les interventions en cas d’incident.
• Clarification des impacts liés à l’indisponibilité du dernier équipement de sécurité disponible et formalisation de la procédure de bascule vers les nouveaux équipements afin de garantir la continuité des services.
• Amélioration de la documentation technique : centralisation et partage des informations nécessaires à la connexion et à l’administration de l’infrastructure afin de faciliter les interventions de l’équipe.

Actions à moyen terme :

• Simplification de la gestion des accès réseau : utilisation de plages d’adresses IP plutôt que d’adresses individuelles afin de faciliter l’ajout de nouveaux équipements.
• Mise en place d’un accès d’administration alternatif afin de disposer d’un second moyen d’intervention sur l’infrastructure de notre hébergeur réseau et de renforcer la capacité de reprise en cas d’indisponibilité du canal d’administration principal.
• Simplification de l’architecture réseau : suppression des accès directs devenus inutiles entre certaines infrastructures afin de réduire les dépendances et les risques associés.

‌

Actions à entreprendre par l’hébergeur réseau

• Doubler l'infrastructure de pare-feu : déploiement d'un second cluster de pare-feu indépendant, avec adaptation de l'architecture réseau associée afin de limiter l'impact d'une erreur de configuration et renforcer la résilience de l'infrastructure. 

• Mise en place d'une supervision de bout en bout du flux entre les infrastructures applicatives et les équipements critiques articulée autour de trois dispositifs :

  • Déploiement d'une sonde de monitoring au sein de l'environnement applicatif, pour une visibilité directe sur l'état de la plateforme.
  • Intégration d'un mécanisme d'alerte automatique depuis les systèmes de supervision Payplug vers l’hébergeur réseau.
  • Mise en place d'une alarme dédiée à la détection de toute baisse anormale de flux à destination des équipements critiques avec des seuils tenant compte de la temporalité des usages.

‌

==============ENGLISH VERSION==============

Post Mortem

Incident reference

TSR-3752

Payment services affected by the incident

E-commerce, 3DS, and in-store payments.

Client impact

Cardholders were unable to make payments.

Incident Overview

• 17 September, 7:03pm: incident began.
• 17 September, 7:05pm: first errors reported.
• 17 September, 7:10pm: dedicated crisis management team established and investigations commenced.
• 17 September, 7:14pm: Statuspage communication published.
• 17 September, 7:27pm: external root cause identified at a network hosting provider.
• 17 September, 7:30pm: our network hosting provider was contacted to resolve the incident.
• 17 September, 7:52pm: initial corrective actions initiated by the network hosting provider. Partial service restoration and continued investigations.
• 17 September, 8:30pm: root cause identified by the network hosting provider. Further corrective actions initiated.
• 17 September, 8:33pm: incident resolved.
• 17 September, 8:34–9:15pm: monitoring of the various services.

Root cause

The incident was caused by a network outage at our hosting provider, making the services required to secure and process payment transactions unavailable. This unavailability prevented payments from being processed, both online and at points of sale.

‌

Actions to be taken by Payplug

Short-term actions:

• Securing firewall interventions: implementation of a procedure with our network hosting provider to govern network rule changes, with a phased update of the data centres carried out during business hours and prior notification to Payplug.
• Improved equipment identification: updating the naming convention for network equipment to facilitate identification and intervention in the event of an incident.
• Clarification of the impact of the unavailability of the last available security device: formalisation of the procedure for switching over to the new equipment to ensure service continuity.
• Improved technical documentation: centralisation and sharing of the information required to connect to and administer the infrastructure, to facilitate interventions by the team.

Medium-term actions:

• Simplification of network access management: use of IP address ranges rather than individual IP addresses to facilitate the addition of new equipment.
• Implementation of an alternative administration access: provision of a second means of accessing and intervening on the network hosting provider’s infrastructure, strengthening recovery capabilities in the event of unavailability of the primary administration channel.
• Simplification of the network architecture: removal of direct access between certain infrastructures where no longer required, in order to reduce dependencies and associated risks.

‌

Actions to be taken by the network hosting provider

• Duplicate the firewall infrastructure: deployment of a second independent firewall cluster with corresponding adaptation of the associated network architecture in order to limit the impact of a configuration error and strengthen the resilience of the infrastructure.

• Implementation of end-to-end monitoring of the flow between the application infrastructure and critical equipment structured around three components:

  • Deployment of a monitoring probe within the application environment, providing direct visibility into the state of the platform.
  • Integration of an automatic alerting mechanism from Payplug's monitoring systems to the network hosting provider.
  • Implementation of a dedicated alarm to detect any abnormal drop in flow to critical equipment with thresholds that take account of usage patterns over time.

Resolved: This incident has been resolved.

Monitoring: TSR-3752

• Début / Start : 17/09/2026 19:08 CEST
• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR Le retour arrière (rollback) chez notre hébergeur réseau est finalisé et le service est désormais pleinement rétabli. Nos équipes maintiennent une surveillance attentive pour s'assurer de la stabilité globale de la plateforme.

EN The rollback at our network hosting provider has been completed and service is now fully restored. Our teams continue to closely monitor the system to ensure the overall stability of the platform.

Identified: FR Le retour arrière (rollback) chez notre hébergeur réseau est toujours en cours d'exécution. Nous vous tiendrons informés dès le service est rétabli. Veuillez nous excuser pour la gêne occasionnée.

EN The rollback at our network hosting provider is still in progress. We will keep you updated as soon as service is fully restored. We sincerely apologize for any inconvenience caused.

Identified: - Début / Start : 17/09/2026 19:08 CEST

• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR L'origine de l'incident a été identifiée : il s'agit d'un problème réseau chez l'un de nos hébergeurs externes. Un rollback est en cours de leur côté, le service devrait être rétabli très rapidement. Nous vous tiendrons informés.

EN The root cause of the incident has been identified: it is related to a network issue at one of our external hosting providers. A rollback is currently underway on their end, and service should be restored very shortly. We will keep you updated.

Investigating: FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans les meilleurs délais .

EN Investigations are still ongoing. We'll get back to you as soon as possible.

Investigating: FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins depuis 19h03. L'incident est en cours d'analyse.

EN We have identified issues affecting online and in-store payments since 7:03 PM (CEST). An investigation is in progress.

Postmortem: # English version below

Post Mortem

Référence incident

TSR-3752

Service concerné

Paiements e-commerce, 3DS et en magasins.

Impact client

Impossibilité pour les porteurs d'effectuer des paiements.

Synthèse de l’incident

• 17 septembre 19h03 : début de l’incident.
• 17 septembre 19h05 : premières remontées d’erreurs.
• 17 septembre 19h10 : création d’une cellule de crise dédiée et début des investigations.
• 17 septembre 19h14 : communication Statuspage.
• 17 septembre 19h27 : identification de l’origine externe de l’incident chez un hébergeur réseau.
• 17 septembre 19h30 : contact de notre hébergeur réseau pour obtenir la résolution de l’incident.
• 17 septembre 19h52 : lancement des premières actions correctives chez l’hébergeur réseau. Rétablissement partiel des services et poursuite des investigations.
• 17 septembre 20h30 : identification de l’origine de l’incident par l’hébergeur réseau. Lancement de nouvelles actions correctives.
• 17 septembre 20h33 : fin de l’incident.
• 17 septembre 20h34-21h15 : monitoring des différents services.

Root cause

L’incident a été causé par une interruption réseau chez notre hébergeur rendant indisponibles les services nécessaires à la sécurisation et au traitement des transactions de paiement. Cette indisponibilité a empêché le traitement des paiements, aussi bien en ligne qu’en point de vente.

‌

‌Actions à entreprendre par Payplug

Actions à court terme : 

• Sécurisation des interventions firewall : mise en place d’une procédure avec notre hébergeur réseau pour encadrer les modifications de règles réseau avec une mise à jour progressive des datacenters réalisée en heures ouvrées avec information préalable de Payplug.
• Amélioration de l’identification des équipements : mise à jour du nommage des équipements réseau afin de faciliter leur identification et les interventions en cas d’incident.
• Clarification des impacts liés à l’indisponibilité du dernier équipement de sécurité disponible et formalisation de la procédure de bascule vers les nouveaux équipements afin de garantir la continuité des services.
• Amélioration de la documentation technique : centralisation et partage des informations nécessaires à la connexion et à l’administration de l’infrastructure afin de faciliter les interventions de l’équipe.

Actions à moyen terme :

• Simplification de la gestion des accès réseau : utilisation de plages d’adresses IP plutôt que d’adresses individuelles afin de faciliter l’ajout de nouveaux équipements.
• Mise en place d’un accès d’administration alternatif afin de disposer d’un second moyen d’intervention sur l’infrastructure de notre hébergeur réseau et de renforcer la capacité de reprise en cas d’indisponibilité du canal d’administration principal.
• Simplification de l’architecture réseau : suppression des accès directs devenus inutiles entre certaines infrastructures afin de réduire les dépendances et les risques associés.

‌

Actions à entreprendre par l’hébergeur réseau

• Doubler l'infrastructure de pare-feu : déploiement d'un second cluster de pare-feu indépendant, avec adaptation de l'architecture réseau associée afin de limiter l'impact d'une erreur de configuration et renforcer la résilience de l'infrastructure. 

• Mise en place d'une supervision de bout en bout du flux entre les infrastructures applicatives et les équipements critiques articulée autour de trois dispositifs :

  • Déploiement d'une sonde de monitoring au sein de l'environnement applicatif, pour une visibilité directe sur l'état de la plateforme.
  • Intégration d'un mécanisme d'alerte automatique depuis les systèmes de supervision Payplug vers l’hébergeur réseau.
  • Mise en place d'une alarme dédiée à la détection de toute baisse anormale de flux à destination des équipements critiques avec des seuils tenant compte de la temporalité des usages.

‌

==============ENGLISH VERSION==============

Post Mortem

Incident reference

TSR-3752

Payment services affected by the incident

E-commerce, 3DS, and in-store payments.

Client impact

Cardholders were unable to make payments.

Incident Overview

• 17 September, 7:03pm: incident began.
• 17 September, 7:05pm: first errors reported.
• 17 September, 7:10pm: dedicated crisis management team established and investigations commenced.
• 17 September, 7:14pm: Statuspage communication published.
• 17 September, 7:27pm: external root cause identified at a network hosting provider.
• 17 September, 7:30pm: our network hosting provider was contacted to resolve the incident.
• 17 September, 7:52pm: initial corrective actions initiated by the network hosting provider. Partial service restoration and continued investigations.
• 17 September, 8:30pm: root cause identified by the network hosting provider. Further corrective actions initiated.
• 17 September, 8:33pm: incident resolved.
• 17 September, 8:34–9:15pm: monitoring of the various services.

Root cause

The incident was caused by a network outage at our hosting provider, making the services required to secure and process payment transactions unavailable. This unavailability prevented payments from being processed, both online and at points of sale.

‌

Actions to be taken by Payplug

Short-term actions:

• Securing firewall interventions: implementation of a procedure with our network hosting provider to govern network rule changes, with a phased update of the data centres carried out during business hours and prior notification to Payplug.
• Improved equipment identification: updating the naming convention for network equipment to facilitate identification and intervention in the event of an incident.
• Clarification of the impact of the unavailability of the last available security device: formalisation of the procedure for switching over to the new equipment to ensure service continuity.
• Improved technical documentation: centralisation and sharing of the information required to connect to and administer the infrastructure, to facilitate interventions by the team.

Medium-term actions:

• Simplification of network access management: use of IP address ranges rather than individual IP addresses to facilitate the addition of new equipment.
• Implementation of an alternative administration access: provision of a second means of accessing and intervening on the network hosting provider’s infrastructure, strengthening recovery capabilities in the event of unavailability of the primary administration channel.
• Simplification of the network architecture: removal of direct access between certain infrastructures where no longer required, in order to reduce dependencies and associated risks.

‌

Actions to be taken by the network hosting provider

• Duplicate the firewall infrastructure: deployment of a second independent firewall cluster with corresponding adaptation of the associated network architecture in order to limit the impact of a configuration error and strengthen the resilience of the infrastructure.

• Implementation of end-to-end monitoring of the flow between the application infrastructure and critical equipment structured around three components:

  • Deployment of a monitoring probe within the application environment, providing direct visibility into the state of the platform.
  • Integration of an automatic alerting mechanism from Payplug's monitoring systems to the network hosting provider.
  • Implementation of a dedicated alarm to detect any abnormal drop in flow to critical equipment with thresholds that take account of usage patterns over time.

Resolved: This incident has been resolved.

Monitoring: TSR-3752

• Début / Start : 17/09/2026 19:08 CEST
• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR Le retour arrière (rollback) chez notre hébergeur réseau est finalisé et le service est désormais pleinement rétabli. Nos équipes maintiennent une surveillance attentive pour s'assurer de la stabilité globale de la plateforme.

EN The rollback at our network hosting provider has been completed and service is now fully restored. Our teams continue to closely monitor the system to ensure the overall stability of the platform.

Identified: FR Le retour arrière (rollback) chez notre hébergeur réseau est toujours en cours d'exécution. Nous vous tiendrons informés dès le service est rétabli. Veuillez nous excuser pour la gêne occasionnée.

EN The rollback at our network hosting provider is still in progress. We will keep you updated as soon as service is fully restored. We sincerely apologize for any inconvenience caused.

Identified: - Début / Start : 17/09/2026 19:08 CEST

• Fin / End : En cours / Ongoing
• Catégorie / Category : Production Processing
• Responsabilité / Responsibility : Externe / External
• Priorité / Priority : P1

FR L'origine de l'incident a été identifiée : il s'agit d'un problème réseau chez l'un de nos hébergeurs externes. Un rollback est en cours de leur côté, le service devrait être rétabli très rapidement. Nous vous tiendrons informés.

EN The root cause of the incident has been identified: it is related to a network issue at one of our external hosting providers. A rollback is currently underway on their end, and service should be restored very shortly. We will keep you updated.

Investigating: FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans les meilleurs délais .

EN Investigations are still ongoing. We'll get back to you as soon as possible.

Investigating: FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins depuis 19h03. L'incident est en cours d'analyse.

EN We have identified issues affecting online and in-store payments since 7:03 PM (CEST). An investigation is in progress.