MicroExits
Verified revenue · Verified traffic · Escrow on every deal

How we verify, and where it stops

You are about to wire five figures to someone you have never met, for a business you cannot physically inspect. That is a real problem, and it is the one we actually built. Here is every check, including where each one stops.

Revenue: pulled from the source, not typed in

A seller can claim any revenue they like. You are paying for proof, so proof is what we build. Three tiers, and we tell you which one a listing is standing on.

Strongest

Read-only OAuth to the payment processor

Revenue Verified via Stripe

The seller connects Stripe, Paddle or Lemon Squeezy with a read-only grant. We pull MRR and the last several months of revenue straight from the processor. The seller never types the number in, so the number can't be wrong. This is the gold standard and the only tier that earns a revenue badge.

Middle

Bank or payout statement upload

Manual review

For platforms with no API, a seller can upload statements. These go to a human on our team for manual review — not straight to a badge. We check the statements against the claim before anything is marked reviewed.

Weakest

Screenshots

Self-reported

A screenshot is a picture of a number. It proves nothing and it is trivial to fake. We allow screenshots because some context beats none, but they are labelled self-reported and are never badged as verified. If a listing's revenue rests only on a screenshot, treat the figure as a claim.

A badge is a snapshot, not a live feed

When we verify revenue we store the figure and the date we pulled it, and the badge shows both. It is what the processor reported on that date. It is not a live number, and it does not update itself — a business verified at $4,100 MRR in March might be at $3,400 by June. Read the as-of date, and ask the seller to re-run the connection if it looks stale.

Traffic: and we check the domain matches

Sellers connect GA4, Plausible or Cloudflare read-only. We pull sessions and uniques for the period, and badge it with the source and the date range.

The part that matters: we confirm the domain inside the analytics connection is the same domain as the listing. Connecting a healthy property you happen to own and passing it off as the one you're selling is the obvious attack here, and the domain check is what closes it.

Read-only, always

The OAuth grant we request can read analytics and nothing else. Tokens are encrypted at rest. A seller can revoke us from their provider at any time.

Source and period on the badge

"Traffic Verified via GA4" carries the provider and the window the numbers cover, so you know what you're looking at.

Screenshots stay self-reported

Same rule as revenue. An analytics screenshot is never badged as verified, no matter how convincing it looks.

Verified-only browsing

You can filter browse down to listings carrying real verification badges and ignore everything else.

Identity: checked before money moves

Identity verification is required before you can fund escrow or receive a payout. It is not required to browse, to message, or to list — you only meet the check at the point where money is actually involved.

That means the person on the other side of your deal has been checked by the time it counts, on both sides.

We don't store your documents

Your ID goes to a specialist identity provider, not to us. All we keep is a status and a reference to their record. There is no passport scan on a MicroExits server to leak, because we never receive one.

Two-factor on money actions

Funding and payout both require verified identity and two-factor enabled. Browsing and listing stay open before you verify, so you can see the whole market before deciding to hand anyone your ID.

Custody

Escrow: we never touch your money

A licensed escrow provider holds the funds for the whole deal. Not us. This is deliberate: we are not a money transmitter and we have no interest in becoming one. Your money never sits in a MicroExits account, so it cannot be lost with a MicroExits account.

We orchestrate the flow inside our UI — line items, status, release, disputes — but custody sits with the provider throughout. Wire or ACH only: no cards, which keeps a processing surcharge off your deal.

  1. 01

    Offer accepted

    The deal is created and its economics freeze: fee schedule version, rate, and escrow split.

  2. 02

    Buyer funds escrow

    The buyer wires into the provider. The seller is notified to start the transfer — and can see the money is real.

  3. 03

    Seller transfers assets

    Domain, repo, Stripe, hosting, socials — each item on the checklist gets marked delivered with evidence.

  4. 04

    Buyer confirms each item

    You confirm item by item, not all-or-nothing. Anything not delivered stays visibly outstanding.

  5. 05

    Funds release

    On full confirmation, the provider releases to the seller minus the success fee. We're paid at the same moment you are.

5-day inspection window

After the assets land, the buyer has 5 days to inspect and confirm. The window is configurable per deal. If the buyer goes silent it auto-releases at the end, so a seller who did the work can't be held hostage by an unresponsive buyer.

A dispute freezes the release

Open a dispute inside the window and auto-release stops immediately. Our team reviews the deal timeline, the transfer evidence, the chat log and the verification history in one view, then releases, partially refunds or refunds — with a written resolution note on the record.

The fee comes out of escrow

Our success fee rides along on the escrow transaction and is deducted at release, so the seller never pays out of pocket. The provider's own fee is a separate, itemized line — and it is not our revenue. See the full breakdown.

Wire and ACH only, and always through the provider

Nobody at MicroExits will ever ask you to wire funds to an account that isn't the escrow provider's, or to move a deal to email, Telegram or a direct transfer. If a counterparty asks you to, that is the single clearest fraud signal in this market. Report it and stop.

Platform integrity: the unglamorous parts

Verification stops a seller lying about the numbers. These stop everything else.

Contact details masked until an offer is accepted

Emails, phone numbers and external URLs are auto-masked in messages before acceptance. This keeps the deal on-platform where escrow, the audit log and the dispute path actually protect you — and stops both sides being pulled into an unprotected wire.

Duplicate and stolen-asset detection

We flag a listing when its domain or repo already appears on another active listing, or was sold here recently. Someone reselling an asset they no longer own gets caught by the same check.

Immutable audit log on every money movement

Every funding event, release, refund, verification decision and admin action is written to an append-only log with actor, timestamp and IP. If a deal goes wrong, there is a record — not a recollection.

Escrow release requires re-entering 2FA

Releasing funds is the one irreversible step, so it takes a fresh two-factor code at the moment of release. A hijacked session isn't enough to move your money.

What we don't claim

Verification is not a valuation and it is not a guarantee. We can prove a Stripe account took $4,100 last month. We cannot prove it will next month, or that the traffic won't fall off an algorithm update, or that the code is any good. Verified numbers narrow the range of things you have to take on faith — they don't take you to zero. Do your own diligence, use the inspection window, and ask hard questions before you confirm.