Vérification Stripe

Après un paiement, Stripe redirige le client vers votre success_url. Si cette page répond 404 ou 500, le client vient de payer et atterrit sur une erreur : il ne sait pas si sa commande est passée, il écrit au support, et parfois il conteste. La vérification Stripe surveille cette page précise, avec la règle qui lui convient.

Ce que PostShip vérifie

PostShip fait un GET sur l'URL de retour (12 secondes, 5 redirections suivies, vérification de chaque saut contre les adresses privées) et exige un statut 2xx — n'importe lequel. C'est la différence avec une cible HTTP, qui exige un statut exact : une page de succès peut légitimement répondre 200 sans session comme 204 ou 201, et ce qu'on veut savoir est qu'elle ne renvoie pas d'erreur.

Ce que ce contrôle ne fait pas :

• il ne rejoue aucun événement webhook Stripe, ne crée aucune session de paiement, ne touche pas à votre compte Stripe — aucune clé ne vous est demandée ;
• il ne vérifie pas votre route de webhook (/api/stripe/webhook). Chaque passage le rappelle dans son détail (webhook_route_not_checked). Pour surveiller cette route, ajoutez-la en cible HTTP avec le statut que votre serveur renvoie à un GET sans signature — souvent 405 ou 400 ;
• il ne vérifie pas que Stripe.js se charge sur le checkout : c'est l'assertion stripe_js du pack argent ou d'un parcours d'argent.

Régler

Projet → URLs → « Ajouter une URL » → sorte « Stripe health (Team) », avec l'URL de retour telle que vous la passez à Stripe — par exemple https://acme.fr/merci ou https://acme.fr/checkout/success. Si votre success_url contient {CHECKOUT_SESSION_ID}, retirez le paramètre : la page doit répondre 2xx même sans identifiant de session, sinon un client qui rafraîchit la page verra aussi l'erreur.

Sur un plan Free ou Pro, l'ajout est refusé : « Stripe health n'est disponible qu'avec le plan Team. »

Ce qui déclenche une alerte

Une erreur de passage (délai, boucle de redirection) ouvre aussi un incident, avec la raison : https://acme.fr/merci : Timeout (12s). L'alerte suit la confirmation du projet et part une fois par panne ; « Rétabli » suit le retour au 2xx. En échec sur un déploiement, la cible coûte 10 points au Ship Score.

Limites et plans

Une cible Stripe compte pour une URL du quota (50 sur Team).

Dépannage

Pourquoi la page de retour est en échec alors qu'elle marche après un vrai paiement ?

Parce que PostShip y arrive sans session Stripe. Si votre page fait redirect('/') ou renvoie 400 quand session_id manque, elle échoue — et un client qui rafraîchit ou revient par l'historique verra la même chose. Rendez la page tolérante : un message générique quand il n'y a pas de session, 200 dans tous les cas.

Puis-je surveiller la page d'annulation aussi ?

Oui, en cible HTTP ordinaire (statut 200) : la cancel_url est une page publique comme une autre. La vérification Stripe est réservée à la page de succès parce que c'est celle qui reçoit un client qui vient de payer.

Que se passe-t-il si je repasse sur Pro ?

La cible reste dans la liste mais ne tourne plus : le plan ne la porte pas. Son dernier verdict est effacé et l'incident éventuel est fermé — elle n'est pas comptée comme une panne, et la page URLs la marque comme retirée par le plan. Elle reprend au cycle suivant si vous revenez sur Team.