Les pages de paiement

PostShip trouve sur votre site les URL qui comptent le plus pour votre revenu et les ajoute, avec des vérifications adaptées à chacune : le prix s'affiche encore sur la page tarifs, le formulaire de connexion est toujours là, Stripe.js se charge sur le checkout. Ce sont les 3 disparitions qui coûtent de l'argent sans rien casser visiblement — la page répond 200, et personne ne peut plus payer.

Ce que PostShip vérifie

Le pack crée des cibles HTTP ordinaires, avec un statut 200 attendu et, en plus, des assertions propres à chaque page :

Comment les pages sont trouvées

PostShip ne devine pas une adresse : il lit votre site. Les liens de la page d'accueil d'abord — menu, pied de page —, avec leur texte, en français comme en anglais ; puis le sitemap ; et, seulement pour un rôle resté sans candidat, quelques adresses usuelles (/pricing, /login, /checkout…). Une page de tarifs qui s'appelle /nos-formules ou une connexion sur app.votre-site.fr/login sont donc trouvées.

Puis chaque candidate est ouverte et n'est confirmée que si son contenu correspond au rôle (tableau ci-dessus). Une adresse qui redirige vers la page de connexion — un /checkout réservé aux clients connectés — n'est pas une page de paiement. Les pages de présentation, d'articles ou de documentation (/produit/…, /blog/…, /docs/…) sont écartées : elles parlent de paiement sans en faire.

Chaque page trouvée est marquée vérifiée (cochée d'office) ou probable (décochée : le lien était net, mais la page n'a rien montré — une connexion rendue en JavaScript, par exemple). Rien n'est ajouté sans votre accord.

Quand le paiement se fait après la création d'un compte

Beaucoup de sites n'encaissent pas sur une page publique : on crée un compte, puis la fenêtre de paiement s'ouvre. Il n'y a alors pas de /checkout à demander. PostShip reconnaît le prestataire autrement, et l'écran « Quelles pages ? » l'affiche sous les pages trouvées, avec ce qui le trahit :

• l'en-tête de sécurité du site (Content-Security-Policy), qui doit autoriser le prestataire — js.stripe.com, api.stripe.com ;
• un script chargé par une page, ou un lien vers une page de paiement hébergée (buy.stripe.com, checkout.paddle.com…) ;
• le code du site lui-même (la bibliothèque du prestataire, une clé publique pk_live_…).

Prestataires reconnus : Stripe, PayPal, Paddle, Lemon Squeezy, Mollie, Braintree, Adyen, Chargebee.

Deux interrupteurs suivent :

• Surveiller le paiement ajoute une vérification « Paiement » : à chaque passage, le site charge et autorise toujours le prestataire, et le prestataire répond. Une CSP resserrée au dernier déploiement qui retire js.stripe.com, et plus personne ne peut payer : c'est ce qu'elle attrape. Elle n'apparaît pas sur la page de statut publique.
• Parcours tarifs → inscription ajoute un parcours de paiement : le prix sur les tarifs, puis le formulaire d'inscription.

Pour aller jusqu'aux vrais paiements, branchez votre compte Stripe en lecture.

Les assertions sont évaluées à chaque passage, sur le HTML tel qu'il est servi, sans navigateur. Une page tarifs dont le prix est injecté par JavaScript n'a donc pas de prix pour PostShip : dans ce cas, mettez comme texte un élément rendu côté serveur.

Le canary prix : T+0 contre T+8

Sur la cible tarifs, PostShip relève aussi les montants visibles — « 29 € », « $49 », « 79 EUR » — à chaque passage de déploiement : à T+0, puis aux reprises T+2 et T+8. Un tarif présent à T+0 et absent au passage suivant devient une alerte de mutation : « Le tarif à 29 € a disparu (T+8) ». C'est ce qu'un cache CDN, un ISR ou une page stale servie après le ship produisent, et que le statut HTTP ne voit pas. Un tarif qui apparaît n'alerte pas ; un tarif qui change de montant est signalé par l'ancien. 20 montants au plus par page, seulement ce qui porte une devise. Comme les autres alertes de qualité de déploiement, Pro et au-delà.

Régler

Projet → URLs → « Surveiller… » → « Les pages de paiement » :

1. Quelles pages ? PostShip lit le site pendant quelques secondes, puis affiche ce qu'il a trouvé : le rôle de chaque page, son adresse, ce qui l'a confirmée, et une pastille vérifiée ou probable. Cochez ou décochez.
2. Le prix à retrouver : € par défaut. Mettez le prix réel affiché (« 49 € », « 29,90 ») pour que l'alerte parte le jour où c'est ce prix-là qui disparaît, pas seulement le symbole.
3. « Ajouter ces pages ».

Si votre hébergeur oppose un défi anti-robot à PostShip, l'écran le dit : voir Autoriser PostShip dans votre pare-feu.

Le message de retour dit ce qui s'est passé : « 3 pages qui font vendre ajoutées. » ; « Aucune URL à ajouter (déjà présentes ou aucune option cochée). » ; ou, si le quota d'URL du plan est atteint en route, « 2 pages sur 3 ajoutées — quota atteint, passez Pro pour couvrir les autres. ».

Une page déjà surveillée en HTTP n'est pas ajoutée 2 fois. Une page surveillée par un contrôle du site (l'indexabilité est posée sur l'accueil) ne compte pas comme déjà surveillée : le pack ajoute quand même la vérification HTTP de l'accueil.

Le paiement

Sur l'Aperçu, la carte « Le paiement » répond à « peut-on encore payer ? » avec les critères au vert — « 3 sur 4 au vert » —, tous lus dans ce que les pages de paiement et le contrôle Sécurité relèvent déjà. Ce n'est plus une note sur 100 : les deux seules notes de PostShip sont le Ship Score, dont le paiement est la catégorie la plus lourde, et la note de sécurité.

Un projet qui surveille encore une page de retour Stripe garde un cinquième critère, « success_url joignable ». Un critère qu'on ne vérifie pas le dit, avec le bouton qui le pose ; un critère qui ne vous concerne pas se marque Pas concerné et sort du compte. Le décompte est sur tous les plans ; le détail par critère, avec l'URL qui casse, est ouvert dès Pro. Le résumé quotidien sur Slack ou Discord porte la même ligne : « Paiement : 3 critères sur 4 au vert. »

Ce qui déclenche une alerte

En plus des manques HTTP habituels (statut, assets, contenu), 3 codes propres aux assertions :

Une page de paiement en échec coûte 40 points au Ship Score — c'est la catégorie la plus lourde, et 2 pages en échec coûtent 2 fois 40. Sur la page Déploiements, le diff du déploiement montre en plus le domaine tiers qui a disparu (« ce ship a retiré js.stripe.com de /checkout »).

Limites et plans

Trouver vos pages de paiement n'est verrouillé par aucun plan : le bouton est présent partout. Ce qui le borne est le quota d'URL, compté sur tous vos projets :

Pour vérifier la chaîne qui relie les 4 pages, et plus seulement chacune — tarifs, puis checkout, puis merci, dans l'ordre — voyez le parcours de paiement (Pro et Pro Plus).

Dépannage

Pourquoi la page tarifs n'a pas été ajoutée ?

Soit aucun lien du site ne ressemblait à une page de tarifs, soit la page trouvée n'affichait aucun prix dans son HTML (prix injecté par JavaScript). Ajoutez la page à la main (« Surveiller… » → « Une page ») et, dans « Doit contenir », mettez un texte rendu côté serveur : vous obtenez la même vérification.

Pourquoi la connexion est en échec alors que le formulaire est là ?

Le formulaire est probablement rendu par JavaScript, sans champ email ni password dans le HTML servi, et sans lien ou bouton dont le texte contient un des mots reconnus. Ajoutez un lien « Se connecter » rendu côté serveur, ou surveillez la page en HTTP simple avec un contenu attendu.

Le prix a changé, comment mettre l'assertion à jour ?

Supprimez la cible tarifs et relancez le pack avec le nouveau texte, ou ajoutez la page en cible HTTP avec « Doit contenir » — ce champ, lui, se modifie sur le détail de l'URL.

Parcours de paiement

Disponible avec les plans Pro et Pro Plus.

La chaîne qui mène au paiement, vérifiée dans l'ordre, arrêtée à la première étape cassée.

Les pages de paiement sont surveillées une à une, 4 pages isolées. Un parcours de paiement est une chaîne : tarifs, puis checkout, puis merci. Une chaîne peut être verte page par page et cassée quand même — le bouton de la page tarifs pointe sur un /checkout qui rend 404, les 3 vérifications individuelles restent au vert, et personne ne paie plus. Le parcours de paiement demande les pages l'une après l'autre et vous dit laquelle casse.

Ce que PostShip vérifie

Un parcours est une liste de 2 à 6 URL de votre site, dans l'ordre. À chaque passage :

1. PostShip demande la première étape exactement comme une cible HTTP : statut 200 attendu (les redirections sont suivies, donc un /checkout qui redirige proprement passe), assets vérifiés, et les assertions des pages de paiement si vous en avez réglé.
2. Si elle passe, il demande la suivante. Sinon il s'arrête : les étapes suivantes sont rapportées « non atteinte », jamais vertes. On ne les a pas vérifiées, et un vert qu'on n'a pas mérité serait un mensonge dans un produit dont c'est le sujet.
3. Le verdict du parcours est celui de la première étape cassée ; son temps de réponse est la somme des étapes parcourues.
4. Quand toute la chaîne passe, chaque étape est rouverte dans un vrai navigateur (Chromium) : une page qui répond 200 puis s'affiche blanche, plante (« Application error »), ou dont un script ou une feuille de style de votre site répond en erreur casse l'étape. Les erreurs JavaScript seules sont notées en avertissement, sans alerte : la plupart viennent de scripts tiers.

2 assertions couvrent ce qui casse vraiment :

• le texte du prix à retrouver sur la première étape — c'est la page qui l'annonce, et c'est là que sa disparition se voit d'abord ;
• le numéro de l'étape qui doit charger Stripe.js (js.stripe.com), c'est-à-dire celle qui encaisse.

Où le lire

Projet → Surveillance → Parcours : chaque parcours avec son dernier passage marche par marche (le statut, ce qui manque, le temps de première réponse de chaque marche en barre), la réussite sur 30 jours, la médiane du temps total et la courbe des derniers passages. « Nouveau parcours » mène au formulaire ci-dessous.

Régler

Projet → Surveillance → Parcours → « Nouveau parcours » → « Des adresses » :

1. Les étapes, dans l'ordre : une URL par ligne, de 2 à 6, toutes sur l'origine du projet. Le bouton « Trouver mon parcours » lit votre page d'accueil et propose une liste — c'est une déduction, relisez-la avant de valider.
2. Ce qui doit s'y lire (facultatif) : le texte du prix sur la première étape — « 49 € », « 29,90 », ce que la page affiche — et l'étape qui charge Stripe.js (0 pour aucune, sinon 1 à 6).
3. « Surveiller ce parcours ».

Refus possibles : « Un parcours demande au moins 2 étapes, une par ligne. », « 6 étapes au maximum. », « Étape 2 : … » quand une ligne n'est pas une URL https de votre domaine, ou le message de quota si le plan est plein.

Ce qui déclenche une alerte

Le parcours échoue quand une étape échoue, pour n'importe quelle raison HTTP (statut, asset, prix, Stripe.js, délai) ou de rendu (page blanche, plantage, script du site en erreur). La phrase nomme l'étape :

Le manque de l'étape cassée est celui d'une cible HTTP — Stripe.js n'est plus chargé sur https://acme.fr/checkout., Le prix n'apparaît plus sur https://acme.fr/tarifs., https://acme.fr/checkout répond 404..

L'empreinte du passage porte le numéro de l'étape : « la 2 sur 4 est cassée » et « la 3 sur 4 est cassée » sont 2 pannes différentes, et la seconde n'est pas avalée par le dédoublonnage de la première. Un parcours en échec coûte 40 points au Ship Score, comme une page de paiement — c'est le paiement par définition.

Limites et plans

Un parcours compte pour une seule URL de votre quota, pas 4 : c'est une seule ligne, quelle que soit sa longueur. Sur Découverte, le choix « Un parcours de paiement » mène aux plans, et l'action répond « Les parcours de paiement sont disponibles à partir du plan Pro. ».

Dépannage

Pourquoi la page « merci » est en échec alors qu'elle n'est accessible qu'après paiement ?

Parce que PostShip la demande sans avoir payé, et qu'elle répond probablement 302 vers l'accueil, ou 200 avec un message d'erreur. Ne mettez dans le parcours que des pages qui répondent 200 à un visiteur anonyme ; pour la page de retour Stripe, voir Stripe.

Pourquoi « Trouver mon tunnel » ne propose rien ?

Il lit les liens de la page d'accueil et cherche des adresses qui ressemblent à des tarifs, un checkout, une inscription. Un site dont la navigation est rendue par JavaScript ne lui donne rien à lire. Tapez les URL vous-même.

Comment modifier un parcours ?

Supprimez-le depuis Parcours de paiement (menu ⋯) et recréez-le avec « Nouveau parcours » : les étapes ne se modifient pas une par une. Un parcours ne prend pas de place d'URL ; seule la limite de parcours par projet compte.

Formulaire canary

Vérifier que l'endpoint de votre formulaire de contact accepte encore un envoi, sans polluer votre CRM.

/api/contact et /api/lead sont les premières victimes d'un refactor : un fichier de route déplacé, un export renommé, un middleware qui avale désormais les POST. La page qui porte le formulaire répond toujours 200, rien d'autre ne le remarque, et les prospects cessent simplement d'arriver. Le formulaire canary envoie des données visiblement fausses à l'endpoint et lit le code de réponse.

Ce que PostShip vérifie

À chaque passage, PostShip fait un POST sur l'URL de la cible avec :

• le corps _postship=canary&email=canary@invalid, en application/x-www-form-urlencoded ;
• l'en-tête X-PostShip-Canary: 1, pour que vous puissiez écarter ces envois de vos statistiques et de votre limitation de débit sans deviner d'après le User-Agent ;
• le même délai de 12 secondes et les mêmes 5 redirections au plus que les autres vérifications. Le corps et la méthode sont renvoyés à chaque saut ; chaque saut est vérifié contre les adresses privées.

L'adresse canary@invalid est volontairement impossible à router : le domaine .invalid est réservé précisément pour que rien n'essaie jamais d'y livrer.

Ce que PostShip ne vérifie pas : qu'un prospect a été enregistré. Il faudrait une vraie adresse et une boîte à relever, et cela mettrait des données bidon dans votre CRM. Le canary lit le statut, rien d'autre.

Régler

Projet → URLs → « Surveiller… » → « Un formulaire ». L'adresse est celle de l'endpoint (https://acme.fr/api/contact), pas de la page qui affiche le formulaire. Puis l'écran « Comment répond-il à un envoi bidon ? » :

Le premier choix est le bon pour un formulaire de contact ordinaire. Le second sert quand l'endpoint est un relais qui doit toujours accepter (un webhook entrant, un formulaire sans validation).

Ce qui déclenche une alerte

Avec le réglage « refuse », un 2xx et un 4xx sont tous deux verts. L'alerte suit la confirmation du projet et part une fois par panne ; « Rétabli » suit le retour au vert. Un formulaire en échec coûte 10 points au Ship Score.

Limites et plans

Disponible sur tous les plans ; une cible canary compte pour une URL du quota (Découverte 5, Pro 25, Pro Plus 100). La fréquence est celle du cycle : 5 minutes sur Découverte, 2 sur Pro, 1 sur Pro Plus, plus chaque déploiement. La sonde de 30 secondes de Pro Plus ne regarde que les pages : elle n'envoie jamais de formulaire.

Dépannage

Pourquoi l'endpoint est en échec avec un 403 ?

Avec le réglage « accepte », tout ce qui n'est pas 2xx échoue — et un 403 vient souvent d'une protection anti-robot (Turnstile, reCAPTCHA) ou d'une vérification d'origine (Origin, jeton CSRF). Passez au réglage « refuse » : le 403 devient une réponse saine, et un 404, 405 ou 5xx reste un échec.

Pourquoi je reçois un email à chaque passage ?

Votre endpoint traite l'envoi avant de valider l'adresse. Rejetez canary@invalid (ou tout ce qui porte X-PostShip-Canary) avant la notification. C'est aussi un bon garde-fou contre les envois de robots.

Le canary peut-il tester un formulaire en GET ou en JSON ?

Non : c'est toujours un POST encodé en formulaire. Pour un endpoint JSON, surveillez-le comme contrat d'API si c'est un GET, ou en cible HTTP avec le statut attendu correspondant.

Stripe

La vérification « Paiement » est sur tous les plans ; la lecture de vos vrais paiements est en Pro et Pro Plus.

Savoir que vos clients peuvent encore payer, et être prévenu quand leurs paiements se mettent à échouer.

Depuis le 26 septembre 2026, tout ce qui touche à Stripe tient en deux choses : la vérification Paiement, posée quand PostShip trouve un prestataire sur votre site, et votre compte Stripe en lecture. L'ancienne vérification de la page de retour (success_url) ne se propose plus ; celles qui existaient continuent de tourner.

Ce que PostShip vérifie

La vérification Paiement regarde, à chaque passage, que le prestataire est bien chargé sur la page où l'on paie, qu'il est autorisé par l'en-tête de sécurité du site et qu'il répond. Voir Quand le paiement se fait après la création d'un compte.

Ce qu'elle ne fait pas : elle ne crée aucune session de paiement, ne rejoue aucun webhook et ne touche pas à votre compte. Pour surveiller votre route de webhook (/api/stripe/webhook), ajoutez-la en cible HTTP avec le statut que votre serveur renvoie à un GET sans signature — souvent 405 ou 400.

Compte en lecture

Pour être alerté quand vos vrais paiements se mettent à échouer, branchez votre compte Stripe dans Paramètres → Intégrations → Compte Stripe, en lecture :

1. Dans Stripe : Développeurs → Clés API → Créer une clé restreinte.
2. Donnez-lui Lecture sur PaymentIntents, et Aucun partout ailleurs.
3. Collez-la dans PostShip : elle commence par rk_live_.

PostShip vérifie la clé en lisant un paiement, puis la vérification Paiement du projet regarde à chaque passage les paiements de la dernière heure. Elle alerte au-delà de trois paiements échoués, et pas moins d'échecs que de réussites : 3 paiements sur 5 ont échoué dans la dernière heure. Une clé révoquée chez Stripe le dit aussi : La clé Stripe donnée à PostShip a été révoquée : les paiements ne sont plus lus.

Une clé secrète complète (sk_…) est refusée : elle pourrait rembourser et encaisser, PostShip n'en a pas besoin. Débrancher efface la clé de PostShip ; révoquez-la aussi dans Stripe.

Limites et plans

Dépannage

Comment surveiller la page de retour après paiement ?

En cible HTTP ordinaire, si elle répond 200 à un visiteur sans session Stripe. Si votre page fait redirect('/') ou renvoie 400 quand session_id manque, rendez-la tolérante — un message générique, 200 dans tous les cas : un client qui rafraîchit la page ou revient par l'historique tombe sur la même chose que PostShip.

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.