Stripe for Multiple Businesses: One Account or Ten, and What That Choice Costs Later

Ten domains, ten small businesses, one repository. When I got to the payments layer of that build, I hit a question that has no good answer published anywhere: does each site get its own Stripe account, or do all ten share one?

The advice that exists is written for a different reader. It shows you where the "New account" button is, lists four reasons separate accounts are nice to have, and stops. What it never covers is what the choice does to your code six months later, which is the only part of the decision that actually costs you anything.

So here is that part. This is the question as it looks from inside a codebase that serves ten domains, and what each branch of it charges you.

Can you use one Stripe account for multiple businesses?

Sometimes, and the line is not a matter of taste. Stripe states it plainly in its guidance on multiple separate accounts: you must use separate accounts for projects, websites, or businesses that operate independently from one another, and each account can only be associated with the tax ID and legal entity of one business.

That gives you a test that has nothing to do with engineering:

• Different legal entities or different tax IDs, and the decision is already made for you. Split them.

• One legal entity with several product lines under it, and you are allowed either shape. Now it is a real choice.

I am a builder, not your accountant. Whether ten small sites should sit under one entity or ten is a question for the person who signs your tax return. What I can tell you is what happens after that question is settled, because that is where I lost time.

There is a second forcing function that is easy to miss. Stripe warns that using one account for separate businesses means both share the same public business information, so a customer who buys from one brand can see a charge from the other brand on their statement. That is not cosmetic. An unrecognised descriptor is one of the most common reasons a perfectly legitimate charge turns into a dispute, and a dispute costs you the fee whether you win it or lose it.

The rule of thumb I settled on: if a customer would not recognise the name on their card statement, that site needs its own account.

What separate Stripe accounts actually change in your code

Here is the part the guides skip.

A Stripe account is not just a dashboard. It is a secret key, a publishable key, its own product catalogue, its own price identifiers, its own webhook endpoints, and its own signing secrets. Every one of those is a value your application has to hold and route correctly.

With one account serving ten sites, your application has one secret key and one catalogue. That is simple to hold, and the complexity moves into telling ten sites apart inside a shared set of records.

With ten accounts, your application has ten of everything. The complexity moves into configuration, and configuration is exactly the layer that does not travel with your code. I wrote about that failure mode in more detail in the six things that do not travel with your code, and payments is where it bites hardest, because a missing key does not throw at build time. It throws at checkout, in front of a customer holding a card.

The shape I use in the domain monorepo is the same shape I use for everything else that varies per site: a manifest. Each site entry names which Stripe account it belongs to, and the environment supplies the keys under names that include the site slug. The application never guesses. It reads the site it is serving, looks up the account, and loads the matching keys. This is the same per-site versus shared split I described in how to manage multiple websites from one codebase, applied to money instead of markup.

One rule saves you most of the pain: never let request-time code pick a Stripe key by branching on a hostname. Resolve it once from the manifest at startup and fail loudly if it is missing.

Where multi-site Stripe setups actually break: webhooks

Every other part of this is bookkeeping. Webhooks are where I actually lost a weekend, and they are the reason I am writing this instead of another dashboard walkthrough.

The redirect that quietly kills your webhook

If you run a portfolio of domains, you almost certainly have redirects. Apex to www, or www to apex, applied as a blanket rule at the DNS or hosting layer because that is the sane thing to do for humans and for search engines.

Stripe does not follow them. Its webhook documentation is explicit that a redirect response to a webhook request counts as a failure, and that the fix is to register the URL the redirect resolves to rather than the one you would type. So if your endpoint is registered on the apex and your host bounces everything to www, every event fails, and it fails in a way that looks like nothing at all. The payment succeeds. The customer is charged. Your fulfilment never runs.

Multiply that by ten domains where the redirect direction was set once per site, months apart, by an automated setup script. That is the whole bug. It took me longer than I want to admit, because I was reading my own handler code, and the request was never arriving in the first place.

Register every webhook endpoint at the exact URL that answers with a 200, not the pretty one.

The event destination limit nobody mentions

Stripe caps you at 16 event destinations per account. That number never comes up in the arguments about one account versus many, and it changes the maths.

Ten sites on one shared account means ten of your sixteen slots are gone before you have added a single other integration, and that is before you account for test mode and live mode being configured separately. Ten separate accounts means sixteen slots each, which sounds generous right up until you are managing sixteen times ten of anything.

There is a middle path that most people building a portfolio never find: one endpoint, ten sites, with the site identity carried in the session metadata rather than in the URL. You attach the site slug when you create the checkout session, and one handler reads it back off the event. You pay for that with a slightly smarter handler, and you get back nine endpoint slots, nine signing secrets you do not have to store, and one place to look when something breaks.

Signing secrets multiply faster than the accounts do

Each endpoint gets its own signing secret, and test mode and live mode produce different secrets for the same endpoint. So ten sites, each with its own endpoint, in two modes, is twenty secrets before you have shipped anything.

Two details are worth having in your head before you need them. When you roll a signing secret, you can keep the previous one alive for up to 24 hours so you have a window to deploy the new value, and during that window Stripe signs each event with both. And the official libraries reject events whose timestamp is more than five minutes old by default, which means a server with a drifting clock produces signature failures that look exactly like a wrong secret.

The parts of this that only hurt later

Three things do not hurt on day one and hurt a great deal on day two hundred.

Catalogue drift. Price identifiers are per account. Ten accounts means ten catalogues, and the moment you change a price you are changing it in ten places. If you go this route, generate the catalogue from a single source of truth in your repository and push it, rather than clicking through ten dashboards and hoping they match.

Replay windows. Stripe retries a failed delivery for up to three days with exponential backoff. You can manually resend an event from the dashboard for up to 15 days after it was created, and from the command line tool for up to 30. Those numbers are your actual recovery budget when something has been quietly broken. Past 30 days, reconciliation stops being a resend and starts being a spreadsheet.

Event ordering. Stripe does not guarantee that events arrive in the order they were generated. A new subscription can deliver its invoice paid event before its subscription created event. If your handler assumes an order, it works in testing and fails in production, and it fails on real customers rather than on your test card.

If you are running several accounts and you want one place to read the numbers, Stripe's Organizations feature is built for exactly that: a consolidated view across accounts, unified reports across currencies, and centralised team management. It solves the reporting half of the split. It does not solve the code half, which stays yours.

How I actually decided for ten domains

I did not split all ten. I grouped them.

Sites that share a legal entity, share a brand family, and would produce a card statement a customer recognises sit together on one account, separated by metadata. Sites that are genuinely their own business, with their own name on the statement and their own payout destination, get their own account.

That left me with a small number of accounts rather than one or ten, which is the answer neither side of the argument offers. The deciding question was never technical. It was whether a customer would recognise the charge, and whether the money needed to land somewhere different.

If you want the rest of that build, the money side is in how to monetize a domain portfolio, which covers what the ten businesses actually sell rather than how they collect for it.

I am walking through the whole system live on Saturday, August 22 at 10:00 AM Eastern, payments layer included, in Domain Factory: One Repo, 10 Sites, 10 Stripe Businesses. The session ships the monorepo, the three business skeletons, the manifest, the daily publishing and indexing routines, and a 16-step launch checklist, and I help attendees launch their first site on the call.

The order I would do it in

If you are at the start of this, here is the sequence that would have saved me the weekend:

1. Settle the entity question with your accountant first. It removes the choice in most cases.

2. Say the brand name out loud as it will appear on a card statement. If it does not match the site, that site needs its own account.

3. Decide on one webhook endpoint with metadata, or one endpoint per site, before you build either. Retrofitting is the expensive direction.

4. Register every endpoint at the URL that answers directly, and confirm it returns a 200 rather than a redirect.

5. Put the account mapping in a manifest in your repository, and the keys in your host's environment settings, named per site.

6. Send one real payment through every site before you announce any of them.

Step six is not padding. A live charge on a real card is the only test that exercises the key, the endpoint, the redirect, the signature and the handler all at once.

Get the whole system, not just the payments layer

The payments decision is one layer of a build that also has to handle deploys, DNS, content and indexing across every site. All of it, plus the live sessions where I build these in front of you and the vault of apps, tools and agents that come with them, is inside the Reinventing AI Accelerator. Members get the full project files from every session, including this one. If you are building more than one thing at a time, that is who it is for.

Frequently asked questions

Can I use the same Stripe account for two websites?

Yes, if both sites are the same business under the same legal entity and tax ID. Stripe requires separate accounts for projects, websites or businesses that operate independently of one another. The practical test is the card statement: if a customer who bought from one site would not recognise the business name that appears on their statement, you are inviting disputes and you should split.

Do I need a separate company for each Stripe account?

Not necessarily. Stripe's requirement is that each account maps to one tax ID and legal entity, which means several accounts can sit under a single entity, but one account cannot span two entities. Whether you should form separate entities is a legal and tax question for a professional, not something to decide from a blog post.

How many Stripe accounts can one person have?

Stripe does not publish a hard cap on accounts per login, and you can create additional accounts from the account switcher and hold them all under one email address. What is capped is event destinations, at 16 per account, and that limit matters far more than the account count when you are wiring up a portfolio.

Can I move customers or subscriptions between Stripe accounts?

Not on your own. Payment method data moves only through a Stripe-run migration process, and existing subscriptions do not simply transfer across. This is the strongest argument for thinking about the split before you have paying customers rather than after, because the cost of changing your mind is measured in customer emails rather than in commits.

Should I use Stripe Connect instead of multiple accounts?

Connect is built for platforms that pay out to other people's businesses, such as a marketplace or a franchise network. If every site is yours, Connect adds an onboarding and payout layer you do not need. Multiple accounts, or one account with metadata, is the right shape for a portfolio you own outright.