Payplug Status Page

Sep 17, 2026 · resolved Sep 18

# _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.

Aug 12, 2026 · resolved Aug 12

# _English version below_ # Post Mortem **Référence incident** TSR-3611 **Service concerné** Dashboard. **Impact client** Retard d’affichage des transactions sur le Dashboard. **Synthèse de l’incident** * **13 août 11h42 :** début d'empilement de logs en base qui engendre des ralentissements. **Début de l’incident.** * **13 août 13h24 :** alertes indiquant un retard dans la remontée des transactions sur le Dashboard. Création d’une cellule de crise dédiée et début des investigations. * **13 août 13h27 : identification de l’origine de l’incident.** * **13 août 13h30 :** déploiement des actions correctives. * **13 août 13h30-14h13 :** monitoring de la remontée progressive des transactions dans le Dashboard. * **13 août 14h14 : fin de l’incident.** ‌ **Root cause** Une saturation de la base de données a été provoquée par une accumulation anormale de logs, entraînant un retard dans la remontée des transactions sur le dashboard. **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Latence dans la remontée de certaines données. | Analyses en cours pour expliquer et accélérer la remontée de ces données spécifiques. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3611 **Payment services affected by the incident** Dashboard. **Client impact** Delay in the display of transactions on the Dashboard. **Incident Overview** * **13 August, 11:42am:** logs began accumulating in the database, causing slowdowns. **Incident began.** * **13 August, 1:24pm:** alerts indicated delays in the display of transactions on the Dashboard. A dedicated crisis management team was established and investigations commenced. * **13 August, 1:27pm: root cause identified.** * **13 August, 1:30 pm:** corrective actions deployed. * **13 August, 1:30–2:13 pm:** monitoring of the gradual recovery of transaction display on the Dashboard. * **13 August, 2:14 pm: incident resolved.** ‌ **Root cause** Database saturation was caused by an abnormal accumulation of logs, resulting in a delay in the display of transactions on the merchant dashboard. **Actions taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Latency in the processing and display of certain data. | Ongoing investigations to determine the cause and accelerate the processing of these specific data sets. |

Jul 23, 2026 · resolved Jul 23

# _English version below_ # Post Mortem **Service concerné** Dashboard & E-commerce. **Impact client** Retard d’affichage des transactions sur le Dashboard et interruption de la fonctionnalité GetTransaction. **Synthèse de l’incident** * **23 juillet 14h30 :** début d'empilement de logs en base qui engendre des ralentissements. **Début de l’incident.** * **23 juillet 16h :** alertes indiquant un retard dans la remontée des transactions sur le Dashboard. * **23 juillet 16h05 :** création d’une cellule de crise dédiée. Début des investigations. * **23 juillet 16h06 : identification de l’origine de l’incident.**  * **23 juillet 16h07 -16h30 :** déploiement des actions correctives. * **23 juillet 16h31 - 17h :** monitoring de la remontée progressive des transactions dans le Dashboard. * **23 juillet 17h : fin de l’incident.** **Root cause** Une saturation de la base de données a été provoquée par une accumulation anormale de logs, entraînant un retard dans la remontée des transactions sur le dashboard marchand et des perturbations de la fonctionnalité GetTransaction. ‌ **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Latence dans la remontée de certaines données. | Analyses en cours pour expliquer et accélérer la remontée de ces données spécifiques. | ‌ ==============ENGLISH VERSION============== # Post Mortem ‌ **Payment services affected by the incident** Dashboard & E-commerce. **Client impact** Delay in the display of transactions on the Dashboard and disruption of the GetTransaction functionality. **Incident Overview** * **23 July, 2.30pm:** log stacking starts in the database, causing system slowdowns. **Start of the incident.** * **23 July, 4.00pm:** alerts were raised indicating delays in the display of transactions on the Dashboard. * **23 July, 4.05pm:** crisis management team established. Investigations begin. * **23 July, 4.06 pm: root cause of the incident identified.** * **23 July, 4.07pm – 4.30pm:** corrective actions deployed. * **23 July, 4.31 pm – 5.00pm:** monitoring the gradual recovery of transaction updates on the Dashboard. * **23 July, 5.00pm: end of the incident.** **Root cause** Database saturation was caused by an abnormal accumulation of logs, resulting in a delay in the display of transactions on the merchant dashboard and disruptions to the GetTransaction functionality. ‌ **Actions taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Latency in the processing and display of certain data. | Ongoing investigations to determine the cause and accelerate the processing of these specific data sets. |

Jul 14, 2026 · resolved Jul 15

# _English version below_ # Post Mortem **Référence incident** TSR-3495 **Service concerné** Paiements E-commerce et 3DS. **Impact client** Impossibilité d’effectuer des paiements pour les porteurs. **Synthèse de l’incident** * **13 juillet :** tentative de renouvellement d’un certificat qui expirera le 15 juillet. Une erreur a provoqué l’échec du renouvellement du certificat. Le délai imposé par Mastercard pour régénérer un certificat repousse l’opération au lendemain. * **14 juillet 9h17 :** mise à jour par le prestataire externe. **Début de l’incident.** * **14 juillet 10h : identification de l’origine de l’incident.** Déploiement du certificat corrigé. * **14 juillet 10h29 : fin de l’incident.**  ‌ **Root cause** Dans le cadre d’une intervention menée par un prestataire externe, un certificat utilisé pour sécuriser les échanges a été retiré de manière anticipée alors qu'il était encore valide pendant 24 heures. Une basculte automatique sur un autre certificat s’est déclenchée. Cependant, la configuration de ce certificat, bien que valide, n’était pas reconnue par Mastercard ce qui a entraîné le blocage des appels 3DS malgré la validité du nouveau certificat. **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Méconnaissance de la suppression d’un certificat 24h avant son expiration. | Révision de la documentation sur l’expiration des certificats. | | Absence d’alerte spécifique sur la bascule automatique de certificat 24h avant l’expiration. | Ajout d’une alerte spécifique concernant le mécanisme de bascule automatique intervenant 24 heures avant l'expiration d'un certificat. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3495 **Payment services affected by the incident** E-commerce payments and 3D Secure. **Client impact** Cardholders were unable to make payments. **Incident Overview** * **13 July:** an attempt was made to renew a certificate due to expire on July, 15th. An error caused the certificate renewal to fail. The waiting period imposed by Mastercard before a new certificate can be generated meant that the operation had to be postponed until the following day. * **14 July, 9:17 am:** update deployed by the external service provider. **Incident began.** * **14 July, 10:00 am: root cause identified.** Deployment of the corrected certificate.  * **14 July, 10:29 am: incident resolved.** ‌ **Root cause** As part of an intervention carried out by an external service provider, a certificate used to secure communications was removed prematurely, even though it remained valid for a further 24 hours. This triggered an automatic switchover to another certificate. However, although this certificate was valid, its configuration was not recognised by Mastercard, resulting in 3DS requests being blocked despite the validity of the new certificate. **Actions taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Lack of awareness that a certificate is removed 24 hours before its expiry. | The certificate expiry documentation is being reviewed. | | No specific alert was in place for the automatic certificate switchover occurring 24 hours before expiry. | A specific alert is currently being implemented for the automatic certificate switchover mechanism that takes place 24 hours before a certificate expires. |

Jun 29, 2026 · resolved Jun 29

# _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. |

Is Payplug down right now?

No — Payplug is up. All systems operational as of Oct 12, 4:56 AM UTC.

What is Payplug's current status?

Payplug: All Systems Operational. Alert24 checks Payplug's status page continuously and can notify you the moment it changes.

How do I get alerted when Payplug goes down?

Alert24 monitors Payplug and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.