Stripe Can Now Share a Customer's Card Across All Your Stripe Accounts. You Can't Turn It Back Off Yourself.

Run more than one Stripe account — one per region, one per brand, one you inherited when you acquired somebody else's product — and you've almost certainly rebuilt the same customer twice. They sign up under your US entity, then six months later a different part of the business tries to bill them through a different account, and as far as that account is concerned, this person has never paid you a dollar. They re-enter their card. Sometimes they don't, and what looks like a payment failure in your dunning report was never really a payment failure at all — it was a customer who got asked to do something they'd already done somewhere else. Stripe shipped a fix for this in September: Organizations can now share customers and their saved cards across every account in a sharing group, automatically, with no custom integration required.

That limit is worth sitting with before anything else, because it's the kind of detail that decides whether this feature quietly fixes your dunning stack or quietly adds a new way for it to fail. If your Organization has five accounts in a sharing group and a returning customer's most recently used card was attached on the sixth, a naive integration that just calls "list payment methods" and charges the first result may never see it. This is a genuinely useful feature. It's also not the kind of thing you turn on and stop thinking about.

What actually shipped, and where it stops

Stripe's own use-case list for Organizations names four reasons companies end up running multiple accounts: global expansion into a country with better local acquiring, separate business units that need isolated finances, franchise networks managed centrally, and company acquisitions. Sharing is built for exactly those situations — a customer who touches more than one of your own accounts shouldn't have to prove who they are financially every single time. Enable sharing for a group of accounts and any customer created on one of them gets mirrored to the rest within a few seconds, all instances carrying the same customer ID. Attach a card to that customer anywhere in the group, and every other account can charge it, update it, or detach it too.

Card sharing — including cards behind Apple Pay, Google Pay, and Link — reached general availability with this release. Everything else is earlier stage:

The specific churn problem this fixes — and the one it doesn't

We've written before about what happens when a customer's payment identity moves between two different legal sellers, in the context of Stripe Managed Payments. Switching to a merchant of record changes who the card network thinks it authorized, and saved tokens don't carry over — customers have to re-verify, and that mass re-authentication event is where involuntary churn spikes. Organizations sharing is a different situation entirely: every account in the group is still legally you. That's precisely why Stripe can automate it, and it's the fastest of the three paths a customer's card has for moving between two of your Stripe accounts.

The acquisition use case is where this matters most, and it's worth reading alongside our piece on acquisition churn. That post is about the behavioral risk — customers getting nervous when the company behind their subscription changes hands, independent of anything technical. This is the technical layer underneath it. If the acquiring company brings the acquired product's Stripe account into a sharing group instead of migrating it onto a new merchant relationship, an acquired customer's card keeps working the moment the accounts are linked — no re-entry, no dunning cycle, no payment failure that has nothing to do with whether they trust the new owner. It doesn't fix the trust problem. It does remove one very concrete reason customers who were otherwise fine end up in your involuntary churn numbers during exactly the window when your acquisition-churn risk is already highest.

What doesn't come along for the ride

Sharing a customer doesn't mean sharing everything about them. Stripe splits customer fields into two groups, and the split isn't arbitrary — it's drawn around what's safe to treat as universal versus what's proprietary to a single account's relationship with that customer.

Twelve of those sixteen fields — name, email, address, phone, description, tax ID, metadata, business name, shipping, tax exemption status, invoice prefix, and preferred locales — sync the moment any account in the group updates them. The four that stay local are the ones that matter operationally: invoice_settings.default_payment_method, account balance, any active discount, and default_source. A shared customer arriving on a new account has their card visible and chargeable, but nothing marked as the default. If your billing logic assumes a synced customer already has a default payment method the way it would on the account where they originally signed up, the first invoice you try to generate on the new account can fail for a reason your own integration created — and it'll land in the same failed-payment bucket as a genuinely declined card, muddying your dunning numbers for a cause that has nothing to do with the customer's bank.

The parts that don't behave the way you'd assume

Three details in Stripe's own documentation are easy to miss and expensive to discover after the fact.

It's all-or-nothing. You can't configure sharing to cover only certain customers or certain payment methods — turn it on for a group of accounts and every eligible customer and card in that group becomes shared, immediately. There's no staged rollout inside a single group; the staging has to happen at the account level, by deciding which accounts join the group and when.

You can't turn it back off yourself. Stripe's documentation is direct about this: once an account is enrolled in sharing, disabling it requires contacting Stripe support to have the account removed. This isn't a Dashboard toggle you can flip experimentally in a sandbox and revert if it doesn't work the way you expected in production — well, you can in a sandbox, but the live decision is meant to be permanent from your side of the relationship.

Consent is on you, not Stripe. Stripe requires that customers consent to having their data and payment methods shared across your accounts and legal entities before you enable it, and collecting that consent is explicitly the merchant's job. If your accounts span different legal entities — which is exactly the scenario sharing is built for — that consent requirement is doing real compliance work, not just covering Stripe legally. It's worth building the same way you'd build any other consent gate tied to a customer-facing action, logged and timestamped, not a line in a terms-of-service update nobody reads.

Two more edge cases are worth knowing before you flip the switch: Stripe only fires payment_method.attached events for the account that actually created the attachment, so if your dunning or fraud tooling only listens to webhooks on its own account, it will never see a card get attached on a sibling account — Stripe recommends an organization-level webhook endpoint for exactly this reason. And charges made against a shared customer post to the Transactions page of whichever account processed them, not to some consolidated "owning" account — your MRR and retention reporting across the group still needs an Organization-level Sigma query or Data Pipeline export to reconcile. Sharing solves customer and card portability. It doesn't solve consolidated revenue reporting, and treating it as though it does is how a customer who genuinely churned from your platform business but stayed active on your enterprise business quietly disappears from both dashboards' view.

Before you turn this on

• Set a default payment method explicitly on every account after sync — don't assume a shared card becomes the default anywhere but the account that originally attached it.
• Build the consent capture before the sharing group, not after — retrofitting consent onto customers you've already shared is a much worse conversation than asking first.
• Subscribe to payment method events at the organization level, not per-account, or your fraud and dunning tooling will have blind spots on every account except the one it's directly attached to.
• Don't rely on "most recently attached" if your group has more than five accounts — the payment-methods list endpoint caps at the requesting account plus four others, so an older card on a sixth account can go permanently invisible to a simple integration.
• Check whether Card Account Updater fees change your accounting — updater fees for a shared card are billed to the account that originally created it, not the account that's currently charging it, which is a detail finance will want to know about before the first invoice, not after.

None of this is a reason to skip the feature — for a company running multiple Stripe accounts by necessity, removing a re-entry step that used to cost a percentage of failed first charges on every account switch is a real involuntary-churn win, and it's worth modeling with our churn calculator against however many customers cross accounts in a typical year. It's a reason to treat the rollout with the same care you'd give any other change to how a customer's payment identity moves through your systems. And whichever account a shared customer ends up transacting through, they still deserve a real reason to stay and a real way to leave if they don't — a portable card doesn't do anything for the customer who's simply done with the product, which is exactly the moment CancelFlow is built to handle.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.