Das Kennzeichen „Verifizierter Kauf“ bedeutet in Provedly genau eines: Der Datensatz kam über einen Webhook, dessen Signatur Provedly mit dem Secret geprüft hat, das du eingefügt hast. Bei Stripe sind das vier Schritte und etwa fünf Minuten, und es ist in jedem Plan verfügbar, auch in Free. Diese Anleitung behandelt die Einrichtung, was Provedly aus dem Event liest, wie du die Zuordnung bekommst und was du prüfst, wenn Events ankommen, aber nichts verifiziert wird.
Die vier Schritte
Schritt 1: eine Stripe-Quelle in Provedly hinzufügen
Öffne das Widget, geh in den Tab Data und füge eine Stripe-Quelle hinzu. Provedly zeigt dir die Endpunkt-URL für dieses Widget:
https://provedly.app/api/hooks/stripe/pp_your_token
Lass diesen Tab offen; du kommst für das Secret zurück.
Schritt 2: den Endpunkt in Stripe registrieren
Geh im Stripe-Dashboard zu Developers, dann Webhooks, dann Add endpoint. Füge die URL ein und wähle ein einziges Event: checkout.session.completed. Andere Events brauchst du nicht. Weitere hinzuzufügen schadet nicht, aber Provedly ignoriert sie, und sie machen deine Webhook-Logs unübersichtlich.
Wenn du die Stripe-CLI für lokale Tests nutzt, ist das Äquivalent:
stripe listen --events checkout.session.completed \
--forward-to https://provedly.app/api/hooks/stripe/pp_your_token
Für die Produktion registriere den Endpunkt im Dashboard, statt dich auf die CLI zu verlassen.
Schritt 3: das Signing Secret einfügen
Stripe zeigt für den neuen Endpunkt ein Signing Secret an, das mit whsec_ beginnt. Kopiere es in das Secret-Feld der Stripe-Quelle in Provedly und speichere. Das ist die ganze Grundlage der Verifizierung: Stripe signiert jedes Event mit diesem Secret, Provedly berechnet die Signatur neu, und ein Event, das nicht übereinstimmt, wird abgelehnt. Ohne das Secret wird nichts verifiziert.
Schritt 4: ein Test-Event senden
Nutze „Send test event“ auf der Endpunktseite in Stripe. Innerhalb weniger Sekunden zeigt die Quelle in Provedly einen Zeitstempel für das „letzte Event“. Test-Events von Stripe enthalten Platzhalterdaten, der Datensatz kann also seltsam aussehen; lösch ihn danach oder lass ihn aus dem Rückblickzeitraum fallen. Der erste echte Checkout erzeugt einen ordentlichen Datensatz.
Was Provedly aus dem Event liest
| Feld im Toast | Stammt aus |
|---|---|
| Name | dem Namen in den Kundendaten der Session |
| Stadt und Land | der Lieferadresse, falls vorhanden, sonst der Rechnungsadresse |
| Produkt | dem ersten Artikel |
| Preis | der formatierten Summe in der Währung der Session |
| Zeit | dem Zeitpunkt des Events |
Der Name läuft dann durch deine Einstellung für das Namensformat (der Standard zeigt „Sarah M.“) und der Ort durch dein Ortsformat (Standard „Austin, US“). Was Stripe dir vollständig sendet, ist nicht das, was Besucher sehen. Siehe Formate für Name und Ort: Datenschutz als Standard.
Wenn eine Session keinen Namen hat, weil du keinen erfasst hast, weicht der Toast auf ein allgemeines Subjekt aus. Erfasse Namen im Checkout, wenn du Benachrichtigungen mit Namen willst; erfinde sie nicht nachträglich.
Zuordnung: die Besucher-ID mitgeben
Das Dashboard zählt proof-unterstützte Bestellungen, definiert als ein Käufer, der vor dem Kauf eine Benachrichtigung gesehen hat, zugeordnet über die Besucher-ID innerhalb von 30 Tagen. Stripe kennt die Besucher-ID nicht, solange du sie nicht mitteilst. Wenn du die Checkout Session auf deinem Server erstellst, gib sie als Metadaten mit:
// 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 liest metadata.provedly_visitor aus der abgeschlossenen Session und verknüpft den Kauf mit dem Besucher, der den Toast gesehen hat. Keine Metadaten, keine Zuordnung; das Dashboard schätzt nie. Bei Shopify passiert das automatisch, weil das Widget die Besucher-ID als Attribut provedly_visitor in den Warenkorb schreibt.
Was der Besucher prüfen kann
Jeder verifizierte Toast verlinkt auf die öffentliche Verifizierungsseite des Widgets. Sie listet die verbundenen Quellen (hier Stripe), die Zahlen, den letzten verifizierten Kauf und die Ehrlichkeitsrichtlinie des Widgets auf. Ein nächtlicher SHA-256-Root versiegelt die Historie, sodass eine Zahl später nicht still umgeschrieben werden kann. Diesen Teil haben Wettbewerber in der Regel nicht; Stand Oktober 2026 lassen laut ihren Angeboten die meisten Tools Händler beliebige Zahlen eintippen, ohne eine Seite, die erklärt, woher sie stammen. Mehr dazu in Warum Social Proof eine Verifizierungsseite braucht.
Fehlerbehebung
Events kommen an, aber Datensätze sind nicht verifiziert. Fast immer liegt es am Secret. Kopiere whsec_ erneut von genau dem Endpunkt, den du registriert hast; jeder Endpunkt hat sein eigenes Secret, und ein Secret von einem anderen Endpunkt oder aus der CLI besteht die Signaturprüfung nicht. Speichere und sende ein weiteres Test-Event.
Es kommen keine Events an. Prüf die Endpunkt-URL auf ein verirrtes Leerzeichen und stell sicher, dass checkout.session.completed ausgewählt ist. Prüf, ob der Endpunkt im Live-Modus ist, wenn dein Shop live ist; Endpunkte im Testmodus empfangen nur Events aus dem Testmodus.
Datensätze kommen ohne Ort an. Die Session hatte keine Liefer- oder Rechnungsadresse. Aktiviere die Adresserfassung im Checkout, wenn dir der Ort wichtig ist, oder stell das Ortsformat auf „none“.
Duplikate. Stripe kann die Zustellung wiederholen. Provedly dedupliziert pro Event, Wiederholungen erzeugen also keine doppelten Datensätze.
Zahlungen nur über Payment Intents. Wenn du mit Elements und Payment Intents statt einer gehosteten Checkout Session abrechnest, wird checkout.session.completed nie ausgelöst. Poste diese Bestellungen stattdessen aus deinem Backend an die Records API; sie werden als Imported gekennzeichnet, und deine Verifizierungsseite führt sie unter „Site owner's backend (API)“ auf. Siehe Die Records API für Käufe aus deinem eigenen Backend nutzen.
Häufige Fragen
Braucht Provedly meinen Stripe-API-Key?
Nein. Webhooks sind eingehend: Stripe schickt Events an Provedly. Du teilst nur das Signing Secret des Webhooks, mit dem sich Signaturen prüfen lassen und sonst nichts.
Kann ich mehrere Stripe-Konten mit einem Widget verbinden?
Jede Stripe-Quelle hat ihr eigenes Endpunkt-Secret, du kannst also pro Konto eine Quelle zum selben Widget hinzufügen, wenn die Widget-Limits deines Plans das erlauben.
Werden Abo-Verlängerungen als Käufe angezeigt?
Nein. Gelesen wird nur checkout.session.completed, der erste Checkout erscheint also, spätere Rechnungszahlungen nicht. Das ist Absicht; eine Verlängerung ist kein neuer Käufer, der eine Entscheidung trifft.
Verifizierte Käufe sind in jedem Plan enthalten, auch in Free: mit verbundenem Stripe starten.