How to show Stripe revenue on your website without leaking your account
There are three common ways to show Stripe revenue on a website: publish a screenshot, build your own widget on top of the Stripe API, or connect Stripe to a third-party service that calculates the figure and gives you something to embed. All three can work. They differ in how credible the number is, how much maintenance it needs, and how much of your Stripe account you expose in the process.
This guide covers each option, explains what RevenueBug's sharing features actually do, and lists the security rules that apply no matter which route you take. The most important one comes first: a Stripe secret key must never appear in browser code, a public repository, or a page's HTML. Everything else is a design choice.
Decide what number you are actually showing
Before you choose a widget, decide which metric you want visitors to see. "Revenue" on a landing page can mean very different things:
- Gross volume: successful charges before refunds, disputes, and fees.
- Adjusted gross revenue: successful payments minus refunds and disputes, before processor fees. RevenueBug's headline figure uses this definition over a trailing 30-day window.
- Subscription MRR: the normalized monthly value of active recurring subscriptions. Annual plans are divided by 12, and one-time sales are excluded.
- Net payouts: what actually reached your bank after fees, reserves, and payout timing.
These numbers are not interchangeable. If your Stripe account includes annual prepayments, lifetime deals, or setup fees, a trailing 30-day revenue figure can be well above your MRR in one month and below it in another. Label the metric precisely on the page. "$8,400 trailing 30-day revenue" is honest; calling the same figure "$8,400 MRR" may not be. The guide to verified MRR and the MRR vs ARR guide go deeper on these distinctions, and the MRR and ARR calculator helps when you need to normalize subscription terms.
Also decide on scope. A single Stripe account often serves several products. If you publish an account-wide total next to one product's logo, visitors will reasonably assume all of that revenue belongs to that product.
Option 1: Screenshots and manual updates
The simplest approach is to take a screenshot of the Stripe Dashboard, crop it, and put it on your site or in a tweet. It costs nothing and requires no credentials to leave your hands.
The weaknesses are equally obvious:
- It goes stale immediately. A screenshot is accurate for the moment it was taken.
- It is easy to fake. Anyone who has seen an edited dashboard image knows that screenshots carry little evidential weight. Visitors, buyers, and journalists increasingly discount them.
- It can leak more than you intend. Dashboard screenshots often include customer names, email addresses, payment method details, or account identifiers in the margins. Crop aggressively and check every pixel before publishing.
Screenshots are fine for a one-off milestone post. They are a poor foundation for a revenue display that you want people to trust over time.
Option 2: Build it yourself with the Stripe API
If you have engineering time, you can calculate the number on your own server and render it however you like. A common design is:
- A scheduled job on your server calls the Stripe API with a restricted key.
- The job reads balance transactions, which Stripe describes as representing funds moving through your account, or subscription objects if you want MRR.
- The job aggregates the result into a single number or a daily series and stores it.
- Your website reads only the stored aggregate from a public endpoint or static file.
The key point is the separation between steps 1–3, which happen on a server, and step 4, which is public. The browser should never call Stripe with anything other than a publishable key, and publishable keys cannot read revenue data.
Security rules for a DIY integration
Stripe's documentation is direct about this. Its API keys page says only publishable keys are safe to expose outside your back end, and it describes secret keys as having unrestricted permissions on all Stripe APIs. Its best-practices guide adds that an unauthorized party holding your secret key can make unauthorized charges, access customer data, or disrupt your integration.
For a revenue display, that translates into a short checklist:
- Use a restricted API key, not a secret key. Stripe's restricted key documentation explains that you set each resource to None, Read, or Write. A revenue widget needs read access to a few resources at most. It does not need write access to anything.
- Keep the key on the server. Store it in your host's secrets manager or an environment variable. Never put it in front-end bundles, mobile apps, or files committed to Git.
- Do not proxy raw Stripe responses. Return only the aggregate you intend to publish. A public endpoint that forwards balance transaction objects can expose customer and payment details.
- Cache the result. Recalculating on every page view wastes API calls and makes your site depend on Stripe's availability.
- Rotate the key if it is ever exposed. Stripe advises treating any exposure as a potential compromise and rotating immediately.
The DIY route gives you full control over design and metric definition. The trade-off is maintenance: refunds that arrive weeks later, disputes, currency conversion, and pagination all need handling. And because you compute and publish the number yourself, visitors have no independent reason to believe it beyond your word.
Option 3: Use a verified revenue service
A third option is to let a service read your provider data and publish the result. The advantage is that the number comes from a connected provider rather than from a screenshot or a value you typed, and someone else maintains the calculation.
RevenueBug works this way. You connect Stripe (or another supported provider) using a restricted, read-only key, as described on the Stripe integration page. RevenueBug imports balance transactions, groups them into daily revenue, subtracts qualifying refunds and disputes, and converts non-USD amounts using historical rates. The methodology page documents the calculation and its limits. Credentials are encrypted and never exposed on public pages.
"Verified" in this context means calculated from the connected provider's data. It is not an audit, proof of profitability, or proof that you own every product in the Stripe account.
What you can publish with RevenueBug
Once the first import finishes, there are several ways to put the number in front of people.
A public startup profile. Every listing gets a profile page under /startups showing a GitHub-style daily revenue graph and the trailing 30-day revenue headline. You can link to it from your site's footer, About page, or pricing page. If you prefer not to reveal which product the revenue belongs to, anonymous mode hides the product name, domain, description, and logo at the server-side data boundary while keeping the revenue public. Anonymous mode is not available for startups marked for sale.
A downloadable PNG card. The Share tab in the dashboard renders a revenue card with trailing 30-day revenue, lifetime revenue, 30-day change, and a 365-day activity grid. A "Download PNG" button saves it as an image you can post to social media, a newsletter, or an investor update. The button is disabled until the first import completes so you do not accidentally publish an empty card.
An image embed for your website. "Copy embed code" copies a short HTML snippet: an image of your revenue card wrapped in a link to your public profile. Paste it into any page that accepts HTML. Because it is a plain <img> inside an <a>, it needs no JavaScript and works in most site builders. The card image is regenerated from your public data, but it is still an image rather than an interactive widget.
Embedding the image well
A few HTML details make the image embed work better. MDN's img reference recommends meaningful alt text so screen-reader users know what the image shows, and notes that loading="lazy" defers loading until the image is near the viewport. Set an explicit width that fits your layout, and keep the surrounding link so visitors can click through to the full profile and its methodology.
What to keep private
Whichever method you choose, some things should not appear on a public revenue display:
- Customer identities. Names, emails, company names, and per-customer amounts. Even a "recent sales" ticker with first names and cities can identify customers in a small niche.
- Account identifiers. Stripe account IDs, payout bank details, and anything that helps an attacker target your account.
- Credentials of any kind. Not in HTML, not in a "view source" comment, not in an error page.
- Numbers you cannot explain. If the figure includes a large one-off contract or a refund backlog, either add context or wait until you can.
If you are considering selling later, remember that buyers will compare whatever you published with private exports. A public figure that is clearly labeled and consistent with the underlying data helps. The guide to preparing a startup for sale covers the rest of the evidence a buyer expects.
Choosing between the options
- Screenshot: low credibility, manual updates, and the main risk is stale figures or leaked customer data.
- DIY Stripe API: credibility depends on visitors trusting you, it needs ongoing engineering, and the main risks are key exposure and metric errors.
- Verified service: the figure is provider-derived, maintenance is low, and the main risk is mislabeling the metric or its scope.
A practical sequence for many founders is to start with a public profile and the PNG card for social posts, then add the image embed once the number is something you want on your homepage. Keep any DIY widget for cases where you need a custom metric, such as normalized MRR, that a cross-provider service does not compute.
If you are ready, you can add your startup and connect Stripe in a few minutes. If you are still estimating what your Stripe fees will be at a given volume, the Stripe fee calculator is a useful companion.
Frequently asked questions
Is it safe to give a third party my Stripe API key?
Only if you give it a restricted key with the minimum permissions required. Stripe's documentation describes restricted keys as the safer way to share access with a third party because the holder can only do what the key allows. Never share an unrestricted secret key, and rotate any key you stop using.
Can I show Stripe revenue on my website with only a publishable key?
No. Publishable keys are designed for front-end payment flows and cannot read account data such as balance transactions or subscriptions. Reading revenue requires a server-side restricted or secret key, which must never be placed in browser code.
Does the RevenueBug embed update automatically?
The image embed copied from the dashboard is a card generated from your public data. It is not an interactive widget, so treat it as a recent snapshot rather than a real-time feed. Your public profile always shows the latest imported data.
Can I show revenue without revealing which product it belongs to?
Yes. Anonymous mode on your public profile hides the product name, domain, description, and logo while keeping revenue visible. It is not available for startups marked for sale, because buyers need to know what they are evaluating.
Is the revenue shown on RevenueBug the same as MRR?
Not necessarily. RevenueBug's headline is trailing 30-day revenue: successful payments minus refunds and disputes, before provider fees. It can include annual prepayments and one-time sales, so it may differ from subscription MRR.