Honest social proof: provenance, refunds and test events in a webhook pipeline

"Emma from Portland just bought Lavender Oat Body Butter." A notification like that is only worth showing if it's true, recent and still valid. In ProofLoom every notification starts as an event you can inspect. The 28-second reel shows the Events screen. Here's how the pipeline decides what may reach a website.

1. Webhooks in, events out

Each source (Stripe, Shopify, WooCommerce, a generic signed webhook, or "Any app" with a field mapping) gets its own URL. The API stores the delivery, and a worker turns it into a normalized event: type (purchase.completed, signup.completed, booking.completed, order.refunded, order.cancelled), time, first name, city, country, product, and an amount kept private.

Shopify, for example, sends orders/paid, orders/cancelled and refunds/create. A paid order becomes a purchase keyed order_<id>. orders/create and orders/paid share that key, so the same order counts once.

2. Provenance is a fact, not a badge

Every event carries one of four provenance values:

• provider_authenticated: the provider signed it (Stripe, Shopify) → "Provider verified"
• customer_server_asserted: your server or store sent it → "From your server"
• browser_observed and manual

The UI never upgrades a server-asserted event to "verified". If your server says a sale happened, that's what the label says.

3. Eligibility has reasons

An event is shown only if it's eligible. When it isn't, it keeps a reason the dashboard can print:

• test_mode: a test event (Shopify's test: true, or the "Send test event" button)
• stale: too old to present as recent
• invalidated: refunded or cancelled
• duplicate_transaction: already reported by another source

4. Refunds invalidate by correlation

A refund isn't shown; it removes. refunds/create carries an order_id, so the refund event gets the same correlation key as the purchase (order_<id>). Processing marks the matching purchase invalidated, and its notification stops being served. Partial refunds count too: it's safer not to show a purchase that was even partly refunded.

5. Amounts never leave the dashboard

The amount is stored for the owner ("$64.00 (private)" in the list) but is never part of what the widget receives. Private details are kept for 30 days.

What we'd tell someone building the same thing

• Label provenance honestly and never promote it in the UI.
• Store a reason for every event you don't show. It turns "why isn't my sale showing?" into a one-line answer.
• Treat refunds and cancellations as invalidations keyed to the original order.
• Make test events first-class, so people can test in production without faking proof.

Try it with a 14-day free trial, no card: https://proofloom.veloxonhub.com. Happy to go deeper into the source mappings or deduplication in the comments.