Is PayPlug down?
Last checked 10m agoNo incidents right now.
PayPlug is operational right now. Last checked 10m ago; the most recent incident resolved 10d ago.
Real-time PayPlug status, recent outages, and incident history — pulled directly from PayPlug's official status page at https://status.payplug.com every 5 minutes. Pingoru tracks 7 PayPlug services and has captured 7 incidents in the last 90 days (96.98% uptime). Get email, Slack, Discord, or webhook alerts the moment PayPlug reports a new incident — free for 5 monitors, no credit card.
Recent outages & incidents
Past 90 days- Paiements e-commerce
Timeline · 6 updates
- investigating · Jul 21, 2026, 12:59 PM UTC
FR Nous avons identifié un problème avec les liens de paiements qui ne remontent pas dans le Portail. Nos équipes sont mobilisées pour résoudre le problème. EN We have identified an issue affecting payment links, which are not appearing in the Portal. Our teams are fully mobilised to resolve the issue. IT Abbiamo identificato un problema per cui i link di pagamento non vengono visualizzati nel Portale. I nostri team sono mobilitati per risolvere il problema.
- investigating · Jul 21, 2026, 01:16 PM UTC
FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans 15 minutes. EN Investigations are still ongoing. We will provide you with a further update in 15 minutes. IT Le indagini sono ancora in corso. Vi aggiorneremo tra 15 minuti.
- investigating · Jul 21, 2026, 01:27 PM UTC
FR L'incident affecte également la remontée des transactions qui peuvent apparaître avec du retard. Nos équipes sont mobilisées pour résoudre le problème. EN The incident is also affecting the display of transactions, which may appear with a delay. Our teams are fully mobilised to resolve the issue. IT L'incidente interessa anche la visualizzazione delle transazioni, che potrebbero comparire con ritardo. I nostri team sono mobilitati per risolvere il problema.
- monitoring · Jul 21, 2026, 01:38 PM UTC
FR Le service est revenu à la normal depuis 15h30. Nos équipes continuent de monitorer le service. EN The service has been back to normal since 3:30 pm. Our teams continue to monitor the service. IT Il servizio è tornato alla normalità dalle ore 15:30. I nostri team continuano a monitorare il servizio.
- resolved · Jul 21, 2026, 02:15 PM UTC
This incident has been resolved.
- postmortem · Jul 24, 2026, 02:42 PM UTC
# _English version below_ # Post Mortem **Référence incident** TSR-3518 **Service concerné** Demandes de paiements et affichage des transactions. **Impact client** Arrêt d’envoi des liens de paiement et non affichage des nouvelles transactions. **Synthèse de l’incident** * **21 juillet 14h10 : début de l’incident.** * **21 juillet 14h37 :** remontée d’alerte sur un potentiel incident affectant les demandes de paiements. Début des investigations. * **21 juillet 14h53 :** création d’une cellule de crise dédiée. * **21 juillet 14h59 :** communication Statuspage. * **21 juillet 15h : identification de l’origine de l’incident.** * **21 juillet 15h06 :** déploiement des actions correctives. * **21 juillet 15h19 :** remontées de retards dans la remontée des transactions. * **21 juillet 15h21 :** début de reprise du service. * **21 juillet 15h30 : fin de l’incident.** **Root cause** Un dysfonctionnement sur l'une de nos instances a provoqué l'absorption massive et anormale d'un grand nombre de données simultanées. Cette surcharge soudaine associée à une gestion synchrone entre deux services a fortement ralenti une partie de notre système et a bloqué la remontée des demandes de paiements sur le Portail. **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence de limite sur l’absorption des données par une instance. | Ajout d’une limite pour éviter un engorgement de l’instance et un ralentissement général de certains services. | | Gestion synchrone entre deux services qui ont ralenti le système une partie de notre système. | Analyses en cours pour fluidifier la communication entre les deux services \(mise en place d’un timeout court ou mise en place d’une gestion asynchrone\). | ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3518 **Payment services affected by the incident** Payment requests and transaction display. **Client impact** Payment links were no longer being sent, and new transactions were not displayed.. **Incident Overview** * **21 July, 2:10 pm: incident began.** * **21 July, 2:37 pm:** alert raised regarding a potential incident affecting payment requests. Investigations commenced. * **21 July, 2:53 pm:** a dedicated crisis management team was established. * **21 July, 2:59 pm:** Statuspage communication published. * **21 July, 3:00 pm: root cause identified.** * **21 July, 3:06 pm:** corrective actions deployed. * **21 July, 3:19 pm:** reports of delays in transaction display received. * **21 July, 3:21 pm:** service recovery began. * **21 July, 3:30 pm: incident resolved.** **Root cause** A malfunction on one of our instances resulted in the abnormal processing of a large volume of data simultaneously. This sudden overload, combined with synchronous processing between two services, significantly slowed down part of our system and prevented payment requests from being displayed in the Portal. **Actions taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | No limit was in place on the volume of data that could be processed by a single instance. | A limit is currently being implemented to prevent instance saturation and the resulting degradation of certain services. | | Synchronous communication between two services contributed to the slowdown of part of our system. | Investigations are underway to improve communication between the two services, either by introducing a shorter timeout or by implementing asynchronous processing. |
Latest: # _English version below_ # Post Mortem **Référence incident** TSR-3518 **Service concerné** Demandes de paiements et affichage des transactions. **Impact client** Arrêt d’envoi de…
-
- Paiements e-commerce
Timeline · 8 updates
- monitoring · Jul 14, 2026, 09:11 AM UTC
FR Un incident a affecté le service d'authentification 3DS pour les transactions Mastercard entre 09h18 et 09h30, entraînant des échecs d'authentification avec le code erreur 4009. L'incident est désormais résolu et le service est de nouveau pleinement opérationnel. EN An incident affected the 3DS authentication service for Mastercard transactions between 09:18 and 09:30, resulting in authentication failures with error code 4009. The incident has now been resolved, and the service is fully operational again. IT Un incidente ha interessato il servizio di autenticazione 3DS per le transazioni Mastercard tra le 09:18 e le 09:30, causando errori di autenticazione con il codice errore 4009. L'incidente è stato risolto e il servizio è nuovamente pienamente operativo.
- identified · Jul 15, 2026, 07:25 AM UTC
FR Nous constatons une résurgence de l'incident avec des erreurs affectant le service d'authentification 3DS pour les transactions Mastercard. Nos équipes sont mobilisées pour restaurer le service le plus rapidement possible. EN We are observing a recurrence of the incident, with errors affecting the 3D Secure authentication service for Mastercard transactions. Our teams are fully mobilised to restore the service as quickly as possible. IT Stiamo riscontrando una recrudescenza dell'incidente, con errori che interessano il servizio di autenticazione 3DS per le transazioni Mastercard. I nostri team sono mobilitati per ripristinare il servizio nel più breve tempo possibile.
- identified · Jul 15, 2026, 07:39 AM UTC
FR Les transactions impactées tombent en 5005 depuis 9h. Nos équipes poursuivent les analyses pour restaurer le service au plus vite. EN Affected transactions have been returning a 5005 error code since 9:00 am. Our teams are continuing their investigations to restore the service as quickly as possible. IT Le transazioni interessate restituiscono un errore 5005 dalle ore 9:00. I nostri team stanno proseguendo le analisi per ripristinare il servizio nel più breve tempo possibile.
- identified · Jul 15, 2026, 07:47 AM UTC
FR L’incident est d’origine externe et provient de Mastercard. Nos équipes sont mobilisées et en surveillance de l'évolution de cet incident externe. EN The incident is external in origin and originates from Mastercard. Our teams remain fully mobilised and are closely monitoring the progress of this external incident. IT L'incidente è di origine esterna ed è riconducibile a Mastercard. I nostri team sono mobilitati e monitorano costantemente l'evoluzione di questo incidente esterno.
- identified · Jul 15, 2026, 08:28 AM UTC
FR Nous observons une amélioration depuis 10h10. Certaines transactions continuent cependant de tomber en erreur. Nos équipes sont en contact avec Mastercard et restent mobilisées. EN We have observed an improvement since 10:10 am. However, some transactions are still returning errors. Our teams are in contact with Mastercard and remain fully mobilised. IT Dalle ore 10:10 osserviamo un miglioramento della situazione. Tuttavia, alcune transazioni continuano a restituire errori. I nostri team sono in contatto con Mastercard e restano pienamente mobilitati.
- monitoring · Jul 15, 2026, 08:58 AM UTC
FR Nous observons une nette amélioration depuis 10h39 et la situtation semble revenir en nominal. Nos équipes sont en contact avec Mastercard et restent mobilisées. EN We have observed a significant improvement since 10:39 am, and the situation appears to be returning to normal. Our teams are in contact with Mastercard and remain fully mobilised. IT Dalle ore 10:39 osserviamo un netto miglioramento e la situazione sembra tornare alla normalità. I nostri team sono in contatto con Mastercard e restano pienamente mobilitati.
- resolved · Jul 15, 2026, 09:20 AM UTC
FR L'incident est terminé et la situation est revenue en nominale. EN The incident has been resolved and the situation has returned to normal. IT L'incidente è risolto e la situazione è tornata alla normalità.
- postmortem · Jul 16, 2026, 12:28 PM UTC
# Post Mortem **Référence incident** TSR-3495 **Service concerné** Paiements E-commerce et 3DS. **Impact client** Impossibilité d’effectuer des paiements pour les porteurs. **Synthèse de l’incident** * **13 juillet :** tentative de renouvellement d’un certificat qui expirera le 15 juillet. Une erreur a provoqué l’échec du renouvellement du certificat. Le délai imposé par Mastercard pour régénérer un certificat repousse l’opération au lendemain. * **14 juillet 9h17 :** mise à jour par le prestataire externe. **Début de l’incident.** * **14 juillet 10h : identification de l’origine de l’incident.** Déploiement du certificat corrigé. * **14 juillet 10h29 : fin de l’incident.** **Root cause** Dans le cadre d’une intervention menée par un prestataire externe, un certificat utilisé pour sécuriser les échanges a été retiré de manière anticipée alors qu'il était encore valide pendant 24 heures. Une basculte automatique sur un autre certificat s’est déclenchée. Cependant, la configuration de ce certificat, bien que valide, n’était pas reconnue par Mastercard ce qui a entraîné le blocage des appels 3DS malgré la validité du nouveau certificat. **Actions prises par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Méconnaissance de la suppression d’un certificat 24h avant son expiration. | Révision de la documentation sur l’expiration des certificats. | | Absence d’alerte spécifique sur la bascule automatique de certificat 24h avant l’expiration. | Ajout d’une alerte spécifique concernant le mécanisme de bascule automatique intervenant 24 heures avant l'expiration d'un certificat. | ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3495 **Payment services affected by the incident** E-commerce payments and 3D Secure. **Client impact** Cardholders were unable to make payments. **Incident Overview** * **13 July:** an attempt was made to renew a certificate due to expire on July, 15th. An error caused the certificate renewal to fail. The waiting period imposed by Mastercard before a new certificate can be generated meant that the operation had to be postponed until the following day. * **14 July, 9:17 am:** update deployed by the external service provider. **Incident began.** * **14 July, 10:00 am: root cause identified.** Deployment of the corrected certificate. * **14 July, 10:29 am: incident resolved.** **Root cause** As part of an intervention carried out by an external service provider, a certificate used to secure communications was removed prematurely, even though it remained valid for a further 24 hours. This triggered an automatic switchover to another certificate. However, although this certificate was valid, its configuration was not recognised by Mastercard, resulting in 3DS requests being blocked despite the validity of the new certificate. **Actions taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Lack of awareness that a certificate is removed 24 hours before its expiry. | The certificate expiry documentation is being reviewed. | | No specific alert was in place for the automatic certificate switchover occurring 24 hours before expiry. | A specific alert is currently being implemented for the automatic certificate switchover mechanism that takes place 24 hours before a certificate expires. |
Latest: # Post Mortem **Référence incident** TSR-3495 **Service concerné** Paiements E-commerce et 3DS. **Impact client** Impossibilité d’effectuer des paiements pour les porteurs. **Synth…
-
- Paiements e-commerce
Timeline · 3 updates
- investigating · Jun 20, 2026, 10:52 AM UTC
FR Nous avons identifié un incident impactant l'envoi des notifications post-paiement pour les marchands utilisant nos modules. L'incident est en cours d'analyse. EN We have identified an incident affecting the delivery of post-payment notifications for merchants using our modules. The incident is currently under investigation.
- resolved · Jun 20, 2026, 01:40 PM UTC
TSR-XXXX - Début / Start : 19/06/2026 18:00:00 CEST - Fin / End : 20/06/2026 15:17:00 CEST - Catégorie / Category : Production/ Processing - Responsabilité / Responsibility : Externe - Priorité / Priority : P1 FR L’incident affectant l’envoi des notifications post-paiement pour les marchands utilisant les modules a été résolu. Le service a été rétabli à 15h17 et fonctionne désormais normalement. Des opérations seront menées afin de rejouer les notifications qui n’ont pas pu être envoyées depuis le début de l’incident, survenu hier à 18h00. EN The incident affecting the delivery of post-payment notifications for merchants using the modules has been resolved. Service was restored at 15:17 and is now operating normally. Operations will be carried out to replay the notifications that could not be sent since the beginning of the incident, which started yesterday at 18:00.
- postmortem · Jun 26, 2026, 09:27 AM UTC
# _English version below_ # Post Mortem **Référence incident** TSR-3421 **Service concerné** Notifications de paiement. **Impact client** Les notifications de paiement n’étaient plus envoyées aux marchands. **Synthèse de l’incident** * **19 juin 18h :** envoi d’un volume massif de paiements. * **19 juin 18h30 : Début de l’incident.** * **20 juin 10h33 :** remontée d’alerte sur un problème de notification. * **20 juin 11h46 :** création d’une cellule de crise dédiée. Début des investigations. * **20 juin 11h48 :** identification de l’absence d’envoi des notifications de paiement. Poursuites des investigations. * **20 juin 12h50 : identification de la root cause.** * **20 juin 13h02 - 15h15 :** déploiement de diverses actions correctives. * **20 juin 15h17 : fin de l’incident.** * **20 juin 22h32 :** lancement d’automatismes pour renvoyer les notifications. * **21 juin 11h57 :** confirmation du renvoi de l’ensemble des notifications. **Root cause** Un volume anormalement élevé de notifications en échec, associé à des tentatives automatiques de réémission vers une URL indisponible, a saturé la file de traitement des notifications. Cette saturation a par conséquent bloqué l'envoi des notifications. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Absence d’alerting spécifique sur une file de traitement des notifications. | Ajout d’alerting spécifique pour détecter et anticiper proactivement toute saturation de la file de traitement. | | Absence de limite d’envoi de requête de paiement par marchand. | Mise en place d'un limite par marchand pour limiter les flux de notifications et prévenir toute saturation de la file de traitement. | | Gestion des timeouts inadaptés. | Révision des seuils de timeout pour prévenir la saturation des files de traitement des notifications. | | Retard dans la prise en charge de l’incident. | Révision de la procédure d’incident en heures non ouvrées et communication à certaines équipes. | ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3421 **Payment services affected by the incident** Payment notifications. **Client impact** Payment notifications were no longer sent to merchants. **Incident Overview** * **19 June 6:00pm:** a large volume of payment transactions was processed. * **19 June 6:30pm: incident began.** * **20 June 10:33am:** alert raised regarding a notification issue. * **20 June 11:46am:** a dedicated crisis management team was established. Investigations began. * **20 June 11:48am:** the failure to send payment notifications was identified. Investigations continued. * **20 June 12:50pm: root cause identified.** * **20 June 1:02pm – 3:15pm:** various corrective actions were deployed. * **20 June 3:17pm: incident resolved.** * **20 June 10:32pm:** automated processes were launched to resend the notifications. * **21 June 11:57am:** confirmation that all notifications had been successfully resent. **Root cause** An abnormally high volume of failed notifications, combined with automatic retry attempts to an unavailable URL, saturated the notification processing queue. As a result, the saturation prevented payment notifications from being sent. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | No specific alerting was in place for the notification processing queue. | Specific alerting has been introduced to detect and proactively anticipate any saturation of the processing queue. | | No per-merchant limit was in place for payment request submissions. | A per-merchant limit has been implemented to control notification traffic and prevent saturation of the processing queue. | | Inappropriate timeout settings. | A review of the timeout thresholds is underway to prevent saturation of the notification processing queues. | | Delay in incident response. | The out-of-hours incident management procedure is currently being reviewed and will be communicated to the relevant teams. |
Latest: # _English version below_ # Post Mortem **Référence incident** TSR-3421 **Service concerné** Notifications de paiement. **Impact client** Les notifications de paiement n’étaient pl…
-
- Reversement / Settlement
Timeline · 4 updates
- investigating · Jun 15, 2026, 10:24 AM UTC
FR Les reversements des 13, 14 et 15 juin prévus aujourd’hui n'ont pas pu être reversés dans leur intégralité. Nos équipes sont pleinement mobilisées afin de résoudre la situation dans les meilleurs délais et rétablir un traitement normal des reversements. Nous vous tiendrons informés de l'évolution de la situation dès que de nouvelles informations seront disponibles. EN The settlements relating to 13, 14 and 15 of June that were scheduled for today could not be processed in full. Our teams are fully mobilised to resolve the situation as quickly as possible and restore normal settlement processing. We will keep you informed of any developments as soon as further information becomes available. IT 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.
- monitoring · Jun 16, 2026, 08:58 AM UTC
TSR-3389 - Début / Start / Inizio : 16/06/2026 - Fin / End /fine : 17/06/2026 - Catégorie / Category / Categoria: Production reversement / settlement / versamento - Responsabilité / Responsibility / Responsabilità : Payplug - Priorité / Priority / Priorità: P2. FR Les fonds restants n’ayant pas pu être reversés hier le seront aujourd'hui. Aucune action n’est requise de votre part et les fonds seront disponibles sur vos comptes comme habituellement. EN The remaining funds that could not be settled yesterday will be settled today. No action is required on your part and the funds will be available in your accounts as usual. IT 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 come di consueto.
- resolved · Jun 16, 2026, 09:17 AM UTC
This incident has been resolved.
- postmortem · Jun 16, 2026, 01:27 PM UTC
# _English version below_ # Post Mortem **Référence incident** TSR-3389 **Service concerné** Reversement des transactions. **Impact 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 weekend et poursuite des investigations sur l’erreur de génération de certaines demandes de virements. * **15 juin 11h34 :** validation des virements du weekend & 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. **Root cause** 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. | ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3389 **Payment services affected by the incident** Transaction settlement **Client impact** Inability to settle all transactions during the incident, resulting in delayed merchant settlements. **Incident Overview** * **15 June 10:10 am:** alerts were raised indicating that some merchants had not received their funds. **Incident start** and commencement of initial investigations. * **15 June 10:36 am:** a dedicated crisis management team was established. * **15 June 10:37 am:** a problem affecting the generation of certain bank transfer requests was identified. * **15 June 10:52 am:** a second incident affecting transfer validation was identified. * **15 June 11:11 am:** the incident affecting transfer validation was resolved. * **15 June 11:14 am:** request submitted for validation of transfers containing weekend transactions, while investigations continued into the error affecting the generation of certain transfer requests. * **15 June 11:34 am:** weekend transfers validated. Investigations continued to enable the missing funds to be sent the following day due to the cut-off time having been exceeded. * **15 June 11:55 am:** **root cause of the incident identified.** * **15 June 12:22 pm:** an action plan was developed to enable the missing funds to be sent the following day. * **15 June 3:00 pm:** corrective actions deployed under team supervision. * **15 June 5:10 pm:** corrective actions completed. **Incident resolved.** * **16 June 7:30 am:** no alerts indicating any errors. * **16 June 9:30 am:** verification of the correct generation of transfer requests. * **16 June 10:57 am:** transfers checked by the technical teams. * **16 June 10:59 am:** all checks confirmed that all funds had been successfully settled. **Root cause** An error in the triggering of a job scheduler interrupted the generation of bank transfer files, preventing the settlement of certain funds. **Actions taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | No specific alert was in place to detect the failure to generate a file. | An alert has been added to detect file generation failures and proactively identify potential settlement incidents. | | No specific alert was in place to detect failures of the job scheduler. | Discussions are underway to implement alerts capable of reporting failures within the job scheduler. |
Latest: # _English version below_ # Post Mortem **Référence incident** TSR-3389 **Service concerné** Reversement des transactions. **Impact client** Impossibilité de procéder au reversemen…
-
- Paiements e-commercePaiements en magasin NexoPaiements en magasin proxypointPaiements en magasin MagellanMoyens de paiements alternatifs
Timeline · 4 updates
- investigating · Jun 07, 2026, 04:43 AM UTC
FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins. L'incident est en cours d'analyse. EN We have identified issues affecting online and in-store payments. An investigation is in progress. IT Abbiamo identificato delle difficoltà nei pagamenti online e nei punti vendita. L'incidente è in fase di analisi.
- investigating · Jun 07, 2026, 05:05 AM UTC
FR Nous avons identifié des difficultés sur la plateforme de paiement. Après analyse, il apparaît que l’incident est externe à notre plateforme. Nous vous tiendrons informés de l’évolution dès que de nouvelles informations seront disponibles. EN We have identified issues on the payment platform. Following analysis, it appears that the incident is external to our platform. We will keep you informed of any developments as soon as further information becomes available. IT Abbiamo identificato delle difficoltà sulla piattaforma di pagamento. Dopo un’analisi, risulta che l’incidente è esterno alla nostra piattaforma. Vi terremo aggiornati sugli sviluppi non appena saranno disponibili nuove informazioni.
- resolved · Jun 07, 2026, 05:28 AM UTC
TSR-XXXX - Début / Start : 07/06/2026 06:15:00 CEST - Fin / End : 07/06/2026 06:58:00 CEST - Catégorie / Category : Production/ Processing - Responsabilité / Responsibility : Externe - Priorité / Priority : P1 FR L'incident est maintenant résolu et le service est rétabli. Nous continuons à surveiller la reprise du service. EN Incident is now resolved and service restored. Service recovery is still under monitoring.
- postmortem · Jul 24, 2026, 09:23 AM UTC
# _English version below_ # Post Mortem **Service concerné** Paiements en magasin, e-commerce et 3DS. **Impact client** Impossibilité d’effectuer des paiements pour les porteurs. **Synthèse de l’incident** * **7 juin 6h02 :** remontée d’alerte. * **7 juin 6h15 : début de l’incident.** * **7 juin 6h27 :** création d’une cellule de crise dédiée. Début des investigations. * **7 juin 6h28 : identification d’un serveur défectueux chez un prestataire externe.** * **7 juin 6h29 :** contact du prestataire externe. * **7 juin 6h54 :** confirmation du prestataire externe que l’incident est bien chez eux. * **7 juin 6h57 : fin de l’incident.** **Root cause** Incident externe chez un prestataire. ==============ENGLISH VERSION============== # Post Mortem **Payment services affected by the incident** In-store payments, e-commerce payments and 3DS. **Client impact** Cardholders were unable to make payments. **Incident Overview** * **7 June, 6:02 am:** alert raised. * **7 June 6:15am: incident began.** * **7 June 6:27am:** a dedicated crisis management team was established. Investigations commenced. * **7 June 6:28am: a faulty server was identified at an external service provider.** * **7 June 6:29am:** the external service provider was contacted. * **7 June 6:54am:** the external service provider confirmed that the incident originated on their side. * **7 June 6:57am: Incident resolved.** **Root cause** External incident at a service provider.
Latest: # _English version below_ # Post Mortem **Service concerné** Paiements en magasin, e-commerce et 3DS. **Impact client** Impossibilité d’effectuer des paiements pour les porteurs. *…
-
See the full PayPlug outage history
1 more incident in the last 90 days, plus the full multi-year archive of per-service events and update timelines.
Browse PayPlug outage history →Or sign up free to get alerts when PayPlug breaks · 10 free monitors · No credit card
- Started Jul 21, 2026, 12:59 PM UTC · Resolved Jul 21, 2026, 02:15 PM UTC · 1h 15m
- Started Jul 14, 2026, 09:11 AM UTC · Resolved Jul 15, 2026, 09:20 AM UTC · 1d
- Perturbation du service de notification des paiements / Payment notification service disruption ResolvedStarted Jun 20, 2026, 10:52 AM UTC · Resolved Jun 20, 2026, 01:40 PM UTC · 2h 47m
- Started Jun 15, 2026, 10:24 AM UTC · Resolved Jun 16, 2026, 09:17 AM UTC · 22h 52m
- Started Jun 07, 2026, 04:43 AM UTC · Resolved Jun 07, 2026, 05:28 AM UTC · 44m
- Started May 07, 2026, 08:16 AM UTC · Resolved May 07, 2026, 02:15 PM UTC · 5h 59m