Historique des pannes de Payplug

1. 12 octobre 2026 à 14:56 UTCinvestigating

   Belgique Nous avons identifié des difficultés sur la plateforme de paiement qui concernent les transactions Unie qui tombent en 5001. Après analyse, il apparaît que l'incident est extérieur à notre plateforme. Nous vous tiendrons informés de l'évolution que de nouvelles informations séront disponibles. FR Nous avons identifié un problème affectant la plate-forme de paiement, avec les transactions Oney retournant un code d'erreur 5001. Après notre enquête, l'incident semble être extérieur à notre plateforme. Nous vous tiendrons informés de toute évolution dès que de plus amples informations seront disponibles. Les Abbiamo riscontrato delle anomalie sulla piattaforma di pagamento che interessano le transazioni Oney, le quali restituiscono un errere 5001. Dopo le analisi, è emerso che l'incident è di origine esterna alla nostra piattaforma. Vi terremo informati sugli sviluppi non appena saranno disponibili nuove informazioni.

2. 12 octobre 2026 à 15:05 UTCidentified

   Belgique L'origine du problème a été identifiée. Un correctif est en cours de préparation par le prestataire. Nous vous tiendrons informés de l'évolution que de nouvelles informations séront disponibles. FR La cause fondamentale a été identifiée. Le fournisseur de services prépare actuellement un correctif. Nous vous tiendrons informés de toute évolution dès que de plus amples informations seront disponibles. Les L'origine del problema è sta identificata. Il fornitore sta preparando una correzione. Vi terremo informati sugli sviluppi non appena saranno disponibili nuove informazioni.

3. 12 octobre 2026 à 16:49 UTCmonitoring

   Belgique Le correctif a été déployé par le président. Le problème ne peut plus se reproduire. Nous continuons de surveiller le service. FR Le correctif a été déployé par le fournisseur de services. La question ne devrait plus se poser. Nous continuons de surveiller le service. Les La correzione è stata implementata dal fornitore. Il problema non dovrebbe più ripresentarsi. Continuiamo a monitorare il servizio.

4. 13 octobre 2026 à 07:10 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 septembre 2026 à 17:14 UTCinvestigating

   Belgique Nous avons identifié des difficultés sur les paiements en ligne et en magasin depuis 19h03. L'incident est en cours d'analyse. FR Nous avons relevé des problèmes touchant les paiements en ligne et en magasin depuis 19 h 03 (HNE). Une enquête est en cours. Les Abbiamo identificato delle difficile nei pagaenti online e nei punti vendita dalle ore 19:03. L'incident è en fase di analisi.

2. 17 septembre 2026 à 17:39 UTCinvestigating

   Belgique Les enquêtes sont toujours en cours. Nous revedrons vers vous dans les meilleurslais . FR Les enquêtes sont toujours en cours. Nous vous rappellerons dès que possible.

3. 17 septembre 2026 à 18:03 UTCinvestigating

   - Début : 17/09/2026 19:08 CEST - Fin / Fin : En cours / En cours - Catégorie : Traitement de la production - Responsabilité : Externe / Externe - Priorité / Priorité : P1 Belgique L'origine de l'incident a été identifiée : il s'agit d'un problème réseau chez l'un de nos hôtes externes. Un rollback est en cours de leur côté, le service est très rapidement. Nous vous avons informés. FR La cause fondamentale de l'incident a été identifiée : elle est liée à un problème de réseau dans l'un de nos fournisseurs d'hébergement externes. Un retour en arrière est en cours et le service devrait être rétabli très prochainement. Nous vous tiendrons au courant.

4. 17 septembre 2026 à 18:25 UTCidentified

   Belgique Le retour arrière chez notre hôtelier réseau est toujours en cours d'exécution. Nous vous tiendrons informés de le service est rétabli. Veuillez nous excuser pour la gêne occasionnée. FR Le recul de notre fournisseur d'hébergement réseau est toujours en cours. Nous vous tiendrons au courant dès que le service sera entièrement restauré. Nous nous excusons sincèrement pour tout désagrément causé. Les Il rirristino della versione precedente (rollback) presso il nostro fornitore di hosting di rete è ancora in corso. Vi terremo aggiornati non appena il servizio sarà completamente rirristinato. Ci scusiamo sideramente per il disagio arrecato.

5. 17 septembre 2026 à 18:38 UTCmonitoring

   TSR-3752 - Début : 17/09/2026 19:08 CEST - Fin / Fin : En cours / En cours - Catégorie : Traitement de la production - Responsabilité : Externe / Externe - Priorité / Priorité : P1 Belgique Le retour arrière chez notre hôtelier réseau est terminé et le service est entièrement réservé. Nos équipes maintiennent une surveillance attentive pour s'assurer de la stabilité globale de la plateforme. FR Le retour sur investissement chez notre fournisseur d'hébergement réseau est terminé et le service est maintenant entièrement rétabli. Nos équipes continuent de surveiller de près le système pour assurer la stabilité globale de la plateforme. Les Il rirristino della versione precedente (rollback) presso il nostro fornitore di hosting di rete è stato completato e il servizio è ora pienamente rirristinato. I nostri team mantengono un attento monitoringaggio per garantie la stabilità globale della piattaforma.

6. 18 septembre 2026 à 07:07 UTCresolved

   Cet incident a été résolu.

7. 18 septembre 2026 à 07:55 UTCpostmortem

   # Version anglaise ci-dessous # Post Mortem **Incidence de référence** TSR-3752 **Service concerné** Paiements e-commerce, 3DS et en magasins. **Pacte client** Impossibilité pour les porteurs d'effet des soins. **Synthèse de l'incident** * **17 septembre 19h03 : début de l'incident.** * **17 septembre 19h05 :** premières remontées d'errereurs. * **17 septembre 19h10 :** création d'une cellule de crise découverte et début des enquêtes. * **17 septembre 19h14 :** communication Statuspage. * **17 septembre 19h27 : identification de l'origine extérieure de l'incident chez un hôtelier réseau.** * **17 septembre 19h30 :** contact de notre hôtelier réseau pour obtenir la résolution de l'incident. * **17 septembre 19h52 :** lancement des premières actions correctrices chez l'hébergeur réseau. Établissement partiel des services et suite des enquêtes. * **17 septembre 20h30 : identification de l'origine de l'incident par l'hébergeur réseau.** Lancement de nouvelles mesures correctives. * **17 septembre 20h33 : fin de l'incident.** * **17 septembre 20h34-21h15 :** suivi des différents services. ** Cause de la mort** L'incident a été causé par une interruption de réseau chez notre hôte pendant indisponibles les services nécessaires à la sécurisation et au traitement des transactions de paiement. Cette indisponibilité a employé le traitement des paiements, aussi bien en ligne qu'en point de vente. (en milliers de dollars) Actions à entreprendre par Payplug** Actions à court terme : * Sécurisation des interventions pare-feu : mise en place d'une procédure avec notre éditeur réseau pour encadre les modifications de règles réseau avec une mise à jour progressive des datacenters réalisés en heures ouvertes avec information préalable de Payplug. * Amélioration de l'identification des équipements : mise à jour du nom 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 base vers les nouveaux équipements fin 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'utilisation de nouveaux équipements. * Mise en place d'un accès d'administration alternative afin de disposer d'un second moyen d'intervention sur l'infrastructure de notre hébergement réseau et de renforcer la capacité de reprise en cas d'indisponibilité du canal d'administration principale. * Simplification de l'architecture réseau : suppression des accès directs devenus inutiles entre certaines infrastructures fin de faire les dépenses et les risques associés. (en milliers de dollars) **Actions à entreprendre par l'hôtesseur 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é afin de limiter l'impact d'une erreur de configuration et de renforcer la résilience de l'infrastructure. * Mise en place d'une supervision de bout en bout du flux entre les infrastructures appliquées et les équipements critiques articulés autour de trois dispositifs : * Développement d'une sonde de monitoring au sein de l'environnement exemplaire, 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'Hebergeur réseau. * Mise en place d'une alarme morte à la sortie de toute baie anormale de flux à destination des équipements critiques avec des seuils locataire compte de la temporalité des usages. (en milliers de dollars) ============ VERSION ENGLISH=================== # Post Mortem **Référence de l'incident** TSR-3752 **Services de paiement touchés par l'incident** Commerce électronique, 3DS et paiements en magasin. ** Impact sur le client** Les détenteurs de cartes n'ont pas pu effectuer de paiements. ** Aperçu de l'incident** * **17 septembre, 19h03 : l'incident a commencé.** * **17 septembre, 19h05 :** premières erreurs signalées. * **17 septembre, 19h10 :** une équipe dédiée à la gestion des crises a été créée et les enquêtes ont commencé. * **17 septembre, 19 h 14 :** Communication sur la page d'état publiée. * **17 septembre, 19h27 : cause racine externe identifiée par un fournisseur d'hébergement réseau.** * **17 septembre, 19h30 :** notre fournisseur d'hébergement réseau a été contacté pour résoudre l'incident. * **17 septembre, 19h52 :** premières mesures correctives prises par le fournisseur d'hébergement de réseau. Remise en état partielle du service et poursuite des enquêtes. * **17 septembre, 20h30 : cause racine identifiée par le fournisseur d'hébergement réseau.** D'autres mesures correctives ont été prises. * **17 septembre, 20 h 33 : résolution de l ' incident** * **17 septembre, de 8h34 à 21h15 :** suivi des différents services. ** Cause de la mort** L'incident a été causé par une panne de réseau chez notre fournisseur d'hébergement, rendant les services nécessaires pour sécuriser et traiter les transactions de paiement indisponibles. Cette indisponibilité a empêché le traitement des paiements en ligne et aux points de vente. (en milliers de dollars) **Mesures à prendre par Payplug** Actions à court terme: * Securing firewall interventions: mise en place d'une procédure avec notre fournisseur d'hébergement réseau pour régir les changements de règles de réseau, avec une mise à jour progressive des centres de données effectuée pendant les heures d'ouverture et notification préalable à Payplug. * Amélioration de l'identification du matériel : mise à jour de la convention de désignation du matériel de réseau pour faciliter l'identification et l'intervention en cas d'incident. * Clarification de l'impact de l'indisponibilité du dernier dispositif de sécurité disponible : formalisation de la procédure de passage au nouvel équipement pour assurer la continuité du service. * Documentation technique améliorée : centralisation et partage des informations nécessaires pour se connecter et administrer l'infrastructure, afin de faciliter les interventions de l'équipe. Actions à moyen terme: * Simplification de la gestion de l'accès au réseau : utilisation de gammes d'adresses IP plutôt que d'adresses IP individuelles pour faciliter l'ajout de nouveaux équipements. * Mise en place d'un autre accès administratif : fourniture d'un deuxième moyen d'accès et d'intervention sur l'infrastructure du fournisseur d'hébergement réseau, renforcement des capacités de récupération en cas d'indisponibilité du canal d'administration primaire. * Simplification de l'architecture du réseau: suppression de l'accès direct entre certaines infrastructures lorsque ce n'est plus nécessaire, afin de réduire les dépendances et les risques associés. (en milliers de dollars) **Mesures à prendre par le fournisseur d'hébergement de réseau** * Dupliquer l'infrastructure de pare-feu : déploiement d'un deuxième groupe de pare-feu indépendant avec adaptation correspondante de l'architecture réseau associée afin de limiter l'impact d'une erreur de configuration et de renforcer la résilience de l'infrastructure. * Mise en place d'une surveillance de bout en bout du flux entre l'infrastructure d'application et l'équipement essentiel structuré autour de trois composantes : * Déploiement d'une sonde de surveillance dans l'environnement d'application, offrant une visibilité directe dans l'état de la plateforme. * Intégration d'un mécanisme d'alerte automatique des systèmes de surveillance de Payplug au fournisseur d'hébergement réseau. * Mise en place d'une alarme dédiée pour détecter toute baisse anormale du débit vers les équipements critiques avec des seuils qui tiennent compte des modes d'utilisation au fil du temps.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 septembre 2026 à 08:18 UTCinvestigating

   Belgique Nous avons identifié des difficultés sur le moyen de paiement Shopify. L'incident est en cours d'analyse. FR Nous avons identifié des problèmes touchant les paiements en utilisant le mode de paiement Shopify. L'enquête est en cours. Les Abbiamo identificato delle difficile con il metodo di pagamento Shopify. L'incident è en fase di analisi.

2. 17 septembre 2026 à 08:24 UTCmonitoring

   Belgique Le trafic vient à la normale depuis 10h20. FR La circulation est revenue à la normale depuis 10h20. Les Il traffico è tornato alla normalità dalle minerai 10:20.

3. 17 septembre 2026 à 08:43 UTCresolved

   TSR-3748 - Début / Inizio : 17/09/2026 10h05 CEST. - Fin / Fin / Fin : 17/09/2026 10h20 CEST. - Catégorie / Catégorie / Catégorie: Traitement de la production. - Responsable / Responsabilité / Responsable : Externe / Externe / Esterna - Priorité / Priorité / Priorité: P2. Belgique L'incident est d'origine externe et est désormais terminé. FR L'incident a été causé par un problème externe et a maintenant été résolu. Les L'incident è di origine esterna è ormai terminato.

4. 21 septembre 2026 à 08:24 UTCpostmortem

   # Version anglaise ci-dessous # Post Mortem **Incidence de référence** TSR-3748. **Service concerné** Magasinez. **Pacte client** L'impossibilité pour les porteurs d'effectuer des soins. **Synthèse de l'incident** * **17 septembre 10h05 : début de l'incident.** * **17 septembre 10h11 :** création d'une cellule de crise morte. Début des enquêtes. * **17 septembre 10h12 : identification de la cause de la racine.** * **17 septembre 10h13 :** lancement des actions correctives. * **17 septembre 10h17 : fin de l'incident.** * **17 septembre 10h18 - 10h45 :** monitoring de la bonne reprise du service. ** Cause de la mort** Une augmentation soudaine et exceptionnelle du volume de paiements a entraîné une saturation du service de traitement des paiements. La capacité maximale de traitement ayant été acquis, certaines demandes n'ont plus pu être prises en charge, entrayant des erreurs et des réseaux. La situation a été aggravée par un temps de traitement plus long sur certaines opérations, ainsi que par l'accumulation de notifications en attente. **Actions à entreprendre par Payplug** **Symptômes** - Oui. Saturation de la capacité de traitement lors d'une visite en cours des erreurs sur les demandes de paiement. Autres Augmentation de la capacité de traitement afin de mieux absorber les photos de trafic et de limiter les risques de saturation. Autres Temps de traitement des paiements allégé par un nombre important d'appelés d'authentification, contribuant à la saturation du service. Autres Mise en place d'un mécanisme de réutilisation temporaire des jetons d'authentification fin de faire le nombre d'appelés nécessaires au traitement des paiements. Autres Accumulation des notifications en attente, entraînant des retardes dans leur traitement. Autres Suppression de la limitation du nombre de notifications traitées simultanément vers le service de paiement afin d'améliorer leur traitement en période de forte activité. Réalisation de tests de montage en charge afin de valider la capacité à traiter des volumes importants de paiements. Autres (en milliers de dollars) ============ VERSION ENGLISH=================== # Post Mortem **Référence de l'incident** TSR-3748. **Services de paiement touchés par l'incident** Magasiner ** Impact sur le client** Les détenteurs de cartes n'ont pas pu effectuer de paiements. ** Aperçu de l'incident** * **17 septembre, 10 h 05 : l ' incident a commencé** * **17 septembre, 10h11 :** une équipe dédiée à la gestion des crises a été créée. Les enquêtes ont commencé. * **17 septembre, 10h12 : cause racine identifiée.** * **17 septembre, 10 h 13 :** mesures correctives prises. * **17 septembre, 10 h 17 : règlement de l ' incident** * **17 septembre, de 10 h 18 à 10 h 45 :** surveillance pour s'assurer que le service a été rétabli avec succès. ** Cause de la mort** Une augmentation soudaine et exceptionnelle du volume des paiements a provoqué la saturation du service de traitement des paiements. Une fois la capacité de traitement maximale atteinte, certaines demandes n'ont plus pu être traitées, ce qui a entraîné des erreurs et des ralentissements. La situation a été encore aggravée par les délais de traitement plus longs pour certaines opérations, ainsi que par l'accumulation de notifications en attente. **Mesures à prendre par Payplug** **Symptômes** - Oui. La capacité de traitement a été saturée au cours d'un pic de trafic, entraînant des erreurs sur les demandes de paiement. Autres La capacité de traitement a été augmentée pour mieux gérer les pics de trafic et réduire le risque de saturation. Autres Les délais de traitement des paiements ont augmenté en raison d'un grand nombre d'appels d'authentification, contribuant à la saturation du service. Autres Un mécanisme d'authentification temporaire a été mis en place pour réduire le nombre d'appels nécessaires au traitement des paiements. Autres Une accumulation de notifications en attente a retardé leur traitement. Autres La limite du nombre de notifications traitées simultanément par le service de paiement a été supprimée pour améliorer le traitement pendant les périodes de haute activité. Autres Des tests de charge ont été effectués pour valider la capacité de traiter des volumes élevés de paiements. Autres

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 septembre 2026 à 10:29 UTCinvestigating

   Belgique 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. FR Nous avons identifié un problème de connexion sur notre portail. Aucun impact sur le traitement. Une enquête est en cours. Les Abbiamo individuato un problema di connessione al nostro portail. Nessun impatto è stato identificato sulle transazioni. L'incident è en fase di analisi.

2. 10 septembre 2026 à 10:46 UTCmonitoring

   TSR-3710 - Début / Inizio : 10/09/2026 12h17 CEST. - Fin / Fin / Fin : 10/09/2026 12h44 CEST. - Catégorie / Catégorie / Catégorie: Portail de production. - Responsable / Responsabilité / Responsable : Payplug - Priorité / Priorité / Priorité: P2. Belgique L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. FR L'incident est maintenant résolu et le service rétabli. La récupération des services est toujours sous surveillance. Les L'incident è stato risolto e il servizio è stato rirristinato. Continuiamo a monitorare la ripresa del servizio.

3. 10 septembre 2026 à 13:14 UTCresolved

   Cet incident a été résolu.

4. 17 septembre 2026 à 14:21 UTCpostmortem

   # Version anglaise ci-dessous # Post Mortem **Incidence de référence** TSR-3710. **Service concerné** Portail. **Pacte client** Les marches ne peuvent plus accéder à leurs comptes sur le Portail. **Synthèse de l'incident** * **10 septembre 12h17 :** déploiement d'une mise en production. **Début de l'incident.** * **10 septembre 12h23 :** remontées d'alertes. * **10 septembre 12h27 :** création d'une cellule de crise morte. Début des enquêtes. * **10 septembre 12h28 : identification de l'incident.** * **10 septembre 12h29 :** communication Statuspage. * **10 septembre 12h37 :** rollback de la mise en production. * **10 septembre 12h42 : fin de l'incident.** (en milliers de dollars) ** Cause de la mort** Une mise en production relative au portail marchand a introduit un nouvel échange avec un service interne nécessaire à son initialisation. Cet échange nécessite une authentification spécifique, qui n'a pas été correctement transmise et configurée. Le portail n'a pas pu récupérer les informations nécessaires au paiement des comptes marsands. Par consul, les utilisateurs ne peuvent plus accéder à leur portail. **Actions à entreprendre par Payplug** **Symptômes** - Oui. L'absence d'allerte sur un point d'entrée spécifique. Autres Revue des alertes en cours pour pâle ce manque. Échec lors de la transmission des informations d'authentification. Autres Déploiement de correctifs pour assurer la bonne transmission des informations du portail vers les services internes afin de garantir le bon fonctionnement du portail. (en milliers de dollars) ============ VERSION ENGLISH=================== # Post Mortem **Référence de l'incident** TSR-3710. **Services de paiement touchés par l'incident** Portail. ** Impact sur le client** Les commerçants n'étaient plus en mesure d'accéder à leurs comptes sur le portail. ** Aperçu de l'incident** * **10 septembre, 12 h 17 :** déploiement de la production. **L'incident a commencé.** * **10 septembre, 12h23 :** des alertes ont été soulevées. * **10 septembre, 12h27 :** mise sur pied d'une équipe dédiée à la gestion des crises. Les enquêtes ont commencé. * **10 septembre, 12h28 : cause racine identifiée.** * **10 septembre, 12 h 29 :** Communication sur la page d'état publiée. * **10 septembre, 12h37:** déploiement de la production roulé. * **10 septembre, 12 h 42 : règlement de l ' incident** (en milliers de dollars) ** Cause de la mort** Un déploiement de production lié au portail marchand a introduit une nouvelle interaction avec un service interne nécessaire à son initialisation. Cette interaction nécessitait une authentification spécifique, qui n'était pas correctement transmise et configurée. Par conséquent, le portail n'a pas pu récupérer l'information nécessaire pour charger les comptes marchands. Par conséquent, les utilisateurs n'étaient plus en mesure d'accéder à leur portail. **Mesures à prendre par Payplug** **Symptômes** - Oui. Aucune alerte n'était en place pour un paramètre spécifique. Autres Les alertes sont actuellement examinées pour combler cette lacune. Défaut de transmettre des informations d'authentification. Des correctifs ont été déployés pour assurer la transmission correcte des informations d'authentification du portail aux services internes et garantir le bon fonctionnement du portail

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 août 2026 à 08:02 UTCinvestigating

   Belgique Nous avons identifié un problème d'affichage des transactions sur notre Portail. Aucun impact processing n'est certifié à l'exception de la fonction getTransaction. L'incident est en cours d'analyse. FR Nous avons identifié un problème touchant l'affichage des transactions dans notre portail. Aucun impact sur le traitement des transactions n'a été observé, à l'exception de la fonctionnalité getTransaction. L'incident fait actuellement l'objet d'une enquête. Les Abbiamo identifier un problema di visualizzazione delle transazioni sul nostro Portale. Non si riscontra alcun impatto sul processing, ad eccezione della funzionalità getTransaction. L'incident è comportemente in fase di analisi.

2. 17 août 2026 à 08:15 UTCmonitoring

   TSR-3623 - Début / Inizio : 17/08/2026 9h50 CEST. - Fin / Fin / Fin : 17/08/2026 10h11 CEST. - Catégorie / Catégorie / Catégorie: Portail de production. - Responsable / Responsabilité / Responsable : Payplug - Priorité / Priorité / Priorité: P2. Belgique Les actions correctives ont été réalisées. Le service est revenu à la normale. FR Les mesures correctives ont été prises. Le service est revenu à la normale. Les Le azioni correttive sono état complet. Il servizio è tornato alla normalità.

3. 17 août 2026 à 08:38 UTCresolved

   Cet incident a été résolu.

4. 18 août 2026 à 09:38 UTCpostmortem

   # Version anglaise ci-dessous # Post Mortem **Incidence de référence** TSR-3623. **Service concerné** Portail. **Pacte client** Accès au Portail indisponible, retard d'affichage des transactions sur le Portail et interruption de la fonction 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éfense des erreurs. Début des analyses. * **18 août 9h56 :** création d'une cellule de crise morte. * **18 août 10h01 :** confirmation que les paiements ne sont pas affecté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 assurer qu'une transaction n'a pu être réalisée pendant l'incident. (en milliers de dollars) ** Cause de la mort** Une modification de configuration prévue uniquement pour l'environnement de préproduction a été appliquée à la configuration de production. Cette configuration a employé un service de communication correcte avec un composant nécessaire à son fonctionnement, entraînant les dysfonctionnements observés lors de l'incident. **Actions entreprises par Payplug** **Symptômes** - Oui. Absence de détection des erreurs présentes dans un environnement de test en amont de cellules en production. Autres Revue des alertes et études en cours pour déterminer les alertes de l'environnement de test sur cellules de production. Autres L'absence de détection d'impact sur un autre environnement. Enforcement des contrôles afin de stopper le risque de propagation involontaire à d'autres environnements. Étude en cours pour déterminer les environnements concernés lors des déploiements et faire l'objet de vérifications spécifiques avant un déploiement. Autres Lire la suite de la modification à sa validation plusieurs jours auparavant. Autres Réduction des retards entre la validation d'une modification et son déploiement. Autres (en milliers de dollars) ============ VERSION ENGLISH=================== # Post Mortem **Référence de l'incident** TSR-3623. **Services de paiement touchés par l'incident** Portail. ** Impact sur le client** Accès au portail indisponible, retards dans l'affichage des transactions sur le portail et perturbation de la fonctionnalité GetTransaction. ** Aperçu de l'incident** * **18 août, 9 h 20 :** déploiement de la production. * **18 août, 9h48 :** premières erreurs détectées. **L'incident a commencé.** * **18 août, 9 h 53 :** erreurs détectées. Les enquêtes ont commencé. * **18 août, 9 h 56 :** une équipe de gestion de crise a été créée. * **18 août, 10 h 01 :** confirmation que les paiements n'ont pas été touchés par l'incident. * **18 août, 10 h 02 :** Communication sur la page d'état publiée. * **18 août, 10 h 08 : cause de la racine identifiée.** * **18 août, 10 h 10 :** mesures correctives déployées. * **18 août, 10 h 11 : règlement de l ' incident** * **18 août, 10h12-10h18 :** une série de vérifications a été effectuée pour s'assurer qu'aucune transaction n'avait été perdue pendant l'incident. (en milliers de dollars) ** Cause de la mort** Un changement de configuration destiné uniquement à l'environnement de préproduction a été appliqué à la configuration de production. Cette configuration a empêché un service de communiquer correctement avec un composant nécessaire à son fonctionnement, ce qui a causé les problèmes observés pendant l'incident. **Mesures prises par Payplug** **Symptômes** - Oui. Aucune détection d'erreurs dans un environnement d'essai avant qu'elles ne se produisent dans la production. Autres Examen des alertes en cours, avec une évaluation visant à aligner les alertes dans l'environnement d'essai sur celles en production. Autres Aucune détection d'un impact sur un autre environnement. Les contrôles sont renforcés pour prévenir le risque de propagation involontaire dans d'autres environnements. Des travaux sont en cours pour identifier les environnements touchés par les déploiements de production et s'assurer que des vérifications spécifiques sont effectuées avant tout déploiement. Autres Le déploiement du changement a été retardé plusieurs jours plus tôt après son approbation. Réduction du temps entre l'approbation du changement et le déploiement

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 juillet 2026 à 12:59 UTCinvestigating

   Belgique Nous avons identifié un problème avec les liens de paiements qui ne remontent pas dans le Portail. Nos équipes sont mobiles pour répondre au problème. FR Nous avons identifié un problème touchant les liens de paiement, qui n'apparaissent pas dans le portail. Nos équipes sont pleinement mobilisées pour résoudre le problème. Les Abbiamo identificato un problemea per cui i link di pagamento non vengono visualizzati nel Portale. I nostri team sono mobiliti per risolvere il problema.

2. 21 juillet 2026 à 13:16 UTCinvestigating

   Belgique Les enquêtes sont toujours en cours. Nous reviendrons vers vous dans 15 minutes. FR Les enquêtes sont toujours en cours. Nous vous fournirons une nouvelle mise à jour dans 15 minutes. Les Le indigini sono ancora dans le corso. Vi aggiorneremo tra 15 minuti.

3. 21 juillet 2026 à 13:27 UTCinvestigating

   Belgique L'incident affecte également la reconstitution des transactions qui peuvent être apparaître avec du retard. Nos équipes sont mobiles pour répondre au problème. FR L'incident affecte également l'affichage des transactions, qui peuvent apparaître avec un retard. Nos équipes sont pleinement mobilisées pour résoudre le problème. Les L'incident interessa anche la visualizzazione delle transazioni, che potrebbero comparire con ritardo. I nostri team sono mobiliti per risolvere il problema.

4. 21 juillet 2026 à 13:38 UTCmonitoring

   Belgique Le service est revenu à la normale depuis 15h30. Nos équipes continuent de surveiller le service. FR Le service est de retour à la normale depuis 15h30. Nos équipes continuent de surveiller le service. Les Il servizio è tornato alla normalità dalle minerai 15:30. I nostri team continue a monitorare il servizio.

5. 21 juillet 2026 à 14:15 UTCresolved

   Cet incident a été résolu.

6. 24 juillet 2026 à 14:42 UTCpostmortem

   # Version anglaise ci-dessous # Post Mortem **Incidence de référence** TSR-3518 **Service concerné** Demandes de paiements et affichage des transactions. **Pacte 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 puissant incident affectant les demandes de soins. Début des enquêtes. * **21 juillet 14h53 :** création d'une cellule de crise morte. * **21 juillet 14h59 :** communication Statuspage. * **21 juillet 15h : identification de l'incident.** * **21 juillet 15h06 :** déploiement des actions correctives. * **21 juillet 15h19 :** remontées de retard dans la reconstitution des transactions. * **21 juillet 15h21 :** début de reprise du service. * **21 juillet 15h30 : fin de l'incident.** ** Cause de la mort** Un dysfonctionnement sur l'une de nos instances a avancé l'absorption massive et anormale d'un grand nombre de données simultanées. Cette supplément sera associé à une gestion synchronisée entre deux services a fortienti une partie de notre système et a gonflé la reconstitution des demandes de paiements sur le Portail. (en milliers de dollars) **Actions entreprises par Payplug** **Symptômes** - Oui. Absence de limite sur l'absorption des données par une instance. Autres Ajout d'une limite pour inviter un engorgement de l'installation et un rapatriement général de certains services. Autres Gestion synchrone entre deux services qui ont ralenti le système une partie de notre système. Autres 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\). Autres (en milliers de dollars) ============ VERSION ENGLISH=================== # Post Mortem **Référence de l'incident** TSR-3518 **Services de paiement touchés par l'incident** Demandes de paiement et affichage des transactions. ** Impact sur le client** Les liens de paiement ne sont plus envoyés et les nouvelles transactions ne sont plus affichées. ** Aperçu de l'incident** * **21 juillet, 14 h 10 : l'incident a commencé.** * **21 juillet, 14 h 37 :** alerte soulevée concernant un incident potentiel affectant les demandes de paiement. Les enquêtes ont commencé. * **21 juillet, 14h53 :** une équipe dédiée à la gestion des crises a été créée. * **21 juillet, 14 h 59 :** Communication sur la page d'état publiée. * **21 juillet, 15h00 : cause racine identifiée.** * **21 juillet, 15 h 06 :** mesures correctives déployées. * **21 juillet, 15 h 19 :** déclarations de retards dans l'affichage des transactions reçues. * **21 juillet, 15h21 :** le rétablissement du service a commencé. * **21 juillet, 15 h 30 : règlement de l'incident** (en milliers de dollars) ** Cause de la mort** Un dysfonctionnement sur une de nos instances a entraîné le traitement anormal d'un grand volume de données simultanément. Cette surcharge soudaine, combinée à un traitement synchrone entre deux services, a considérablement ralenti une partie de notre système et empêché l'affichage des demandes de paiement dans le portail. **Mesures prises par Payplug** **Symptômes** - Oui. Aucune limite n'était en place sur le volume de données pouvant être traitées par une seule instance. Autres Une limite est actuellement appliquée pour empêcher la saturation en instance et la dégradation de certains services qui en résulte. Autres La communication synchrone entre deux services a contribué au ralentissement d'une partie de notre système. Des enquêtes sont en cours pour améliorer la communication entre les deux services, soit par l'introduction d'un délai plus court, soit par la mise en œuvre d'un traitement asynchrone. Autres

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 juillet 2026 à 09:11 UTCmonitoring

   Belgique Un incident a affecté le service d'authentification 3DS pour les transactions Mastercard entre 09h18 et 10h30, entravant des dossiers d'authentification avec le code erreur 4009. L'incident est désespéré résolu et le service est de nouveau entièrement opérationnel. FR Un incident a affecté le service d'authentification 3DS pour les transactions Mastercard entre 9h18 et 10h30, entraînant des défaillances d'authentification avec le code d'erreur 4009. L'incident a maintenant été résolu et le service est de nouveau pleinement opérationnel. Les Un incident ha interessato il servizio di autenticazione 3DS per le transazioni Mastercard tra le 09:18 e le 10:30, causando errori di autenticazione con il codice errere 4009. L'incident è stato risolto e il servizio è nuovamente pienamento opérativo.

2. 15 juillet 2026 à 07:25 UTCidentified

   Belgique Nous constatons une résurgence de l'incident avec des erreurs affectant le service d'authentification 3DS pour les transactions Mastercard. Nos équipes sont mobiles pour restaurer le service le plus rapidement possible. FR Nous observons une récurrence de l'incident, avec des erreurs affectant le service d'authentification 3D Secure pour les transactions Mastercard. Nos équipes sont pleinement mobilisées pour restaurer le service le plus rapidement possible. Les Stiamo riscontrando una recrudescenza dell'incidente, con erreri che interessano il servizio di autenticazione 3DS per le transazioni Mastercard. I nostri team sono mobilitati per rirristinare il servizio nel più breve tempo possibile.

3. 15 juillet 2026 à 07:39 UTCidentified

   Belgique Les transactions impactées tombent en 5005 depuis 9h. Nos équipes servent les analyses pour restaurer le service au plus vide. FR Les transactions touchées renvoient un code d'erreur 5005 depuis 9 h. Nos équipes poursuivent leurs enquêtes afin de rétablir le service le plus rapidement possible. Les Le transazioni interessate restituiscono un errere 5005 dalle minerai 9:00. I nostri team stanno proseguendo le analisi per rirristinare il servizio nel più breve tempo possibile.

4. 15 juillet 2026 à 07:47 UTCidentified

   Belgique L'incident est d'origine externe et produit de Mastercard. Nos équipes sont mobiles et en surveillance de l'évolution de cet incident externe. FR L'incident est d'origine externe et provient de Mastercard. Nos équipes restent pleinement mobilisées et suivent de près les progrès de cet incident externe. Les L'incident è di origine esterna è riconducibilite a Mastercard. I nostri team sono mobiliti e monitorano costantemente l'evoluzione di questo incidente esterno.

5. 15 juillet 2026 à 08:28 UTCidentified

   Belgique Nous observons une amélioration depuis 10h10. Certaines transactions continuent cependent de tomber en erreur. Nos équipes sont en contact avec Mastercard et reste mobile. FR Nous avons observé une amélioration depuis 10h10. Cependant, certaines transactions renvoient toujours des erreurs. Nos équipes sont en contact avec Mastercard et restent pleinement mobilisées. Les 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.

6. 15 juillet 2026 à 08:58 UTCmonitoring

   Belgique Nous observons une nette amélioration depuis 10h39 et la localisation ressemble de nouveau en nominal. Nos équipes sont en contact avec Mastercard et reste mobile. FR Nous avons observé une amélioration significative depuis 10 h 39, et la situation semble revenir à la normale. Nos équipes sont en contact avec Mastercard et restent pleinement mobilisées. Les 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.

7. 15 juillet 2026 à 09:20 UTCresolved

   Belgique L'incident est terminé et la situation est revenu en nominal. FR L'incident a été résolu et la situation est revenue à la normale. Les L'incident è risolto e la situazione è tornata alla normalità.

8. 16 juillet 2026 à 12:28 UTCpostmortem

   # Post Mortem **Incidence de référence** TSR-3495 **Service concerné** Paiements E-commerce et 3DS. **Pacte client** Impossibilité d'effectuer des paiements pour les porteurs. **Synthèse de l'incident** * **13 juillet :** provisoire de renouvellement d'un certificat qui expirera le 15 juillet. Une erreur a présenté l'Échec du renouvellement du certificat. Le délai imposé par Mastercard pour générer un certificat repousse l'opération au prêtmain. * **14 juillet 9h17 :** mise à jour par le président 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.** (en milliers de dollars) ** Cause de la mort** Dans le cadre d'une intervention menée par un prestataire externe, un certificat utilisé pour sécuriser les échanges a été retiré de la gestion anticipée qu'il était encore valide pendant 24 heures. Une basculte automatique sur un autre certificat s=est déclenchée. Cependent, 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 entreprises par Payplug** **Symptômes** - Oui. Méconnaissance de la suppression d'un certificat 24h avant son expiration. Révision de la documentation sur l'expiration des certificats. L'absence d'alerte spécifique sur la base automatique de certification 24h avant l'expiration. Autres Ajout d'une alerte spécifique concernant le mécanisme de base automatique intervenant 24 heures avant l'expiration d'un certificat. Autres (en milliers de dollars) ============ VERSION ENGLISH=================== # Post Mortem **Référence de l'incident** TSR-3495 **Services de paiement touchés par l'incident** Paiements de commerce électronique et 3D Secure. ** Impact sur le client** Les détenteurs de cartes n'ont pas pu effectuer de paiements. ** Aperçu de l'incident** * **13 juillet :** une tentative de renouvellement d'un certificat devait expirer le 15 juillet. Une erreur a causé l'échec du renouvellement du certificat. La période d'attente imposée par Mastercard avant qu'un nouveau certificat puisse être généré signifie que l'opération a dû être reportée au lendemain. * **14 juillet, 9 h 17 :** mise à jour déployée par le prestataire de services externe. **L'incident a commencé.** * **14 juillet, 10h00 : cause racine identifiée.** Déploiement du certificat corrigé. ** 14 juillet, 10 h 29 : règlement de l ' incident** (en milliers de dollars) ** Cause de la mort** Dans le cadre d'une intervention effectuée par un prestataire de services externe, un certificat utilisé pour sécuriser les communications a été retiré prématurément, même s'il est resté valide pendant 24 heures supplémentaires. Cela a déclenché un passage automatique à un autre certificat. Toutefois, bien que ce certificat soit valide, sa configuration n'a pas été reconnue par Mastercard, ce qui a empêché les demandes 3DS malgré la validité du nouveau certificat. **Mesures prises par Payplug** **Symptômes** - Oui. Le manque de sensibilisation au fait qu'un certificat est retiré 24 heures avant son expiration. Autres La documentation relative à l'expiration du certificat est en cours de révision. Autres Aucune alerte spécifique n'était en place pour le basculement automatique du certificat 24 heures avant l'expiration. Autres Une alerte spécifique est actuellement mise en place pour le mécanisme de basculement automatique des certificats qui a lieu 24 heures avant l'expiration d'un certificat. Autres

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 juin 2026 à 10:52 UTCinvestigating

   FR Nous avons identifié un incident impactant l'envoi des notifications post-paiement pour les marchands en utilisant nos modules. L'incident est en cours d'analyse. FR Nous avons identifié un incident affectant l'envoi des notifications post-paiement pour les commerçants utilisant nos modules. L'incident fait actuellement l'objet d'une enquête.

2. 20 juin 2026 à 13:40 UTCresolved

   TSR 3421 - Début/Départ : 19/06/2026 18:00:00 CEST - Fin/Fin : 20/06/2026 15:17:00 CEST - Catégorie/Catégorie : Production/ Transformation - Responsabilité/Responsabilité : Externe - Priorité/Priorité : 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. FR L'incident affectant l'envoi des notifications de post-paiement pour les commerçants utilisant les modules a été résolu. Le service a été rétabli à 15 h 17 et fonctionne maintenant normalement. Des opérations seront effectuées pour rejouer les notifications qui n'ont pas pu être envoyées depuis le début de l'incident, qui a débuté hier à 18h00.

3. 26 juin 2026 à 09:27 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR 3421 **Service concerné** Payment notifications. **Influencer le 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 enquêtes. * **20 juin 11h48 :** identification de l'absence d'envoi des notifications de paiement. Investigations poursuites. * **20 juin 12h50 : identification de la cause première. ** * **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. **Cause principale** 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'alerte spécifique sur une file de traitement des notifications. | Ajout d'une alerte 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'une limite par marchand pour limiter les flux de notifications et prévenir toute saturation de la file de traitement. | | Gestion des délais d'attente inadaptés. | Révision des seuils de délai d'attente pour prévenir la saturation des fichiers 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. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR 3421 **Services de paiement concernés par l'incident** Notifications de paiement. **Impact sur les clients** Les notifications de paiement n'étaient plus envoyées aux commerçants. **Aperçu de l'incident** * **19 juin 18h00 :** un volume important de transactions de paiement a été traité. * **19 juin à 18 h 30 : début de l'incident. ** * **20 juin 10h33 :** alerte déclenchée concernant un problème de notification. * **20 juin 11 h 46 :** une équipe dédiée à la gestion de crise a été mise en place. Les enquêtes ont commencé. * **20 juin 11 h 48 :** l'échec de l'envoi des notifications de paiement a été identifié. Les enquêtes se sont poursuivies. * **20 juin à 12 h 50 : cause première identifiée. ** * **20 juin 13 h 02 — 15 h 15 :** diverses mesures correctives ont été déployées. * **20 juin à 15 h 17 : incident résolu. ** * **20 juin 22 h 32 :** des processus automatisés ont été lancés pour renvoyer les notifications. * **21 juin 11 h 57 :** confirmation que toutes les notifications ont été renvoyées avec succès. **Cause principale** Un volume anormalement élevé de notifications ayant échoué, combiné à de nouvelles tentatives automatiques vers une URL non disponible, a saturé la file d'attente de traitement des notifications. Par conséquent, la saturation a empêché l'envoi de notifications de paiement. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Aucune alerte spécifique n'était en place pour la file d'attente de traitement des notifications. | Des alertes spécifiques ont été introduites pour détecter et anticiper de manière proactive toute saturation de la file d'attente de traitement. | | Aucune limite par commerçant n'était en place pour l'envoi de demandes de paiement. | Une limite par commerçant a été mise en place pour contrôler le trafic de notifications et éviter la saturation de la file d'attente de traitement. | | Paramètres de temporisation inappropriés. | Une révision des seuils de temporisation est en cours pour éviter la saturation des files d'attente de traitement des notifications. | | Retard dans la réponse aux incidents. | La procédure de gestion des incidents en dehors des heures de bureau est en cours de révision et sera communiquée aux équipes concernées. |

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 juin 2026 à 10:24 UTCinvestigating

   FR Les retournements des 13, 14 et 15 juin prévus aujourd'hui n'ont pas pu être inversés dans leur intégralité. Nos équipes sont pleinement mobilisées afin de résoudre la situation dans les meilleurs délais et de rétablir un traitement normal des inversions. Nous vous tiendrons informés de l'évolution de la situation dès que de nouvelles informations seront disponibles. FR Les règlements relatifs aux 13, 14 et 15 juin qui étaient prévus pour aujourd'hui n'ont pas pu être traités dans leur intégralité. Nos équipes sont pleinement mobilisées pour résoudre la situation le plus rapidement possible et rétablir un traitement normal des règlements. Nous vous tiendrons informés de tout développement dès que de plus amples informations seront disponibles. IL I versamenti del 13, 14 e 15 giugno previsti per oggi non hanno potuto essere effettuati integralmente. I nostri team sono pienamente impegnati a risolvere la situazione nel più breve tempo possibile e a ripristinare il normale processo di versamento dei fondi. Vi terremo informati sugli sviluppi della situazione non appena saranno disponibili nuove informazioni.

2. 16 juin 2026 à 08:58 UTCmonitoring

   TSR-3389 - Début/Start/Début : 16/06/2026 - Fin/Fin/amende : 17/06/2026 - Catégorie/Catégorie/Catégorie : Production, reversement/règlement/versamento - Responsabilité/Responsabilité : Payplug - Priorité/Priorité/Priorité : P2. FR Les fonds restants n'ayant pas pu être inversés hier le seront aujourd'hui. Aucune action n'est requise de votre part et les fonds seront disponibles sur vos comptes comme habituellement. FR Les fonds restants qui n'ont pas pu être réglés hier seront réglés aujourd'hui. Aucune action n'est requise de votre part et les fonds seront disponibles sur vos comptes comme d'habitude. IL I fondi rimanenti che non hanno potuto essere versati ieri saranno accreditati oggi. Non è richiesta alcuna azione da parte vostra e i fondi saranno disponibili sui vostri conti como di consueto.

3. 16 juin 2026 à 09:17 UTCresolved

   Cet incident a été résolu.

4. 16 juin 2026 à 13:27 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-3389 **Service concerné** Reversement des transactions. **Influencer le client** Impossibilité de procéder au reversement de l'intégralité des transactions pendant la durée de l'incident, entraînant un retard de règlement des marchands. **Synthèse de l'incident** * **15 juin 10h10 :** remontées d'alertes indiquant que certains marchands n'ont pas reçu de fonds. **Début de l'incident** et début des premières analyses. * **15 juin 10h36 :** création d'une cellule de crise dédiée. * **15 juin 10h37 :** identification d'un problème de génération de certaines demandes de virements. * **15 juin 10h52 :** identification d'un second incident affectant la validation des virements. * **15 juin 11h11 :** résolution de l'incident affectant la validation des virements. * **15 juin 11h14 :** demande de validation des virements contenant les transactions du week-end et poursuite des investigations sur l'erreur de génération de certaines demandes de virements. * **15 juin 11h34 :** validation des virements du week-end & poursuites des investigations pour pouvoir envoyer les fonds le lendemain suite au dépassement du cutoff. * **15 juin 11h55 : identification de l'origine de l'incident. ** * **15 juin 12h22 :** élaboration d'un plan d'action pour permettre l'envoi des fonds manquants le lendemain. * **15 juin 15h :** déploiement des actions correctives sous surveillance des équipes. * **15 juin 17h10 :** fin des actions correctives. **Fin de l'incident. ** * **16 juin 7h30** : aucune alerte indiquant des erreurs. * **16 juin 9h30 :** vérification de la bonne génération des demandes de virement. * **16 juin 10h57 :** contrôle des virements par les équipes techniques. * **16 juin 10h59 :** les différents contrôles confirment le reversement de l'ensemble des fonds. **Cause principale** Une erreur dans le déclenchement d'un lanceur de tâche a interrompu la génération des fichiers de virements et a ainsi empêché le reversement de certains fonds. **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence d'une alerte spécifique sur la non génération d'un fichier. | Ajout d'une alerte pour détecter des erreurs de non génération d'un fichier et anticiper un incident de reversement. | | Absence d'alerte spécifique sur l'échec d'un lanceur de tâches. | Réflexions en cours pour ajouter des alertes pouvant remonter des échecs dans un lanceur de tâches. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-3389 **Services de paiement concernés par l'incident** Règlement des transactions **Impact sur les clients** Incapacité de régler toutes les transactions pendant l'incident, ce qui a retardé le règlement des transactions par les commerçants. **Aperçu de l'incident** * **15 juin 10 h 10 :** des alertes ont été déclenchées indiquant que certains commerçants n'avaient pas reçu leurs fonds. **Début de l'incident** et début des enquêtes initiales. * **15 juin 10 h 36 :** une équipe dédiée à la gestion de crise a été mise en place. * **15 juin 10h37 :** un problème affectant la génération de certaines demandes de virement bancaire a été identifié. * **15 juin 10 h 52 :** un deuxième incident affectant la validation du transfert a été identifié. * **15 juin 11 h 11 :** l'incident affectant la validation du transfert a été résolu. * **15 juin 11 h 14 :** demande de validation de virements contenant des transactions du week-end, tandis que les enquêtes se poursuivaient sur l'erreur affectant la génération de certaines demandes de transfert. * **15 juin 11 h 34 :** transferts de fin de semaine validés. Les enquêtes se sont poursuivies afin de permettre l'envoi des fonds manquants le lendemain en raison du dépassement de l'heure limite. * **15 juin 11 h 55 :** **cause première de l'incident identifiée. ** * **15 juin 12h22 :** un plan d'action a été élaboré pour permettre l'envoi des fonds manquants le lendemain. * **15 juin 15 h 00 :** actions correctives déployées sous la supervision de l'équipe. * **15 juin 17 h 10 :** mesures correctives terminées. **Incident résolu. ** * **16 juin à 7 h 30 :** aucune alerte indiquant une erreur. * **16 juin 9h30 :** vérification de la bonne génération des demandes de virement. * **16 juin 10h57 : ** transferts vérifiés par les équipes techniques. * **16 juin à 10 h 59 :** tous les chèques ont confirmé que tous les fonds avaient été réglés avec succès. **Cause principale** Une erreur lors du déclenchement d'un planificateur de tâches a interrompu la génération des fichiers de virement bancaire, empêchant le règlement de certains fonds. **Mesures prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Aucune alerte spécifique n'a été mise en place pour détecter l'échec de génération d'un fichier. | Une alerte a été ajoutée pour détecter les échecs de génération de fichiers et identifier de manière proactive les incidents de règlement potentiels. | | Aucune alerte spécifique n'était en place pour détecter les défaillances du planificateur de tâches. | Des discussions sont en cours pour mettre en place des alertes capables de signaler les défaillances dans le planificateur de tâches. |

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 juin 2026 à 04:43 UTCinvestigating

   FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins. L'incident est en cours d'analyse. FR Nous avons identifié des problèmes affectant les paiements en ligne et en magasin. Une enquête est en cours. IL Abbiamo identificato delle difficultà nei pagamenti online e nei punti vendita. L'incident est en cours d'analyse.

2. 7 juin 2026 à 05:05 UTCinvestigating

   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. FR Nous avons identifié des problèmes sur la plateforme de paiement. Après analyse, il apparaît que l'incident est externe à notre plateforme. Nous vous tiendrons informés de tout développement dès que de plus amples informations seront disponibles. IL Abbiamo identificato delle difficultà sulla platforma di pagamento. Après une analyse, il apparaît que l'incident est externe à notre plateforme. Vi terremo aggiornati sugli sviluppi non appena saranno disponibili nuove informazioni.

3. 7 juin 2026 à 05:28 UTCresolved

   TSR-XXXX - Début/Début : 07/06/2026 06:15:00 CEST - Fin/Fin : 07/06/2026 06:58:00 CEST - Catégorie/Catégorie : Production/ Transformation - Responsabilité/Responsabilité : Externe - Priorité/Priorité : P1 FR L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. FR L'incident est désormais résolu et le service est rétabli. La reprise du service est toujours surveillée.

4. 24 juillet 2026 à 09:23 UTCpostmortem

   # Version anglaise ci-dessous # Post Mortem **Service concerné** Paiement en magasin, e-commerce et 3DS. **Pacte 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 enquêtes. * **7 juin 6h28 : identification d'un serveur défectueux chez un médecin externe.** * **7 juin 6h29 :** contacter le prestataire externe. * **7 juin 6h54 :** confirmation du régime externe que l'incident est bien chez eux. * **7 juin 6h57 : fin de l'incident.** ** Cause de la mort** Incident externe chez un médecin. (en milliers de dollars) ============ VERSION ENGLISH=================== # Post Mortem **Services de paiement touchés par l'incident** Paiements en magasin, paiements de commerce électronique et 3DS. ** Impact sur le client** Les détenteurs de cartes n'ont pas pu effectuer de paiements. ** Aperçu de l'incident** * **7 juin, 6 h 02 :** alerte soulevée. * **7 juin 6h15 : l'incident a commencé.** * **7 juin 6h27 :** une équipe de gestion de crise a été créée. Les enquêtes ont commencé. * **7 juin 6h28 : un serveur défectueux a été identifié chez un fournisseur de services externe.** * **7 juin 6h29 :** le fournisseur de services externes a été contacté. * **7 juin 6h54 :** le prestataire de services externes a confirmé que l'incident venait de leur côté. **7 juin 6 h 57 : résolution de l'incident** ** Cause de la mort** Un incident externe chez un fournisseur de services.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 mai 2026 à 09:00 UTCmonitoring

   FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins entre 9h58 et 10h12. L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. FR Nous avons identifié des problèmes affectant les paiements en ligne et en magasin entre 9 h 58 et 10 h 12. L'incident est désormais résolu et le service est rétabli. La reprise du service est toujours surveillée. IL Abbiamo identificato delle difficultà nei pagamenti online e nei punti vendita tra 9:58 e 10:12. L'incident est maintenant résolu et le service a été rétabli. Continuiamo a monitorare la represa del servizio.

2. 7 mai 2026 à 14:15 UTCresolved

   Cet incident a été résolu.

3. 15 mai 2026 à 13:32 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-3279 **Service concerné** E-commerce Payments, 3DS et en magasins. **Influencer le client** Impossibilité pour les porteurs d'effectuer des paiements. **Synthèse de l'incident** * **7 mai 9h58 :** **début de l'incident. ** * **7 mai 9h59 :** remontée d'alerte. Début des enquêtes. * **7 mai 10h03 :** création d'une cellule de crise dédiée et poursuite des enquêtes. * **7 mai 10h09 : identification de l'origine de l'incident. ** * **7 mai 10h10 :** lancement des actions correctives. * **7 mai à 10h12 : fin de l'incident. ** **Cause principale** La mise à jour d'un composant technique a activé une option de sécurité qui a entraîné un redémarrage de l'ensemble des serveurs ainsi que d'une base de données. Les serveurs ayant redémarré avant la base de données, ils n'ont pas pu appeler la configuration des marchands présents dans cette base de données ce qui a causé l'échec des paiements. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Redémarrage automatique des serveurs suite à la mise à jour de ce composant technique. | Désactivation du redémarrage automatique lié à ce composant technique spécifique. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-3279 **Services de paiement concernés par l'incident** E-commerce, 3DS et paiements en magasin. **Impact sur les clients** Les titulaires de cartes n'ont pas pu effectuer de paiements. **Aperçu de l'incident** * **7 mai 9 h 58 : début de l'incident. ** * **7 mai 9 h 59 :** alerte déclenchée. Les enquêtes ont commencé. * **7 mai 10 h 03 :** Une cellule de crise dédiée a été mise en place et les enquêtes se sont poursuivies. * **7 mai à 10 h 09 : cause première identifiée. ** * **7 mai 10 h 10 :** actions correctives lancées. * **7 mai 10 h 12 :** **fin de l'incident. ** **Cause principale** La mise à jour d'un composant technique a activé une option de sécurité qui a déclenché le redémarrage de tous les serveurs ainsi que d'une base de données. Les serveurs ayant redémarré avant la création de la base de données, ils n'ont pas pu récupérer les configurations des commerçants stockées dans la base de données, ce qui a entraîné des échecs de paiement. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Redémarrage automatique du serveur suite à la mise à jour de ce composant technique. | Désactivation du redémarrage automatique lié à ce composant technique spécifique. |

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 avril 2026 à 09:50 UTCmonitoring

   FR Les retournements des 3, 4 et 5 avril ont été effectués. Ceux du 6 et 7 avril initialement prévus aujourd'hui seront effectués demain. Aucune action n'est requise de votre part, et les fonds seront disponibles sur vos comptes comme habituellement. Les détails des virements correspondants seront mis à disposition aujourd'hui. FR Les règlements des 3, 4 et 5 avril sont terminés. Celles des 6 et 7 avril, initialement prévues aujourd'hui, seront effectuées demain. Aucune action n'est requise de votre part et les fonds seront disponibles sur vos comptes comme d'habitude. Les détails des transferts correspondants seront disponibles aujourd'hui. IL Les élections des 3, 4 et 5 avril ont été effectuées. Quelli del 6 e 7 avril, initialement previsti per oggi, saranno effettuati domani. Non è richiesta alcuna azione da parte vostra e i fondi saranno disponibili sui vostri conti como di consueto. I dettagli dei bonifici corrispondenti saranno messi a disposizione oggi.

2. 8 avril 2026 à 09:05 UTCmonitoring

   FR Les fonds des 6 et 7 avril ont été inversés. Ceux du 8 avril initialement prévus aujourd'hui seront effectués demain. Aucune action n'est requise de votre part, et les fonds seront disponibles sur vos comptes comme habituellement. FR Les fonds pour les 6 et 7 avril ont été réglés. Celles du 8 avril, initialement prévues aujourd'hui, seront effectuées demain. Aucune action n'est requise de votre part et les fonds seront disponibles sur vos comptes comme d'habitude. IL Les fonds du 6 au 7 avril ont été transférés. Quelli dell'8 avril, initialement previsti per oggi, saranno effettuati domani. Non è richiesta alcuna azione da parte vostra e i fondi saranno disponibili sui vostri conti como di consueto.

3. 9 avril 2026 à 09:16 UTCresolved

   FR L'intégralité des fonds sera reversée dans la journée. Les détails des virements correspondants seront mis à disposition aujourd'hui. FR Tous les fonds seront transférés au cours de la journée. Les détails des transferts correspondants seront disponibles aujourd'hui. IL L'intégralité de l'importation des fonds sera transférée au cours de la journée. I dettagli dei bonifici corrispondenti saranno messi a disposizione oggi.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 mars 2026 à 10:58 UTCidentified

   TSR-3077 - Début/Début : 16/03/2026 - Fin/Fin : En cours/En cours - Catégorie/Catégorie : Inversions/Colonies - Responsabilité/Responsabilité : Un confirmateur/À confirmer - Priorité/Priorité : P1 FR Un incident impacte actuellement l'émission des virements. Les virements prévus aujourd'hui ne pourront pas être effectués. Nos équipes sont mobilisées pour résoudre la situation et nous vous tiendrons informés dès que les virements pourront être envoyés. FR Un incident affecte actuellement l'émission des règlements. Les règlements prévus pour aujourd'hui ne pourront pas être réalisés. Nos équipes travaillent activement pour résoudre la situation et nous vous tiendrons informés dès que les virements pourront être envoyés. IL Un incident sta attualmente impattando l'emissione dei versamenti. I bonifici previsti per oggi ne potranno essere effettuati. I nostri team sono mobilitati per risolvere la situazione e vi terremo informati non appena i bonifici potranno essere inviati.

2. 17 mars 2026 à 08:48 UTCidentified

   TSR-3077 - Début/Début : 16/03/2026 - Fin/Fin : En cours/En cours - Catégorie/Catégorie : Inversions/Colonies - Responsabilité/Responsabilité : Payplug - Priorité/Priorité : P1 FR Des actions correctives ont été menées pour rattraper les fichiers de reversements d'hier. Toutefois, un problème empêche actuellement leur validation. Nos équipes sont mobilisées pour rétablir la situation dans les plus brefs délais. FR Des mesures correctives ont été prises pour récupérer les dossiers des règlements d'hier. Cependant, un problème empêche actuellement leur validation. Nos équipes s'efforcent de rétablir la situation le plus rapidement possible. IL Sono state intraprese acioni correttive per recuperare i file dei versamenti di ieri. Cependant, un problème empêche actuellement leur validation. I nostri team sono mobilitati per repristinare la situazione nel più breve tempo possibile.

3. 17 mars 2026 à 11:12 UTCmonitoring

   TSR-3077 - Début/Début : 16/03/2026 - Fin/Fin : En cours/17/03/2026 - Catégorie/Catégorie : Inversions/Colonies - Responsabilité/Responsabilité : Payplug - Priorité/Priorité : P1 FR Les retournements des 16 et 17 mars ont été validés. Les fonds seront disponibles dans la journée. FR Les règlements des 16 et 17 mars ont été validés. Les fonds seront disponibles aujourd'hui. IL I versamenti del 16 e 17 marzo sono stati validati. Les fonds seront disponibles pendant la journée.

4. 17 mars 2026 à 13:29 UTCresolved

   Cet incident a été résolu.

5. 27 mars 2026 à 10:49 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-3077 **Service concerné** Reversement des paiements en ligne et en magasin. **Influencer le client** Impossibilité de procéder au reversement des transactions pendant la durée de l'incident, entraînant un retard de règlement des marchands. **Synthèse de l'incident** * **16 mars 11h02 :** création d'une cellule de crise dédiée et début des enquêtes. * **16 mars 11h05 :** identification d'un échec de dépôt des fichiers de reversements. * **16 mars 11h15 :** identification d'un second problème : impossibilité d'accéder à l'outil permettant la validation des virements. * **16 mars 11h15 - 12h :** poursuite des enquêtes. * **16 mars 12h :** confirmation de l'impossibilité de débloquer les fonds le jour même. * **16 mars 12h - 18h30 :** poursuite des enquêtes. * **17 mars 9h :** reprise de la cellule de crise. * **17 mars 9h28 :** récupération des fichiers de virements de la veille. Poursuite des enquêtes. * **17 mars 10h23 : identification d'une solution de contournement permettant d'envoyer les fonds. ** * **17 mars 10h23 - 11h15 :** tests pour vérifier le bon fonctionnement de la solution. Concluants des tests. * **17 mars 11h30 :** validation des fichiers de retournements. **Fin de l'incident. ** * **17 mars 12h09 :** confirmation du traitement des fichiers et du transfert des fonds dans la journée. **Cause principale** Une opération de migration a introduit une incohérence dans les données techniques utilisées par le système de validation des virements, en raison d'un défaut entre deux mécanismes. Cette situation a bloqué le traitement normal des validations. **Actions prises par Payplug** Un retour arrière vers la dernière version stable a été initié afin de restaurer le service. This operation a permis de rétablir l'ensemble des fonctionnalités de validation des virements de manière fiable. ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-3077 **Services de paiement concernés par l'incident** E-commerce et règlement des paiements en magasin. **Impact sur les clients** Incapacité de traiter l'annulation des transactions pendant la période de l'incident, ce qui entraîne un retard dans le règlement des transactions par les commerçants. **Aperçu de l'incident** * **16 mars 11 h 02 :** création d'une équipe de crise dédiée et début des enquêtes. * **16 mars 11 h 05 :** identification d'un échec dans la soumission des dossiers de décaissements. * **16 mars 11 h 15 :** identification d'un deuxième problème : impossibilité d'accéder à l'outil utilisé pour valider les transferts. * **16 mars 11 h 15 — 12 h :** enquêtes en cours. * **16 mars à 12 h 00 :** confirmation que les fonds n'ont pas pu être débloqués le jour même. * **16 mars de 12 h à 18 h 30 :** enquêtes en cours. * **17 mars à 9 h 00 :** l'équipe de crise a repris ses activités. * **17 mars 9h28 :** récupération des fichiers de transfert de la veille. Enquêtes en cours. * **17 mars 10 h 23 :** **identification d'une solution permettant d'envoyer les fonds. ** * **17 mars 10 h 23 — 11 h 15 : ** tests pour vérifier la solution. Tests réussis. * **17 mars à 11 h 30 :** validation des dossiers de décaissements. **Incident résolu. ** * **17 mars à 12 h 09 :** confirmation que les dossiers ont été traités et que les fonds seraient transférés dans la journée. **Cause principale** Une migration a introduit une incohérence dans les données techniques utilisées par le système de validation des transferts, en raison d'une divergence entre deux mécanismes, ce qui a empêché le traitement normal des validations. **Mesures prises par Payplug** Un retour à la dernière version stable a été lancé pour restaurer le service. Cette opération a restauré avec succès toutes les fonctionnalités de validation des transferts.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 2 mars 2026 à 11:46 UTCinvestigating

   FR Nous avons identifié des difficultés sur la plateforme de paiement. L'incident est en cours d'analyse. FR Nous avons identifié des difficultés persistantes sur la plateforme de paiement. Une enquête est en cours. IL Abbiamo identificato delle difficultà nell'elaborazione dei pagamenti. L'incident est en cours d'analyse.

2. 2 mars 2026 à 12:09 UTCmonitoring

   TSR-3011 - Début/Début : 02/03/2026 12h28 CET - Fin/Fin : 02/03/2026 13h01 CET - Catégorie/Catégorie : Traitement de production - Responsabilité/Responsabilité : Payplug - Priorité/Priorité : P1 FR L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. FR L'incident est désormais résolu et le service est rétabli. La reprise du service est toujours surveillée. IL L'incident a été résolu et le service a été repristiné. Continuiamo a monitorare la represa del servizio.

3. 2 mars 2026 à 14:15 UTCresolved

   Cet incident a été résolu.

4. 5 mars 2026 à 15:09 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-3011 **Service concerné** E-commerce Payments, 3DS et en magasins. **Influencer le client** Impossibilité pour les porteurs d'effectuer des paiements. **Synthèse de l'incident** * **2 mars 12h26 :** déploiement d'une mise en production. * **2 mars à 12h28 : début de l'incident. ** * **2 mars 12h29 :** première remontée d'alerte. * **2 mars 12h33 :** création d'une cellule de crise dédiée. Début des enquêtes. * **2 mars à 12h37 :** identification d'erreurs sur un service. * **2 mars 12h56 : identification de l'origine de l'incident. ** * **2 mars 13h :** mise en place d'actions correctives. * **2 mars 13h01 : reprise du trafic e-commerce et 3DS. ** * **2 mars 13h38 :** remontée d'erreurs sur certains paiements en magasins. Poursuite des enquêtes. * **2 mars 13h50 :** identification et redémarrage des services en erreur. **Fin de l'incident. ** **Contexte** N/A **Cause principale** Une mise en production a entraîné la mise en pause des points d'entrées des services acceptant les transactions. Ces points d'entrées étant en pause, ils n'acceptaient plus les transactions et ont causé l'interruption du trafic. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Déploiement d'une mise en production sur un horaire critique. | Rappel du processus de déploiement pour éviter les mises en production sur un horaire critique. | | Monitoring défaillant sur les points d'entrées des services acceptant les transactions. | Renforcement du monitoring sur les points d'entrées et sur les services répartissant les transactions. | | Absence de contrôle sur un certificat spécifique suite au déploiement d'une mise en production. | Ajout de contrôle pour vérifier l'état du certificat après le déploiement d'une mise en production. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-3011 **Services de paiement concernés par l'incident** Paiements en ligne, 3DS et paiements en magasin. **Impact sur les clients** Les titulaires de cartes n'ont pas pu effectuer de paiements. **Aperçu de l'incident** * **2 mars à 12 h 26 :** déploiement en production. * **2** **12 h 28 mars :** **début de l'incident. ** * **2 mars 12h29 :** première alerte déclenchée. * **2 mars à 12 h 33 :** mise en place d'une équipe de crise dédiée. Les enquêtes commencent. * **2 mars à 12 h 37 :** erreurs identifiées sur un service. * **2 mars à 12 h 56 :** **cause première de l'incident identifiée. ** * **2 mars à 13 h 00 :** mesures correctives mises en œuvre. * **2 mars 13h01 : reprise du commerce électronique et du trafic 3DS. ** * **2 mars 13 h 38 :** erreurs signalées sur certains paiements en magasin. Les enquêtes se poursuivent. * **2 mars 13h50 :** identification et redémarrage des services concernés. **Fin de l'incident. ** **Contexte** N/A **Cause principale** Un déploiement de production a entraîné la suspension des points d'entrée des services gérant les transactions. Ces points d'entrée étant suspendus, ils n'acceptaient plus les transactions, ce qui a entraîné une interruption du trafic. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Déploiement en production effectué pendant une fenêtre temporelle critique. | Rappel du processus de déploiement pour éviter les déploiements en production pendant des fenêtres temporelles critiques. | | Surveillance insuffisante des points d'entrée des services acceptant les transactions. | Renforcement de la surveillance des points d'entrée et des services distribuant les transactions. | | Absence de vérification d'un certificat spécifique après un déploiement de production. | Ajout de contrôles pour vérifier l'état du certificat après un déploiement de production. |

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 février 2026 à 08:39 UTCmonitoring

   Bonjour, Des perturbations sont en cours depuis 8h00 ce jour concernant l'authentification 3-D Secure. Cet incident externe à notre plateforme concerne les porteurs de carte Crédit agricole. Nous vous tiendrons informés lorsque l'incident sera résolu. -------------- En italien : Bonjour, Ci sono delle perturbazioni in corso della 9:00 di oggi riguardanti l'autenticazione 3-D Secure. Sono principalmente i titolari delle MasterCard ad essere interessati. Questo incidente, esterno alla nostra platforma, riguarda circa il 30 al 50% delle richieste di autenticazione 3-D Secure. Vi terremo informati non appena l'incidente sarà resolto. -------------- En anglais : Bonjour, Des perturbations sont en cours depuis 8 h 00 ce jour en ce qui concerne l'authentification 3D-Secure. Cet incident est externe à notre plateforme. Les titulaires de cartes du Crédit Agricole sont les principaux concernés. Nous vous tiendrons au courant dès que l'incident sera résolu.

2. 21 février 2026 à 12:26 UTCmonitoring

   L'incident externe est toujours en cours. Nous vous tiendrons informés en cas de changements. --------------- L'incident est toujours en cours. Nous vous tiendrons au courant en cas de changement.

3. 21 février 2026 à 14:52 UTCresolved

   EXTERNE - Dysfonctionnements en cours concernant l'authentification 3-D Secure (9h00 CET - 15h00 CET) FR L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. FR L'incident est désormais résolu et le service est rétabli. La reprise du service est toujours surveillée. IL L'incident a été résolu et le service a été repristiné. Continuiamo a monitorare la represa del servizio.

4. 23 février 2026 à 09:12 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-2981 **Service concerné** E-commerce Payments et 3DS. **Influencer le client** Impossibilité d'effectuer des paiements pour les porteurs. **Synthèse de l'incident** * **21 février 5 h : début de l'incident. ** * **21 février 6h23 :** remontée d'alerte. Le seuil d'erreur est trop faible à ce stade pour déclencher l'astreinte. * **21 février 8h32 :** création d'une cellule de crise dédiée par l'astreinte. Début des enquêtes. * **21 février 8h34 :** identification d'échecs de paiements provenant d'un réseau bancaire spécifique. * **21 février 9h-13h :** poursuite des analyses. * **21 février 13h30 : fin de l'incident. ** * **21 février 14h41 :** confirmation par le réseau d'un incident chez eux. **Contexte** N/A **Cause principale** Incident externe provenant d'un réseau bancaire. ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-2981 **Services de paiement concernés par l'incident** Paiements en ligne et 3DS. **Impact sur les clients** Les titulaires de cartes n'ont pas pu effectuer de paiements. **Aperçu de l'incident** * **21 février 5 h 00 : début de l'incident. ** * **21 février 6h23 :** alerte déclenchée. Le seuil d'erreur est trop bas à ce stade pour déclencher l'équipe d'escalade sur appel. * **21 février 8 h 32 :** équipe de crise dédiée mise en place par l'équipe de garde. Les enquêtes commencent. * **21 février 8 h 34 :** échecs de paiement identifiés provenant d'un réseau bancaire spécifique. * **21 février de 9 h 00 à 13 h 00 :** analyse en cours. * **21 février 13h30 : fin de l'incident. ** * **21 février 14h41 :** confirmation par le réseau d'un incident de leur côté. **Contexte** N/A **Cause principale** Incident externe provenant d'un réseau bancaire.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 février 2026 à 09:59 UTCidentified

   FR Nous avons identifié des difficultés sur la plateforme de paiement. Les transactions concernées sont exclusivement traitées par l'intermédiaire du Crédit Agricole. Les premières analyses indiquent que l'origine de l'incident est externe à notre plateforme. FR Nous avons identifié des difficultés persistantes sur la plateforme de paiement. Les transactions concernées sont limitées à celles traitées via le Crédit Agricole. Les premières enquêtes indiquent que la cause première de l'incident est externe à notre plateforme.

2. 19 février 2026 à 10:25 UTCmonitoring

   FR L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. FR L'incident est désormais résolu et le service est rétabli. La reprise du service est toujours surveillée.

3. 19 février 2026 à 16:19 UTCresolved

   Cet incident a été résolu.

4. 20 février 2026 à 13:54 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR 2964 **Service concerné** E-commerce Payments et 3DS. **Influencer le client** Impossibilité d'effectuer des paiements pour les porteurs. **Synthèse de l'incident** * **19 février 10h19 : début de l'incident. ** * **19 février 10h24 :** création d'une cellule de crise dédiée et début des enquêtes. * **19 février 10h27 :** identification d'erreurs provenant d'un groupe bancaire externe spécifique. * **19 février 10h29 :** contact d'un partenaire pour obtenir des informations supplémentaires concernant l'incident. * **19 février 10h39 :** retour du partenaire confirmant l'incident chez le groupe bancaire externe. * **19 février 10h51 :** contact du groupe bancaire concerné. * **19 février 10h56 : fin de l'incident. ** * **19 février 11h :** le groupe bancaire indique que l'incident provient d'un prestataire externe. **Contexte** N/A **Cause principale** Incident externe chez le prestataire d'un groupe bancaire externe. ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR 2964 **Services de paiement concernés par l'incident** Paiements en ligne et 3DS. **Impact sur les clients** Les titulaires de cartes n'ont pas pu effectuer de paiements. **Aperçu de l'incident** * **19 février 10h19 : début de l'incident. ** * **19 février 10 h 24 :** mise en place d'une équipe de crise dédiée et début des enquêtes. * **19 février 10 h 27 :** erreurs identifiées provenant d'un groupe bancaire externe spécifique. * **19 février 10h29 :** un partenaire est contacté pour obtenir de plus amples informations concernant l'incident. * **19 février 10h39 :** retour du partenaire confirmant l'incident au sein du groupe bancaire externe. * **19 février 10h51 :** le groupe bancaire concerné est contacté. * **19 février 10h56 : fin de l'incident. ** * **19 février 11h00 :** le groupe bancaire indique que l'incident a pour origine un prestataire externe. **Contexte** N/A **Cause principale** Incident externe chez un fournisseur de services d'un groupe bancaire externe.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 février 2026 à 16:11 UTCinvestigating

   FR Nous avons identifié des difficultés sur le portail Payplug. L'incident est en cours d'analyse. FR Nous avons identifié des problèmes avec le portail Payplug. L'enquête est en cours. IL Nous avons identifié des difficultés avec le portail Payplug. L'incident est en cours d'analyse.

2. 18 février 2026 à 07:23 UTCmonitoring

   TSR-2951 - Début/Start/Début : 17/02/2026 16h CET - Fin/Fin/Amende : 17/02/2026 18h52 CET - Catégorie/Catégorie/Catégorie : Portail de production. - Responsabilité/Responsabilité : Payplug. - Priorité/Priorité/Priorité : P1. FR La situation est revenue à la normale suite au déploiement d'un correctif. Nous continuons de surveiller le service. FR La situation est revenue à la normale suite au déploiement d'un correctif. Nous continuons à surveiller le service. IL La situazione è tornata alla normalità a seguito del relascio di una correzione. Continuiamo a monitorare il servizio.

3. 18 février 2026 à 14:32 UTCresolved

   Cet incident a été résolu.

4. 18 février 2026 à 15:05 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-2951 **Service concerné** Portal **Influencer le client** Problèmes de connexion pour accéder au Portail et messages d'erreurs intempestifs une fois connecté. **Synthèse de l'incident** * **16 février 15h15 :** déploiement d'une mise en production. * **16 février 15h18 :** des problèmes de connexions - deconnexions ainsi que des messages d'erreurs apparaissent sur le Portail. **Début de l'incident. ** * **16 février 15h34 :** remontée d'alerte. Début des enquêtes. * **16 février 15h53 :** création d'une cellule incident majeur. * **16 février 15h58 :** Page d'état de la communication. Identification d'une mise en production concordant avec le début de l'incident. Lancement de l'annulation de la mise en production. * **16 février 16h08 :** échec de l'annulation de la mise en production. * **16 février 16h25 : identification de l'origine de l'incident. ** * **16 février 16h33 :** des problèmes de connexions persistants. Lancement du retour à une version précédente de certains services défaillants identifiés. * **16 février 16h54 :** redémarrage des services avec la version précédente. * **16 février 16h59 :** fin des problèmes de connexions sur le Portail. * **16 février 17h06 :** fin des messages d'erreurs sur le Portail. **Fin de l'incident. ** * **17 février 16h16 :** **résurgence des erreurs. ** * **17 février 16h29-18h35 :** création d'une cellule de crise et reprise des analyses. * **17 février 18h40 : identification de l'origine de l'incident et déploiement d'un correctif. ** * **17 février 18h52 : Fin de l'incident. ** **Contexte** N/A **Cause principale** Une mise en production a généré des problèmes d'accès entre nos services internes. Ces problèmes ont engendré une déconnexion forcée de la part de l'utilisateur qui revenait sur sa page d'authentification. La seconde occurrence a été provoquée suite à une nouvelle mise en production qui a récupéré les mauvais identifiants suite au rollback de la veille. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Désynchronisation de certains paramètres d'une clé API. | Mise à jour de l'ensemble des paramètres désynchronisés. | | Renouvellement automatique de la clef API. | Investigations en cours pour empêcher le renouvellement automatique de la clef API. | | Absence d'alerte concernant la désynchronisation de certains paramètres de l'API. | Ajout de messages d'erreurs en cas de désynchronisation des paramètres & amélioration de l'alerte. | | Complexités sur un service de déploiement. | Améliorer les déploiements sur le service gérant les secrets \ (API KEY, mots de passe internes... \) . | | Déconnexion forcée si un service sur l'ensemble est indisponible. | Améliorations en cours pour éviter de déconnecter les utilisateurs dès qu'un service est indisponible. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-2951 **Services de paiement concernés par l'incident** Portail **Impact sur les clients** Problèmes de connexion lors de l'accès au portail et messages d'erreur inattendus une fois connecté. **Aperçu de l'incident** * **16 février à 15 h 15 :** déploiement en production. * **16 février 15 h 18 :** problèmes de connexion : les déconnexions ainsi que des messages d'erreur apparaissent sur le portail. **Début de l'incident. ** * **16 février 15 h 34 :** alerte déclenchée. Les enquêtes commencent. * **16 février 15 h 53 :** Création de l'équipe chargée des incidents majeurs. * ** 16 février à 15 h 58 :** Communication sur la page d'état publiée. Un déploiement de production coïncidant avec le début de l'incident est identifié. Annulation du déploiement initiée. * **16 février 16 h 08 :** L'annulation du déploiement de production a échoué. * **16 février 16 h 25 : identification de la cause première de l'incident. ** * **16 février 16 h 33 :** les problèmes de connexion persistent. Le retour à une version précédente de certains services défectueux identifiés a été lancé. * **16 février 16 h 54 :** les services ont redémarré avec la version précédente. * **16 février 16 h 59 :** fin des problèmes de connexion sur le portail. * **16 février 17h06 :** fin des messages d'erreur sur le portail. **Incident résolu. ** * **17 février 16 h 16 : Récurrence des erreurs. ** * **17 février 16 h 29 à 18 h 35 :** Mise en place d'une équipe de crise et reprise des enquêtes. * **17 février à 18 h 40 : identification de la cause première et déploiement du correctif. ** * **17 février à 18 h 52 : incident résolu. ** **Contexte** N/A **Cause principale** Un déploiement en production a entraîné des problèmes d'accès entre nos services internes. Ces problèmes ont entraîné la déconnexion forcée des utilisateurs et leur ont été redirigés vers la page d'authentification. Le deuxième événement a été déclenché par un déploiement de production ultérieur qui a récupéré des informations d'identification incorrectes après la restauration effectuée la veille. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Désynchronisation de certains paramètres clés d'API. | Mise à jour de tous les paramètres désynchronisés. | | Renouvellement automatique de la clé API. | Enquêtes en cours pour empêcher le renouvellement automatique de la clé API. | | Aucune alerte déclenchée concernant la désynchronisation de certains paramètres de l'API. | Ajout de messages d'erreur en cas de désynchronisation des paramètres et amélioration des alertes. | | Complexités d'un service de déploiement. | Améliorations apportées aux déploiements sur le service de gestion des secrets \ (clés API, mots de passe internes, etc. \) . | | Déconnexion forcée si un service de l'écosystème devient indisponible. | Améliorations en cours pour empêcher les utilisateurs d'être déconnectés dès qu'un service devient indisponible. |

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 février 2026 à 14:58 UTCinvestigating

   FR Nous avons identifié des difficultés sur le portail Payplug. L'incident est en cours d'analyse. FR Nous avons identifié des problèmes avec le portail Payplug. L'enquête est en cours. IL Nous avons identifié des difficultés avec le portail Payplug. L'incident est en cours d'analyse.

2. 16 février 2026 à 15:10 UTCinvestigating

   FR Les enquêtes sont toujours en cours. Nous reviendrons vers vous dans 15 minutes. FR Les enquêtes sont toujours en cours. Nous vous recontacterons dans 15 minutes. IL Les indagini sono ancora in corso. Tu me contacteras dans 15 minutes.

3. 16 février 2026 à 15:25 UTCidentified

   FR Les enquêtes sont toujours en cours. Nous reviendrons vers vous dans 15 minutes. FR Les enquêtes sont toujours en cours. Nous vous recontacterons dans 15 minutes. IL Les indagini sono ancora in corso. Tu me contacteras dans 15 minutes.

4. 16 février 2026 à 15:40 UTCidentified

   TSR-2951 - Début/Start/Début : 16/02/2026 15h18 CET - Fin/Fin /fin : En cours/En cours/En cours/En cours. - Catégorie/Catégorie/Catégorie : Portail de production. - Responsabilité/Responsabilité/Responsabilité : A confirmer/À confirmer/Da confirmare. - Priorité/Priorité/Priorité : P2. FR Les enquêtes sont toujours en cours. Nous reviendrons vers vous dans 15 minutes. FR Les enquêtes sont toujours en cours. Nous vous recontacterons dans 15 minutes. IL Les indagini sono ancora in corso. Tu me contacteras dans 15 minutes.

5. 16 février 2026 à 15:53 UTCidentified

   TSR-2951 - Début/Start/Début : 16/02/2026 15h18 CET - Fin/Fin /fin : En cours/En cours/En cours/En cours. - Catégorie/Catégorie/Catégorie : Portail de production. - Responsabilité/Responsabilité/Responsabilité : A confirmer/À confirmer/Da confirmare. - Priorité/Priorité/Priorité : P2. FR Les demandes de retraits et l'accès au Portail sont actuellement pertubés. Des soucis de déconnexions et des messages d'erreurs peuvent apparaître. Nous travaillons à rétablir le service dès que possible. FR Les demandes de transfert et l'accès au portail sont actuellement perturbés. Les utilisateurs peuvent rencontrer des déconnexions et des messages d'erreur inattendus. Nous nous efforçons de rétablir le service dès que possible. IL Les demandes de secours et l'accès au portail sont actuellement perturbés. Je peux vérifier les déconnexions et les messages d'erreur. Stiamo lavorando per repristinare il servizio il prima possibile.

6. 16 février 2026 à 16:05 UTCmonitoring

   TSR-2951 - Début/Start/Début : 16/02/2026 15h18 CET - Fin/Fin/Amende : 16/02/2026 16h59 CET - Catégorie/Catégorie/Catégorie : Portail de production. - Responsabilité/Responsabilité/Responsabilité : A confirmer/À confirmer/Da confirmare. - Priorité/Priorité/Priorité : P2. FR La situation revient progressivement à la normale depuis 16h59. Nous continuons de surveiller le service. FR La situation est progressivement revenue à la normale depuis 16 h 59. Nous continuons à surveiller le service. IL La situation est revenue progressivement à la normale à partir de 16:59. Continuiamo a monitorare il servizio.

7. 16 février 2026 à 16:11 UTCresolved

   Cet incident a été résolu.

8. 18 février 2026 à 15:00 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-2951 **Service concerné** Portal **Influencer le client** Problèmes de connexion pour accéder au Portail et messages d'erreurs intempestifs une fois connecté. **Synthèse de l'incident** * **16 février 15h15 :** déploiement d'une mise en production. * **16 février 15h18 :** des problèmes de connexions - deconnexions ainsi que des messages d'erreurs apparaissent sur le Portail. **Début de l'incident. ** * **16 février 15h34 :** remontée d'alerte. Début des enquêtes. * **16 février 15h53 :** création d'une cellule incident majeur. * **16 février 15h58 :** Page d'état de la communication. Identification d'une mise en production concordant avec le début de l'incident. Lancement de l'annulation de la mise en production. * **16 février 16h08 :** échec de l'annulation de la mise en production. * **16 février 16h25 : identification de l'origine de l'incident. ** * **16 février 16h33 :** des problèmes de connexions persistants. Lancement du retour à une version précédente de certains services défaillants identifiés. * **16 février 16h54 :** redémarrage des services avec la version précédente. * **16 février 16h59 :** fin des problèmes de connexions sur le Portail. * **16 février 17h06 :** fin des messages d'erreurs sur le Portail. **Fin de l'incident. ** * **17 février 16h16 :** **résurgence des erreurs. ** * **17 février 16h29-18h35 :** création d'une cellule de crise et reprise des analyses. * **17 février 18h40 : identification de l'origine de l'incident et déploiement d'un correctif. ** * **17 février 18h52 : Fin de l'incident. ** **Contexte** N/A **Cause principale** Une mise en production a généré des problèmes d'accès entre nos services internes. Ces problèmes ont engendré une déconnexion forcée de la part de l'utilisateur qui revenait sur sa page d'authentification. La seconde occurrence a été provoquée suite à une nouvelle mise en production qui a récupéré les mauvais identifiants suite au rollback de la veille. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Désynchronisation de certains paramètres d'une clé API. | Mise à jour de l'ensemble des paramètres désynchronisés. | | Renouvellement automatique de la clef API. | Investigations en cours pour empêcher le renouvellement automatique de la clef API. | | Absence d'alerte concernant la désynchronisation de certains paramètres de l'API. | Ajout de messages d'erreurs en cas de désynchronisation des paramètres & amélioration de l'alerte. | | Complexités sur un service de déploiement. | Améliorer les déploiements sur le service gérant les secrets \ (API KEY, mots de passe internes... \) . | | Déconnexion forcée si un service sur l'ensemble est indisponible. | Améliorations en cours pour éviter de déconnecter les utilisateurs dès qu'un service est indisponible. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-2951 **Services de paiement concernés par l'incident** Portail **Impact sur les clients** Problèmes de connexion lors de l'accès au portail et messages d'erreur inattendus une fois connecté. **Aperçu de l'incident** * **16 février à 15 h 15 :** déploiement en production. * **16 février 15 h 18 :** problèmes de connexion : les déconnexions ainsi que des messages d'erreur apparaissent sur le portail. **Début de l'incident. ** * **16 février 15 h 34 :** alerte déclenchée. Les enquêtes commencent. * **16 février 15 h 53 :** Création de l'équipe chargée des incidents majeurs. * ** 16 février à 15 h 58 :** Communication sur la page d'état publiée. Un déploiement de production coïncidant avec le début de l'incident est identifié. Annulation du déploiement initiée. * **16 février 16 h 08 :** L'annulation du déploiement de production a échoué. * **16 février 16 h 25 : identification de la cause première de l'incident. ** * **16 février 16 h 33 :** les problèmes de connexion persistent. Le retour à une version précédente de certains services défectueux identifiés a été lancé. * **16 février 16 h 54 :** les services ont redémarré avec la version précédente. * **16 février 16 h 59 :** fin des problèmes de connexion sur le portail. * **16 février 17h06 :** fin des messages d'erreur sur le portail. **Incident résolu. ** * **17 février 16 h 16 : Récurrence des erreurs. ** * **17 février 16 h 29 à 18 h 35 :** Mise en place d'une équipe de crise et reprise des enquêtes. * **17 février à 18 h 40 : identification de la cause première et déploiement du correctif. ** * **17 février à 18 h 52 : incident résolu. ** **Contexte** N/A **Cause principale** Un déploiement en production a entraîné des problèmes d'accès entre nos services internes. Ces problèmes ont entraîné la déconnexion forcée des utilisateurs et leur ont été redirigés vers la page d'authentification. Le deuxième événement a été déclenché par un déploiement de production ultérieur qui a récupéré des informations d'identification incorrectes après la restauration effectuée la veille. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Désynchronisation de certains paramètres clés d'API. | Mise à jour de tous les paramètres désynchronisés. | | Renouvellement automatique de la clé API. | Enquêtes en cours pour empêcher le renouvellement automatique de la clé API. | | Aucune alerte déclenchée concernant la désynchronisation de certains paramètres de l'API. | Ajout de messages d'erreur en cas de désynchronisation des paramètres et amélioration des alertes. | | Complexités d'un service de déploiement. | Améliorations apportées aux déploiements sur le service de gestion des secrets \ (clés API, mots de passe internes, etc. \) . | | Déconnexion forcée si un service de l'écosystème devient indisponible. | Améliorations en cours pour empêcher les utilisateurs d'être déconnectés dès qu'un service devient indisponible. |

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 5 décembre 2025 à 09:00 UTCinvestigating

   FR Nous avons identifié des difficultés sur le traitement des paiements qui semblent liées à un incident chez Cloudflare. FR Nous avons identifié des difficultés liées au traitement des paiements qui semblent être liées à un incident survenu chez Cloudflare. IL Abbiamo individuato delle difficoltà nell'elaborazione dei pagamenti che sembrano essere correlate a un incidente avvenuto su Cloudflare.

2. 5 décembre 2025 à 09:06 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 5 décembre 2025 à 09:17 UTCmonitoring

   TSR 2651 - Début/Départ : 04/12/2025 09h48 CET - Fin/Fin : 04/12/2025 10h13 CET - Catégorie/Catégorie : Traitement de production - Responsabilité/Responsabilité : Externe/Externe - Priorité/Priorité : P1 FR Le traitement est en train de revenir depuis 10h13. Nous continuons de surveiller le service. FR Le traitement est en cours depuis 10 h 13. Nous continuons à surveiller le service. Le traitement est de retour à partir de 10:13. Continuiamo a monitorare il servizio.

4. 5 décembre 2025 à 14:44 UTCresolved

   Cet incident a été résolu.

5. 9 décembre 2025 à 09:21 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR 2651 **Service concerné** E-commerce Payments et 3DS. **Influencer le client** Impossibilité d'effectuer des paiements pour les porteurs. **Synthèse de l'incident** * **5 décembre 09h48 : début de l'incident** et remontées d'alertes. * **5 décembre 09h52 :** création d'une cellule de crise dédiée. Début des investigations et suspicion d'un incident chez Clouflare. * **5 décembre 09h54 :** confirmation de l'incident chez Cloudflare. * **5 décembre 10h :** Page d'état de la communication. * **5 décembre 10h13 : fin de l'incident. ** **Contexte** N/A **Cause principale** Incident chez Clouflare. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence d'alternative en cas de défaillance de Cloudflare. | Étude en cours sur les alternatives pour avoir une solution de sauvegarde en cas d'incident. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR 2651 **Services de paiement concernés par l'incident** Paiements en ligne et 3DS. **Impact sur les clients** Impossibilité pour les titulaires de cartes d'effectuer des paiements. **Aperçu de l'incident** * **5 décembre 09h48 : début de l'incident** et déclenchement des alertes. * **5 décembre 09h52 :** mise en place d'une cellule de crise dédiée. Début des enquêtes et suspicion d'incident chez Cloudflare. * **5 décembre 09h54 :** confirmation de l'incident chez Cloudflare. * ** 5 décembre, 10 h 00 :** Communication sur la page d'état. * **5 décembre 10h13 : fin de l'incident. ** **Contexte** N/A **Cause principale** Incident chez Cloudflare. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence d'alternative en cas de panne de Cloudflare. | Une étude est actuellement en cours sur les alternatives permettant de fournir une solution de sauvegarde en cas d'incident. |

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 3 décembre 2025 à 10:36 UTCinvestigating

   FR Les retournements du 2 décembre initialement prévus aujourd'hui seront effectués demain. Aucune action n'est requise de votre part, et les fonds seront disponibles sur vos comptes comme habituellement. Les détails des virements correspondants seront mis à disposition aujourd'hui. FR Les paiements pour le 2 décembre, initialement prévus pour aujourd'hui, seront traités demain. Aucune action n'est requise de votre part et les fonds seront disponibles sur vos comptes comme d'habitude. Les détails des transferts correspondants seront disponibles aujourd'hui.

2. 3 décembre 2025 à 10:44 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 4 décembre 2025 à 10:39 UTCmonitoring

   FR Les retournements du 2 décembre ont bien été effectués. En revanche, les retournements du 3 décembre initialement prévus aujourd'hui seront effectués demain. Aucune action n'est requise de votre part, et les fonds seront disponibles sur vos comptes comme habituellement. Les détails des virements correspondants seront mis à disposition aujourd'hui. FR Les paiements pour le 2 décembre ont été traités avec succès. Cependant, les paiements pour le 3 décembre, initialement prévus pour aujourd'hui, seront traités demain. Aucune action n'est requise de votre part et les fonds seront disponibles sur vos comptes comme d'habitude. Les détails des transferts correspondants seront disponibles aujourd'hui.

4. 5 décembre 2025 à 11:20 UTCresolved

   FR Nous vous confirmons le reversement des transactions du 3 décembre. Nous sommes certains à jour sur les inversions. FR Nous confirmons les paiements des transactions à partir du 3 décembre. Nous sommes à jour en ce qui concerne les paiements. IL Vi confirmiamo il rimborso delle transazioni del 3 dicembre. Siamo aggiornati sui rimborsi.

Traduit automatiquement depuis la mise à jour officielle de l'incident.