Is Dalenys down?

FR Nous avons identifié un problème d'affichage des transactions sur notre Cockpit. 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 Cockpit. No impact on transaction processing has been observed, with the exception of the getTransaction functionality. The incident is currently under investigation.

FR Des actions correctives ont été lancées. La situation revient progressivement à la normale. Nos équipe continuent de monitorer le service. EN Corrective actions have been initiated. The situation is gradually returning to normal. Our teams continue to monitor the service.

FR Nos équipes continuent de monitorer le service. Les transactions s'affichent désormais avec une vingtaine de minutes de retard. EN Our teams continue to monitor the service. Transactions are now being displayed with a delay of approximately 20 minutes.

FR La situation est revenue à la normale. Nos équipes continuent de monitorer le service. EN The situation has returned to normal. Our teams continue to monitor the service.

This incident has been resolved.

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

FR Un incident a affecté le service d'authentification 3DS pour les transactions Mastercard entre 09h18 et 10h30, 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 10:30, resulting in authentication failures with error code 4009. The incident has now been resolved, and the service is fully operational again.

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.

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.

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.

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.

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.

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.

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

FR Nous avons identifié des difficultés sur les paiements en magasins CB2A et Nexo. L'incident est en cours d'analyse. EN We have identified issues affecting CB2A and Nexo in-store payments. An investigation is in progress.

TSR-3440 - Début / Start : 29/06/2026 14h37 CEST - Fin / End : En cours / Ongoing - Catégorie / Category : Production Processing - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR L'origine de l'incident a été identifié. Un correctif a été déployé. La situation est en train de revenir à la normale. EN The root cause of the incident has been identified. A fix has been deployed. The situation is returning to normal.

TSR-3440 - Début / Start : 29/06/2026 14h37 CEST - Fin / End : En cours / Ongoing - Catégorie / Category : Production Processing - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR Nous confirmons la reprise progressive du service. Nos équipes continuent de monitorer le service. EN We confirm that the service is being progressively restored. Our teams continue to monitor the service.

This incident has been resolved.

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

FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins. L'incident est en cours d'analyse. EN We have identified issues affecting online and in-store payments. An investigation is in progress.

FR Nous avons identifié des difficultés sur la plateforme de paiement. Après analyse, il apparaît que l’incident est externe à notre plateforme. Nous vous tiendrons informés de l’évolution dès que de nouvelles informations seront disponibles. EN We have identified issues on the payment platform. Following analysis, it appears that the incident is external to our platform. We will keep you informed of any developments as soon as further information becomes available.

TSR-XXXX - Début / Start : 07/06/2026 06:15:00 CEST - Fin / End : 07/06/2026 06:58:00 CEST - Catégorie / Category : Production/ Processing - Responsabilité / Responsibility : Externe - Priorité / Priority : P1 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.

# _English version below_ # Post Mortem **Service concerné** Paiements en magasin, e-commerce et 3DS. **Impact client** Impossibilité d’effectuer des paiements pour les porteurs. **Synthèse de l’incident** * **7 juin 6h02 :** remontée d’alerte. * **7 juin 6h15 : début de l’incident.** * **7 juin 6h27 :** création d’une cellule de crise dédiée. Début des investigations. * **7 juin 6h28 : identification d’un serveur défectueux chez un prestataire externe.** * **7 juin 6h29 :** contact du prestataire externe. * **7 juin 6h54 :** confirmation du prestataire externe que l’incident est bien chez eux. * **7 juin 6h57 : fin de l’incident.** **Root cause** Incident externe chez un prestataire. ‌ ==============ENGLISH VERSION============== # Post Mortem **Payment services affected by the incident** In-store payments, e-commerce payments and 3DS. **Client impact** Cardholders were unable to make payments. **Incident Overview** * **7 June, 6:02 am:** alert raised. * **7 June 6:15am: incident began.** * **7 June 6:27am:** a dedicated crisis management team was established. Investigations commenced. * **7 June 6:28am: a faulty server was identified at an external service provider.** * **7 June 6:29am:** the external service provider was contacted. * **7 June 6:54am:** the external service provider confirmed that the incident originated on their side. * **7 June 6:57am: Incident resolved.** **Root cause** External incident at a service provider.

FR Nous avons identifié un problème d'affichage des transactions sur notre Cockpit. Aucun impact transactionnel n'est identifié. L'incident est en cours d'analyse. EN We have identified a transaction display issue on our Cockpit. No impact on the processing. An investigation is in progress.

TSR-3349 - Début / Start : 01/06/2026 - Fin / End : En cours / Ongoing - Catégorie / Category : Production Cockpit - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR L'origine de l'incident a été identifié. Un correctif est en cours de déploiement. EN The root cause of the incident has been identified. A fix is currently being deployed.

TSR-3349 - Début / Start : 01/06/2026 11h CEST - Fin / End : En cours / Ongoing - Catégorie / Category : Production Cockpit - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR La fonctionnalité getTransaction a été impactée et les paiements étant validés par cette fonctionnalité sont tombés en erreurs. Suite au correctif, la situation est en train de revenir à la normale. Nous continuons de monitorer le service. EN The getTransaction functionality was impacted, and payments validated through this functionality failed. Following the deployment of the fix, the situation is returning to normal. We will continue to monitor the service.

TSR-3349 - Début / Start : 01/06/2026 11h CEST - Fin / End : 01/06/2026 16h05 CEST - Catégorie / Category : Production Cockpit - Responsabilité / Responsibility : Payplug - Priorité / Priority : P2 FR L'affichage des transactions est revenue à la normale. EN Transaction display has returned to normal.

# Post Mortem **Référence incident** TSR-3349 **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** * **1 juin 12h06 :** début d'empilement de logs en base qui engendre des ralentissements. **Début de l’incident.** * **1 juin 13h39 :** remontées d’alertes indiquant un faible taux de transaction. * **1 juin 14h01 :** création d’une cellule de crise dédiée et début des investigations.   * **1 juin 14h05 :** communication Statuspage.  * **1 juin 14h16 : identification de l’origine de l’incident.** Déploiement d’un correctif pour faire retomber la pile de logs. * **1 juin 14h16 - 16h09 :** monitoring pour vérifier la baisse continue des logs. * **1 juin 16h09 :** retour à la normale. **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 à entreprendre 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. | | Détection de l’incident lorsque l’impact marchand est constaté. | Analyses en cours pour détecter l’empilement de logs, agir proactivement et anticiper un impact pour les marchands. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3349 **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** * **1 June - 12:06pm:** log accumulation in the database begins, causing performance degradation. **Start of the incident.** * **1 June - 1:39pm:** alerts raised indicating a low transaction success rate. * **1 June - 2:01pm:** dedicated crisis cell established and investigations started. * **1 June - 2:05pm:** Statuspage communication published. * **1 June - 2:16pm: root cause identified.** Deployment of a fix to reduce the backlog of logs. * **1 June - 2:16pm–4:09pm:** monitoring carried out to verify the continuous reduction of the log backlog. * **1 June - 4:09pm:** service returned to normal. **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 to be 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. | | The incident was detected once merchant impact was observed. | Ongoing analysis to detect log accumulation earlier, take proactive action, and prevent any impact on merchants. |