PayPlug Outage History

Started May 06, 2025, 08:33 AM UTC· resolved May 13, 2025, 11:54 AM UTC

1. monitoring May 06, 2025, 08:33 AM UTC

   TSR-1723 - Début / Start / Inizio : 03/05/2025 - Fin / End /fine : En cours / Ongoing / In corso. - Catégorie / Category / Categoria: Production - Oney - Responsabilité / Responsibility / Responsabilità : Externe / External /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. EN We have been informed of an incident that affected several Oney financing applications opened between Saturday, May 3rd and the morning of Monday, May 5th. The impacted applications remained in a pending state. Oney is currently working to recover these applications, but transactions that have already been declined can no longer be validated, even if the financing was approved. Actions are also underway to cancel approved financing applications that are linked to declined transactions. IT 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. Le pratiche interessate sono rimaste in stato di attesa. Oney sta attualmente lavorando per recuperare queste pratiche, ma le transazioni già rifiutate non 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. resolved May 13, 2025, 11:54 AM UTC

   TSR-1723 - Début / Start / Inizio : 03/05/2025 - Fin / End /fine : 07/05/2025 - Catégorie / Category / Categoria: Production - Oney - Responsabilité / Responsibility / Responsabilità : Externe / External /Esterna FR Les dossiers liés à des transactions refusées ont été annulés, vos clients seront donc remboursés. EN Financing applications linked to declined transactions have been cancelled. Your customers will be refunded. IT Le pratiche collegate a transazioni rifiutate sono state annullate. I vostri clienti saranno rimborsati.

Read the full incident report →

Started Apr 10, 2025, 12:25 PM UTC· resolved Apr 17, 2025, 07:46 AM UTC

1. identified Apr 10, 2025, 12:25 PM UTC

   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 de 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. EN Some in-store payments made via PAX terminals (NEXO protocol) were charged twice to your cardholder clients. Most of these duplicate transactions occurred on April 7th. The issue was quickly identified, and a fix is currently being implemented. - Affected merchants will be contacted directly. - All duplicate charges will be automatically canceled. - Refunds will be processed without any action required from you or your clients. - The adjustments will soon be visible on the cardholders’ accounts. IT Alcuni pagamenti effettuati in negozio su terminali PAX (protocollo Nexo) potrebbero essere stati addebitati due volte ai vostri clienti. La maggior parte dei pagamenti sono stati effettuati il 7 aprile. L'anomalia è stata identificata e stiamo procedendo con la correzione. - Gli esercenti interessati saranno contattati direttamente. - Tutti i doppi addebiti verranno automaticamente cancellati. - I rimborsi saranno effettuati senza alcuna azione da parte vostra o dei clienti. - La regolarizzazione sarà visibile sui conti corrente dei clienti a breve.

2. monitoring Apr 11, 2025, 12:26 PM UTC

   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. EN In-store payments that were wrongly debited will be canceled by April 15th, 2025, at the latest. Your customers will therefore see the refunds for these payments on their account no later than April 16th, 2025. IT 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 aprile 2025.

3. monitoring Apr 14, 2025, 03:54 PM UTC

   TSR-1610 - Début / Start / Inizio : 07/04/2025 - Fin / End /fine : En cours / Ongoing / In corso. - Catégorie / Category / Categoria: Production - Processing. - Responsabilité / Responsibility / Responsabilità : Payplug. - Priorité / Priority / 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. EN The in-store payments that were wrongly debited have been cancelled. Your customers will therefore see the refunds of these payments on their bank accounts starting from April 15, 2025, depending on interbank processing times. IT 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. resolved Apr 17, 2025, 07:46 AM UTC

   This incident has been resolved.

5. postmortem Apr 17, 2025, 07:47 AM UTC

   # _English version below / Versione Italiana in calce_ # Post Mortem **Référence incident** TSR-1610 **Service concerné** Nexo. **Impact 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 investigations. * **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é. **Root cause** 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. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-1610 **Payment services affected by the incident** Nexo. **Client impact** Multiple payments debited from PAX terminals \(Nexo protocol\). **Incident Overview** * **April 7:** update of the Nexo transaction status management. * **April 8 – 9:12 AM:** a first batch of transactions is debited, but their status is not updated to “debited.” **Incident begins.** * **April 9:** a second debit of the same batch of transactions occurs, causing duplicate charges. Some of these transactions retain an incorrect status. * **April 10:** a routine check reveals 5,000 excess debits. * **April 10 – 9:30 AM:** major incident task force created. Analysis begins. * **April 10 – 11:43 AM:** manual update of statuses to prevent further accidental debits. * **April 10 – 3:25 PM:** delivery of a fix to ensure correct automatic update of transaction statuses. A list of transactions to be refunded is sent to our external provider. **Return to normal service.** * **April 11 – 8:43 AM:** follow-up sent to our external provider. * **April 14 – 17h:** reversal of undue charges for VISA & CB customers. * **April 15 – 17h:** reversal of undue charges for customers. **End of the incident.** ‌ **Context** Reversing a duplicate debit and refunding the undue charge is a manual and sensitive operation. Our provider took all necessary precautions to avoid collateral damage, which explains the observed delay. **Root cause** The incident was caused by the addition of a transaction status update process on April 7. This process could occasionally conflict with an existing one, preventing the status update of affected transactions. ‌ **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Late detection of duplicate debits. | Implementation of short-term daily manual monitoring. Medium-term automation of monitoring. | | No error feedback during process conflict. | Implementation of logging \+ alert in case of a status update conflict. Improvement of retry logic to automatically attempt status update again. | | Undetected bug during testing phase. | Systematic addition of tests with larger volumes of transactions. Investigation of new load testing methods. | ‌ ==============VERSIONE ITALIANA============== # Post Mortem **Riferimento incidente** TSR-1610 **Servizio interessato** Nexo. **Impatto sui clienti** Addebiti multipli effettuati su terminali PAX \(protocollo Nexo\). **Sintesi dell'incidente** * **7 aprile**: aggiornamento della gestione degli stati delle transazioni Nexo. * **8 aprile – 09:12**: una prima serie di transazioni viene addebitata ma lo stato del pagamento non viene aggiornato a "addebitato". **Inizio dell'incidente.** * **9 aprile**: secondo addebito della stessa serie di transazioni, causando un doppio addebito. Alcune di queste transazioni mantengono uno stato errato. * **10 aprile**: un controllo di routine individua 5.000 addebiti in eccesso. * **10 aprile – 09:30**: creazione di una task force per incidente maggiore. Inizio delle indagini. * **10 aprile – 11:43**: aggiornamento manuale degli stati per evitare ulteriori addebiti accidentali. * **10 aprile – 15:25**: rilascio 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. **Ripristino del servizio.** * **11 aprile – 08:43**: sollecito inviato al fornitore esterno. * **14 aprile – 17:00**: annullamento degli addebiti illegittimi per i clienti VISA e CB. * **15 aprile – 17:00**: annullamento degli addebiti illegittimi per i clienti MASTERCARD. **Fine dell’incidente.** ‌ **Contesto** L’annullamento di un doppio addebito e il conseguente rimborso è un’operazione manuale e delicata. Il nostro fornitore ha preso tutte le precauzioni necessarie per evitare danni collaterali, il che spiega il ritardo osservato. **Root cause** L’incidente è stato causato dall’aggiunta, il 7 aprile, di un processo di aggiornamento degli stati delle transazioni. Questo nuovo processo poteva occasionalmente entrare in conflitto con un processo esistente, impedendo l’aggiornamento delle transazioni interessate. ‌ **Azioni da intraprendere da Payplug** | **Sintomi** | **Azioni** | | --- | --- | | Rilevamento tardivo dei doppi addebiti. | Implementazione a breve termine di un monitoraggio manuale quotidiano. Automazione del monitoraggio a medio termine. | | Mancanza di segnalazioni di errore in caso di conflitto tra processi. | Implementazione di log \+ allarme in caso di conflitto nell'aggiornamento dello stato di una transazione. Miglioramento della logica di retry per tentare nuovamente l’aggiornamento dello stato. | | Bug non rilevato durante i test. | Aggiunta sistematica di test con volumi maggiori di transazioni. Analisi di nuovi test di carico. |

Read the full incident report →

Started Apr 09, 2025, 12:51 PM UTC· resolved Apr 16, 2025, 03:15 PM UTC

1. identified Apr 09, 2025, 12:51 PM UTC

   FR Les factures de mars n'ont pas été prélevées le 1er avril. Elles devraient être prélevées dans les prochains jours sans action de votre part. EN March invoices were not collected on April the 1st. These invoices should be collected in the next few days without any action required on your part. IT Le fatture di marzo non sono state addebitate il primo aprile. Esse saranno addebitate automaticamente nei prossimi giorni.

2. monitoring Apr 14, 2025, 12:59 PM UTC

   TSR-1572 - Début / Start / Inizio : 01/04/2025. - Fin / End /fine : En cours / Ongoing / In corso. - Catégorie / Category / Categoria: Production - Invoice - Responsabilité / Responsibility / Responsabilità : Payplug FR Les factures de mars ont été relancées ce matin. Les prélèvements seront effectifs d'ici 24h EN The March invoices were followed up this morning. The direct debits will be processed within 24 hours. IT Le fatture di marzo sono state sollecitate questa mattina. Gli addebiti diretti saranno effettuati entro 24 ore.

3. resolved Apr 16, 2025, 03:15 PM UTC

   TSR-1572 - Début / Start / Inizio : 01/04/2025. - Fin / End /fine : 15/04/2025. - Catégorie / Category / Categoria: Production - Invoice - Responsabilité / Responsibility / Responsabilità : Payplug FR Les factures de mars ont été bien été prélevées hier. EN The March invoices were successfully debited yesterday. IT Le fatture di marzo sono state correttamente addebitate ieri.

4. postmortem Apr 17, 2025, 08:55 AM UTC

   # _English version below / Versione Italiana in calce_ # Post Mortem **Référence incident** TSR-1572 **Service concerné** Facturation. **Impact client** Les factures n’ont pas été prélevées le premier jour du mois. **Synthèse de l’incident** * **13 mars :** mise à jour d’un processus interne. **Début de l’incident.** * **1 avril :** non prélèvement des factures. * **1 avril 12h11 :** détection d’erreurs sur le processus exécutant les virements. * **2 avril** : investigation sur l’absence du fichier interne des chargebacks, nécessaire pour la facturation. * **7 avril 16h41 :** correction du processus de génération du fichier interne des chargebacks. * **8 avril 10h53** : confirmation de la génération du fichier interne des chargebacks. * **9 avril** : identification de la root cause. * **10 avril 16h59** : test du correctif sur un échantillon restreint. * **11 avril 10h47** : confirmation que le correctif fonctionne. * **14 avril 11h24** : prélèvement des factures. **Fin de l’incident.** **Contexte** N/A **Root cause** Mise à jour d’un processus interne. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Détection tardive de l’impact de la mise à jour malgré des alertes existantes. | Meilleure prise en charge des alertes remontées. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-1572 **Payment services affected by the incident** Invoicing **Client impact** The invoices were not debited on the first day of the month. **Incident Overview** * **March 13:** update of an internal process. **Incident begins**. * **April 1:** invoices were not debited. * **April 1 - 12:11 PM:** errors detected in the process executing the transfers. * **April 2:** investigation into the absence of the internal chargeback file, which is required for billing. * **April 7 - 4:41 PM:** correction of the process generating the internal chargeback file. * **April 8 - 10:53 AM:** confirmation that the internal chargeback file was generated. * **April 9:** root cause identified. * **April 10 - 4:59 PM:** fix tested on a limited sample. * **April 11 - 10:47 AM:** confirmation that the fix works. * **April 14 - 11:24 AM:** invoices debited. **End of the incident.** ‌ **Context** N/A **Root cause** Update of an internal process. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Late detection of the impact of the update despite existing alerts. | Better handling of reported alerts. | ‌ ==============VERSIONE ITALIANA============== # Post Mortem **Riferimento incidente** TSR-1572 **Servizio interessato** Fatturazione. **Impatto sui clienti** Le fatture non sono state addebitate il primo giorno del mese. **Sintesi dell'incidente** * **13 marzo:** aggiornamento di un processo interno. **Inizio dell'incidente.** * **1 aprile:** mancato addebito delle fatture. * **1 aprile - ore 12:11:** rilevamento di errori nel processo che esegue i bonifici. * **2 aprile:** indagine sull'assenza del file interno dei chargeback, necessario per la fatturazione. * **7 aprile - ore 16:41:** correzione del processo di generazione del file interno dei chargeback. * **8 aprile - ore 10:53:** conferma della generazione del file interno dei chargeback. * **9 aprile:** identificazione della causa principale. * **10 aprile - ore 16:59:** test della correzione su un campione ristretto. * **11 aprile - ore 10:47:** conferma del corretto funzionamento della correzione. * **14 aprile - ore 11:24:** addebito delle fatture. **Fine dell'incidente.** **Contesto** N/A **Root cause** Aggiornamento di un processo interno. **Azioni da intraprendere da Payplug** | **Sintomi** | **Azioni** | | --- | --- | | Rilevamento tardivo dell’impatto dell’aggiornamento nonostante gli avvisi esistenti. | Gestione migliorata degli avvisi segnalati. |

Read the full incident report →

Started Mar 27, 2025, 03:42 PM UTC· resolved Mar 27, 2025, 05:00 PM UTC

1. monitoring Mar 27, 2025, 03:42 PM UTC

   TSR-1532 - Début / Start : 27/03/2025 16h11 CET - Fin / End : 27/03/2025 16h23 CET - Catégorie / Category : Production - Responsabilité / Responsibility : Payplug - Priorité / Priority : P1 FR Un incident affectant le e-commerce et les paiements in-store a eu lieu entre 16h11 et 16h23. La situation est revenue à la normale. Nous continuons de monitorer le service. EN An incident affecting e-commerce and in-store payments occurred between 4.11pm and 4.23pm. The situation has now returned to normal. We are continuing to monitor the service. IT Tra le 16.11 e le 16.23 si è verificato un incidente che ha interessato l'e-commerce e i pagamenti in negozio. La situazione è ora tornata alla normalità. Continuiamo a monitorare il servizio.

2. resolved Mar 27, 2025, 05:00 PM UTC

   TSR-1532 - Début / Start : 27/03/2025 16h11 CET - Fin / End : 27/03/2025 16h23 CET - Catégorie / Category : Production - Responsabilité / Responsibility : Payplug - Priorité / Priority : P1 FR L'incident est maintenant résolu et le service est rétabli. EN Incident is now resolved and service restored. IT L'incidente è stato risolto e il servizio è stato ripristinato.

3. postmortem Mar 31, 2025, 07:43 AM UTC

   # _English version below_ # Post Mortem **Référence incident** TSR-1532 **Service concerné** Paiements e-commerce et magasin. **Impact client** Aucun paiement durant 13 minutes. **Synthèse de l’incident** * **16h11 :** mise en production d’une évolution sur un composant réseau \(ingress\). **Début de l’incident.** * **16h16 :** cellule incident majeur ouverte. * **16h21 :** déploiement du rollback de la mise en production. * **16h21 :** communication status page. * **16h24 :** Service rétabli. **Fin de l’incident.** **Contexte** N/A **Root cause** Dans le cadre d’une mise à jour d’un composant réseau \(ingress\), les serveurs correspondants ont été vu down par les load balancer, ce qui a bloqué l’ensemble des flux entrant sur la plateforme. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Mise en production en erreur. | Investigation de la mise en production avant toute tentative de redéploiement ultérieure. | | Test des composants réseau \(ingress externals\) ne permettant pas de valider qu’ils étaient fonctionnels après le changement en environnement de test. | Créer des tests dédiés afin de valider isolément le fonctionnement des ingress external des ingress internal. | ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-1532 **Payment services affected by the incident** E-commerce and instore payments.. **Client impact** No payment during 13 minutes. **Incident Overview** * **4h11 PM :** Production deployment of an upgrade on a network component \(ingress\). **Incident begins.** * **4h16 PM :** Major incident response team activated. * **4h21 PM :** Rollback deployment of the production change. * **4h21 PM :** Status page communication. * **4h24 PM :** Service restored. **Incident resolved.** **Context** N/A **Root cause** As part of an update to a network component \(ingress\), the corresponding servers were seen as down by the load balancers, which blocked all incoming traffic to the platform. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Production deployment failed. | Investigation of the deployment before any further redeployment attempts. | | Testing of network components \(external ingress\) did not confirm whether they were functional after the change in the test environment. | Create dedicated tests to validate the functionality of external ingresses separately from internal ingresses. |

Read the full incident report →

Started Mar 05, 2025, 11:54 AM UTC· resolved Mar 05, 2025, 04:50 PM UTC

1. investigating Mar 05, 2025, 11:54 AM UTC

   FR Nous avons identifié des difficultés sur le processing de paiements. Des liens de paiements envoyés sont fonctionnels pendant les 15 premières minutes. Ensuite, ils tombent en abandon. Les investigations sont en cours. EN We have identified ongoing difficulties on the payment processing. Payment links are sent and are functional for the first 15 minutes. After that, they are abandoned. An investigation is in progress. IT Abbiamo identificato delle difficoltà nell'elaborazione dei pagamenti. I link di pagamento vengono inviati e funzionano per i primi 15 minuti. Dopodiché, vengono abbandonati. L'incidente è in fase di analisi.

2. identified Mar 05, 2025, 12:38 PM UTC

   FR Le problème a été identifié et un correctif est en cours de mise en œuvre. EN The issue has been identifed and a fix is being implemented. IT Il problema è stato identificato e si sta provvedendo a risolverlo.

3. resolved Mar 05, 2025, 04:50 PM UTC

   TSR-1418 - Début / Start : 04/03/2025 18h00 CET - Fin / End : 05/03/2025 16h11 CET - Catégorie / Category : Production - Processing - Responsabilité / Responsibility : Payplug - Priorité / Priority : P3 FR Cet incident a été résolu. EN This incident has been resolved. IT L'incidente è stato risolto.

4. postmortem Mar 07, 2025, 09:13 AM UTC

   # _English version below_ # Post Mortem **Référence incident** TSR-1418 **Service concerné** Demandes de paiement. **Impact client** Impossibilité pour les marchands de payer 15 minutes après l’envoi du lien. **Synthèse de l’incident** * **04 mars - 09h32 :** déploiement d’une mise en production de nettoyage de requêtes expirées. **Début de l’incident.** * **04 mars - 18h14 :** premières remontées marchandes d’expiration immédiates de liens de demandes de paiements. * **04 mars - 18h16 :** tests pour tenter de reproduire le problème mais on ne reproduit pas la situation. * **05 mars - 11h11 :** nouvelles remontées marchandes. * **05 mars - 11h12 :** contact avec le marchand pour détailler l’erreur et notamment l’expiration après 15 minutes et non immédiate. * **05 mars - 12h02 :** demande d’escalade du ticket. * **05 mars - 12h15 :** différents tests sont menés pour reproduire le bug. * **05 mars - 12h38 :** confirmation d’un incident généralisé. * **05 mars - 12h40 :** création d’une cellule de crise dédiée. * **05 mars - 12h55 :** identification d’une mise en production qui pourrait impacter l’expiration des liens de paiements. * **05 mars - 13h50 :** tentatives de fix mais blocage au niveau des tests. * **05 mars - 16h11 :** rollback de la mise en production. **Fin de l’incident.** **Contexte** N/A **Root cause** Une mise en production a causé l’expiration des liens de paiements après 15 minutes et rendait les paiements impossibles. ‌ **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Erreur de configuration dans une mise en production. | Revue complète du processus de déploiement. | ‌ ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-1418 **Payment services affected by the incident** Payment requests. **Client impact** Merchants unable to pay 15 minutes after the link has been sent. **Incident Overview** * **March 4 - 09:32 AM:** deployment of a production update for cleaning expired queries. **Start of the incident.** * **March 4 - 06:14 PM:** first merchant reports of immediate expiration of payment request links. * **March 4 - 06:16 PM:** tests conducted to try to reproduce the issue, but the situation cannot be replicated. * **March 5 - 11:11 AM:** new merchant reports. * **March 5 - 11:12 AM:** contact with the merchant to explain the error and in particular the fact that the link expired after 15 minutes rather than immediately. * **March 5 - 12:02 PM:** ticket escalation. * **March 5 - 12:15 PM:** various tests carried out to reproduce the bug. * **March 5 - 12:38 PM:** confirmation of a widespread incident. * **March 5 - 12:40 PM:** creation of a dedicated crisis unit. * **March 5 - 12:55 PM:** identification of a production update that might impact the expiration of payment links. * **March 5 - 01:50 PM:** attempted fixes but blocked at the testing stage. * **March 5 - 04:11 PM:** rollback of the production update. **End of the incident.** **Context** N/A **Root cause** A production update caused payment links to expire after 15 minutes, making payments impossible. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Configuration error in a production deployment. | Complete review of the deployment process |

Read the full incident report →

Started Feb 27, 2025, 02:22 PM UTC· resolved Mar 17, 2025, 08:02 AM UTC

1. identified Feb 27, 2025, 02:22 PM UTC

   FR Nous avons identifié des difficultés sur le processing des paiements Oney Certaines transactions restent à un statut en attente ne permettant pas le débit de vos client.es. L'incident est en cours d'analyse. EN We have identified issues with the processing of Oney payments. Some transactions remain in a pending status, preventing the debit of your customers. The incident is currently under analysis. IT Abbiamo identificato problemi nell'elaborazione dei pagamenti Oney. Alcune transazioni rimangono in uno stato in sospeso, impedendo l'addebito ai tuoi clienti. L'incidente è attualmente in fase di analisi.

2. identified Mar 03, 2025, 07:53 AM UTC

   FR Certaines transactions Oney restent à un statut en attente ne permettant pas le débit de vos client.es. Une investigation a été ouverte avec notre partenaire. Nous reviendrons vers vous d'ici demain EN Some Oney transactions remain in a pending status, preventing the debit of your customers. An investigation has been opened with our partner. We will get back to you by tomorrow." IT Alcune transazioni Oney rimangono in stato di attesa, impedendo l'addebito ai vostri clienti. È stata aperta un'indagine con il nostro partner. Vi ricontatteremo entro domani."

3. monitoring Mar 03, 2025, 05:01 PM UTC

   FR Les transactions Oney sont désormais reversées et une analyse est en cours pour essayer de reverser celles qui ont été bloquées. EN Oney transactions are now being reversed and an analysis is underway to try to reverse those that were blocked. IT Una parte delle transazioni è stata annullata ed è in corso un'analisi per cercare di annullare quelle che erano state bloccate.

4. resolved Mar 17, 2025, 08:02 AM UTC

   FR L'ensemble des commandes a été annulé. EN The entire set of orders has been canceled. IT L'intero set di ordini è stato annullato.

5. postmortem Mar 17, 2025, 08:02 AM UTC

   # _English version below_ # Post Mortem **Référence incident** TSR-1392 **Service concerné** Oney. **Impact client** Les paiements Oney étaient bloqués à un statut inconnu. **Synthèse de l’incident** * **26 février :** migration d’application chez un prestataire externe. **Début de l’incident.** * **26 février 16h10 :** création d’un ticket auprès de nos équipes techniques. * **27 février : 14h18 :** remontée de nouveaux cas marchands. * **27 février 14h26 :** escalade de la demande. * **27 février 14h30 :** début des analyses techniques et compréhension de l’incident. * **27 février 17h18 :** identification de d’un nouveau statut de paiement. * **28 février 11h11 :** ticket ouvert chez le support du prestataire externe et poursuite des analyses internes. * **3 mars & 4 mars :** plusieurs relances et échanges avec le support du prestataire externe pour identifier l’origine de l’envoi de ce nouveau statut. * **4 mars 18h01 :** reversement des nouvelles transactions. **Fin de l’incident.** * **5 mars 9h28 :** décision d’annuler les transactions avec le prestataire sur la période d’incident concernée. * **5–14 mars :** plusieurs relances et échanges avec le prestataire externe pour annuler l’ensemble des transactions. * **14 mars 17h44 :** confirmation par le prestataire externe de l’annulation des transactions. **Contexte** N/A **Root cause** Une migration d’application avec un nouveau parcours a été effectuée par notre prestataire externe. C’est l’application avec ce nouveau parcours qui a envoyé un statut qui n’était pas reconnu par nos services. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Non communication de la migration par le prestataire externe. | Communication par le partenaire des migrations et des dates impliquées en amont. | | Non détection de l’incident de la part du prestataire externe. | Vérification le jour du déploiement du bon fonctionnement du service. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-1392 **Payment services affected by the incident** Oney. **Client impact** Oney payments were blocked at an unknown status. **Incident Overview** * **February 26:** application migration with an external service provider. **Incident begins.** * **February 26 - 4:10 PM:** ticket created with our technical teams. * **February 27 - 2:18 PM:** new merchant cases reported. * **February 27 - 2:26 PM:** request escalated. * **February 27 - 2:30 PM:** technical analysis and understanding of the incident begins. * **February 27 - 5:18 PM:** identification of a new payment status. * **February 28 - 11:11 AM:** ticket opened with the support of the external service provider and continuation of internal analysis. * **March 3 & 4:** multiple follow-ups and exchanges with the external provider’s support to identify the origin of the new status transmission. * **March 4 - 6:01 PM:** reversal of new transactions. **Incident ends.** * **March 5 - 9:28 AM:** decision to cancel transactions with the provider for the affected incident period. * **March 5–14:** multiple follow-ups and exchanges with the external provider to cancel the transactions. * **March 14 - 5:44 PM:** confirmation from the external provider of the cancellation of the transactions. **Context** N/A **Root cause** An application migration with a new workflow was carried out by our external service provider. It is the application with this new workflow that sent a status that was not recognized by our services. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Lack of communication regarding the migration by the external service provider. | Communication by the partner regarding the migrations and the involved dates in advance. | | Failure to detect the incident by the external service provider. | Verification of the proper functioning of the service on the deployment day. |

Read the full incident report →

Started Feb 26, 2025, 02:11 PM UTC· resolved Feb 26, 2025, 05:25 PM UTC

1. investigating Feb 26, 2025, 02:11 PM UTC

   FR Nous avons identifié des difficultés sur les demandes de paiements. Elles sont actuellement stockées et seront renvoyées une fois l'incident terminé. EN We have identified ongoing difficulties on the payment requests. They are currently being stored and will be returned once the incident is over. IT Abbiamo riscontrato delle difficoltà con le richieste di pagamento. Attualmente sono in deposito e saranno restituiti una volta terminato l'incidente.

2. monitoring Feb 26, 2025, 04:43 PM UTC

   FR L'incident est fixé, les demandes de paiement non envoyées durant l'incident sont dépilées au fur et à mesure et le service devrait être rétabli d'ici 30 minutes. EN The incident has been resolved, and the payment requests that were not sent during the incident are being processed gradually. The service should be fully restored within 30 minutes. IT L'incidente è stato risolto e le richieste di pagamento non inviate durante l'incidente vengono elaborate progressivamente. Il servizio dovrebbe essere completamente ripristinato entro 30 minuti.

3. resolved Feb 26, 2025, 05:25 PM UTC

   FR L'incident est résolu, les demandes de paiement sont de nouveau envoyées en temps réel. EN The incident has been resolved, and payment requests are now being sent in real time. IT L'incidente è stato risolto e le richieste di pagamento vengono ora inviate in tempo reale.

4. postmortem Mar 05, 2025, 11:02 AM UTC

   # _English version below_ # Post Mortem **Référence incident** TSR-1381 **Service concerné** Demandes de paiements. Affichage des transactions. **Impact client** Arrêt d’envoi des liens de paiement. Non affichage des nouvelles transactions. **Synthèse de l’incident** * **26 février - 12h10 :** surcharge de messages qui s’empilent dans une file. **Début de l’incident.** * **26 février - 12h26 :** redémarrage des services défectueux. * **26 février - 12h50 :** création d’une cellule de crise dédiée et début des analyses. * **26 février - 13h00 :** compréhension de l’origine de l’incident. * **26 février - 13h01 :** redémarrage d’une instance et poursuite des analyses suite à la continuation des erreurs. * **26 février - 13h40 :** identification d’une désynchronisation entre les instances d’un logiciel de gestion des messages. * **26 février - 14h15 :** contact du support externe d’un outil gérant les files des messages. * **26 février - 14h32 :** test d’un fix. * **26 février - 14h38 :** remontée d’alerte sur la non transmission des liens de paiement. * **26 février - 14h39 :** réponse du support externe qui débute les analyses. * **26 février - 15h04 :** relance du support externe devant l’absence d’informations supplémentaires. * **26 février - 15h23 :** réponse du support externe qui ne parvient pas à débloquer la situation. * **26 février - 16h07 :** plusieurs relances au support et mise en pause des actions internes pour ne pas entrer en collision avec les actions menées par le support externe. * **26 février - 16h40 :** redémarrage avec succès de la première instance. * **26 février - 16h45 :** redémarrage successifs des autres instances. * **26 février - 16h46 :** différentes actions de redémarrages des services suite au retour du support externe.. * **26 février - 17h22 :** les messages sont de nouveau envoyés. **Reprise du service.** * **26 février - 18h15 : Fin de l’incident.** **Contexte** Les différents messages qui s’empilent contiennent les informations des transactions. Le non traitement de ces messages cause donc le non affichage des transactions et le non envoi des demandes de paiement. Le service de gestion des messages repose sur plusieurs instances redondées. **Root cause** La désynchronisation des queues a été causée par un pic très élevé de messages ce qui a mené à la saturation des instances. | **Symptômes** | **Actions** | | --- | --- | | Surcharge soudaine de messages dans les instances. | Une analyse est en cours pour mettre en place des actions permettant d’éviter cette surcharge. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-1381 **Payment services affected by the incident** Payment requests. Transactions display. **Client impact** Stop sending payment links and displaying transactions. **Incident Overview** * **February 26 - 12:10 PM**: message overload stacking up in a queue. **Incident begins.** * **February 26 - 12:26 PM**: restart of malfunctioning services. * **February 26 - 12:50 PM**: creation of a dedicated crisis team and start of analysis. * **February 26 - 1:00 PM**: understanding of the origin of the incident. * **February 26 - 1:01 PM**: restart of an instance and continuation of analysis due to ongoing errors. * **February 26 - 1:40 PM**: identification of desynchronisation between instances of a message management software. * **February 26 - 2:15 PM**: contact with external support for a tool managing the message queues. * **February 26 - 2:32 PM**: testing of a fix. * **February 26 - 2:38 PM**: alert raised regarding the non-transmission of payment links. * **February 26 - 2:39 PM**: response from external support who begins analysis. * **February 26 - 3:04 PM**: follow-up with external support due to lack of additional information. * **February 26 - 3:23 PM**: response from external support unable to resolve the issue. * **February 26 - 4:07 PM**: several follow-ups with support and pause of internal actions to avoid conflict with actions from external support. * **February 26 - 4:40 PM**: successful restart of the first instance. * **February 26 - 4:45 PM**: successive restarts of other instances. * **February 26 - 4:46 PM**: various service restarts following the return of external support. * **February 26 - 5:22 PM**: messages are sent again. **Service resumed.** * **February 26 - 6:15 PM**: **End of the incident.** **Context** The various messages that pile up contain transaction information. If these messages are not processed, transactions are not displayed and payment requests are not sent. The message management service is based on several redundant instances. **Root cause** The desynchronisation of the queues was caused by a very high peak of messages, which led to the saturation of the instances. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Sudden overload of messages in the instances. | An analysis is underway to put in place measures to avoid this overload. |

Read the full incident report →

Started Jan 22, 2025, 04:25 PM UTC· resolved Jan 22, 2025, 07:36 PM UTC

1. identified Jan 22, 2025, 04:25 PM UTC

   FR Nous avons identifié des difficultés sur le processing des paiements e-commerce. Pas d'impact sur les paiements sur TPE. Une action est en cours pour rétablir le service EN We have identified ongoing difficulties on the e-commerce payment processing. No impact on the POS terminals payments. An action is ongoing to resume service

2. monitoring Jan 22, 2025, 04:38 PM UTC

   TSR-1177 - Début / Start : 22/01/2024 16h54 CET - Fin / End : 22/01/2024 17h28 CET - Catégorie / Category : Production - Processing - Responsabilité / Responsibility : Payplug FR L'incident est en cours de résolution. Il y a eu un impact sur le service e-commerce entre 16h54 et 17h09 puis entre 17h13 et 17h28 Le service est rétabli depuis 17h28. Nous continuons à surveiller la reprise du service. EN Incident is being resolved. There was an impact on e-commerce service between 4.54pm and 5.09pm then between 5.13pm and 5.28pm. Service is restored since 5.28pm. Service recovery is still under monitoring.

3. resolved Jan 22, 2025, 07:36 PM UTC

   This incident has been resolved.

4. postmortem Jan 24, 2025, 04:57 PM UTC

   _English version below_ **Référence incident** TSR-1177 **Service concerné** Paiements e-commerce. **Impact client** Service interrompu sur deux plages de 15 minutes. **Synthèse de l’incident** * **22 janvier - 16h54 : début de l’incident.** * **22 janvier - 16h57 :** création de la cellule incident majeur. * **22 janvier - 17h04 :** décision de rollback du service API. * **22 janvier - 17h07 :** redémarrage d’une instance. * **22 janvier - 17h09 : reprise du service sur l’instance redémarrée.** * **22 janvier - 17h10 :** redémarrage des autres instances. * **22 janvier - 17h12 :** temporisation du rollback vu que le redémarrage semble suffisant. * **22 janvier - 17h13 : réplique de l’incident.** Décision de rollback sur toutes les instances. * **22 janvier - 17h28 :** **reprise du service.** * **22 janvier - 17h32 :** rollback effectif sur toutes les instances. **Fin de l’incident.** **Contexte** Les flux de paiements sont répartis sur plusieurs instances sur lesquelles des actions peuvent être prises de manière individuelle. Une livraison du service API opérée la veille de l’incident a engendré une augmentation du nombre de messages transitant sur la plateforme, ce qui était anticipé. **Root cause** Le service de gestion des messages transitant sur la plateforme est arrivé à saturation. Les tentatives de connexion du service API à ce service de gestion des messages sont toutes tombées en échec, ce qui a fini par faire tomber tout le service. ‌ **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Saturation du service de gestion des messages. | Court terme - Montée vers une version pouvant encaisser une charge plus importante. Moyen terme - Comprendre les raisons de la saturation. | | Interruption du service API provoqué par la saturation du service de gestion des messages. | Reproduire ce comportement en environnement hors production pour analyser la stabilité du service API. Des actions seront prises en conséquence pour améliorer la résilience du service API vis à vis d’une saturation du service de gestion des messages | | Mise en production non conforme au processus défini. | Faire des rappels de processus aux équipes. | | Délai de résolution trop long. | Analyse de la chronologie de l’incident et élaboration d’actions en conséquence. | ‌ ==============ENGLISH VERSION============== **Incident reference** TSR-1177 **Payment services affected by the incident** E-commerce payments. **Client impact** Service interrupted for two periods of 15 minutes. **Incident Overview** * **January 22nd - 4:54pm : incident beginning.** * **January 22nd - 4:57pm :** major incident response team created. * **January 22nd - 5:04pm :** decision to rollback API service. * **January 22nd - 5:07pm :** restart of one instance * **January 22nd - 5:09pm : service restored on restarted instance.** * **January 22nd - 5:10pm :** restart of the other instances. * **January 22nd - 5:10pm :** rollback on hold on other instances since restart seems to fix the incident. * **January 22nd - 5:13pm : incident restart.** Decision to rollback all instances. * **January 22nd - 5:28pm : service restored.** * **January 22nd - 5:28pm :** All instances rollbacked. **Incident ending.** **Context** Payment flows are distributed across multiple instances, on which actions can be taken individually. A delivery of the API service performed the day before the incident caused an increase in the number of messages transiting on the platform, which was anticipated. **Root cause** The message management service on the platform reached saturation. All connection attempts from the API service to the message management service failed, ultimately bringing down the entire service **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Saturation of the message management service. | Short term - Upgrade to a version capable of handling a higher load. Medium term - Understand the reasons for the saturation. | | API service interruption caused by the saturation of the message management service. | Reproduce this behavior in a non-production environment to analyze the stability of the API service. Actions will be taken accordingly to improve the API service's resilience to saturation of the message management service. | | Production deployment not compliant with defined process. | Remind teams of the defined processes. | | Resolution delay too long. | Analyze the incident timeline and develop actions accordingly. |

Read the full incident report →

Started Dec 17, 2024, 01:30 PM UTC· resolved Dec 17, 2024, 04:31 PM UTC

1. identified Dec 17, 2024, 01:30 PM UTC

   FR Nous avons identifié des difficultés sur le processing des paiements e-commerce. Pas d'impact sur les paiements sur TPE. Une action est en cours pour rétablir le service EN We have identified ongoing difficulties on the e-commerce payment processing. No impact on the POS terminals payments. An action is ongoing to resume service

2. monitoring Dec 17, 2024, 01:42 PM UTC

   FR Le service reprend progressivement Nous continuons à surveiller la reprise du service. EN Service is gradually resuming. Service recovery is under monitoring.

3. monitoring Dec 17, 2024, 01:49 PM UTC

   TSR-1026 - Début / Start / Inizio : 17/12/2024 14h16 CET. - Fin / End /fine : 17/12/2024 14h37 CET. - Catégorie / Category / Categoria: Production - Processing - Responsabilité / Responsibility / Responsabilità : Payplug - Priorité / Priority / Priorità: P1. FR L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. EN Incident is now resolved and service restored. Service recovery is still under monitoring. IT L'incidente è stato risolto e il servizio è stato ripristinato. Continuiamo a monitorare la ripresa del servizio.

4. resolved Dec 17, 2024, 04:31 PM UTC

   This incident has been resolved.

5. postmortem Dec 20, 2024, 04:01 PM UTC

   _English version below_ # Post Mortem **Référence incident** TSR-1026 **Service concerné** Paiements e-commerce. **Impact client** Service interrompu durant 20 minutes. **Synthèse de l’incident** * **17 décembre - 14h08 :** mise en production de la première partie d’une évolution. * **17 décembre - 14h17 : début de l’incident.** * **17 décembre - 14h18 :** création de la cellule incident majeur. * **17 décembre - 14h24 :** mise en production de la seconde partie d’une évolution. * **17 décembre - 14h37 : reprise du service et fin de l’incident.** **Contexte** Déploiement d’une évolution impactant la structure d’une base de données. **Root cause** Erreur dans la mise en production d’une évolution. Seul le changement structurel a été déployé dans un premier temps et pas l’applicatif lié. Durant l’incident, l’ancien applicatif n’était pas adapté à ce changement structurel. **Actions à entreprendre par Payplug** ‌ | **Symptôme** | **Action** | | --- | --- | | Déploiement partiel. | Blocage temporaire de tous les changements de ce type pouvant mener à un déploiement partiel. Revue du processus d’application de changement ayant un impact structurel \(capacité de déploiement des changements structurels séparément des changements applicatifs sans impact\). Découpe des déploiements de gros sujets en plus petits afin d’améliorer la maîtrise lors de leur validation | | Correctif lent à appliquer \(lié au délai actuel nécessaire pour mettre en production\). | Revue complète du processus de déploiement pour le raccourcir drastiquement. Action déjà en cours. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-1026 **Payment services affected by the incident** E-commerce payments. **Client impact** Service interrupted for 20 minutes. **Incident Overview** * **17th of December - 14h08 :** Deployment of the first part of an update. * **17th of December - 14h17 : Incident beginning.** * **17th of December - 14h18 :** Major incident unit opened. * **17th of December - 14h24 :** Deployment of the second part of the update. * **17th of December - 14h37 : Service restored. Incident ending.** **Contexte** Deployment of an update impacting the structure of a database. **Root cause** Error in the deployment of an update. Only the structural change was deployed initially, and the associated application update was not deployed. During the incident, the old application was incompatible with the structural change. **Actions to be taken by Payplug** ‌ | **Symptom** | **Action** | | --- | --- | | Partial deployment. | Temporary block on all similar changes that could lead to a partial deployment. Review the change implementation process for structural impacts \(ability to deploy structural changes separately from application updates without impact\). Break down large deployments into smaller parts to improve control during validation. | | Slow corrective measures \(due to the current time required for deployment\). | Comprehensive review of the deployment process to drastically reduce its duration \(action already underway\). |

Read the full incident report →

Started Dec 07, 2024, 04:42 PM UTC· resolved Dec 07, 2024, 05:38 PM UTC

1. investigating Dec 07, 2024, 04:42 PM UTC

   FR Nous avons identifié des difficultés sur certains terminaux de paiement. Cet incident concerne une route d'acquisition spécifique et vous n'êtes pas tous concernés. Nous vous invitons à utiliser la demande de paiement, accessible depuis votre portail PayPlug : https://support.payplug.com/hc/fr/articles/360021504031-Comment-envoyer-une-demande-de-paiement L'incident est en cours d'analyse. EN We have identified ongoing difficulties on some payment terminals. This incident affects one acquisition route, not all of you are affected. We invite you to use the payment request form, accessible from your PayPlug portal: https://support.payplug.com/hc/fr/articles/360021504031-Comment-envoyer-une-demande-de-paiement An investigation is in progress.

2. monitoring Dec 07, 2024, 05:04 PM UTC

   FR Nous actions ont permis de restaurer une pleine capacité d'encaissement en magasin / Nexo. Nous monitorons avant d'annoncer une pleine résolution. EN Our actions have restored full in-store / Nexo checkout capacity. We are monitoring before announcing a full recovery.

3. resolved Dec 07, 2024, 05:38 PM UTC

   FR Nos services sont à nouveau pleinement opérationnels. Un post mortem sera publié lundi. EN Our services are fully operational again. A post-mortem will be published on Monday.

4. postmortem Dec 11, 2024, 09:32 AM UTC

   # Post Mortem **Référence incident** TSR-965 **Service concerné** Paiements en magasin NEXO **Impact client** Indisponibilité du paiement en magasin via TPE NEXO. **Synthèse de l’incident** * **5 décembre 14h34 :** activation de la nouvelle brique d’acquisition. * **7 décembre - 16h45 : début de l’incident.** * **7 décembre - 16h58 :** remontées d’alertes. * **7 décembre - 17h17 :** création de la cellule incident majeur. * **7 décembre - 17h35 :** actions pour purger des files de messages bloquant le trafic. * **7 décembre - 18h00 : Reprise du service et fin de l’incident.** **Contexte** Plan de transformation en cours impliquant un changement de brique d’acquisition, pour se rendre plus indépendant, réactif et résilient qu’avec la brique actuelle. **Root cause** Le timeout d’une requête d’autorisation n’a pas été géré correctement par une instance de notre nouvelle brique d’acquisition. L’instance est restée en attente de réponse à cette requête, sans passer aux requêtes suivantes. La file d’attente de cette instance s’est engorgée jusqu’à ne plus répondre et a fini par faire échouer les deux autres instances, coupant par la même occasion l’intégralité du trafic NEXO. Les tests n’ont pas permis de reproduire ce cas en amont du déploiement et de s’en prémunir. **Actions à entreprendre par Payplug** | **Symptôme** | **Action** | | --- | --- | | Robustesse de la nouvelle brique insuffisante. | Switch sur l’ancienne brique tant qu’on n’a pas suffisamment fiabilisé la nouvelle. **Aucun risque ne sera pris avant la fin des soldes.** | | Mauvaise gestion des requêtes d’autorisations en erreur. | Changement structurant sur les applicatifs utilisés par cette nouvelle brique priorisé en amont du redéploiement de cette nouvelle brique. | | Délai de résolution important. | Mise à jour de la documentation à destination de l’astreinte. |

Read the full incident report →

Started Nov 21, 2024, 02:53 PM UTC· resolved Nov 22, 2024, 09:16 AM UTC

1. investigating Nov 21, 2024, 02:53 PM UTC

   TSR-860 - Début / Start : 21/11/2024 15h20 CET - Fin / End : En cours / Ongoing - Catégorie / Category : Production - Processing - Responsabilité / Responsibility : Payplug - Priorité / Priority : P1 FR Nous avons identifié un incident qui impacte les transactions des terminaux de paiement, nous investiguons pour rétablir la situation au plus vite. EN An incident affects payment terminal transactions and we investigate to restore the situation as quickly as possible.

2. monitoring Nov 21, 2024, 03:04 PM UTC

   TSR-860 - Début / Start : 21/11/2024 15h20 CET - Fin / End : 21/11/2024 15h55 CET - Catégorie / Category : Production - Processing - Responsabilité / Responsibility : Payplug - Priorité / Priority : P1 FR Le service est rétabli depuis 15h55 Nous continuons à surveiller la reprise du service. EN Service is restored since 3.55pm. Service recovery is still under monitoring.

3. resolved Nov 22, 2024, 09:16 AM UTC

   This incident has been resolved.

4. postmortem Dec 10, 2024, 05:44 PM UTC

   # Post Mortem **Référence incident** TSR-860 **Service concerné** Nexo **Impact client** Indisponibilité partielle de la plateforme Nexo. **Synthèse de l’incident** * **21 novembre - 10h48 : début de l’incident.** * **21 novembre – 11h07 :** création d’une cellule incident majeur. * **21 novembre – 11h30 : reprise du service.** * **21 novembre – 11h37 :** prise de contact avec un prestataire pour investigations. * **21 novembre – 15h20 : réplique de l’incident.** * **21 novembre – 15h44 :** nouvelle prise de contact avec notre prestataire. * **21 novembre – 15h55 : fin de l’incident.** * **21 novembre – 16h32 :** retour de notre partenaire qui confirme des problèmes chez un émetteur. **Contexte** Plan de transformation en cours impliquant un changement de route d’acquisition, pour se rendre indépendant et plus résilient. **Root cause** Perturbations sur le flux d’autorisations d’un émetteur externe provoquant des timeouts non correctement gérés sur la nouvelle route d’acquisition. **Actions à entreprendre par Payplug** ‌ | **Symptôme** | **Action** | | --- | --- | | Robustesse de la nouvelle route insuffisante. | Switch temporaire sur l’ancienne route. | | Mauvaise gestion des perturbations émetteurs. | Correction de la gestion des requêtes/réponses. |

Read the full incident report →

Started Nov 15, 2024, 02:15 PM UTC· resolved Nov 15, 2024, 02:15 PM UTC

1. resolved Nov 15, 2024, 02:15 PM UTC

   FR Nous invitons nos marchands utilisant notre module Prestashop 4.14 à le mettre à jour vers la version 4.14.2. Celle-ci corrige des dysfonctionnements impactant le bon fonctionnement des paiements. IT Invitiamo i nostri commercianti che utilizzano il nostro modulo Prestashop 4.14 ad aggiornarlo alla versione 4.14.2. Quest'ultima corregge i malfunzionamenti che incidono sul buon funzionamento dei pagamenti. EN We invite our merchants using our Prestashop 4.14 module to upgrade to version 4.14.2. This corrects malfunctions impacting the payments.

Read the full incident report →