Stripe est-il en panne ?

Comprendre la disponibilité de Stripe

La disponibilité de Stripe ne se résume pas à une condition unique — disponible ou indisponible. Un problème peut affecter le traitement des paiements, Checkout, l’accès au dashboard ou les requêtes envoyées à api.stripe.com, et ces composants peuvent échouer pour des raisons différentes.

La page de statut officielle de Stripe est le meilleur premier point de contrôle pour vérifier si un incident généralisé a été signalé. Comparez l’horaire de l’incident et le composant affecté avec vos logs, notamment le endpoint, la région ou l’opération de paiement lorsque ces informations sont disponibles. Une page de statut sans incident n’exclut pas un problème de configuration du compte, de déploiement, de connectivité locale ou une erreur spécifique à l’intégration.

Diagnostiquer les problèmes Stripe

1. Vérifier si un incident Stripe a été signalé

Ouvrez la page de statut officielle de Stripe et recherchez un incident correspondant au composant Stripe affecté et à l’horaire du problème. Si un incident est en cours, suivez ses mises à jour, évitez les changements de configuration généralisés et conservez les détails des requêtes ayant échoué pour un examen ultérieur.

Si aucun incident correspondant n’apparaît, considérez que le problème peut être localisé et poursuivez avec les vérifications ci-dessous. Une page de statut sans incident ne permet pas d’exclure un problème de compte, de déploiement, d’intégration ou de réseau.

2. Identifier le composant Stripe en échec

Déterminez où se produit l’échec :

• Accès au dashboard ou au compte : testez le dashboard dans une fenêtre de navigation privée et, le cas échéant, demandez à un autre utilisateur autorisé si les mêmes pages du compte échouent également.
• Checkout ou parcours de paiement : déterminez si l’erreur se produit dans le navigateur avant que votre serveur contacte Stripe, pendant la requête API ou après réception d’une réponse par votre application.
• Requêtes API : notez le statut HTTP, le corps de la réponse, le endpoint, l’horodatage ainsi que tout identifiant de requête ou d’erreur. Vérifiez que la requête cible api.stripe.com et déterminez si le comportement est reproductible.

Un message tel que « paiement échoué » peut correspondre à un refus de carte, une requête invalide, un paramètre de compte ou une erreur applicative, plutôt qu’à une panne généralisée de Stripe.

3. Distinguer les problèmes de réseau et de connectivité

Si les requêtes vers api.stripe.com expirent ou ne parviennent pas à établir une connexion, comparez le comportement depuis un second réseau ou un autre environnement de déploiement. Vérifiez la résolution DNS, l’accès HTTPS sortant, les règles du firewall, les paramètres du proxy et l’inspection TLS dans l’environnement concerné.

Si la même requête fonctionne ailleurs, la cause est probablement locale au réseau, à l’hôte ou au déploiement d’origine. Pour les réponses HTTP 502, 503 ou 504, utilisez les logs de l’application et du serveur pour déterminer si la réponse provient de Stripe, de votre couche d’hébergement, d’un reverse proxy ou d’une API gateway. Utilisez uniquement un test sécurisé et authentifié pour reproduire la requête.

4. Vérifier les causes liées au navigateur, au compte et à l’intégration

Pour un problème de dashboard ou de Checkout limité à un seul navigateur, effacez les données propres au site ou testez une fenêtre privée, puis comparez avec un autre navigateur ou appareil pris en charge. Si le problème suit le compte plutôt que le navigateur, demandez à un utilisateur autorisé de vérifier l’accès au compte et les permissions.

Lorsque Stripe semble disponible mais qu’un seul compte ou une seule intégration échoue, examinez l’environnement concerné, les identifiants API, les permissions, la gestion des webhooks, les paramètres de requête et les changements de configuration récents. Comparez les comportements en mode test et en mode live uniquement lorsque cela est sûr et pertinent. Un échec limité à un endpoint, un compte marchand, un moyen de paiement ou un déploiement est moins compatible avec une panne générale de Stripe.

N’exposez jamais les clés API secrètes dans des rapports de navigateur, des tickets ou des logs. Masquez les informations de paiement et les identifiants avant de partager les résultats du diagnostic.

5. Réessayer avec prudence et transmettre des éléments probants

Pour les réponses réseau ou serveur temporaires, suivez le comportement de retry défini par votre intégration et évitez les opérations de paiement en double. Utilisez la protection par idempotence lorsque votre intégration la prend en charge et vérifiez l’état du paiement avant de tenter un nouvel encaissement.

Si la page de statut n’affiche aucun incident correspondant et que le problème persiste, recueillez l’horodatage et le fuseau horaire, l’environnement concerné, le endpoint, le statut HTTP, la réponse expurgée, l’identifiant de requête ou d’erreur, ainsi que l’indication que le problème se reproduit ou non depuis un autre réseau. Ces éléments sont plus utiles que des retries répétés effectués à l’aveugle.