Is PayPlug down?

FR Nous avons identifié un problème de connexion sur notre Portail. Aucun impact sur les paiements n'est identifié. L'incident est en cours d'analyse. EN We have identified a connection issue on our Portal. No impact on the processing. An investigation is in progress. IT Abbiamo individuato un problema di connessione al nostro portale. Nessun impatto è stato identificato sulle transazioni. L'incidente è in fase di analisi.

FR L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. EN Incident is now resolved and service restored. Service recovery is still under monitoring. IT L'incidente è stato risolto e il servizio è stato ripristinato. Continuiamo a monitorare la ripresa del servizio.

This incident has been resolved.

FR Nous avons identifié un problème d'affichage des transactions sur notre Portail. Aucun impact processing n'est constaté à l'exception de la fonctionnalité getTransaction. L'incident est en cours d'analyse. EN We have identified an issue affecting the display of transactions in our Portal. No impact on transaction processing has been observed, with the exception of the getTransaction functionality. The incident is currently under investigation. IT Abbiamo identificato un problema di visualizzazione delle transazioni sul nostro Portale. Non si riscontra alcun impatto sul processing, ad eccezione della funzionalità getTransaction. L'incidente è attualmente in fase di analisi.

TSR-3623 - Début / Start / Inizio : 17/08/2026 9h50 CEST. - Fin / End /fine : 17/08/2026 10h11 CEST. - Catégorie / Category / Categoria: Production Portail. - Responsabilité / Responsibility / Responsabilità : Payplug - Priorité / Priority / Priorità: P2. FR Les actions correctives ont été réalisées. Le service est revenu à la normale. EN The corrective actions have been completed. The service has returned to normal. IT Le azioni correttive sono state completate. Il servizio è tornato alla normalità.

This incident has been resolved.

# _English version below_ # Post Mortem **Référence incident** TSR-3623. **Service concerné** Portail. **Impact client** Accès au Portail indisponible, retard d’affichage des transactions sur le Portail et interruption de la fonctionnalité GetTransaction. **Synthèse de l’incident** * **18 août 9h20 :** livraison d’une mise en production.  * **18 août 9h48 :** premières erreurs, **début de l’incident.** * **18 août 9h53 :** détection des erreurs. Début des analyses. * **18 août 9h56 :** création d’une cellule de crise dédiée. * **18 août 10h01 :** confirmation que les paiements ne sont pas impactés par l’incident. * **18 août 10h02 :** communication Statuspage. * **18 août 10h08 : identification de l’origine de l’incident.** * **18 août 10h10 :** déploiement des actions correctives. * **18 août 10h11 : fin de l’incident.** * **18 août 10h12-10h18 :** série de contrôles pour s’assurer qu’aucune transaction n’a été perdue durant l’incident.  ‌ **Root cause** Une modification de configuration prévue uniquement pour l'environnement de préproduction a été appliquée à la configuration de production. Cette configuration a empêché un service de communiquer correctement avec un composant nécessaire à son fonctionnement, entraînant les dysfonctionnements observés lors de l'incident. **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence de détection des erreurs présentes dans un environnement de test en amont de celles en production. | Revue des alertes et étude en cours pour calquer les alertes de l’environnement de test sur celles de production. | | Absence de détection d’impact sur un autre environnement. | Renforcement des contrôles afin de stopper le risque de propagation involontaire à d'autres environnements. Étude en cours pour préciser les environnements concernés lors des déploiements et faire l'objet de vérifications spécifiques avant un déploiement. | | Livraison tardive de la modification suite à sa validation plusieurs jours auparavant. | Réduction des délais entre la validation d'une modification et son déploiement. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3623. **Payment services affected by the incident** Portal. **Client impact** Portal access unavailable, delays in transaction display on the Portal, and disruption to the GetTransaction functionality. **Incident Overview** * **18 August, 9:20am:** production deployment. * **18 August, 9:48am:** first errors detected. **Incident began.** * **18 August, 9:53am:** errors detected. Investigations commenced. * **18 August, 9:56am:** a dedicated crisis management team was established. * **18 August, 10:01am:** confirmation that payments were not impacted by the incident. * **18 August, 10:02am:** Statuspage communication published. * **18 August, 10:08am: root cause identified.** * **18 August, 10:10am:** corrective actions deployed. * **18 August, 10:11am: incident resolved.** * **18 August, 10:12–10:18am:** a series of checks was carried out to ensure that no transactions had been lost during the incident. ‌ **Root cause** A configuration change intended solely for the pre-production environment was applied to the production configuration. This configuration prevented a service from communicating correctly with a component required for its operation, resulting in the issues observed during the incident. **Actions taken by Payplug** | **Symptômes** | **Actions** | | --- | --- | | No detection of errors in a test environment before they occurred in production. | Review of alerts underway, with an assessment to align alerts in the test environment with those in production. | | No detection of an impact on another environment. | Controls are being strengthened to prevent the risk of unintended propagation to other environments. Work is underway to identify the environments affected by production deployments and ensure that specific checks are carried out before any deployment. | | Delayed deployment of the change following its approval several days earlier. | Reduction of the time between change approval and deployment. |

FR Nous avons identifié un problème avec les liens de paiements qui ne remontent pas dans le Portail. Nos équipes sont mobilisées pour résoudre le problème. EN We have identified an issue affecting payment links, which are not appearing in the Portal. Our teams are fully mobilised to resolve the issue. IT Abbiamo identificato un problema per cui i link di pagamento non vengono visualizzati nel Portale. I nostri team sono mobilitati per risolvere il problema.

FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans 15 minutes. EN Investigations are still ongoing. We will provide you with a further update in 15 minutes. IT Le indagini sono ancora in corso. Vi aggiorneremo tra 15 minuti.

FR L'incident affecte également la remontée des transactions qui peuvent apparaître avec du retard. Nos équipes sont mobilisées pour résoudre le problème. EN The incident is also affecting the display of transactions, which may appear with a delay. Our teams are fully mobilised to resolve the issue. IT L'incidente interessa anche la visualizzazione delle transazioni, che potrebbero comparire con ritardo. I nostri team sono mobilitati per risolvere il problema.

FR Le service est revenu à la normal depuis 15h30. Nos équipes continuent de monitorer le service. EN The service has been back to normal since 3:30 pm. Our teams continue to monitor the service. IT Il servizio è tornato alla normalità dalle ore 15:30. I nostri team continuano a monitorare il servizio.

This incident has been resolved.

# _English version below_ # Post Mortem **Référence incident** TSR-3518 **Service concerné** Demandes de paiements et affichage des transactions. **Impact client** Arrêt d’envoi des liens de paiement et non affichage des nouvelles transactions. **Synthèse de l’incident** * **21 juillet 14h10 : début de l’incident.** * **21 juillet 14h37 :** remontée d’alerte sur un potentiel incident affectant les demandes de paiements. Début des investigations. * **21 juillet 14h53 :** création d’une cellule de crise dédiée. * **21 juillet 14h59 :** communication Statuspage. * **21 juillet 15h : identification de l’origine de l’incident.** * **21 juillet 15h06 :** déploiement des actions correctives. * **21 juillet 15h19 :** remontées de retards dans la remontée des transactions.  * **21 juillet 15h21 :** début de reprise du service.  * **21 juillet 15h30 : fin de l’incident.** **Root cause** Un dysfonctionnement sur l'une de nos instances a provoqué l'absorption massive et anormale d'un grand nombre de données simultanées. Cette surcharge soudaine associée à une gestion synchrone entre deux services a fortement ralenti une partie de notre système et a bloqué la remontée des demandes de paiements sur le Portail. ‌ **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence de limite sur l’absorption des données par une instance. | Ajout d’une limite pour éviter un engorgement de l’instance et un ralentissement général de certains services. | | Gestion synchrone entre deux services qui ont ralenti le système une partie de notre système. | Analyses en cours pour fluidifier la communication entre les deux services \(mise en place d’un timeout court ou mise en place d’une gestion asynchrone\). | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3518 **Payment services affected by the incident** Payment requests and transaction display. **Client impact** Payment links were no longer being sent, and new transactions were not displayed.. **Incident Overview** * **21 July, 2:10 pm: incident began.** * **21 July, 2:37 pm:** alert raised regarding a potential incident affecting payment requests. Investigations commenced. * **21 July, 2:53 pm:** a dedicated crisis management team was established. * **21 July, 2:59 pm:** Statuspage communication published. * **21 July, 3:00 pm: root cause identified.** * **21 July, 3:06 pm:** corrective actions deployed. * **21 July, 3:19 pm:** reports of delays in transaction display received. * **21 July, 3:21 pm:** service recovery began. * **21 July, 3:30 pm: incident resolved.** ‌ **Root cause** A malfunction on one of our instances resulted in the abnormal processing of a large volume of data simultaneously. This sudden overload, combined with synchronous processing between two services, significantly slowed down part of our system and prevented payment requests from being displayed in the Portal. **Actions taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | No limit was in place on the volume of data that could be processed by a single instance. | A limit is currently being implemented to prevent instance saturation and the resulting degradation of certain services. | | Synchronous communication between two services contributed to the slowdown of part of our system. | Investigations are underway to improve communication between the two services, either by introducing a shorter timeout or by implementing asynchronous processing. |

FR Un incident a affecté le service d'authentification 3DS pour les transactions Mastercard entre 09h18 et 09h30, entraînant des échecs d'authentification avec le code erreur 4009. L'incident est désormais résolu et le service est de nouveau pleinement opérationnel. EN An incident affected the 3DS authentication service for Mastercard transactions between 09:18 and 09:30, resulting in authentication failures with error code 4009. The incident has now been resolved, and the service is fully operational again. IT Un incidente ha interessato il servizio di autenticazione 3DS per le transazioni Mastercard tra le 09:18 e le 09:30, causando errori di autenticazione con il codice errore 4009. L'incidente è stato risolto e il servizio è nuovamente pienamente operativo.

FR Nous constatons une résurgence de l'incident avec des erreurs affectant le service d'authentification 3DS pour les transactions Mastercard. Nos équipes sont mobilisées pour restaurer le service le plus rapidement possible. EN We are observing a recurrence of the incident, with errors affecting the 3D Secure authentication service for Mastercard transactions. Our teams are fully mobilised to restore the service as quickly as possible. IT Stiamo riscontrando una recrudescenza dell'incidente, con errori che interessano il servizio di autenticazione 3DS per le transazioni Mastercard. I nostri team sono mobilitati per ripristinare il servizio nel più breve tempo possibile.

FR Les transactions impactées tombent en 5005 depuis 9h. Nos équipes poursuivent les analyses pour restaurer le service au plus vite. EN Affected transactions have been returning a 5005 error code since 9:00 am. Our teams are continuing their investigations to restore the service as quickly as possible. IT Le transazioni interessate restituiscono un errore 5005 dalle ore 9:00. I nostri team stanno proseguendo le analisi per ripristinare il servizio nel più breve tempo possibile.

FR L’incident est d’origine externe et provient de Mastercard. Nos équipes sont mobilisées et en surveillance de l'évolution de cet incident externe. EN The incident is external in origin and originates from Mastercard. Our teams remain fully mobilised and are closely monitoring the progress of this external incident. IT L'incidente è di origine esterna ed è riconducibile a Mastercard. I nostri team sono mobilitati e monitorano costantemente l'evoluzione di questo incidente esterno.

FR Nous observons une amélioration depuis 10h10. Certaines transactions continuent cependant de tomber en erreur. Nos équipes sont en contact avec Mastercard et restent mobilisées. EN We have observed an improvement since 10:10 am. However, some transactions are still returning errors. Our teams are in contact with Mastercard and remain fully mobilised. IT Dalle ore 10:10 osserviamo un miglioramento della situazione. Tuttavia, alcune transazioni continuano a restituire errori. I nostri team sono in contatto con Mastercard e restano pienamente mobilitati.

FR Nous observons une nette amélioration depuis 10h39 et la situtation semble revenir en nominal. Nos équipes sont en contact avec Mastercard et restent mobilisées. EN We have observed a significant improvement since 10:39 am, and the situation appears to be returning to normal. Our teams are in contact with Mastercard and remain fully mobilised. IT Dalle ore 10:39 osserviamo un netto miglioramento e la situazione sembra tornare alla normalità. I nostri team sono in contatto con Mastercard e restano pienamente mobilitati.

FR L'incident est terminé et la situation est revenue en nominale. EN The incident has been resolved and the situation has returned to normal. IT L'incidente è risolto e la situazione è tornata alla normalità.

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

FR Nous avons identifié un incident impactant l'envoi des notifications post-paiement pour les marchands utilisant nos modules. L'incident est en cours d'analyse. EN We have identified an incident affecting the delivery of post-payment notifications for merchants using our modules. The incident is currently under investigation.

TSR-XXXX - Début / Start : 19/06/2026 18:00:00 CEST - Fin / End : 20/06/2026 15:17:00 CEST - Catégorie / Category : Production/ Processing - Responsabilité / Responsibility : Externe - Priorité / Priority : P1 FR L’incident affectant l’envoi des notifications post-paiement pour les marchands utilisant les modules a été résolu. Le service a été rétabli à 15h17 et fonctionne désormais normalement. Des opérations seront menées afin de rejouer les notifications qui n’ont pas pu être envoyées depuis le début de l’incident, survenu hier à 18h00. EN The incident affecting the delivery of post-payment notifications for merchants using the modules has been resolved. Service was restored at 15:17 and is now operating normally. Operations will be carried out to replay the notifications that could not be sent since the beginning of the incident, which started yesterday at 18:00.

# _English version below_ # Post Mortem **Référence incident** TSR-3421 **Service concerné** Notifications de paiement. **Impact client** Les notifications de paiement n’étaient plus envoyées aux marchands. **Synthèse de l’incident** * **19 juin 18h :** envoi d’un volume massif de paiements. * **19 juin 18h30 : Début de l’incident.** * **20 juin 10h33 :** remontée d’alerte sur un problème de notification. * **20 juin 11h46 :** création d’une cellule de crise dédiée. Début des investigations. * **20 juin 11h48 :** identification de l’absence d’envoi des notifications de paiement. Poursuites des investigations. * **20 juin 12h50 : identification de la root cause.** * **20 juin 13h02 - 15h15 :** déploiement de diverses actions correctives. * **20 juin 15h17 : fin de l’incident.** * **20 juin 22h32 :** lancement d’automatismes pour renvoyer les notifications.  * **21 juin 11h57 :** confirmation du renvoi de l’ensemble des notifications.  ‌ **Root cause** Un volume anormalement élevé de notifications en échec, associé à des tentatives automatiques de réémission vers une URL indisponible, a saturé la file de traitement des notifications. Cette saturation a par conséquent bloqué l'envoi des notifications. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence d’alerting spécifique sur une file de traitement des notifications. | Ajout d’alerting spécifique pour détecter et anticiper proactivement toute saturation de la file de traitement. | | Absence de limite d’envoi de requête de paiement par marchand. | Mise en place d'un limite par marchand pour limiter les flux de notifications et prévenir toute saturation de la file de traitement. | | Gestion des timeouts inadaptés. | Révision des seuils de timeout pour prévenir la saturation des files de traitement des notifications. | | Retard dans la prise en charge de l’incident. | Révision de la procédure d’incident en heures non ouvrées et communication à certaines équipes. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3421 **Payment services affected by the incident** Payment notifications. **Client impact** Payment notifications were no longer sent to merchants. **Incident Overview** * **19 June 6:00pm:** a large volume of payment transactions was processed. * **19 June 6:30pm: incident began.** * **20 June 10:33am:** alert raised regarding a notification issue. * **20 June 11:46am:** a dedicated crisis management team was established. Investigations began. * **20 June 11:48am:** the failure to send payment notifications was identified. Investigations continued. * **20 June 12:50pm: root cause identified.** * **20 June 1:02pm – 3:15pm:** various corrective actions were deployed. * **20 June 3:17pm: incident resolved.** * **20 June 10:32pm:** automated processes were launched to resend the notifications. * **21 June 11:57am:** confirmation that all notifications had been successfully resent. ‌ **Root cause** An abnormally high volume of failed notifications, combined with automatic retry attempts to an unavailable URL, saturated the notification processing queue. As a result, the saturation prevented payment notifications from being sent. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | No specific alerting was in place for the notification processing queue. | Specific alerting has been introduced to detect and proactively anticipate any saturation of the processing queue. | | No per-merchant limit was in place for payment request submissions. | A per-merchant limit has been implemented to control notification traffic and prevent saturation of the processing queue. | | Inappropriate timeout settings. | A review of the timeout thresholds is underway to prevent saturation of the notification processing queues. | | Delay in incident response. | The out-of-hours incident management procedure is currently being reviewed and will be communicated to the relevant teams. |