Échecs de paiements Mastercard dans le monde : cinq processeurs signalent des erreurs avant que la récupération ne commence

Les paiements par carte sur le réseau Mastercard ont commencé à échouer dans les premières heures du vendredi 15 août, et dans l'heure qui a suivi, cinq sociétés de paiement distinctes avaient publié des avis techniques décrivant le même problème sous cinq angles différents. Mastercard a depuis confirmé qu'elle rencontrait un problème, et à 05h30 UTC, au moins une passerelle signalait que les transactions avaient commencé à se rétablir.

Ce rapport est entièrement basé sur des divulgations de statut de première partie des processeurs de paiement eux-mêmes, chacune étant horodatée et citée ci-dessous, car au moment de l'écriture, aucun service de câblage ou salle de presse traditionnelle n'avait rapporté la perturbation. Mastercard n'opère aucune page de statut publique et n'a publié aucune déclaration de sa part.

Worldpay a levé le premier drapeau à 04h28 UTC

Le premier avis est venu de Worldpay, maintenant partie de Global Payments, qui a ouvert l'incident INC0619188 à 04h28 UTC signalant « un problème technique avec le réseau Mastercard Debit qui peut causer des erreurs de traitement des transactions » sur sa plateforme de traitement principale. À 04h54 UTC, l'incident était passé de l'enquête à identifié, Worldpay déclarant que ses équipes techniques travaillaient avec le tiers « en priorité ». Son composant d'autorisation et de paiements était marqué comme dégradé tandis que l'acquisition, les paiements et le reporting restaient normaux.

Windcave a nommé le code d'échec

Windcave, une passerelle opérant en Nouvelle-Zélande, en Australie, en Amérique et en EMEA, a été la plus précise sur le mode d'échec. Il a intitulé son incident « Panne non planifiée - Mastercard » à 04h38 UTC et a signalé que les transactions échouées renvoyaient un code de réponse 96. Dans la norme de messagerie ISO 8583 que les banques et les réseaux de cartes utilisent pour communiquer entre eux, le code de réponse 96 signifie défaillance du système — une faute quelque part dans la chaîne de traitement, plutôt qu'une décision de refuser une carte individuelle. À 05h00 UTC, Windcave a déclaré avoir escaladé à Mastercard, qui était « activement en train de travailler en priorité pour restaurer le service ». Huit de ses propres composants ont été listés comme dégradés dans cinq régions, y compris les services de carte présentés utilisés aux caisses physiques.

Stripe a confirmé que la faute était en dehors de ses propres systèmes

Stripe a ouvert un incident intitulé « Déclins élevés sur Mastercard » à 04h49 UTC et a durci son langage à 05h25, déclarant qu'il avait « confirmé que la panne est extérieure à l'infrastructure Stripe ». Son tableau de bord a rendu la distinction visible : paiements globaux, facturation, banque en tant que service et composants principaux montraient tous des opérations, tandis que le seul composant couvrant les acquéreurs et les méthodes de paiement — banques, réseaux de cartes et méthodes de paiement locales — était signalé comme une panne majeure.

Adyen a relayé la confirmation de Mastercard

Adyen a fourni la chose la plus proche d'un mot officiel du réseau lui-même. Le processeur néerlandais a d'abord enregistré un petit problème à 06h34 CEST, disant qu'il avait été informé de problèmes avec Mastercard mais n'attendait aucune erreur de paiement de son propre côté. Moins d'une heure plus tard, il a ouvert un deuxième incident, plus large, contre son composant de paiements, déclarant simplement : « Mastercard a confirmé qu'ils rencontrent un problème débutant à 06h00 CEST. » Ce début coïncide avec 04h00 UTC.

À quelle hauteur cela s'est étendu

L'image la plus large provient de Cybersource, la passerelle détenue par Visa, qui a enregistré un horaire de début à 04h01 GMT et a décrit la cause simplement comme une « Perturbation d'un participant de l'écosystème financier » — un échec chez un participant financier qui « peut impacter la capacité de certains titulaires de cartes à effectuer des paiements ». Cybersource ne nomme pas Mastercard dans son avis, et a souligné qu'aucune partie de sa propre plateforme n'était en faute.

Sa liste de composants est où l'échelle devient lisible. Environ cinquante connexions d'acquéreurs individuelles montraient des performances dégradées au même moment — parmi eux Chase Paymentech, Bank of America Merchant Services, Barclays, HSBC, Elavon, Moneris, TSYS, Lloyds Cardnet, Streamline, Cielo, Rede, Prosa, Saudi Payments, China UnionPay, RuPay et FDI Australia — tandis que les propres API, portails, outils de risque et services de règlement de Cybersource restaient opérationnels. Une seule dépendance partagée échouant en amont produit exactement cette signature, et la géographie de ces acquéreurs s'étend à l'Amérique du Nord et du Sud, à l'Europe, au Moyen-Orient, à l'Inde et à l'Asie-Pacifique.

L'impact n'était pas uniforme, et il semble avoir dépendu de la façon dont chaque processeur a routé son trafic Mastercard. Klarna et GoCardless ont signalé un service normal tout au long, tout comme Authorize.net — notables car, comme Cybersource, il est détenu par Visa, mais a montré chaque connexion d'acquéreur en bonne santé. Les opérateurs affectés ont également décrit des symptômes différents : Worldpay a nommé spécifiquement le trafic de débit Mastercard, le premier avis d'Adyen n'attendait aucune erreur de paiement, tandis que Windcave et Stripe ont vu des échecs de transaction complets.

Signes de récupération

À 05h36 UTC, Windcave a déplacé son incident de identifié à monitoring, rapportant que les transactions Mastercard avaient commencé à être traitées à nouveau à partir d'environ 05h30 UTC. Cela place la période de perturbation sur la route de Windcave à environ quatre-vingt-dix minutes, depuis environ 04h01 UTC. Tous ses huit composants sont restés listés comme dégradés tandis qu'elle continuait à surveiller.

La récupération n'était pas universelle à ce moment-là. L'incident de Stripe était toujours ouvert et son composant d'acquéreurs montrait toujours une panne majeure, et ni Worldpay ni Adyen n'avaient marqué leurs incidents comme résolus. Les lecteurs rencontrant des échecs ne devraient pas supposer que le problème a été résolu partout.

Ce qui est encore inconnu

Mastercard n'a pas publié de déclaration de sa part, et sa confirmation n'est connue que par intermédiaire d'Adyen. Aucun processeur n'a donné de volumes de transactions, de comptes de clients affectés ou de répartition régionale, et aucun chiffre de ce type ne doit être déduit des avis ci-dessus. La cause reste non déclarée : un code de réponse 96 identifie une défaillance sans identifier ce qui a mal fonctionné.

Il existe un précédent récent pour un échec de la même nature, mais plus court. Le journal des incidents de Worldpay enregistre un échec d'autorisation de débit Mastercard le 11 août, où certaines transactions de débit « ont pu être refusées entre 09h53 ET - 10h02 ET » avant de se résoudre sans intervention — environ neuf minutes d'impact sur les clients. L'événement de vendredi a duré considérablement plus longtemps.

Une note sur la façon dont les pages de statut doivent être lues : ce sont les meilleures preuves disponibles pendant un incident en direct, mais elles ne sont pas infaillibles. Worldpay a entièrement rétracté un incident du réseau Visa le 8 août après avoir conclu qu'il n'y avait eu « aucun impact sur Visa ». Des rapports individuels sur Downdetector et des plateformes sociales pendant l'événement de vendredi ont décrit des cartes qui étaient refusées aux marchés et des transferts de portefeuilles échouant ; ces comptes sont cohérents avec ce que les processeurs ont documenté, mais ils ne sont pas vérifiés et ne sont pas la base de ce rapport.

Pourquoi un tremblement de réseau de carte voyage si loin

La perturbation de vendredi est une illustration compacte de la façon dont l'infrastructure de paiement est devenue concentrée. Cinq processeurs sur quatre continents, servant des dizaines de milliers de commerçants entre eux, tous dégradés en même temps à cause d'une faute dont aucun d'eux n'était responsable et qu'aucun d'eux ne pouvait réparer. Chacun pouvait voir le symptôme clairement et pouvait faire peu plus que d'escalader et d'attendre. C'est la même forme que les échecs que nous avons examinés dans notre analyse des plus grandes pannes d'internet jusqu'à présent, où une seule dépendance en amont a mis à terre des services qui semblaient sans lien.

Pour toute entreprise acceptant des paiements par carte, la leçon pratique est que les premières minutes comptent. Savoir rapidement si la faute est vôtre, de votre passerelle ou du réseau détermine si vous changez de routes, publiez un avis aux clients ou attendez simplement. Status Is Down surveille les plateformes de paiement et l'infrastructure qui les sous-tend, vous apprenant un échec par vos propres alertes plutôt que par une queue de clients dont les cartes ne passent pas. Vous pouvez suivre des incidents en direct sur notre tableau de statut en temps réel et recevoir des alertes dès qu'un service dont vous dépendez commence à échouer.

Sources

• Page de statut de Worldpay — incident INC0619188, 15 août 2026, 04h28 et 04h54 UTC
• Page de statut de Windcave — Panne non planifiée - Mastercard, 15 août 2026, 04h38, 05h00 et 05h36 UTC
• Page de statut de Stripe — Déclins élevés sur Mastercard, 15 août 2026, 04h49 et 05h25 UTC
• Statut de la plateforme Adyen — deux incidents Mastercard, 15 août 2026, 06h34 et 07h22 CEST
• Page de statut de Cybersource — Perturbation d'un participant de l'écosystème financier, heure de début rapportée 04h01 GMT, 15 août 2026
• Page de statut d'Authorize.net — traitement opérationnel de la passerelle de paiement, 15 août 2026

Toutes les pages de statut ont été capturées entre 05h31 et 05h38 UTC le 15 août 2026. Les incidents étaient ouverts à ce moment-là et les détails peuvent avoir changé depuis. Ce rapport ne sera pas mis à jour rétrospectivement ; consultez la page de statut de chaque opérateur pour son état actuel.