Dans Provedly, la mention « Achat vérifié » signifie une seule chose : l'enregistrement est arrivé par un webhook dont Provedly a contrôlé la signature avec le secret que vous avez collé. Pour Stripe, cela demande quatre étapes et environ cinq minutes, et c'est disponible sur tous les plans, Free compris. Ce guide couvre la configuration, ce que Provedly lit dans l'événement, comment obtenir l'attribution, et quoi vérifier quand les événements arrivent mais que rien n'est vérifié.
Les quatre étapes
Étape 1 : ajouter une source Stripe dans Provedly
Ouvrez le widget, allez dans l'onglet Data et ajoutez une source Stripe. Provedly vous affiche l'URL d'endpoint de ce widget :
https://provedly.app/api/hooks/stripe/pp_your_token
Laissez cet onglet ouvert ; vous y reviendrez pour le secret.
Étape 2 : enregistrer l'endpoint dans Stripe
Dans le dashboard Stripe, allez dans Développeurs, puis Webhooks, puis Ajouter un endpoint. Collez l'URL et sélectionnez un seul événement : checkout.session.completed. Vous n'avez besoin d'aucun autre événement. En ajouter d'autres ne fait pas de mal, mais Provedly les ignore et cela encombre vos logs de webhooks.
Si vous utilisez la CLI Stripe pour tester en local, l'équivalent est :
stripe listen --events checkout.session.completed \
--forward-to https://provedly.app/api/hooks/stripe/pp_your_token
En production, enregistrez l'endpoint dans le dashboard plutôt que de compter sur la CLI.
Étape 3 : coller le secret de signature
Stripe affiche un secret de signature pour le nouvel endpoint, qui commence par whsec_. Copiez-le dans le champ secret de la source Stripe dans Provedly et enregistrez. C'est tout le fondement de la vérification : Stripe signe chaque événement avec ce secret, Provedly recalcule la signature, et un événement qui ne correspond pas est rejeté. Sans le secret, rien n'est vérifié.
Étape 4 : envoyer un événement de test
Utilisez « Envoyer un événement de test » depuis la page de l'endpoint dans Stripe. En quelques secondes, la source dans Provedly affiche un horodatage de « dernier événement ». Les événements de test de Stripe contiennent des données factices, l'enregistrement peut donc paraître étrange ; supprimez-le ensuite ou laissez la fenêtre de rétrospective le faire disparaître. Le premier vrai checkout produit un enregistrement correct.
Ce que Provedly lit dans l'événement
| Champ de la notification | Provient de |
|---|---|
| Nom | le nom dans les informations client de la session |
| Ville et pays | l'adresse de livraison si présente, sinon de facturation |
| Produit | le premier article |
| Prix | le total formaté dans la devise de la session |
| Heure | l'heure de l'événement |
Le nom passe ensuite par votre réglage de format de nom (par défaut « Sarah M. ») et le lieu par votre format de lieu (par défaut « Austin, US »). Ce que Stripe vous envoie en entier n'est pas ce que voient les visiteurs. Voir Formats de nom et de lieu : la confidentialité par défaut.
Si une session n'a pas de nom parce que vous n'en avez pas collecté, la notification utilise un sujet générique. Collectez les noms au checkout si vous voulez des notifications nominatives ; ne les inventez pas après coup.
Attribution : transmettre l'identifiant visiteur
Le dashboard compte les commandes assistées par la preuve, c'est-à-dire les acheteurs qui ont vu une notification avant d'acheter, rapprochés par identifiant visiteur dans les 30 jours. Stripe ne connaît pas l'identifiant visiteur si vous ne le lui donnez pas. Quand vous créez la Checkout Session sur votre serveur, ajoutez-le en metadata :
// client: read the id before redirecting to checkout
const visitor = window.Provedly?.visitorId();
// server: create the session
const session = await stripe.checkout.sessions.create({
mode: 'payment',
line_items: [{ price: 'price_123', quantity: 1 }],
success_url: 'https://example.com/thanks',
cancel_url: 'https://example.com/cart',
metadata: { provedly_visitor: visitor ?? '' },
});
Provedly lit metadata.provedly_visitor dans la session finalisée et relie l'achat au visiteur qui a vu la notification. Pas de metadata, pas d'attribution ; le dashboard n'estime jamais. Sur Shopify, c'est automatique, car le widget écrit l'identifiant visiteur dans le panier sous l'attribut provedly_visitor.
Ce que le visiteur peut vérifier
Chaque notification vérifiée renvoie vers la page de vérification publique du widget. Elle liste les sources connectées (ici, Stripe), les décomptes, le dernier achat vérifié et la politique d'honnêteté du widget. Une racine SHA-256 calculée chaque nuit scelle l'historique, pour qu'un décompte ne puisse pas être réécrit discrètement plus tard. C'est la partie que les concurrents n'ont généralement pas ; en octobre 2026, d'après leurs fiches, la plupart des outils laissent un marchand saisir les chiffres qu'il veut, sans aucune page expliquant d'où ils viennent. Plus de détails dans Pourquoi la preuve sociale a besoin d'une page de vérification.
Dépannage
Les événements arrivent mais les enregistrements ne sont pas vérifiés. C'est presque toujours le secret. Recopiez le whsec_ de l'endpoint exact que vous avez enregistré ; chaque endpoint a son propre secret, et un secret venant d'un autre endpoint ou de la CLI échouera au contrôle de signature. Enregistrez, puis envoyez un nouvel événement de test.
Aucun événement n'arrive. Vérifiez qu'il n'y a pas d'espace parasite dans l'URL de l'endpoint et que checkout.session.completed est bien sélectionné. Assurez-vous que l'endpoint est en mode live si votre boutique est en ligne ; les endpoints en mode test ne reçoivent que les événements du mode test.
Les enregistrements arrivent sans lieu. La session n'avait ni adresse de livraison ni adresse de facturation. Activez la collecte d'adresse dans Checkout si le lieu compte pour vous, ou réglez le format de lieu sur « none ».
Doublons. Stripe peut relancer une livraison. Provedly dédoublonne par événement, donc les relances ne créent pas d'enregistrements en double.
Paiements via Payment Intents uniquement. Si vous encaissez avec Elements et Payment Intents plutôt qu'avec une Checkout Session hébergée, checkout.session.completed ne se déclenche jamais. Envoyez plutôt ces commandes depuis votre backend vers l'API Records ; elles seront étiquetées Imported, et votre page de vérification les listera sous « Site owner's backend (API) ». Voir Utiliser l'API Records pour les achats de votre propre backend.
Questions fréquentes
Provedly a-t-il besoin de ma clé API Stripe ?
Non. Les webhooks sont entrants : Stripe pousse les événements vers Provedly. Vous ne partagez que le secret de signature du webhook, qui permet de vérifier des signatures et rien d'autre.
Puis-je connecter plusieurs comptes Stripe à un même widget ?
Chaque source Stripe a son propre secret d'endpoint : vous pouvez donc ajouter une source par compte sur le même widget, dans la limite de widgets de votre plan.
Les renouvellements d'abonnement s'affichent-ils comme des achats ?
Non. Seul checkout.session.completed est lu : le checkout initial apparaît, les paiements de factures suivants non. C'est voulu ; un renouvellement n'est pas un nouvel acheteur qui prend une décision.
Les achats vérifiés sont inclus dans tous les plans, Free compris : commencez avec Stripe connecté.