How do I switch a BRM store to a new Stripe account without disrupting live bookings?

If you're moving a store to a different Stripe account — selling the business, splitting a multi-store group into separate Stripe accounts, or switching to a new organisation entirely — there are three ways to make the move, and one part almost everyone misses: the Stripe webhook BRM registered for the old account doesn't travel with you. It has to be re-created against the new one, or payment confirmations can silently stop reaching BRM.

The three ways to move to a new Stripe account

The first two are handled by Stripe Support and requested by the current Stripe account owner. The third is done entirely inside BRM.

1. Transfer ownership of the existing Stripe account. Stripe moves the same account to a new legal owner. This is the cleanest option — full payment and customer history stays intact in both BRM and Stripe, because the account itself (and its API keys) doesn't change. You do not need to change anything in BRM's Stripe settings for this route — no new keys, no webhook to re-register.
2. Copy the existing account's data to a brand-new Stripe account, with each customer keeping their own Stripe customer ID. This keeps full history inside BRM, but the new Stripe account's own dashboard won't show the old transaction history. Because this is a genuinely new Stripe account, the API keys in BRM must be updated, and so must the webhook (see below).
3. Start a new BRM store from a clone, without existing customers, and manually bring across reservations and customers you still need. This is the most disruptive option and isn't recommended mid-season. It also means a new Stripe account, so the same key and webhook changes apply as above.

What changes in BRM

For routes 2 and 3, once the new Stripe account exists, go to Settings > Payment Management > Online Payment Method and paste in the new account's Publishable key and Secret key, then save. See Setting up Stripe for where to find these in your Stripe dashboard if you haven't done this before.

Saving new keys only updates the keys — it does not touch the Stripe webhook BRM already has registered. That's a separate step, and it's easy to miss because nothing prompts you to do it.

The webhook has to be re-registered too

When Stripe was first connected to your store, BRM automatically registered a dedicated webhook endpoint with that Stripe account, and Stripe issued a matching signing secret that BRM stores against your store. This webhook is what tells BRM "this payment succeeded" — without it, online bookings can sit unpaid or get auto-cancelled even though the customer was charged (this is covered in more depth in Troubleshooting Stripe Webhook Issues for Online Bookings).

That webhook and its signing secret belong to the old Stripe account. A new Stripe account has no knowledge of it, and BRM doesn't automatically create a fresh one just because you changed the keys. Until you re-register it, one of two things happens: BRM either keeps signing/verifying against a secret that no longer matches anything Stripe is sending, or (for routes 2/3, where a new webhook simply doesn't exist yet against the new account) BRM never hears back from Stripe about payments at all.

On the same Payment Management page, look for the Stripe webhook status:

• "Stripe Webhooks setup" — a webhook is registered and matches what's in Stripe.
• "Stripe Webhooks need repairing" — BRM has a webhook on record but it can't be found under the currently configured Stripe account. This is exactly the state you'll typically see right after saving new keys for a different account.
• "Stripe Webhooks not setup" — nothing registered yet.

If it shows as needing repair or already set up from the old account, use Delete Webhooks to clear the old record first, then Set up Stripe webhooks (or Repair) to register a fresh one — this issues a brand-new signing secret tied to the new Stripe account. Do this after the new keys are saved.

Avoiding disruption to live bookings mid-switch

The keys themselves swap over immediately — the next payment BRM processes after you save will use whichever key is currently saved, live or otherwise. The risk isn't the key swap itself; it's the gap it creates for anything already in flight:

• A payment or checkout that was started under the old account but doesn't complete until after you've re-registered the webhook will have its confirmation arrive signed with the old account's secret — but BRM will by then be checking against the new one. That confirmation fails and the booking never gets marked paid, even though the customer was charged.
• Pick a quiet window to do the switch — outside opening hours if you can, or at least when no online booking checkouts are likely to be mid-way through. Before you delete the old webhook and register the new one, check your (old) Stripe dashboard for any payments or checkout sessions still pending, and let them clear first.
• If you're moving several stores to individual Stripe accounts, do them one store at a time rather than all at once — each store's keys and webhook are entirely independent, so there's no need to take every store's payments offline together.
• Once the new webhook is registered, place one small real booking/payment to confirm the charge goes through and the reservation gets marked paid, rather than assuming it from the "setup" status alone.

Should I test in Stripe's test mode first?

BRM does support Stripe test-mode keys — you can put a test Publishable/Secret key pair (from the new Stripe account, in Test mode) into the same Settings > Payment Management fields used for live keys. But a store only has one active key pair at a time. Switching a live store to test keys doesn't open a sandbox alongside live traffic — it takes that store's live payment processing offline for as long as the test keys are in place, because every payment request uses whichever key is currently saved.

There's also a known knock-on effect: any customer who saves a card while the store is in test mode gets a test-mode card token. If you switch back to live keys afterwards and try to charge that same customer, it fails with an error to the effect of "your request was in test mode, but used a non-test (live) card" — see Troubleshooting - you can't mix live and test customers on Stripe. The customer needs a fresh card added before a live charge will go through.

So a "test pass" against the new Stripe account only makes sense as a genuine offline exercise — during a maintenance window, or on a store that isn't yet taking live bookings — not as something that quietly runs in parallel with live traffic on the same store. If the store is live and you want confidence before committing, the safer route is to do the real key-and-webhook switch in a quiet window (as above) and place a real, small live booking straight afterwards to confirm it.

Suggested order of operations

1. Agree the move with Stripe Support (transfer of ownership) or have the new Stripe account and its live API keys ready (copy-data or clean-slate routes).
2. For transfer of ownership: nothing further needed in BRM.
3. For a new Stripe account: pick a quiet window, and check the old Stripe dashboard for anything still pending before you touch BRM.
4. In BRM, go to Settings > Payment Management > Online Payment Method. If a webhook already shows as set up, delete it.
5. Paste in the new account's Publishable key and Secret key, and save.
6. Set up Stripe webhooks again (or Repair, if BRM shows it as needing repair) so BRM registers a fresh webhook against the new account and picks up its new signing secret.
7. Place one small real booking/payment to confirm the charge and the webhook confirmation both land correctly.
8. Moving multiple stores to separate accounts? Repeat from step 3 for each store, one at a time.