Historique des pannes de Payplug

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.

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.

1. 21 octobre 2025 à 08:02 UTCinvestigating

   FR Les documents comptables ne peuvent actuellement plus être exportés depuis le Portail. Les documents restent consultables en ligne. Nos équipes enquêtent activement sur la cause du problème. FR Les documents comptables ne peuvent plus être exportés depuis le portail pour le moment. Les documents restent disponibles pour consultation en ligne. Nos équipes étudient activement la cause du problème. IL I documententi contabili non possono actualmente più essere exportati dal Portale. Les documents restent consultables en ligne. Notre équipe est en train d'étudier activement la cause du problème.

2. 21 octobre 2025 à 08:40 UTCinvestigating

   TSR- 2453 - Début/Début/Début : A confirmer/À confirmer/À confirmer. - 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é : P3. FR L'incident semble affecter uniquement les tentatives d'exports réalisées avec Google Chrome. Les documents comptables sont téléchargeables avec Firefox. Nos équipes continuent d'enquêter pour détecter l'origine de l'incident. FR L'incident semble affecter uniquement les tentatives d'exportation effectuées avec Google Chrome. Les documents comptables peuvent être téléchargés via Firefox. Nos équipes continuent d'enquêter pour déterminer la source de l'incident. IL L'incident semble influencer uniquement les tentatives d'exportation effectuées avec Google Chrome. Les documents comptables peuvent être téléchargés à l'aide de Firefox. Notre équipe poursuit ses recherches pour déterminer l'origine de l'incident.

3. 21 octobre 2025 à 12:00 UTCmonitoring

   TSR- 2453 - Début/Start/Début : 21/10/2025 8h30 - Fin/Fin/Amende : 21/10/2025 13h54 - Catégorie/Catégorie/Catégorie : Portail de production. - Responsabilité/Responsabilité/Responsabilité : A confirmer/À confirmer/Da confirmare. - Priorité/Priorité/Priorité : P3. FR Les documents comptables sont de nouveaux téléchargeables depuis Google Chrome. Nos équipes continuent de surveiller le service. FR Les documents comptables peuvent désormais être téléchargés à nouveau à l'aide de Google Chrome. Nos équipes continuent de surveiller le service. IL Les documents comptables peuvent être téléchargés à nouveau via Google Chrome. Notre équipe continue de surveiller le service.

4. 23 octobre 2025 à 06:10 UTCresolved

   Cet incident a été résolu.

5. 13 novembre 2025 à 10:58 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-2453 **Service concerné** Marchand Portal **Influencer le client** Impossibilité pour les marchands d'exporter les documents comptables. **Synthèse de l'incident** * **21 octobre 8h30 :** demandes d'exports volumineuses répétées par un utilisateur. **Début de l'incident. ** * **21 octobre 9h48 :** remontées d'alertes sur l'indisponibilité des documents comptables. * **21 octobre 9h50 :** création d'un ticket auprès des équipes techniques. Début des enquêtes. * **21 octobre 10h02 :** Page d'état de la communication. * **21 octobre 10h07 :** escalade du ticket. * **21 octobre 10h30 :** identification d'une solution de contournement transmise aux marchands. * **21 octobre 11h19 :** identification de l'origine de l'incident. * **22 octobre 16h43 :** mise en place d'actions pour éviter la reproduction de l'incident. **Fin de l'incident. ** * **Depuis le 23 octobre :** poursuite des enquêtes pour traiter la cause profonde. **Contexte** N/A **Cause principale** Le service de génération des exportations comptables a été impacté par des demandes très volumineuses et répétées faites par des utilisateurs. Ces demandes ont créé une surcharge et ont rendu le service inaccessible. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Méconnaissance de l'impact des demandes volumineuses et répétées d'exports. | Mise en place d'une alerte dès qu'un export important est demandé. Rédaction d'une procédure en cas de reproduction de la situation. | | Saturation du service de génération des exportations comptables. | Enquêtes en cours. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-2453 **Services de paiement concernés par l'incident** Portail marchand. **Impact sur les clients** Les commerçants ne sont pas en mesure d'exporter des documents comptables. **Aperçu de l'incident** * **21 octobre à 8 h 30 :** demandes d'exportation volumineuses répétées par un utilisateur. **Début de l'incident. ** * **21 octobre 9h48 :** alertes émises concernant l'indisponibilité de documents comptables. * **21 octobre 9h50 :** ticket créé pour les équipes techniques. Début des enquêtes. * **21 octobre 10 h 02 :** Communication sur la page d'état publiée. * **21 octobre 10 h 07 :** billet augmenté. * **21 octobre à 10 h 30 :** identification d'une solution de contournement partagée avec les commerçants. * **21 octobre 11 h 19 :** identification de la cause première de l'incident. * **22 octobre 16 h 43 :** mise en œuvre de mesures visant à éviter que cela ne se reproduise. **Fin de l'incident. ** * **Depuis le 23 octobre :** Enquêtes en cours pour s'attaquer à la cause première. **Contexte** N/A **Cause principale** Le service de génération d'exportations comptables a été affecté par des demandes très importantes et répétées de la part de plusieurs utilisateurs. Ces demandes ont provoqué une surcharge, rendant le service inaccessible. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Méconnaissance de l'impact des demandes d'exportation importantes et répétées. | Mise en place d'une alerte chaque fois qu'une exportation importante est demandée. Rédaction d'une procédure au cas où la situation se reproduirait. | | Saturation du service de génération d'exportations comptables. | Enquêtes en cours. |

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

1. 4 septembre 2025 à 09:23 UTCidentified

   TSR-2228 - Début/Début : 04/09/2025 - Fin/Fin : En cours/En cours - Catégorie/Catégorie : Reversement/Règlement - Responsabilité/Responsabilité : Payplug - Priorité/Priorité : P2 FR Le reversement de certaines opérations de paiement e-commerce et magasin qui aurait dû être effectué aujourd'hui n'a pas pu être effectué dans les temps. La réconciliation financière correspondante sera mise à disposition aujourd'hui. L'origine de l'incident a été identifiée et les virements non exécutés seront automatiquement reportés et traités demain, sans qu'aucune action ne soit nécessaire de votre part. FR Le paiement de certaines transactions de commerce électronique et de paiement en magasin qui auraient dû être effectuées aujourd'hui n'a pas pu être effectué à temps. Le rapprochement financier correspondant sera disponible aujourd'hui. La cause de l'incident a été identifiée et les paiements non exécutés seront automatiquement reportés et traités demain, sans qu'aucune action ne soit requise de votre part.

2. 4 septembre 2025 à 12:35 UTCmonitoring

   TSR-2228 - Début/Début : 04/09/2025 - Fin/Fin : En cours/En cours - Catégorie/Catégorie : Reversement/Règlement - Responsabilité/Responsabilité : Payplug - Priorité/Priorité : P2 FR Nous confirmons le rattrapage des virements qui seront inversés demain. Nous continuons de surveiller le service. FR Nous confirmons le recouvrement des virements, qui seront versés demain. Nous continuons à surveiller le service.

3. 5 septembre 2025 à 08:43 UTCresolved

   TSR-2228 - Début/Début : 04/09/2025 - Fin/Fin : 05/09/2025 - Catégorie/Catégorie : Reversement/Règlement - Responsabilité/Responsabilité : Payplug - Priorité/Priorité : P2 FR Les opérations de paiement e-commerce et magasin non inversées hier ont été inversées aujourd'hui. La réconciliation financière correspondante intègre bien les transactions rattrapées. FR Les opérations de commerce électronique et de paiement en magasin qui n'étaient pas réglées hier l'ont été aujourd'hui. Le rapprochement financier correspondant inclut avec précision les transactions récupérées.

4. 5 septembre 2025 à 12:16 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR-2228 **Service concerné** Reversement des paiements en ligne et en magasin. **Influencer le client** Reversement partiel des transactions. **Synthèse de l'incident** * **4 septembre 7h30 :** début de saturation des fichiers traitant différents flux. **Début de l'incident. ** * **4 septembre 8h50 :** détection d'un retard dans le traitement des virements. Création d'une cellule de crise dédiée et début des analyses. * **4 septembre 8h53 :** identification de la saturation de flux due à une tâche qui tourne en boucle sans succès. * **4 septembre 8h56 :** tests pour répartir certains flux sur des routes secondaires pour éviter la saturation. * **4 septembre 9h09 :** déplacement de certains flux non affectés par l'incident sur d'autres itinéraires. Poursuite des analyses pour tenter de relancer les virements dans la journée. * **4 septembre 10h :** relance des traitements des virements après plusieurs actions menées pour s'assurer d'éviter des effets de bords. * **4 septembre 11h57 :** fin des traitements après l'heure limite. Certains virements seront réalisés le lendemain. * **5 septembre :** reversement des transactions. **Fin de l'incident. ** **Contexte** N/A **Cause principale** Une mise en production a entraîné une interruption de connexion entre deux API. Une tâche est entrée en boucle et a saturé les différentes routes traitant les flux. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence de détection d'alerte. | Amélioration du monitoring pour une meilleure identification en cas d'incident. | | Blocage des traitements causés par une erreur. | Révision de l'architecture des fichiers d'attentes pour s'assurer qu'une tâche en erreur ne puisse pas bloquer l'ensemble des traitements. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR-2228 **Services de paiement concernés par l'incident** E-commerce et règlement des paiements en magasin. **Impact sur les clients** Règlement partiel des transactions. **Aperçu de l'incident** * **4 septembre 7 h 30 —** début de la saturation de la file d'attente pour le traitement des différents flux. **Début de l'incident. ** * **4 septembre 8 h 50 —** détection d'un retard dans le traitement des transferts. Une unité de crise dédiée a été créée et l'analyse a commencé. * **4 septembre 8 h 53 —** identification de la saturation du débit causée par une boucle de tâches échouée. * **4 septembre à 8 h 56 —** tests visant à rediriger certains flux par des voies secondaires afin d'éviter la saturation. * **4 septembre 9 h 09 —** transfert de certains flux non affectés par l'incident vers d'autres itinéraires. Analyse plus approfondie pour tenter de relancer les transferts au cours de la journée. * **4 septembre 10 h 00 —** le traitement des transferts a repris après plusieurs mesures prises pour éviter les effets secondaires. * **4 septembre 11 h 57 —** traitement terminé après l'heure limite. Certains transferts seront effectués le lendemain. * **5 septembre —** transactions payées. **Fin de l'incident. ** **Contexte** N/A **Cause principale** Un déploiement en production a provoqué une interruption de connexion entre deux API. Une tâche est entrée dans une boucle et a saturé les différentes routes traitant les flux. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Aucune alerte détectée. | Surveillance améliorée pour une meilleure identification en cas d'incident. | | Blocage du traitement causé par une erreur. | Révision de l'architecture de la file d'attente pour s'assurer qu'une tâche échouée ne peut pas bloquer tout le traitement. |

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

1. 29 juillet 2025 à 12:57 UTCinvestigating

   FR Nous avons identifié des difficultés sur le traitement des paiements. L'incident est en cours d'analyse. FR Nous avons identifié des difficultés persistantes liées au traitement des paiements. Une enquête est en cours. IL Abbiamo identificato delle difficultà nell'elaborazione dei pagamenti. L'incident est en cours d'analyse.

2. 29 juillet 2025 à 13:14 UTCmonitoring

   TSR-2090 - Début/Start/Début : 29/07/2025 14h43 CEST. - Fin/Fin /fin : En cours/En cours/En cours/En cours. - Catégorie/Catégorie/Catégorie : Traitement de production - Responsabilité/Responsabilité : Payplug - Priorité/Priorité/Priorité : P2 FR Le service revient progressivement en nominal depuis 15h08. Nous continuons de surveiller le service. FR Le service nominal est observé depuis 15 h 08. Nous continuons à surveiller le service. IL Le service revient progressivement à la normale à partir de 15:08. Continuiamo a monitorare il servizio.

3. 29 juillet 2025 à 14:17 UTCresolved

   TSR-2090 - Début/Start/Début : 29/07/2025 14h43 CEST. - Fin/Fin/Amende : 29/07/2025 à 15h08 CEST. - Catégorie/Catégorie/Catégorie : Traitement de production - Responsabilité/Responsabilité : Payplug - Priorité/Priorité/Priorité : P2 FR Un correctif a été appliqué. Le service a été rétabli. FR Un correctif a été appliqué. Le service a été rétabli. IL Une correction a été appliquée. Le service a été rétabli.

4. 30 juillet 2025 à 07:12 UTCpostmortem

   # _Version anglaise ci-dessous_ # Post Mortem **Référence incident** TSR 2090 **Service concerné** E-commerce and store payments. **Influencer le client** General Inavailability. **Synthèse de l'incident** * **23 juillet :** mise hors production du premier groupe de serveurs. * **24 juillet :** mise hors production du second groupe de serveurs. * **29 juillet 14h43** : mise hors production du troisième groupe de serveurs. **Début de l'incident. ** * **29 juillet 14h45** : remontées d'alertes. * **29 juillet 14h48 :** création d'une cellule d'incident majeur et début des enquêtes. * **29 juillet 14h51 :** Page d'état de la communication. * **29 juillet 14h51 :** redéploiement du service. * **29 juillet 15:05 :** reprise progressive du service. * **29 juillet 15h08** : **fin de l'incident. ** **Contexte** La gestion des correctifs consiste en une série de correctifs qui sont déployés chaque semaine alternativement sur chacune des trois parties des serveurs de production \ (les mardi, mercredi et jeudi \). **Cause principale** Le patch management a successivement mis hors production chacun des serveurs. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Default de détection de la mise hors production des serveurs. | Ajout de contrôles pour être alerté dès qu'un serveur est mis hors production. | | Mise hors production du dernier serveur. | Ajout de contrôles pour être alerté lorsqu'il ne reste plus qu'un serveur actif en production. Interdiction de la mise hors production automatique du dernier serveur. | | Mises hors production successives de tous les serveurs de production par le patch management. | Désactivation jusqu'à nouvel ordre du patch management. Enquêtes en cours. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR 2090 **Services de paiement concernés par l'incident** E-commerce et paiements en magasin. **Impact sur les clients** Indisponibilité généralisée. **Aperçu de l'incident** * **23 juillet :** mise hors service du premier groupe de serveurs. * **24 juillet :** mise hors service du deuxième groupe de serveurs. * **29 juillet à 14 h 43 :** mise hors service du troisième groupe de serveurs. **Début de l'incident. ** * **29 juillet - 14 h 45 :** alertes déclenchées. * **29 juillet - 14 h 48 :** Un groupe de travail sur les incidents majeurs a été créé et les enquêtes ont commencé. * ** 29 juillet - 14 h 51 :** communication de la page de statut. * **29 juillet à 14 h 51 :** redéploiement des services. * **29 juillet - 15 h 05 :** rétablissement progressif du service. * **29 juillet à 15 h 08 : fin de l'incident. ** **Contexte** La gestion des correctifs consiste en une série de mises à jour déployées chaque semaine à tour de rôle sur chacun des trois groupes de serveurs de production \ (les mardis, mercredis et jeudis \). **Cause principale** La gestion des correctifs a mis hors service successivement chacun des serveurs. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Impossible de détecter la mise hors service du serveur. | Ajout de contrôles pour déclencher des alertes dès qu'un serveur est mis hors service. | | Mise hors service du dernier serveur. | Ajout de contrôles pour déclencher des alertes lorsqu'il ne reste qu'un seul serveur de production actif. Blocage de la mise hors service automatique du dernier serveur. | | Mise hors service successive de tous les serveurs de production par gestion des correctifs. | Gestion des correctifs désactivée jusqu'à nouvel ordre. Enquêtes en cours. |

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

1. 15 juillet 2025 à 08:41 UTCinvestigating

   FR Nous avons identifié des difficultés sur le traitement des paiements Oney qui entraînent une indisponibilité totale du service. L'incident est en cours d'analyse. FR Nous avons identifié des problèmes liés au traitement des paiements Oney, entraînant une indisponibilité totale du service. Une enquête est en cours. IL Abbiamo identificato delle difficoltà nell'elaborazione dei pagamenti Oney, che comportano una completa indisponibilità del servizio. L'incident est en cours d'analyse.

2. 15 juillet 2025 à 09:03 UTCmonitoring

   FR L'incident affectant le traitement des paiements Oney est résolu. L'origine de cet incident a été externe à notre plateforme. FR L'incident affectant le traitement des paiements Oney a été résolu. L'origine de cet incident était externe à notre plateforme. IL L'incidente che ha interessato l'elaborazione dei pagamenti Oney è stato risolto. L'origine de cet incident était externe à notre plateforme.

3. 15 juillet 2025 à 12:05 UTCresolved

   Cet incident a été résolu.

4. 17 juillet 2025 à 13:19 UTCpostmortem

   # Post Mortem **Service concerné** Oney. **Influencer le client** Indisponibilité totale du moyen de paiement Oney. **Synthèse de l'incident** * **14 juillet 00h01** : **début de l'incident** chez le partenaire** . ** * **14 juillet 01h56** : déclaration d'un incident par le partenaire** . ** * **15 juillet 10h23** : **fin de l'incident**. **Contexte** N/A **Cause principale** Défaillance chez un partenaire. **Actions to entreprendre by Payplug** | **Symptômes** | **Actions** | | --- | --- | | Détection tardive de l'incident. | Revue de l'alerte dédiée au moyen de paiement Oney et modification de paramètres pour en affiner le déclenchement. | ==========VERSION ANGLAISE============== # Post Mortem **Services de paiement concernés par l'incident** Oney. **Impact sur les clients** Panne totale du mode de paiement Oney. **Aperçu de l'incident** * **14 juillet, 00h01 — début de l'incident** chez le fournisseur de services. * **14 juillet, 1 h 56 —** incident signalé par le fournisseur de services. * **15 juillet, 10 h 23 — incident résolu. ** **Contexte** N/A **Cause principale** Interruption de service chez un partenaire. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Détection différée de l'incident. | Révision des alertes liées au mode de paiement Oney et ajustement des paramètres pour améliorer la précision du déclenchement. |

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

1. 4 juillet 2025 à 08:07 UTCidentified

   FR Nous avons identifié des difficultés sur le traitement des paiements sur Hosted Fields via Shopify. L'incident est en cours d'analyse. Nous vous conseillons de basculer sur du paiement redirigé en attendant la résolution. FR Nous avons identifié des problèmes liés au traitement des paiements à l'aide de Hosted Fields via Shopify. L'incident fait actuellement l'objet d'une enquête. Dans l'intervalle, nous vous recommandons de passer au paiement redirigé. IL Nous avons identifié des difficultés lors du traitement des paiements via Hosted Fields sur Shopify. L'incident est actuellement en phase d'analyse. Consigliamo di passare temporaneamente ai pagamenti reindirizzati in attesa della risoluzione.

2. 4 juillet 2025 à 08:57 UTCidentified

   TSR 1977 - Début/Start/Début : 03/07/2025 18h30 CEST. - Fin/Fin /fin : En cours/En cours/En cours/En cours. - Catégorie/Catégorie/Catégorie : Traitement 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 d'ici une heure. FR Les enquêtes sont toujours en cours. Nous vous recontacterons dans l'heure qui suit. IL Les indagini sono ancora in corso. Contactez-moi d'ici une heure.

3. 4 juillet 2025 à 09:37 UTCmonitoring

   TSR 1977 - Début/Start/Début : 03/07/2025 18h30 CEST. - Fin/Fin/amende : 04/07/2025 à 11h34 CEST. - Catégorie/Catégorie/Catégorie : Traitement de production - Responsabilité/Responsabilité/Responsabilité : A confirmer/À confirmer/Da confirmare. - Priorité/Priorité/Priorité : P2. FR Un correctif a été appliqué permettant de restaurer le service. Nous continuons de surveiller la reprise du service. FR Un correctif a été appliqué, permettant de restaurer le service. Nous continuons de surveiller la reprise du service. IL A stata applicata una correzione che ha permesso il repristino del servizio. Continuiamo a monitorare il recupero del servizio.

4. 4 juillet 2025 à 16:10 UTCresolved

   TSR 1977 - Début/Start/Début : 03/07/2025 18h30 CEST. - Fin/Fin /amende : 04/07/2025 à 16h30 CEST. - Catégorie/Catégorie/Catégorie : Traitement de production - Responsabilité/Responsabilité/Responsabilité : A confirmer/À confirmer/Da confirmare. - Priorité/Priorité/Priorité : P2. FR Le service a été restauré à 11h30. La plateforme est revenue à l'état nominal à 16h30. L'incident est résolu. FR Le service a été rétabli à 11 h 30. La plateforme est revenue à son statut nominal à 16h30. L'incident est résolu. IL Le service a été rétabli à 11 h 30. La plateforme est revenue en état normal à 16h30. L'incident est résolu.

5. 7 juillet 2025 à 18:02 UTCpostmortem

   _Version anglaise ci-dessous_ _Version italienne ci-dessous _ # Post Mortem **Référence incident** TSR 1977 **Service concerné** Page de paiement intégrée \ (Champs hébergés \) sur Shopify **Influencer le client** Payments faits via une page de paiement intégrée \ (Hosted Fields \) sur Shopify en erreur. **Synthèse de l'incident** * **2 juillet 18h10** : **début de l'incident**. * **3 juillet 9h37** : remontée d'alerte de perturbations sur la page de paiement intégrée \ (Hosted Fields \) sur Shopify. * **3 juillet 9h42** : création d'une cellule incident majeur. * **3 juillet 09h53-10h30** : multiples actions pour tenter de restaurer le service. * **3 juillet 10h30** : mail d'escalade sur Shopify. * **3 juillet 10h50 :** identification d'erreurs liées au certificat. * **3 juillet 11h11 :** envoi d'un second mail à Shopify avec plus de détails. * **3 juillet 11h15 :** test impliquant la désactivation du contrôle du certificat. Concluant du test. * **3 juillet 11h28 :** désactivation du contrôle du certificat réalisée sur tous les serveurs. **Reprise du service. ** * **3 juillet 11h30 :** envoi d'un troisième mail à Shopify. * **3 juillet 11h30-15h :** les enquêtes se poursuivent pour rétablir la vérification du certificat. * **3 juillet 15h :** compréhension de la cause première. * **3 juillet 16h :** ajout de l'ancienne autorité de certification et réactivation du contrôle du certificat sur un serveur. Concluant du test. * **3 juillet 16h29 :** ajout de l'ancienne autorité de certification et réactivation du contrôle du certificat sur tous les serveurs. **Fin de l'incident. ** **Contexte** Une autorité de certification a pour but de vérifier l'identité d'un site web et de délivrer un « certificat numérique » pour prouver que ce site est bien ce qu'il prétend être. En 2024, Shopify nous a informé du déploiement d'une nouvelle autorité de certification qui viendrait remplacer l'ancienne qui expire le 26 octobre 2025. Nous avons déployé la nouvelle autorité de certification en août 2024 puis désactivé l'ancienne en décembre 2024. **Cause principale** Réutilisation de l'ancienne autorité de certification par Shopify suite à un incident, alors que nous l'avions désactivée. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Quiproquo sur la révocation de l'ancienne autorité de certification \ (CA \) par Payplug suite au déploiement de la nouvelle. | Clarifications à mener sur la raison de la révocation de l'ancienne CA. Conservation systématique des anciennes CA jusqu'à la date d'expiration. | | Détection tardive de l'incident. | Réflexion à mener sur des alertes spécifiques à chaque parcours de paiement \ (dont celui impacté par cet incident \), ne représentant chacun qu'une faible portion des flux de la plateforme. Améliorer la remontée des erreurs liées à des certificats pour avoir une alerte plus précise sur ce cas. | | Délai de compréhension de la cause racine perfectible. | Obtenir un contact d'urgence chez Shopify pour faciliter les investigations. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR 1977 **Services de paiement concernés par l'incident** Page de paiement intégrée \ (Champs hébergés \) sur Shopify **Impact sur les clients** Les paiements effectués via la page de paiement intégrée \ (Champs hébergés \) sur Shopify ont échoué. **Aperçu de l'incident** * **2 juillet, 18 h 10 : début de l'incident. ** * **3 juillet, 9 h 37 :** alerte déclenchée suite à des perturbations sur la page de paiement intégrée \ (Champs hébergés \) sur Shopify. * **3 juillet, 9 h 42 :** Création d'un groupe de travail sur les incidents majeurs. * **3 juillet, 9 h 53 — 10 h 30 :** plusieurs actions de restauration ont été tentées. * **3 juillet, 10 h 30 :** e-mail d'escalade envoyé à Shopify. * **3 juillet, 10 h 50 :** erreurs identifiées comme étant liées au certificat. * **3 juillet, 11 h 11 :** deuxième e-mail envoyé à Shopify avec plus de détails. * **3 juillet, 11 h 15 :** test réalisé en désactivant la validation du certificat — Test réussi. * **3 juillet, 11 h 28 :** Validation du certificat désactivée sur tous les serveurs — **Service rétabli. ** * **3 juillet, 11 h 30 :** troisième e-mail envoyé à Shopify. * **3 juillet, 11 h 30-15 h 00 :** enquêtes en cours pour réactiver la validation des certificats en toute sécurité. * **3 juillet, 15 h 00 :** cause première comprise. * **3 juillet, 16 h 00 :** l'ancienne autorité de certification \ (CA \) a été ajoutée à nouveau et la validation des certificats a été réactivée sur un serveur — Test réussi. * **3 juillet, 16 h 29 :** l'ancienne autorité de certification a été ajoutée et la validation des certificats a été réactivée sur tous les serveurs — **Fin de l'incident. ** **Contexte** Une autorité de certification \ (CA \) vérifie l'identité d'un site Web et émet un certificat numérique pour prouver son authenticité. En 2024, Shopify nous a informés de l'existence d'une nouvelle autorité de certification pour remplacer la certification actuelle expirant le 26 octobre 2025. Nous avons déployé le nouveau CA en août 2024 et désactivé l'ancien en décembre 2024. **Cause principale** Réutilisation de l'ancienne autorité de certification par Shopify à la suite d'un incident, alors que nous l'avions précédemment désactivée. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Malentendu concernant la révocation de l'ancienne autorité de certification \ (CA \) par Payplug suite au déploiement de la nouvelle. | Clarifier les raisons de la révocation. Conservation systématique des anciennes CA jusqu'à leur date d'expiration. | | Détection différée des incidents. | Envisagez de mettre en place des alertes spécifiques par flux de paiement \ (y compris celui concerné \), même si chacune ne représente qu'une faible part du trafic de la plateforme. Améliorez les mécanismes d'alerte pour détecter plus précisément les problèmes liés aux certificats. | | Le temps nécessaire pour comprendre la cause première pourrait être amélioré. | Établissez un contact d'urgence avec Shopify pour faciliter les enquêtes futures. | ==========VERSION ITALIENNE============== # Post Mortem **Référence incidente** TSR 1977 **Service intéressé** Page de paiement intégrée \ (Hosted Fields \) sur Shopify **Impact pour les clients** Les paiements effectués via la page de paiement intégrée \ (Hosted Fields \) sur Shopify sont le résultat d'une erreur. **Synthèse de l'incident** * **2 juillet, 18h10 : début de l'incidente** * **3 juillet, 09h37 :** alerte en cas d'anomalie sur la page de paiement intégrée \ (Hosted Fields \) de Shopify. * **3 juillet, à 9 h 42 :** activation de la task force incidente maggiore. * **3 juillet, 09:53 — 10:30 :** diverses actions sont tentées pour rétablir le service. * **3 juillet, 10h30 : ** premier message d'escalade envoyé à Shopify. * **3 juillet, 10 h 50 :** identification des erreurs liées aux certificats. * **3 juillet, 11:11:** deuxième message à Shopify avec plus de détails. * **3 juillet, 11 h 15 : ** test désactivant le contrôle du certificat — Esito positif. * **3 juillet, 11 h 28 :** désactivation du contrôle du certificat sur tous les serveurs — **Service rétabli. ** * **3 juillet, 11 h 30** troisième message à Shopify. * **3 juillet, 11h30 — 15h00 : ** Proseguimento delle analisi per reattivare il controlo del certificato. * **3 juillet, à 15h00 : ** identification de la cause première. * **3 juillet, 16h00 :** ajout de l'ancienne autorité de certification et réinitialisation du contrôle du certificat sur un serveur — Test terminé. * **3 juillet, 16 h 29 :** ajout de l'ancienne autorité de certification et réinitialisation du contrôle des certificats sur tous les serveurs — **Fin de l'incident. ** **Concours** Une autorité de certification \ (CA \) a le pouvoir de vérifier l'identité d'un site Web et de délivrer un certificat numérique qui ne confirme pas l'authenticité. En 2024, Shopify ci ha informato del passaggio a una nuova CA, in substituzione di quella esistente che scade il 26 ottobre 2025. Abbiamo a implémenté la nuova CA en août 2024 et disattivato la vecchia en décembre 2024. **Cause principale** Riutilizzo della vecchia Certificate Authority da parte di Shopify a seguito di un incidente, nonostante fosse già stata disattivata da noi. **Actions d'apprentissage de la part de Payplug** | **Synthème** | **Actions** | | --- | --- | | Incomprensione sulla revoca della vecchia Certificate Authority \ (CA \) da parte di Payplug dopo l'adozione della nuova. | Clarire les motivazioni della revoca. Conservazione sistematica delle vecchie CA jusqu'à la date de péremption. | | Rilevamento tardivo dell'incidente. | Evalutare l'attivazione di alert specifici per ciascun percorso di pagamento, anche se representano una piccola parte del traffico. Améliorez les alertes pour détecter plus facilement les problèmes de certificat. | | Temps amélioré pour identifier la cause première. | Obtenez un contact d'urgence auprès de Shopify pour faciliter les recherches futures. |

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

1. 6 mai 2025 à 08:33 UTCmonitoring

   TSR 1723 - Début/Start/Début : 03/05/2025 - Fin/Fin /fin : En cours/En cours/En cours/En cours. - Catégorie/Catégorie/Catégorie : Production - Oney - Responsabilité/Responsibility/Responsabilità : Externe/Externe/Esterna FR Nous avons été informés d'un incident ayant affecté plusieurs dossiers de financement Oney ouverts entre le samedi 3 mai et le lundi 5 mai matin. Les dossiers impactés sont restés en attente. Des actions sont en cours chez Oney pour rattraper ces dossiers, mais les transactions déjà refusées ne pourront plus être validées malgré un financement accepté. Des actions sont en cours pour annuler les dossiers de financement acceptés liés à des transactions refusées. FR Nous avons été informés d'un incident qui a affecté plusieurs demandes de financement d'Oney ouvertes entre le samedi 3 mai et le lundi 5 mai au matin. Les demandes concernées sont restées en attente. Oney travaille actuellement à récupérer ces demandes, mais les transactions déjà refusées ne peuvent plus être validées, même si le financement a été approuvé. Des mesures sont également en cours pour annuler les demandes de financement approuvées liées à des transactions refusées. IL Siamo stati informati di un incidente che ha interessato diverse pratiche di finanziamento Oney aperte tra sabato 3 maggio e la mattina di lunedì 5 maggio. Les pratiques intéressées sono rimaste in stato di attesa. Oney sta attualmente lavorando per recuperare queste pratiche, mais le transazioni già rifiutate ne potranno più essere validate, anche se il finanziamento è stato approvato. Sono inoltre in corso azioni per annullare le pratiche di finanziamento approvate collegate a transazioni rifiutate.

2. 13 mai 2025 à 11:54 UTCresolved

   TSR 1723 - Début/Start/Début : 03/05/2025 - Fin/Fin /amende : 07/05/2025 - Catégorie/Catégorie/Catégorie : Production - Oney - Responsabilité/Responsibility/Responsabilità : Externe/Externe/Esterna FR Les dossiers liés à des transactions refusées ont été annulés, vos clients seront donc remboursés. FR Les demandes de financement liées à des transactions refusées ont été annulées. Vos clients seront remboursés. IL Les pratiques liées aux transactions annulées sont annulées. Vos clients seront remboursés.

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

1. 10 avril 2025 à 12:25 UTCidentified

   FR Certains paiements en magasin réalisés sur des terminaux PAX (protocole Nexo) ont été débités deux fois à vos clients porteurs de carte. Il s'agit pour la plupart des paiements réalisés le 7 avril. L'anomalie a été rapidement identifiée et un correctif est en cours. - Les marchands concernés seront contactés directement. - Tous les doublons seront automatiquement annulés. - Les remboursements seront effectués sans action requise de votre part ni des clients. - La régularisation sera visible sur les comptes des porteurs sous peu. FR Certains paiements en magasin effectués via des terminaux PAX (protocole NEXO) ont été débités deux fois à vos clients titulaires de carte. La plupart de ces transactions dupliquées ont eu lieu le 7 avril. Le problème a été rapidement identifié et un correctif est en cours de mise en œuvre. - Les commerçants concernés seront contactés directement. - Tous les frais dupliqués seront automatiquement annulés. - Les remboursements seront traités sans qu'aucune action ne soit requise de votre part ou de celle de vos clients. - Les ajustements seront bientôt visibles sur les comptes des titulaires de cartes. IL Alcuni pagamenti effettuati in negozio su terminali PAX (protocollo Nexo) potrebbero essere stati addebitati due volte ai vostri clienti. La majeure partie des paiements ont été effectués le 7 avril. L'anomalie a été identifiée et nous sommes en train de procéder à la correction. - Les personnes intéressées seront contactées directement. - Tous les doubles ajouts seront automatiquement annulés. - I rimborsi saranno effettuati senza alcuna azione da parte vostra o dei clienti. - La regolarizzazione sera visible sur les comptes actuels des clients à brève échéance.

2. 11 avril 2025 à 12:26 UTCmonitoring

   FR Les paiements en magasins débités à tort vont être annulés au plus tard le 15 avril 2025. Vos clients verront donc le remboursement de ces paiements sur leur compte au plus tard le 16 avril 2025. FR Les paiements en magasin qui ont été débités à tort seront annulés au plus tard le 15 avril 2025. Vos clients verront donc les remboursements de ces paiements sur leur compte au plus tard le 16 avril 2025. IL I pagamenti effettuati nei negozi addebitati erroneamente saranno annullati entro e non oltre il 15 aprile 2025. I vostri clienti vedranno quindi il rimborso di tali pagamenti sul loro conto entro e non oltre il 16 avril 2025.

3. 14 avril 2025 à 15:54 UTCmonitoring

   TSR 1610 - Début/Start/Début : 07/04/2025 - Fin/Fin /fin : En cours/En cours/En cours/En cours. - Catégorie/Category/Categoria : Production - Transformation. - Responsabilité/Responsabilité : Payplug. - Priorité/Priorité/Priorité : P2. FR Les paiements en magasins débités à tort ont été annulés. Vos clients verront donc le remboursement de ces paiements sur leur compte à partir du 15 avril 2025, en fonction des délais interbancaires. FR Les paiements en magasin qui ont été débités à tort ont été annulés. Vos clients verront donc les remboursements de ces paiements sur leurs comptes bancaires à compter du 15 avril 2025, en fonction des délais de traitement interbancaires. IL I pagamenti effettuati nei negozi addebitati per errore sono stati annullati. I vostri clienti vedranno quindi il rimborso di tali pagamenti sul loro conto bancario a partire dal 15 aprile 2025, in base ai tempi di elaborazione interbancaria.

4. 17 avril 2025 à 07:46 UTCresolved

   Cet incident a été résolu.

5. 17 avril 2025 à 07:47 UTCpostmortem

   # _Version anglaise ci-dessous/Versione Italiana in calce_ # Post Mortem **Référence incident** TSR 1610 **Service concerné** Nexo. **Influencer le client** Multiples débits de paiements effectués sur des terminaux PAX \ (protocole Nexo \). **Synthèse de l'incident** * **07 avril :** mise à jour de la gestion des statuts des transactions Nexo. * **08 avril - 09h12 :** une première série de transactions est débitée mais leur statut n'est pas mis à jour en « débité ». **Début de l'incident. ** * **09 avril :** second débit de la même série de transactions, occasionnant un double débit. Certaines de ces transactions conservent un statut incorrect. * **10 avril :** un contrôle de routine identifie 5000 débits en trop. * **10 avril - 09h30 :** création d'une cellule de crise pour incident majeur. Lancement des enquêtes. * **10 avril - 11h43 :** mise à jour manuelle des statuts pour éviter un nouveau débit accidentel sur les transactions. * **10 avril - 15h25 :** livraison d'un correctif pour garantir la bonne mise à jour automatique des statuts des transactions. Envoi d'une liste de transactions à rembourser à notre prestataire externe. **Reprise du service nominal. ** * **11 avril - 08h43 :** relance envoyée à notre prestataire externe. * **14 avril - 17h :** annulation des débits indus pour les clients VISA & CB. * **15 avril - 17h :** annulation des débits indus pour les clients MASTERCARD. **Fin de l'incident. ** **Contexte** L'annulation d'un double-débit menant au remboursement du débit indu est une opération manuelle et sensible. Notre prestataire a pris toutes les précautions nécessaires pour ne pas générer de dommages collatéraux, ce qui explique le délai observé. **Cause principale** L'incident a été causé par l'ajout d'un processus de mise à jour des statuts de transactions le 7 avril. Ce dernier pouvait occasionnellement entrer en conflit avec un processus déjà existant, empêchant la mise à jour des transactions concernées. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Détection tardive des double-débits. | Mise en place d'un monitoring manuel quotidien à court terme. Automatisation du monitoring à moyen terme. | | Absence de remontée d'erreurs lors du conflit de processus. | Mise en place d'un log \ + alerte lors d'un conflit de mise à jour de statut d'une transaction. Amélioration du retry pour retenter automatiquement la mise à jour du statut. | | Bug non détecté lors de la phase de test. | Ajout systématique de tests sur un plus gros volume de transactions. Investigations sur de nouveaux tests de charge. | ==========VERSION ANGLAISE============== # Post Mortem **Référence de l'incident** TSR 1610 **Services de paiement concernés par l'incident** Nexo. **Impact sur les clients** Paiements multiples débités depuis des terminaux PAX \ (protocole Nexo \). **Aperçu de l'incident** * **7 avril :** mise à jour de la gestion du statut des transactions Nexo. * **Du 8 avril à 9 h 12 :** un premier lot de transactions est débité, mais leur statut n'est pas mis à jour pour indiquer « débité ». **Début de l'incident. ** * **9 avril :** un deuxième débit du même lot de transactions est effectué, ce qui entraîne des frais dupliqués. Certaines de ces transactions conservent un statut incorrect. * **10 avril :** un contrôle de routine révèle 5 000 débits excédentaires. * **Du 10 avril à 9 h 30 :** Création d'un groupe de travail sur les incidents majeurs. L'analyse commence. * **Du 10 avril à 11 h 43 :** mise à jour manuelle des statuts pour éviter de nouveaux débits accidentels. * **Du 10 avril à 15 h 25 :** livraison d'un correctif pour assurer une mise à jour automatique correcte des statuts des transactions. Une liste des transactions à rembourser est envoyée à notre fournisseur externe. **Reprise du service normal. ** * **11 avril — 8 h 43 :** suivi envoyé à notre fournisseur externe. * **Du 14 au 17 avril :** annulation des frais indus pour les clients VISA et CB. * **Du 15 au 17 avril :** annulation des frais indus pour les clients. **Fin de l'incident. ** **Contexte** L'annulation d'un double débit et le remboursement des frais indus sont des opérations manuelles et sensibles. Notre prestataire a pris toutes les précautions nécessaires pour éviter des dommages collatéraux, ce qui explique le retard constaté. **Cause principale** L'incident a été causé par l'ajout d'un processus de mise à jour du statut des transactions le 7 avril. Ce processus peut parfois entrer en conflit avec un processus existant, empêchant ainsi la mise à jour du statut des transactions concernées. **Mesures à prendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Détection tardive des doubles débits. | Mise en place d'un suivi manuel quotidien à court terme. Automatisation de la surveillance à moyen terme. | | Aucun retour d'erreur lors d'un conflit de processus. | Mise en œuvre d'une alerte de journalisation \ + en cas de conflit de mise à jour de statut. Amélioration de la logique des nouvelles tentatives pour tenter automatiquement une nouvelle mise à jour du statut. | | Bug non détecté pendant la phase de test. | Ajout systématique de tests avec des volumes de transactions plus importants. Étude de nouvelles méthodes d'essai de charge. | ==========VERSION ITALIENNE============== # Post Mortem **Référence incidente** TSR 1610 **Service intéressé** Nexo. **Impact sur les clients** Ajoutez plusieurs effets sur les terminaux PAX \ (protocole Nexo \). **Synthèse de l'incident** * **7 avril** : aggiornamento della gestione degli stati delle transazioni Nexo. * **8 avril — 09:12** : una prima serie di transazioni viene addebitata mais lo stato del pagamento non viene aggiornato a « addebitato ». **Début de l'incident. ** * **9 avril** : deuxième ajout à la même série de transactions, provoquant un double ajout. Alcune di queste transazioni mantengono uno stato errato. * **10 avril** : un contrôle de routine individuel de 5 000 ajouts supplémentaires. * **10 avril — 09h30 ** : création d'un groupe de travail pour les incidents majeurs. Inicio delle indagini. * **10 avril — 11:43** : mise à jour manuelle des États pour éviter d'autres ajouts accidentels. * **10 avril — 15h25 ** : relascio di una correzione per garantire il corretto aggiornamento automatico degli stati delle transazioni. Invio di una lista di transazioni da rimborsare al nostro fornitore esterno. **Réinitialisation du service. ** * **11 avril — 08:43** : demande envoyée au fournisseur externe. * **14 avril — 17:00 ** : annulation des frais de port illégaux pour les clients VISA et CB. * **15 avril — 17:00 ** : annulation des frais de port illégaux pour les clients MASTERCARD. **Fin de l'incident. ** **Concours** L'annullamento di un doppio addebito e il conseguente rimborso è un'operazione manuale e delicata. Il nostro fornitore ha preso tutte le precautions necessarie per evitare danni collaterali, il che spiega il ritardo osservato. **Cause principale** L'incidente è stato causato dall'aggiunta, il 7 avril, d'un processo di aggiornamento degli stati delle transazioni. Questo nuovo processo poteva occasionalmente entrare in conflitto avec un processo esistente, impedendo l'aggiornamento delle transazioni interessate. **Actions d'apprentissage depuis Payplug** | **Synthème** | **Actions** | | --- | --- | | Rilevamento tardivo dei doppi addebiti. | Implémentation a breve termine di un monitoraggio manuale daily. Automatisation de la surveillance à moyen terme. | | Mancanza di signalazioni di errore in caso di conflitto tra processi. | Implémentation de log \ + alarme en cas de conflit lors de la mise à jour de l'état d'une transaction. Amélioramento della logica di retry per tentare nuovamente l'aggiornamento dello stato. | | Bug non détecté lors des tests. | Ajout d'un système de test avec un plus grand volume de transactions. Analyse de nouveaux tests de charge. |

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