The verified-revenue bar

How verification works

A revenue badge is a claim, and a claim is worthless unless you can audit the standard behind it. Here it is, in the open: what has to be true for a figure to count as verified, the exact line for each check, and (just as important) what we never touch.

Demo revenue data · verification wires in later
01

Connected processor, read-only

The line: A live, read-only link to the processor charging the customers

The number comes from the account that actually takes the money (Dodo Payments, Stripe, RevenueCat, Lemon Squeezy or Polar) through a read-only connection. We can read the revenue totals and nothing else: we never see a card number, never move a cent, and can never issue a charge or a refund. The scope is read, and only read.

02

Pulled via API, never typed

The line: Every figure is fetched from the source: no manual entry, no screenshots

Nobody types their MRR into a box. There is no field to inflate, no screenshot to doctor, no invoice PDF to photoshop. The figure on a badge is the figure the API returned, and a listing that can only offer a self-reported number is not verified: it stays in the un-verified state until a real connection is made.

03

Refreshed regularly

The line: Re-pulled on a regular schedule: a stale badge is flagged, not left to look current

A verified number is only honest on the day it was read, so we re-pull it on a regular schedule and stamp each badge with when it was last checked. If a connection goes quiet or the pull starts failing, the badge is marked stale rather than frozen at its last good reading. An out-of-date badge that still claims a number is exactly the lie this whole system exists to prevent.

04

Public & permanent: Open Revenue

The line: The verified figure is shown in the open and stays on the record

Once a figure is verified it is shown in public (on the board, in the stats, on the listing) as Open Revenue. It is not a private dashboard metric you flash and hide; it is a standing entry anyone can see and return to. Building in the open is the point: the badge means something precisely because it can't be quietly walked back the moment the number dips.

All four have to hold at once. A connected processor whose numbers are typed in by hand, or a real API pull that hasn't refreshed in a week, is not “mostly verified”. It's not verified, and the badge is withheld or flagged until every point is true again.

What we refuse to call verified

A number someone typed

A screenshot of a dashboard, a figure in a form, a “trust me” in a bio. None of it touches the processor, so none of it is verified. Self-reported revenue is left in the un-verified state: visible as unclaimed, never dressed up as confirmed.

A badge that went stale

A connection that stops pulling doesn't get to keep coasting on its last good number. Once a refresh is overdue the badge is flagged stale, and the last-checked date is on it the whole time, so nobody acts on a figure that no longer describes the business.

What we never touch

The connection is read-only by design, not by policy we could quietly change. We read the revenue totals the processor reports and nothing beside them: no card or bank details, no customer identities, no ability to charge, refund, or move money. A verified badge proves the money is real: it is never a doorway into the account behind it. Processors we verify through: Dodo Payments, Stripe, RevenueCat, Lemon Squeezy, Polar.