How to Show Verified MRR Publicly (Stripe Guide)

Plenty of founders want to show their MRR publicly. It is a quick signal that a product is real, it helps with hiring and partnerships, and it gives people following your journey a number to cheer for. The problem is proof. This guide covers how to show verified MRR from Stripe, step by step, without giving anyone the keys to your account.

Why verified beats a screenshot

A Stripe dashboard screenshot has three weaknesses:

• It is easy to fake. Browser dev tools can change any number on a page before you take the picture.
• It is a snapshot. It was true on the day you took it. Nobody knows if it is still true.
• It hides the method. Does it include one-off charges? Refunds? Annual plans divided by twelve?

A verified number comes straight from Stripe's API, is refreshed automatically and is counted the same way for everyone. Readers do not have to trust you. They have to trust the method, which is a much easier ask.

What a Stripe restricted key is

Stripe has two kinds of server-side keys:

• Secret keys start with sk_live_. They can do anything in your account: create charges, issue refunds, read customers, trigger payouts.
• Restricted keys start with rk_live_. They can do only what you allow. For each resource you pick None, Read or Write.

Stripe's own documentation recommends restricted keys wherever possible and specifically calls them safer for third-party sharing. If a restricted key leaks, the person holding it is limited to that key's permissions.

What "read-only" actually means

When we say a key is read-only, we mean that every permission is set to None or Read, and nothing is set to Write. In Stripe's model, a read permission maps to GET requests. Creating, updating or deleting anything (charges, refunds, customers, payouts) needs write access, so a read-only key cannot do it.

For MRR you only need two resources:

• Subscriptions: Read, to list active subscriptions and add up what they bill per month.
• Charges: Read, to sum the last 30 days of payments if you sell one-off products instead of subscriptions.

Everything else can stay at None. The key will not be able to see your bank details, change prices or move money.

Step by step: create the key

1. In the Stripe Dashboard, go to Developers, then API keys.
2. Click Create restricted key.
3. Name it after the tool you are giving it to, so you can find it later.
4. Set Subscriptions to Read and Charges to Read. Leave every other permission at None.
5. Click Create key and complete the two-factor check Stripe asks for.
6. Copy the key. Stripe notes you cannot retrieve it later, so paste it straight into the tool.

If you ever want to cut access, come back to the same page and delete or roll the key. The tool stops working instantly.

How MRR should be calculated

"MRR" gets used loosely, so it helps to know what a fair calculation looks like:

• Start from active subscriptions only. Cancelled, unpaid or incomplete ones do not count.
• Normalise each subscription to a monthly amount. A yearly plan at $120 counts as $10 a month.
• Apply discounts that are still active, so a 50% coupon halves that subscription's contribution.
• Leave out one-off charges, which are not recurring.

If your product is not subscription-based, MRR is the wrong number. Show revenue over the last 30 days, net of refunds, instead, and label it clearly.

Keeping the key safe after you share it

Handing a restricted key to a tool is a small act of trust, so it is worth checking how the tool treats it:

• Is the key checked before it is saved? A good tool tests the key once and rejects it if it is a full secret key or lacks the right permissions.
• Is it encrypted at rest? The key should be stored encrypted, not in plain text in a database.
• Is it ever shown again? After you paste it, the tool should never display it back to you or anyone else.
• Can you disconnect? You should be able to remove the connection in the tool, and you can always delete the key in Stripe.

Stripe also lets you view a key's request logs from the API keys page, so you can see exactly what a tool has been reading.

Common mistakes

• Pasting a secret key. Never paste an sk_live_ key into a third-party tool. Make a restricted key, even if the tool would accept the secret one.
• Giving write access "just in case". If a display tool asks for write permissions, ask why.
• Using a test-mode key. Test keys start with rk_test_ and will show test data, which is usually zero or nonsense.
• Forgetting multiple accounts. If each product has its own Stripe account, each needs its own key.

Should you share MRR at all?

Not everyone should, and not always. Some founders stop sharing once copycats appear or once numbers become useful to competitors. That is a fair call. Verification does not oblige you to share forever: you can disconnect, hide a project or switch to showing only the status. We wrote more about that trade-off in building in public: sharing revenue and failures.

Showing verified MRR on makerhandle

On makerhandle, each project on your page can connect a Stripe restricted key with Charges and Subscriptions set to Read. We check the key before saving it, encrypt it at rest and never show it again. Your page then shows MRR from active subscriptions (or the last 30 days of charges, net of refunds) with a check mark, and the same number appears on the leaderboard, which can filter to verified only.

You can read the details on the verified revenue page, or claim a handle and connect your first project in a couple of minutes. Selling on Shopify instead? See how to show Shopify revenue.