Metrivo
Solution

Why doesn't my Stripe revenue match what I'm seeing elsewhere?

A missing webhook event, a refund that changed a charge after the fact, or a downstream number that hasn't caught up can all make Stripe revenue look wrong when it isn't — or right when it isn't. Metrivo's Revenue Assurance independently reconciles Stripe's provider records with signed webhook receipts and canonical payment data before it tells you which one it is.

The problem

Stripe is the source of truth for what actually happened to a payment, but the number you see in a dashboard depends on every step between Stripe and that dashboard working correctly: the webhook endpoint staying up, every event type being subscribed to, refunds and disputes being replayed correctly, and the downstream data actually processing what arrived. Any one of those can fail quietly — the charge still exists in Stripe, but your revenue number doesn't reflect it.

Most tools assume their own number is right and stop there. That turns a measurement problem into a revenue-decision problem: you either chase a leak that isn't there, or miss one that is.

How Metrivo helps

Revenue Assurance compares Stripe's read-only provider records, your signed webhook receipts, and Metrivo's canonical payment record for each website. When they disagree, it names the specific incident instead of just flagging a generic discrepancy.

Missing delivery

Stripe's provider records show a finalized payment, but Metrivo never received a signed webhook for it. That gap is surfaced, not silently dropped.

Canonical mismatch

The amount, currency, state, refund, or dispute facts from Stripe conflict with Metrivo's normalized payment record. You see exactly what disagrees.

Stale projector

Webhook receipts exist, but the downstream data hasn't caught up recently enough to trust for a decision right now.

Coverage gap

A Stripe stream or attribution handoff is incomplete. Metrivo preserves the uncertainty instead of assigning false confidence to a guess.

Setup steps

  1. 1. Connect the Stripe webhook. Add your Metrivo webhook endpoint in Stripe and save the signing secret. See the Stripe integration doc for exact steps.
  2. 2. Add a restricted read-only key. Open Revenue Assurance for the website, add an rk_test_ or rk_live_ key scoped to the listed read permissions. It cannot create charges, refunds, transfers, or payouts.
  3. 3. Run bootstrap and shadow verification. The configuration observes and compares evidence before it becomes authoritative for any diagnosis.
  4. 4. Review incidents as they surface. Each one is labeled with the specific category and the evidence behind it — never a bare "numbers don't match."

What Metrivo will NOT claim

  • We will not guarantee a diagnosis when evidence is stale, incomplete, or insufficient — we report insufficient evidence instead.
  • We will not move money, change your Stripe settings, or automatically modify your site.
  • We will not guarantee revenue recovery or perfect attribution.
  • We will not treat a missing answer as a reason to guess. Honest unknown beats a confident wrong verdict.

Related docs

FAQ

Why doesn't my Stripe revenue match what an analytics tool shows?

Usually one of a few things: a webhook event never arrived (delivery failure or endpoint downtime), a refund or dispute changed a charge's state after it was first recorded, or the tool's own data hasn't caught up with the latest Stripe event. Metrivo's Revenue Assurance checks for all three independently instead of assuming the two numbers should already agree.

What is a missing webhook delivery, exactly?

It's when Stripe's own provider records show a finalized payment that never produced a signed webhook receipt on your end. This can happen from endpoint downtime, misconfigured event selection, or a delivery retry that silently exhausted. Metrivo flags it as a distinct incident category rather than folding it into a generic error.

Does Metrivo need write access to my Stripe account to check this?

No. Revenue Assurance uses a Stripe restricted key validated for read-only access. It cannot create charges, refunds, transfers, or payouts. It does not modify your Stripe account or checkout logic.

What happens if Metrivo doesn't have enough evidence to explain a mismatch?

It reports insufficient evidence instead of guessing. Metrivo checks provider and data freshness, provider coverage, and sample sufficiency before returning a verdict — a missing answer is treated as more honest than a wrong one.

Can I see this running before it affects anything?

Yes. New Revenue Assurance configurations start in shadow mode, where they observe and compare without being used as the source for a decision. A configuration only becomes authoritative for diagnosis after its evidence sources and permissions pass setup checks.