[$250] Bank account - The page automatically redirects to the BA success page when manually connecting new BA

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.38-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83893
Email or phone of affected tester (no customers): biruknew45+6yu@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web
App Component: Workspace Settings

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Enable Expensify Card feature in workspace settings > More features
3. Go to workspace settings > Expensify Card
4. Click Issue new card
5. Click Log into your bank
6. Complete the process of adding a bank account
7. On "You're all set" success page, close the RHP
8. Click Issue new card
9. Click Add a new bank account
10. Click Connect manually > Next
11. Wait a moment on that page

Expected Result:

The page should stay on the same page

Actual Result:

After waiting a moment on the Routing Number and Account Number page, the system automatically redirects to the previously added BA success page.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @MonilBhavsar

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043620548570916144
• Upwork Job ID: 2043620548570916144
• Last Price Increase: 2026-04-13

[harryautomazione]

Hi everyone, here is my proposal to fix this issue:

🔍 Root Cause

In ReimbursementAccountPage.tsx:

1. Asynchronous Data Load: The fetchData() function calls openReimbursementAccountPage(). For a workspace with an existing bank account, the backend responds that the current step is ENABLE (Success).
2. Strict Success Redirect: The effect managing shouldShowConnectedVerifiedBankAccount (around line 275) relies solely on achData?.currentStep === ENABLE or state === OPEN.
   Since this is calculated before displaying sub-components, the ConnectedVerifiedBankAccount (Success Page) is rendered, hijacking display.
3. Step Overwrite: The effect synchronizing step around line 271 overwrites the local step (BankInfo / Country) back with ENABLE.

---

🛠️ Solution

We must prevent navigation to the success page during intermediate setup steps if the user manually started a new connection flow (e.g., coming from Expensify Card flow).

📄 ReimbursementAccountPage.tsx

1. Prevent sync override when inside setup:

   // Around line 271
   if (!isNonUSDSetup && USDBankAccountStep !== null && achData?.currentStep && achData.currentStep !== USDBankAccountStep) {
       // Do not overwrite if we are initiating setup from ExpensifyCard or explicitly pushing a step
       if (!isComingFromExpensifyCard || achData.currentStep === CONST.BANK_ACCOUNT.STEP.ENABLE) {
           setUSDBankAccountStep(achData.currentStep);
       }
   }

2. Block success page render during setup:

   // Around line 275
   const isEnableStep = isNonUSDSetup ? achData?.state === CONST.NON_USD_BANK_ACCOUNT.STATE.OPEN : achData?.currentStep === CONST.BANK_ACCOUNT.STEP.ENABLE;
   
   // Success page shows if it's the right step and we are NOT setting up via expensify card or explicitly driving steps
   const shouldShowSuccess = isEnableStep && (!isComingFromExpensifyCard || USDBankAccountStep === CONST.BANK_ACCOUNT.STEP.ENABLE || USDBankAccountStep === null);
   
   setShouldShowConnectedVerifiedBankAccount(shouldShowSuccess);

---

Let me know if this approach looks good to you! Happy to hear your feedback and coordinate on the fix.

[MelvinBot]

Proposal

What is the root cause of that problem?

The effect at ReimbursementAccountPage.tsx:272 unconditionally sets shouldShowConnectedVerifiedBankAccount = true when achData.currentStep === ENABLE (USD) or achData.state === OPEN (non-USD).

When a user who already has a connected bank account tries to add a new one via the Expensify Card flow, the existing bank account's achData is already loaded in Onyx with currentStep = 'EnableStep'. The mount effect at line 234 skips fetchData() because isPreviousPolicy is true and reimbursementAccount already exists. So the sync effect at line 254-274 fires immediately with the old bank account data and redirects to the success page.

Additionally, removeExistingBankAccountDetails in VerifiedBankAccountFlowEntryPoint.tsx:106-118 only clears draft values and sets bankAccountID: 0 — it does not clear achData.currentStep or achData.state, so the redirect condition remains satisfied.

What changes do you think we should make in order to solve the problem?

In the effect at ReimbursementAccountPage.tsx:272, add a guard that checks whether the user has started a new bank account setup flow. Since removeExistingBankAccountDetails sets bankAccountID to 0 when the user initiates a new connection, we can use achData.bankAccountID === 0 as a signal that a new setup is in progress and skip setting shouldShowConnectedVerifiedBankAccount = true in that case.

This is more robust than gating on isComingFromExpensifyCard alone because it covers any entry point where the user starts a fresh bank account flow (not just the Expensify Card route).

What alternative solutions did you explore?

1. Gate on isComingFromExpensifyCard only (as proposed in the comments): This would fix the specific Expensify Card flow but miss other entry points where a user replaces a bank account. Too narrow.
2. Clear achData.currentStep/achData.state in removeExistingBankAccountDetails: This could work but risks side effects in other parts of the codebase that depend on those fields for rendering decisions. Checking bankAccountID === 0 is a safer, less invasive signal.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Eskalifer1 (External)