One payment account across many stores

The account is the thing you own, not the storefront

When a shop owner tells me they want to add a second brand, a wholesale shop or a mobile app, the first question is almost always the wrong one. They ask how many Stripe or Adyen accounts they will need, as if each shop had to bring its own. The better question is the reverse: how few can you get away with, and where does the law or your accounting force your hand.

That question only makes sense if you own the processor account in the first place. This article is the scale and structure chapter of a longer argument I make in the pillar, own your payment stack. The short version is that the card vault, the saved cards, the customers and the subscriptions live at the processor, not inside any one storefront. So the account is the asset. A storefront is just one of the things that talks to it. Once you see it that way, running several shops from one account, or deliberately splitting them, becomes a design choice you make on purpose, rather than a limit a platform sets for you.

Below I lay out the patterns honestly, including the ones where a single account is genuinely the wrong answer, and the point where paying money out to other people turns a shop into a regulated marketplace with real obligations attached. Every claim about how a processor behaves is footnoted to that processor's own current documentation. The businesses in the examples are invented, and so are their numbers.

One account can stand behind many fronts

Here is the pattern most owners underuse. A single processor account can back several storefronts at once: a main shop, a separate wholesale shop, a second brand, a mobile app, a pop up checkout for an event. They all call the same account's API. They all read and write the same customers. A card a customer saved on the main shop is already on file for the wholesale shop, because the vault is one vault, not one per store.

This is the opposite of the platform island model, where each store you spin up is its own sealed world with its own payments, its own customers and no bridge between them. There, a customer who saved a card on your clothing brand is a stranger to your homeware brand, even though it is the same person and the same business behind both. You pay for that separation in lost conversion every time someone has to type their card in again, and you cannot undo it without a migration.

The mechanics that make one account serve many fronts are ordinary. A saved card belongs to a Customer record in your account. Stripe's Setup Intents API, for example, lets you "save a customer's payment details without an initial payment" so you can "charge them in the future, when they're offline".¹ That Customer and that saved card are not bound to the URL where they were first entered. Any storefront, any app, any back office tool that holds your account's keys can charge them, subject to the authentication rules. If you want the detail on why that portability exists at all, I wrote it up in payments that move with you, and the subscription side in subscriptions you actually own.

The architecture that makes this painless on the shop side is a headless, API first build, where the storefront and the app are just clients of the same commerce core and the same payment account. I set out why that matters for a mobile app in headless and API first Solidus. The payment account is one more shared service behind that core, and every front you add is a thin new client, not a new silo.

A worked example: Harbourline runs three fronts from one account

Harbourline is an invented company in Brighton that sells its own range of sea themed homeware at harbourline.example. Mara runs it. She started with one shop, then added a wholesale shop for interior designers and boutiques at trade.harbourline.example, then an iOS app for repeat buyers. Three fronts, one business, one legal entity.

Because I built all three against one owned processor account, they share everything that matters. A designer who bought a sample through the retail shop and saved her card can log into the trade shop and reorder in one tap, with no card re entry, because that saved card is on file at the account, not at the shop. The app charges the same cards. When Mara looks at a customer, she sees every order across all three fronts, because there is one customer list, not three.

Contrast the road Mara did not take. Had each front been a separate platform store with its own built in payments, she would be running three disconnected customer bases and three vaults, a designer would be three different people depending on where she shopped, and Mara could never move a brand to a new storefront without a card migration. None of that is a law of nature. It is a consequence of who owns the account.

The honest caveat, which I come back to below, is that this only holds while the three fronts really are one business. The moment one of them becomes a separate company, or needs to settle in a different currency, or carries a different risk profile, the calculus changes.

When one account is the wrong answer

I am not selling the idea that everything belongs on one account. Several good reasons push the other way, and ignoring them creates its own mess.

The clearest is legal entity. A processor ties each account to the tax identity and legal entity of exactly one business. Stripe states it plainly: "You must use separate Stripe accounts for projects, websites, or businesses that operate independently from one another," and "You can only associate each account with the tax ID and legal entity of one business".² If your second brand is a separate limited company, it needs its own account. Putting its takings through the first company's account mixes two entities' money and two companies' tax, and no amount of engineering convenience is worth that.

The second is public identity on the customer's statement. The business name and descriptor attached to an account is what shows on a card statement. Stripe warns that "using the same Stripe account for separate businesses can cause confusion as the public business information used is the same for both", so "a customer who purchases from your business XYZ might see a charge from your business ABC on their statement, potentially resulting in a dispute".² If your two brands look nothing alike to a shopper, one shared descriptor invites chargebacks.

The third is currency and settlement, which I cover in its own section below. The fourth is risk and accounting hygiene: if one brand is high risk, or one line of business could attract disputes or a reserve, keeping it on its own account stops a problem in one from freezing the funds of the other. And sometimes the reason is simply clean books. Stripe notes that separating accounts "helps you find payments, create and export reports, and reconcile payouts to your bank account".²

So the rule is not "always one account". It is "one account per real business, and as many fronts on it as you like". Where a difference is cosmetic, share the account. Where the difference is legal, fiscal or a genuine risk boundary, split it.

Separate accounts, sub accounts and an organisation over the top

When you do need more than one account for the same business, you do not have to run them as unrelated logins. Stripe lets one business "operate multiple accounts related to the same business, such as for local acquiring or maintaining separate business lines", and group them under an organisation for centralised reporting and management.² Under one legal entity you may also "use the same tax ID and business information across multiple accounts".² So you can keep the UK brand and the newly incorporated subsidiary on their own accounts for clean settlement and tax, and still see them in one place.

There is a line worth knowing about here, because it is where this article turns. Stripe says that to "create many new accounts, or provision accounts automatically", while keeping centralised reporting, you should "create a Connect platform instead of using multiple Stripe accounts".² In other words, a handful of accounts for your own entities is ordinary account management. The moment you are creating accounts on behalf of other people and moving money to them, you have crossed into Connect, which is the marketplace model, and that is a different build with a different weight of obligation.

Pattern	What it is	Good for	The cost
One account, many fronts	Several storefronts and apps of one business on one account	Shared customers and saved cards, one source of truth	All fronts share one risk and compliance surface
Separate accounts, one organisation	Several accounts for the same business, grouped for reporting	Distinct entities, currencies or risky lines, kept tidy	More admin, no shared vault across the accounts
Connect platform	You onboard and pay out to third party sellers	Marketplaces, paying vendors or contractors	Know your customer on sellers, payout rules, a bigger build

Paying out to other people changes everything

Everything so far assumes the money is yours. You take a card payment, it settles to your bank account, you decide what to do with it. The instant you need to pay a cut to someone else, a third party seller, a vendor, a contractor, an artist whose work you sell, you are no longer just a shop. You are a marketplace routing other people's money, and the processor treats you very differently.

This is what Stripe calls Connect, its "solution for multi party businesses, such as marketplace or software platforms, to route payments between sellers, customers, and other recipients".³ It is not a Stripe peculiarity. Mollie, to pick one peer, has the same shape: "Mollie Connect lets software platforms and marketplaces offer payments and money management to their merchants", split into Connect for Platforms, "for SaaS businesses where each merchant runs their own payment operation", and Connect for Marketplaces, "for platforms that own the payment".⁴ Adyen, Braintree and the other large processors all have their own version. The point is architectural, not a pitch for one brand: once you pay out to others, you adopt a connected accounts model, whoever your processor is.

Mechanically, the money can move in a few shapes. Stripe's Connect documentation names three charge types.⁵ With a destination charge, "you create a charge on your platform, so the payment appears in your platform's balance", and "a portion of the funds immediately transfers to the connected account's balance", with the remainder, your commission, left behind as a fee.⁵ With separate charges and transfers, you "create charges on your platform and split funds between multiple connected accounts, or hold them when you don't know the specific user at the time of the charge", which is the model for "an ecommerce marketplace that allows a single shopping cart for goods sold by multiple businesses".⁵ With a direct charge, the payment is made directly to the seller's connected account and "funds then transfer from the connected account to Stripe or the platform account as fees".⁵ In each case your cut is an application fee the processor splits out for you.

That is the attractive part, and it is genuinely capable. A single basket can hold items from five sellers, take one payment from the customer, and settle five different amounts to five different accounts minus your commission. But the attractive part is not the part that decides whether you should build it.

What a marketplace actually puts on you

Here is the honest weight. When you pay out to sellers, the processor has to know who those sellers are, and it makes you do the knowing. Stripe is direct about it: before a connected account "can accept payments and send payouts", it must meet "Know Your Customer (KYC) requirements", and "Connect platforms collect the required information from users and provide it to Stripe".⁶ That information "can include information about the legal entity and personal information about the representative of the business, and those who own or control the business", and where keyed data is not enough, "a scan of a valid government issued ID, a proof of address document, or both".⁶ The requirements "vary by account, depending on country, capabilities, business type, business structure, the service agreement type, and the risk level".⁶ At thresholds of time or volume, you may have to collect still more, and Stripe "temporarily pauses charges or payouts if the information isn't provided or verified".⁶

Two things follow that owners routinely miss. First, the compliance does not end when Stripe ticks a box. Stripe says so itself: "Even after Stripe verifies a connected account, platforms still must monitor for and prevent fraud," and "don't rely on Stripe's verification to meet any independent legal KYC or verification requirements".⁶ You carry an ongoing duty to watch your sellers, not a one time checkbox. Mollie frames its side the same way, verifying and onboarding merchants "through Mollie's business verification (KYB)" that merchants "must complete during onboarding".⁴

Second, the money risk reshapes around you. On destination charges and separate charges and transfers, "refunds and chargebacks reduce your platform's balance", and when a customer disputes a payment "your platform balance is automatically debited for the disputed amount and fee", after which you may try to claw it back from the seller by reversing the transfer.⁵ So a seller can vanish with their payout while a chargeback lands on you weeks later. That is a credit risk you did not have when you only sold your own goods.

None of this makes a marketplace a bad idea. It makes it a bigger, regulated build with a different risk profile, and it belongs in a plan with its eyes open, not bolted onto a shop because a split payment looked easy. If all you want is to pay a single supplier their invoice once a month, you almost certainly do not need Connect at all. You need a shop that is yours and a normal bank transfer.

A worked example: Harbourline opens a maker's marketplace

Two years on, Mara wants to sell work by independent coastal makers alongside Harbourline's own range, and pay each maker their share automatically. That is a marketplace, and it changes her build.

I move her onto a Connect style integration on the same processor. Harbourline stays the platform. Each maker becomes a connected account. Before a maker can be paid, Harbourline has to collect and submit that maker's details for verification: the legal entity, the representative, proof of identity where the keyed data does not clear on its own.⁶ A maker who will not provide it cannot be paid out, full stop, because the processor pauses payouts until the information is there.⁶

When a customer buys a £180 basket with a £120 lamp from one maker and a £60 print from another, Harbourline takes the single payment and the processor splits it: £120 less commission to the first maker's account, £60 less commission to the second, Harbourline's cut retained as the application fee.⁵ Good so far. Then a customer disputes the £120 lamp. The disputed amount and fee come off Harbourline's balance, not the maker's, and Mara has to recover it by reversing what she already paid out, if the maker still has a balance to reverse against.⁵ She now needs a float to absorb that timing, and a rule for holding a new maker's first payouts until they have a track record. She also, honestly, needs to accept that she is now carrying an anti fraud duty over people she does not employ.⁶

The upside is real: Harbourline becomes a destination, not just a brand, and keeps its own customers and vault throughout, because this is still her owned account. The cost is equally real: a regulated onboarding flow, identity checks on every maker, payout and dispute exposure, and a build far larger than her shop. Worth it for a marketplace. Absurd for paying one supplier.

Multiple currencies from one account, and where it stops

A single owned account can also sell into several countries and, within limits, settle in several currencies, so you do not need a separate account per market just to show local prices. But there are real edges here, and inventing capabilities you do not have is how people get stranded.

Start with the distinction. The presentment currency is the currency the customer sees and is charged in. The settlement currency is the one your bank account actually receives. By default a processor converts everything into your one home currency. Stripe's multi currency settlement lets you instead "configure your account to accrue balances and get paid out in up to 18 supported currencies", but with a firm condition: "to accrue a balance in a currency, accept payments presented in that currency".⁷ You cannot conjure a euro balance from pound sales. You hold euros only once you actually take euro payments, and to be paid out in euros "you must add a separate supported bank account with the same currency".⁷

There are two more limits worth stating plainly. Multi currency settlement is only available in a defined list of countries, which for Stripe includes AE, AU, CH, EU, GB, HK, LI, NO, SG and US.⁷ And settling into a currency other than your primary one is not free: Stripe "charges the applicable fee when funds settle into a non primary settlement currency".⁷ I will not quote a percentage, because fees change and the SPEC rightly bans invented numbers; I check the processor's live pricing page for every build and so should you.

Then there is which payment methods even exist in each market, which is a separate question from currency. A customer in Austria or Germany expects local methods that a card first checkout does not offer by default, and the availability of each method varies by country. I walk through the DACH set, invoice purchase, SEPA, Klarna, EPS and Twint, in DACH payments in Solidus. The headline for this article is that one owned account can carry many currencies and many local methods across many fronts, up to the processor's country list and method availability, which is far more reach than a per store platform gives you, but it is not unlimited, and the limits are the processor's, not yours to wish away.

The honest tradeoffs

Owning one account across many stores is the position I argue for, so I owe you its downsides stated as plainly as its upsides.

A single account is a single point. One shared account is also one shared risk and compliance surface. A reserve, a freeze or a review triggered by one front's activity touches every front behind that account, because they share a balance. That is the flip side of the shared vault: the convenience and the exposure travel together. The mitigation is exactly the "when to separate" section above. Put a genuinely risky line, or a separate entity, on its own account, and keep the shared account for the fronts that truly belong together.

A marketplace multiplies your duties. The connected accounts model is powerful, but it brings know your customer obligations on your sellers, payout rules, dispute exposure on your own balance and an ongoing anti fraud duty that does not expire.⁶⁵ That is regulatory weight, and it is the right trade only when you are actually running a marketplace, not a convenience you add lightly.

You carry the merchant relationship. Owning the account means the disputes, the reserves and your share of card security are yours to hold, across every front. For most shops that share is the lightest self assessment, because a hosted, tokenised checkout keeps card numbers off your servers, but it is still yours. And because all of this sits on your account rather than a platform's, the question of who holds the customers and the data answers itself in your favour, which is the whole point I make in who actually owns your business data. The migration pain you avoid by owning the account is the pain I catalogue in the hidden dangers of switching payment gateways: the reason to own the account now is to never pay that bill later.

How I decide, and what I ask before building

My rule of thumb is short. Count the real businesses, not the storefronts. One account per legal entity, as many fronts on it as you want, separate accounts only where law, currency, statement identity or genuine risk force it, and a connected accounts model only when you actually pay out to other people. Before I build, I settle these questions with the owner, in writing:

Is each front the same legal entity, or will any become its own company? Separate entities need separate accounts.²
Do any fronts need to settle in a different currency, and is that currency and country supported, with a bank account to receive it?⁷
Will you ever pay money out to third parties? If yes, this is a connected accounts marketplace, with onboarding, identity checks and payout compliance budgeted in.⁶
Which local payment methods does each market need, and are they available on the account?
Where is the risk concentrated, and should a risky line sit on its own account so a reserve on it cannot freeze the rest?

Answer those, and the structure almost draws itself: usually one owned account standing behind every front of the business, deliberately split only where a real boundary runs, and a marketplace build only where you have genuinely become one. That is the freedom of owning the account. The number of accounts becomes a decision you make for your own reasons, not a cage a platform builds around you.

If you are weighing a second brand, a wholesale arm, an app or a marketplace, and you are not sure how many accounts that really needs, bring it to the free workshop and we will map the structure together, honestly, including where one account is the wrong answer. The first two weeks of the work are on me.

Stripe, Save a customer's payment method without making a payment (Setup Intents API), Stripe documentation, 2026, https://docs.stripe.com/payments/save-and-reuse ↩
Stripe, Multiple separate accounts, Stripe documentation, 2026, https://docs.stripe.com/get-started/account/multiple-accounts ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Stripe, Connect (overview of Stripe's solution for multi party businesses), Stripe documentation, 2026, https://docs.stripe.com/connect ↩
Mollie, Mollie Connect: Overview (Connect for Platforms, Connect for Marketplaces and business verification), Mollie developer documentation, 2026, https://docs.mollie.com/connect/overview ↩ ↩²
Stripe, Understand how charges work in a Connect integration (direct, destination, and separate charges and transfers; refunds and disputes), Stripe documentation, 2026, https://docs.stripe.com/connect/charges ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Stripe, Identity verification for connected accounts (KYC requirements, platform responsibilities and ongoing fraud monitoring), Stripe documentation, 2026, https://docs.stripe.com/connect/identity-verification ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰
Stripe, Multi-currency settlement (settlement vs presentment currency, supported countries, and settlement fees), Stripe documentation, 2026, https://docs.stripe.com/payouts/multi-currency-settlement ↩ ↩² ↩³ ↩⁴ ↩⁵