PayPlug status

Updated just now

PayPlug reports Operational

No reported issues with this provider’s services in the last 24 hours.

PayPlug status history

  • Up
  • Down
  • Warning

30 days ago 60 days ago 90 days ago Today

Incidents

Provider incidents

Outage 17 Sep at 17:14 UTC Resolved

Incident plateforme de paiement / Payment platform incident / Incidente della piattaforma di pagamento

[2026-09-17 19:14] (investigating): FR Nous avons identifié des difficultés sur les paiements en ligne et en magasins depuis 19h03. L'incident est en cours d'analyse. EN We have identified issues affecting online and in-store payments since 7:03 PM (CEST). An investigation is in progress. IT Abbiamo identificato delle difficoltà nei pagamenti online e nei punti vendita dalle ore 19:03. L'incidente è in fase di analisi. [2026-09-17 19:39] (investigating): FR Les investigations sont toujours en cours. Nous reviendrons vers vous dans les meilleurs délais . EN Investigations are still ongoing. We'll get back to you as soon as possible. [2026-09-17 20:03] (investigating): - Début / Start : 17/09/2026 19:08 CEST - Fin / End : En cours / Ongoing - Catégorie / Category : Production Processing - Responsabilité / Responsibility : Externe / External - Priorité / Priority : P1 FR L'origine de l'incident a été identifiée : il s'agit d'un problème réseau chez l'un de nos hébergeurs externes. Un rollback est en cours de leur côté, le service devrait être rétabli très rapidement. Nous vous tiendrons informés. EN The root cause of the incident has been identified: it is related to a network issue at one of our external hosting providers. A rollback is currently underway on their end, and service should be restored very shortly. We will keep you updated. [2026-09-17 20:25] (identified): FR Le retour arrière (rollback) chez notre hébergeur réseau est toujours en cours d'exécution. Nous vous tiendrons informés dès le service est rétabli. Veuillez nous excuser pour la gêne occasionnée. EN The rollback at our network hosting provider is still in progress. We will keep you updated as soon as service is fully restored. We sincerely apologize for any inconvenience caused. IT Il ripristino della versione precedente (rollback) presso il nostro fornitore di hosting di rete è ancora in corso. Vi terremo aggiornati non appena il servizio sarà completamente ripristinato. Ci scusiamo sinceramente per il disagio arrecato. [2026-09-17 20:38] (monitoring): TSR-3752 - Début / Start : 17/09/2026 19:08 CEST - Fin / End : En cours / Ongoing - Catégorie / Category : Production Processing - Responsabilité / Responsibility : Externe / External - Priorité / Priority : P1 FR Le retour arrière (rollback) chez notre hébergeur réseau est finalisé et le service est désormais pleinement rétabli. Nos équipes maintiennent une surveillance attentive pour s'assurer de la stabilité globale de la plateforme. EN The rollback at our network hosting provider has been completed and service is now fully restored. Our teams continue to closely monitor the system to ensure the overall stability of the platform. IT Il ripristino della versione precedente (rollback) presso il nostro fornitore di hosting di rete è stato completato e il servizio è ora pienamente ripristinato. I nostri team mantengono un attento monitoraggio per garantire la stabilità globale della piattaforma. [2026-09-18 09:07] (resolved): This incident has been resolved. [2026-09-18 09:55] (postmortem): # _English version below_ # Post Mortem **Référence incident** TSR-3752 **Service concerné** Paiements e-commerce, 3DS et en magasins. **Impact client** Impossibilité pour les porteurs d'effectuer des paiements. **Synthèse de l’incident** * **17 septembre 19h03 : début de l’incident.** * **17 septembre 19h05 :** premières remontées d’erreurs. * **17 septembre 19h10 :** création d’une cellule de crise dédiée et début des investigations. * **17 septembre 19h14 :** communication Statuspage. * **17 septembre 19h27 : identification de l’origine externe de l’incident chez un hébergeur réseau.** * **17 septembre 19h30 :** contact de notre hébergeur réseau pour obtenir la résolution de l’incident. * **17 septembre 19h52 :** lancement des premières actions correctives chez l’hébergeur réseau. Rétablissement partiel des services et poursuite des investigations. * **17 septembre 20h30 : identification de l’origine de l’incident par l’hébergeur réseau.** Lancement de nouvelles actions correctives. * **17 septembre 20h33 : fin de l’incident.** * **17 septembre 20h34-21h15 :** monitoring des différents services. **Root cause** L’incident a été causé par une interruption réseau chez notre hébergeur rendant indisponibles les services nécessaires à la sécurisation et au traitement des transactions de paiement. Cette indisponibilité a empêché le traitement des paiements, aussi bien en ligne qu’en point de vente. ‌ ‌**Actions à entreprendre par Payplug** Actions à court terme :  * Sécurisation des interventions firewall : mise en place d’une procédure avec notre hébergeur réseau pour encadrer les modifications de règles réseau avec une mise à jour progressive des datacenters réalisée en heures ouvrées avec information préalable de Payplug. * Amélioration de l’identification des équipements : mise à jour du nommage des équipements réseau afin de faciliter leur identification et les interventions en cas d’incident. * Clarification des impacts liés à l’indisponibilité du dernier équipement de sécurité disponible et formalisation de la procédure de bascule vers les nouveaux équipements afin de garantir la continuité des services. * Amélioration de la documentation technique : centralisation et partage des informations nécessaires à la connexion et à l’administration de l’infrastructure afin de faciliter les interventions de l’équipe. Actions à moyen terme : * Simplification de la gestion des accès réseau : utilisation de plages d’adresses IP plutôt que d’adresses individuelles afin de faciliter l’ajout de nouveaux équipements. * Mise en place d’un accès d’administration alternatif afin de disposer d’un second moyen d’intervention sur l’infrastructure de notre hébergeur réseau et de renforcer la capacité de reprise en cas d’indisponibilité du canal d’administration principal. * Simplification de l’architecture réseau : suppression des accès directs devenus inutiles entre certaines infrastructures afin de réduire les dépendances et les risques associés. ‌ **Actions à entreprendre par l’hébergeur réseau** * Doubler l'infrastructure de pare-feu : déploiement d'un second cluster de pare-feu indépendant, avec adaptation de l'architecture réseau associée afin de limiter l'impact d'une erreur de configuration et renforcer la résilience de l'infrastructure.  * Mise en place d'une supervision de bout en bout du flux entre les infrastructures applicatives et les équipements critiques articulée autour de trois dispositifs : * Déploiement d'une sonde de monitoring au sein de l'environnement applicatif, pour une visibilité directe sur l'état de la plateforme. * Intégration d'un mécanisme d'alerte automatique depuis les systèmes de supervision Payplug vers l’hébergeur réseau. * Mise en place d'une alarme dédiée à la détection de toute baisse anormale de flux à destination des équipements critiques avec des seuils tenant compte de la temporalité des usages. ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3752 **Payment services affected by the incident** E-commerce, 3DS, and in-store payments. **Client impact** Cardholders were unable to make payments. **Incident Overview** * **17 September, 7:03pm: incident began.** * **17 September, 7:05pm:** first errors reported. * **17 September, 7:10pm:** dedicated crisis management team established and investigations commenced. * **17 September, 7:14pm:** Statuspage communication published. * **17 September, 7:27pm: external root cause identified at a network hosting provider.** * **17 September, 7:30pm:** our network hosting provider was contacted to resolve the incident. * **17 September, 7:52pm:** initial corrective actions initiated by the network hosting provider. Partial service restoration and continued investigations. * **17 September, 8:30pm: root cause identified by the network hosting provider.** Further corrective actions initiated. * **17 September, 8:33pm: incident resolved.** * **17 September, 8:34–9:15pm:** monitoring of the various services. **Root cause** The incident was caused by a network outage at our hosting provider, making the services required to secure and process payment transactions unavailable. This unavailability prevented payments from being processed, both online and at points of sale. ‌ **Actions to be taken by Payplug** Short-term actions: * Securing firewall interventions: implementation of a procedure with our network hosting provider to govern network rule changes, with a phased update of the data centres carried out during business hours and prior notification to Payplug. * Improved equipment identification: updating the naming convention for network equipment to facilitate identification and intervention in the event of an incident. * Clarification of the impact of the unavailability of the last available security device: formalisation of the procedure for switching over to the new equipment to ensure service continuity. * Improved technical documentation: centralisation and sharing of the information required to connect to and administer the infrastructure, to facilitate interventions by the team. Medium-term actions: * Simplification of network access management: use of IP address ranges rather than individual IP addresses to facilitate the addition of new equipment. * Implementation of an alternative administration access: provision of a second means of accessing and intervening on the network hosting provider’s infrastructure, strengthening recovery capabilities in the event of unavailability of the primary administration channel. * Simplification of the network architecture: removal of direct access between certain infrastructures where no longer required, in order to reduce dependencies and associated risks. ‌ **Actions to be taken by the network hosting provider** * Duplicate the firewall infrastructure: deployment of a second independent firewall cluster with corresponding adaptation of the associated network architecture in order to limit the impact of a configuration error and strengthen the resilience of the infrastructure. * Implementation of end-to-end monitoring of the flow between the application infrastructure and critical equipment structured around three components: * Deployment of a monitoring probe within the application environment, providing direct visibility into the state of the platform. * Integration of an automatic alerting mechanism from Payplug's monitoring systems to the network hosting provider. * Implementation of a dedicated alarm to detect any abnormal drop in flow to critical equipment with thresholds that take account of usage patterns over time.

Degraded 17 Sep at 08:18 UTC Resolved

Incident Shopify / Shopify incident / Incidente Shopify

[2026-09-17 10:18] (investigating): FR Nous avons identifié des difficultés sur le moyen de paiement Shopify. L'incident est en cours d'analyse. EN We have identified issues affecting payments using the Shopify payment method. Investigation is in progress. IT Abbiamo identificato delle difficoltà con il metodo di pagamento Shopify. L'incidente è in fase di analisi. [2026-09-17 10:24] (monitoring): FR Le traffic revient à la normale depuis 10h20. EN Traffic has been back to normal since 10:20 am. IT Il traffico è tornato alla normalità dalle ore 10:20. [2026-09-17 10:43] (resolved): TSR-3748 - Début / Start / Inizio : 17/09/2026 10h05 CEST. - Fin / End /fine : 17/09/2026 10h20 CEST. - Catégorie / Category / Categoria: Production Processing. - Responsabilité / Responsibility / Responsabilità : Externe / External /Esterna - Priorité / Priority / Priorità: P2. FR L'incident est d'origine externe et est désormais terminé. EN The incident was caused by an external issue and has now been resolved. IT L'incidente è di origine esterna ed è ormai terminato. [2026-09-21 10:24] (postmortem): # _English version below_ # Post Mortem **Référence incident** TSR-3748. **Service concerné** Shopify. **Impact client** Impossibilité pour les porteurs d’effectuer des paiements. **Synthèse de l’incident** * **17 septembre 10h05 : début de l’incident.** * **17 septembre 10h11 :** création d’une cellule de crise dédiée. Début des investigations. * **17 septembre 10h12 : identification de la root cause.**  * **17 septembre 10h13 :** lancement des actions correctives. * **17 septembre 10h17 : fin de l’incident.**  * **17 septembre 10h18 - 10h45 :** monitoring de la bonne reprise du service.  **Root cause** Une augmentation soudaine et exceptionnelle du volume de paiements a entraîné une saturation du service de traitement des paiements. La capacité maximale de traitement ayant été atteinte, certaines demandes n’ont plus pu être prises en charge, entraînant des erreurs et des ralentissements. La situation a été aggravée par un temps de traitement plus long sur certaines opérations, ainsi que par l’accumulation de notifications en attente. **Actions à entreprendre par Payplug** | **Symptômes** | **Actions** | | --- | --- | | Saturation de la capacité de traitement lors d’un pic de trafic entraînant des erreurs sur les demandes de paiement. | Augmentation de la capacité de traitement afin de mieux absorber les pics de trafic et de limiter les risques de saturation. | | Temps de traitement des paiements allongé par un nombre important d’appels d’authentification, contribuant à la saturation du service. | Mise en place d’un mécanisme de réutilisation temporaire des jetons d’authentification afin de réduire le nombre d’appels nécessaires au traitement des paiements. | | Accumulation des notifications en attente, entraînant des retards dans leur traitement. | Suppression de la limitation du nombre de notifications traitées simultanément vers le service de paiement afin d’améliorer leur traitement en période de forte activité. | | | Réalisation de tests de montée en charge afin de valider la capacité à traiter des volumes importants de paiements. | ‌ ==============ENGLISH VERSION============== # Post Mortem **Incident reference** TSR-3748. **Payment services affected by the incident** Shopify **Client impact** Cardholders were unable to make payments. **Incident Overview** * **17 September, 10:05am: incident began.** * **17 September, 10:11am:** dedicated crisis management team established. Investigations commenced. * **17 September, 10:12am: root cause identified.** * **17 September, 10:13am:** corrective actions initiated. * **17 September, 10:17am: incident resolved.** * **17 September, 10:18–10:45 am:** monitoring to ensure the service was successfully restored. **Root cause** A sudden and exceptional increase in payment volumes caused the payment processing service to become saturated. Once the maximum processing capacity was reached, some requests could no longer be handled, resulting in errors and slowdowns. The situation was further exacerbated by longer processing times for certain operations, as well as a build-up of pending notifications. **Actions to be taken by Payplug** | **Symptoms** | **Actions** | | --- | --- | | Processing capacity was saturated during a traffic peak, resulting in errors on payment requests. | Processing capacity has been increased to better handle traffic peaks and reduce the risk of saturation. | | Payment processing times increased due to a high number of authentication calls, contributing to service saturation. | A temporary authentication token reuse mechanism has been implemented to reduce the number of calls required to process payments. | | A build-up of pending notifications resulted in delays in their processing. | The limit on the number of notifications processed simultaneously by the payment service has been removed to improve processing during periods of high activity. | | | Load testing was carried out to validate the ability to process high volumes of payments. |

Community reports

No community reports yet

No users have reported issues with this provider yet.

About PayPlug status page

  • Monitoring since Oct 2026
  • 7 services and components tracked
  • 50 incidents total
  • Last updated: Oct 12, 2026

Frequently asked questions

Quick answers for payment teams and merchants investigating an incident. Firemap explains the evidence; it does not diagnose your merchant account.

Is PayPlug down right now?

No. PayPlug currently reports normal operation on its official status page. PayAtlas last checked it today at 05:42 UTC.

What do Operational, Degraded, Outage and Resolved mean?

They are the states PayPlug publishes on its official status page. Operational means the service works normally. Degraded means part of it is slower or failing for some customers, regions or payment methods, while the rest still works. Outage means a major disruption: a service, or a key part of it, is unavailable. Resolved marks an incident PayPlug has closed; the time it was resolved shows when you hover it.

Does this confirm that my merchant account or customers are affected?

Not on its own. Firemap shows what PayPlug publishes about its platform, not the state of your account. An incident may affect only some regions, payment methods or integrations. Check your own transaction logs and decline codes, and contact PayPlug support with specific transaction IDs if you see failures.

Where does Firemap get this status information?

From official status pages only. Firemap reads each page it tracks automatically every few minutes and records every status change and incident the provider publishes there. Nothing about PayPlug is added or edited by hand.

Why can official and community signals disagree?

They come from different sources. The official status is what PayPlug has confirmed, and providers often post an incident only after the first failures. Community reports come from users and can show a problem earlier, but it may be local: one bank, one country or one integration. Treat reports without an official incident as an early signal, not a confirmed outage.

What should I check before changing payment routing?

Start with your own data: error rates, decline codes and response times by payment method, card scheme and country. Compare them with the scope of the incident on the status page. Make sure the backup provider supports the same methods and currencies, move a small share of traffic first, and switch back once the incident is resolved and your metrics recover.

What is Firemap’s coverage and method?

Firemap tracks the official status pages of payment providers listed on PayAtlas. Each page is checked automatically, and every incident is stored with its start time and, once resolved, its end time. When Firemap has data for PayPlug, this page shows up to 90 days of status history and incidents from the last 30 days.

What can Firemap confirm, and what can’t it?

Firemap can confirm only what PayPlug has published on its status page: the current status, incidents with their start time and, once resolved, end time, and how long the page has been tracked. It cannot confirm the impact on a specific merchant, transaction or region unless PayPlug says so, and it cannot see problems the provider has not reported.

PayAtlas Stack

Manage Your Payment Stack in One Place

Save the providers you work with and get instant access to their status, coverage, insights, comparisons, and recommended alternatives whenever you need them.

Coming soon
  • Free monitoring
  • 5 minutes setup
Error
Something went wrong. Please try again.
Image is too large
Please upload PNG or JPEG up to 1 MB.
Company already exists
There's already a company with this website address.
Company created
Your company has been added to PayAtlas.