By: Money Navigator Research Team
Last Reviewed: 18/01/2026

FACT CHECKED
Quick Summary
In many cases, card processors can update where payouts are sent even if your current bank account is under restriction or heading for closure – but the change can be delayed or blocked by verification checks, processor-side limitations/holds, or because payouts are already “in flight”.
A successful switch depends on:
- (1) whether the processor can approve new payout details and
- (2) whether the new account can actually receive credits (and handle reversals/chargebacks where relevant)
This article is educational and not financial advice.
What “switching payouts” actually means
When people say “switch payouts”, they usually mean changing the bank account details held by the payment processor/acquirer (not changing anything at the bank that is closing or restricted).
It helps to separate three moving parts:
Your bank account status (restricted, frozen, closing, or closed). If you’re unsure of the terminology, see the difference between a frozen and a closed business bank account.
Your processor account status (normal, under review, limited, reserve increased, payouts paused).
The payout pipeline (scheduled payout > submitted to banking rails > credited, rejected, or returned).
Switching payout details changes the destination for future payouts, but it doesn’t automatically override holds, reserves, or disputes that exist at the processor level.
Can you change payout bank details during restriction or closure?
If the bank account is closing (notice given) but still operating
Often, yes – because the processor can typically store new payout details while the old account still exists. The timing still matters because payouts already queued may go to the old account.
Most processors publish operational guidance on updating payout accounts, and the flow commonly includes extra checks (sometimes including manual review):
Stripe explains that you can add or update bank account details from payout settings in the dashboard, and that bank details requirements vary by country and currency. See Stripe’s payouts documentation.
PayPal describes linking a bank account through “Wallet”, including instant linking via bank login or adding details manually. See PayPal’s UK help on linking a bank account.
Adyen outlines adding/editing payout accounts, including scenarios where edits can be routed for approval and review timelines. See Adyen’s guidance on managing payout account details.
Square describes linking/editing a bank account and notes verification steps and email confirmation. See Square’s support article on linking and editing bank accounts.
If the bank account is restricted/frozen
A switch may still be possible at the processor, but it may not solve the practical problem if:
the processor has also restricted payouts (common where risk/verification is unresolved), or
the restriction at the bank prevents incoming credits or causes funds to be returned.
If your processor is holding funds due to restriction dynamics, these two guides are relevant context: why payment processors hold payouts during account restrictions and can a bank freeze trigger higher processor reserves or payout delays.
If the bank account is already closed
Changing payout details can still be possible, but anything already routed to the closed account may be rejected/returned by the banking system. What happens next depends on the processor’s retry logic and whether a new payout account is already verified.
Stripe’s documentation indicates that if a payout sent to an external bank account fails, the account status can move to an error state and scheduled payouts may stop until bank details are updated. See Stripe’s external bank account object reference.
For the “what happens to incoming payments” angle once an account is closed, see what happens to incoming payments when a business account is closed.
The checks that most commonly block or delay a switch
Processors vary, but these are recurring friction points:
Name and ownership matching
PayPal lists name matching as one reason linking a bank account can fail (the bank account name needs to match the PayPal account name). See PayPal: reasons you can’t link a bank account.
This matters in closure scenarios because businesses sometimes try to route funds to an account in a different name (for example, a director’s personal account). Even if a processor technically supports it for some setups, name mismatch rules can prevent linking or trigger manual review.
Related internal context: personal vs business account differences.
Country/currency constraints
- PayPal notes country alignment as a potential limitation for linking banks. See PayPal: reasons you can’t link a bank account.
- Stripe notes currency and payout settings alignment, and that required bank details vary by location. See Stripe’s payouts documentation.
In practice, this can be relevant if your new bank account is set up differently (for example, different currency settlement arrangements).
Verification and confirmation steps
Square describes verification steps and confirmation windows (including confirming changes via email). See Square’s bank account linking guidance.
Those steps can slow down a “same-day” switch during an active closure window.
Processor-side holds, reserves, and negative balances
Even if payout details can be changed, payouts may still be paused while the processor resolves risk exposure – often tied to refunds/chargebacks and rolling reserves.
If you’re trying to understand why processors increase reserves during disruption, see rolling reserves explained and Stripe/PayPal holds during a business account freeze.
Requirements to support reversals/chargebacks
Some providers require the linked account to support money movement in both directions (not just credits). Square, for example, states that it requires a current bank account to support refunds or chargebacks. See Square’s bank account linking guidance.
This matters because a “receiving-only” destination can create operational problems when disputes arise.
For deeper context, see chargebacks when a business account is frozen and can a bank close an account while chargebacks are open.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Bank gives closure notice, account still open | Processor may accept new payout details | Transition period where some payouts still hit the old account |
| Bank account restricted but not closed | Processor may accept change, but bank/processor restrictions can still disrupt deposits | Payouts may be delayed, returned, or paused despite updated details |
| Account closed and processor still paying out | Payouts sent to old details may bounce/return | Reconciliation burden; payouts may reattempt only after details are updated/verified |
| Processor account under limitation/hold | Bank detail change may be allowed, but payouts remain paused | Switching destination doesn’t bypass processor risk controls |
| Active chargebacks/refund exposure | Processor may increase reserve or delay payouts | Cash-flow timing changes; funds may be held longer |
| Name mismatch between business and new account | Linking new account may fail | Switch blocked until acceptable ownership/verification is provided |
What happens to payouts already “in flight”?
A common misconception is that changing bank details re-routes every pending payout. In reality, processors often treat payouts in stages:
Not yet initiated/scheduled: these are the easiest to redirect to a newly added account (once approved/verified).
Initiated/submitted to banking rails: these may still go to the original destination, even if you update details immediately afterwards.
Rejected/returned: if the old bank account is closed or cannot accept the credit, the payment may be returned, and the processor’s next step depends on internal rules.
Stripe’s documentation indicates that if a payout to an external bank account fails, scheduled payouts can stop until the bank details are updated. See Stripe’s external bank account object reference.
If you’re dealing with broader “in-process payments”, also see outgoing payments if an account is closed mid-processing.
Restrictions, safeguarding, and FSCS cover: where people get tripped up
Some businesses assume that because a processor is FCA-regulated, it has the same protection as a bank deposit. That’s not how the UK regime is framed.
FSCS explains that it protects money held with banks/building societies/credit unions (subject to eligibility rules) and that it does not protect money held with e-money institutions and payment providers, even though such firms are regulated by the FCA. See FSCS: e-money and FSCS protection.
The Bank of England (PRA) discusses depositor protection proposals intended to protect eligible customers of e-money/payment institutions if the credit institution holding safeguarded funds fails (a “look-through” style outcome in that specific scenario). See Bank of England (PRA): depositor protection and safeguarded funds.
This is one reason processors may be cautious about changing payout destinations during disruption: they’re managing both operational risk and regulatory expectations around safeguarding and controls.
The FCA’s policy statement on strengthening safeguarding for payments and e-money firms also underlines the direction of travel, including an implementation date for parts of the regime. See FCA PS25/12 overview page.
If you want the deposit-style angle for business bank balances (as distinct from processor-held funds), see is money in a business bank account protected by FSCS.
Scenario Table
| Scenario-level (what’s happening) | Process-level (what changes behind the scenes) | Outcome-level (what you typically see) |
|---|---|---|
| Closure notice received | Processor attempts to verify and activate new payout account | New account appears as “active/verified” after checks; some payouts still land in the old account if already queued |
| Bank restriction applied | Incoming credits may be blocked/returned; processor risk review may trigger | Payout timing becomes uncertain; deposits can fail even after account change |
| Processor imposes limitation | Payouts are paused while requirements/verification are completed | Bank detail edits may be accepted, but no payout release until limitation ends |
| High dispute/refund exposure | Reserve/hold settings can change and payout cadence may be adjusted | Payouts reduce, slow, or become irregular even with a new destination |
| Account closed unexpectedly | Credits to old account bounce back; processor may mark payout as failed | Payouts may stop until a verified destination exists and internal retries are satisfied |
| New destination is different legal owner | Linking fails or triggers manual review | Switch delayed/blocked until ownership/identity evidence matches processor rules |
Compare Business Bank Accounts
When payout routing is disrupted, the operational constraint is often not the card terminal or online checkout – it’s the ability to receive and reconcile funds reliably, including handling reversals. Some businesses therefore maintain more than one banking relationship to reduce dependency on a single account for operational receipts.
If you’re mapping options (without changing your current setup), our business bank accounts hub summarises common features that matter in disruption scenarios (for example: multi-user access, inbound/outbound payment controls, account verification, and how quickly an account can be opened).
This section is informational only; product suitability depends on your circumstances.
Frequently Asked Questions
Sometimes, but “immediately” is not guaranteed because processors often require the new account to pass verification or approval steps before it becomes the live payout destination.
Documentation from multiple providers shows that changing payout accounts can involve verification flows and, in some cases, manual review.
There can also be a timing gap between “new account accepted” and “all payouts redirected”. If a payout was already initiated before the change, it may still be sent to the old account and only fail later if the bank rejects it.
Some processors and banks may allow this in limited circumstances, but it often fails in practice because name/ownership matching is a common control. PayPal, for example, lists name matching as a factor in bank-linking outcomes.
Even where a processor can technically pay out to an account in a different name, it can create downstream complications for reconciliation, tax/accounting records, and dispute handling. See personal vs business account differences for context.
A processor limitation can override bank-detail changes. In other words, you may be able to enter new payout details, but payouts can remain paused until the limitation is resolved.
This is consistent with how payout controls are described across providers: payout account updates are one capability; releasing funds is another, often controlled by risk/compliance processes.
It can. Many providers treat a payout-account change as a risk-sensitive event because it affects where funds are delivered. Square, for example, describes verification and confirmation steps, and Adyen describes approval flows for certain edits.
Extra checks are also more common where there has been recent unusual activity, rapid growth, high dispute levels, or prior verification gaps.
It depends on how far along the payout is. If it’s not initiated, it may go to the new account once verified. If it’s already in transit, it may still go to the old account.
Stripe’s documentation indicates that a failed payout to an external bank account can result in scheduled payouts stopping until bank details are updated, which is one mechanism that can show up as “everything suddenly paused” after a failed deposit.
Some processors support multiple payout accounts in certain configurations, while others run a single primary destination per currency. Where multiple accounts exist, there can still be restrictions on how payouts are allocated (for example, by currency, entity, or location).
Even when multiple accounts are supported, the practical constraint is often verification and the processor’s risk position – not simply the presence of a second account number.
Not always automatically, because “restriction” can cover different controls (inbound blocked, outbound blocked, partial holds, or full freezes). Some restrictions primarily stop outward payments, while others prevent credits from being applied.
That’s why the first diagnostic step is to clarify what kind of restriction exists (and whether the account can receive credits), then consider whether changing the processor payout destination changes the outcome at all.
Potentially, yes – because chargebacks/refunds can be handled through multiple mechanisms (netting against future payouts, reserves, or debiting the linked account depending on the provider and product).
Square explicitly notes the need for an account that supports refunds/chargebacks, which signals that reversals are a core operational requirement for some setups.
If there are ongoing disputes, this guide is relevant: can a bank close an account while disputes/chargebacks are open.
FSCS states that it cannot protect money held with e-money institutions and payment providers, even though those firms are regulated by the FCA. See FSCS: e-money and FSCS protection.
Separately, depositor protection can apply in specific safeguarding-bank failure scenarios (where safeguarded funds are placed with a PRA-authorised bank), which the Bank of England (PRA) discusses in its depositor protection materials. See Bank of England (PRA): depositor protection and safeguarded funds.
Yes, a complaint route can exist, but it’s separate from the operational question of receiving funds tomorrow. The Financial Ombudsman Service explains how it approaches complaints about bank account closures, including expectations around notice and fairness. See FOS: bank account closures (business guidance).
A complaint process can run in parallel with operational changes, but it typically doesn’t force a processor to release payouts or remove a risk hold, and it doesn’t guarantee that a bank will keep an account open.
The hidden mechanism in “switch payouts during closure” is that there are two separate gates:
The bank gate: can the destination account receive credits (and, where required, support debits/reversals)?
The processor gate: will the processor release funds to any external account right now, given its verification status, dispute exposure, reserves, and compliance controls?
A payout switch can solve the bank gate while leaving the processor gate unchanged. That’s why a closure/restriction event often coincides with seemingly unrelated processor behaviour (new reserves, delayed settlements, additional verification). The payout destination is only one variable in the system.
Sources & References
FCA PS25/12 overview: changes to safeguarding for payments and e-money firms
Stripe documentation: receive payouts and update bank accounts
Stripe API reference: external bank account object and payout failure behaviour
Financial Ombudsman Service: how complaints about bank account closures are approached
Bank of England (PRA): depositor protection and safeguarded funds
