iOS - Expensify card - Swiping back on the successful screen reopens bank account flow

[applause-bot]

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.89-1
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-35253/folder/13176890/41237377/1447302757?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 13 iOS 26.5
App Component: Workspace Settings

Action Performed:

1. Open the app
2. Navigate to the "Expensify Card" page in WS settings
3. Click on "Issue new card"
4. Finish the bank account flow
5. On the successful screen, swipe right to close the RHP

Expected Result:

After a bank account is added successfully, the bank account flow should no longer be accessible. Using the swipe-back gesture should navigate the user to the Expensify Card screen

Actual Result:

Swiping back on the successful screen reopens bank account flow

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166043_1780028630596.ScreenRecording_05-28-2026_22-47-54_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Rizky Gunawan
Bug ID: 7166043

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/dc0c72416595ea830a336a995968b1ca7cd32dc509b6b77909786a4bd6ec72b2

[melvin-bot]

Triggered auto assignment to @Gonals (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

After PR #90302 (merged 2026-05-27), the USD bank account flow uses two RHP screens:

1. REIMBURSEMENT_ACCOUNT — the entry/wrapper screen (route bank-account/new), rendered by ReimbursementAccountPage.tsx.
2. REIMBURSEMENT_ACCOUNT_USD — the step pages (route bank-account/new/us/:page?), rendered by USDVerifiedBankAccountFlowPage.tsx.

When the user taps Issue new card from the Workspace Expensify Card empty state with no eligible bank account, WorkspaceExpensifyCardPageEmptyState.tsx#L71-L76 pushes REIMBURSEMENT_ACCOUNT, which in turn navigates to REIMBURSEMENT_ACCOUNT_USD. The resulting modal stack is:

[WorkspaceExpensifyCard] → [REIMBURSEMENT_ACCOUNT] → [REIMBURSEMENT_ACCOUNT_USD]

The "successful screen" is rendered inside the VALIDATION step (ConnectBankAccount.tsx) when bankAccountState === CONST.BANK_ACCOUNT.STATE.OPEN. Because the workspace flow is not in SETTINGS_SPLIT_NAVIGATOR, it falls into the branch at ConnectBankAccount.tsx#L97-L105 and renders ConnectedVerifiedBankAccount with onBackButtonPress={() => Navigation.dismissModal()}.

The header back button is wired to dismissModal, but the iOS native swipe-back gesture is not — it just pops the topmost route. Popping REIMBURSEMENT_ACCOUNT_USD reveals REIMBURSEMENT_ACCOUNT, where ReimbursementAccountPage.tsx#L504-L532 re-renders the bank account flow wrapper (entry point / continue-setup / verified view depending on achData.currentStep). That is what the reporter perceives as "the bank account flow reopening".

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

The success state shown by ConnectBankAccount must be terminal — the iOS swipe-back gesture should not leak back into the earlier flow screen. Two viable approaches, in order of preference:

1. Disable the swipe-back gesture on the success view. When bankAccountState === STATE.OPEN inside ConnectBankAccount.tsx, set gestureEnabled: false via navigation.setOptions (or pass the equivalent prop to ScreenWrapper) so the only way to leave is the header back button / "Confirm" button, both of which already call Navigation.dismissModal(). This matches the implicit contract (the header back button already collapses the entire flow).

2. Collapse the stack when reaching success. In the same STATE.OPEN branch, dispatch Navigation.goBack(backTo) (or dismissModal()) on mount so the user is dropped back at the Expensify Card screen and the success affordance is moved into that page (e.g., refreshed state showing the verified bank). This is more invasive but eliminates the dead "second success page" on REIMBURSEMENT_ACCOUNT as well.

Note that the parallel SETTINGS_SPLIT_NAVIGATOR branch at ConnectBankAccount.tsx#L79-L96 has the same shape and the equivalent branch in ReimbursementAccountPage.tsx#L504-L532 is symmetric — the same fix should be applied to both so reporters from Workflows/Wallet (e.g. PR #90302's Scenario A) don't regress.

What alternative solutions did you explore? (Optional)

• Intercepting the gesture via navigation.addListener('beforeRemove', ...) and routing it through dismissModal(). Equivalent UX, but more code than gestureEnabled: false.
• Replacing REIMBURSEMENT_ACCOUNT_USD with a navigation REPLACE action when entering the success state. Possible, but it leaves the back-to behavior dependent on what is under REIMBURSEMENT_ACCOUNT, which still re-renders a stale flow view as shown above.

Investigation details

• Bug introduced (or re-introduced) by PR #90302 "feat: Refactor USD flow to use useSubPage" merged 2026-05-27, three days before this issue was reported on 9.3.89-1. This PR was previously merged as #88193, reverted in #90199, then reapplied.
• The Tests section of #90302 explicitly covers "swipe back on mobile" from the success modal in the Workflows entry path (Scenario A) but does not cover the Expensify Card entry path that this bug exercises. The Workflows scenario reaches REIMBURSEMENT_ACCOUNT first and then REIMBURSEMENT_ACCOUNT_USD, the same stack shape — so the same regression likely affects Workflows as well.
• Header back button vs. swipe-back asymmetry: ConnectBankAccount success view sets onBackButtonPress={() => Navigation.dismissModal()}, but the native stack swipe gesture is governed by React Navigation's gestureEnabled option, which defaults to true and is not overridden in ScreenWrapper for this case.
• topmostFullScreenRoute?.name === NAVIGATORS.SETTINGS_SPLIT_NAVIGATOR (used in both ConnectBankAccount and ReimbursementAccountPage) is false for the workspace flow because the workspace flow runs under WORKSPACE_SPLIT_NAVIGATOR, which is why the workspace path renders ConnectedVerifiedBankAccount instead of ConfirmationPage. Both paths exhibit the same gesture leak.
• This is also why the Navigation.dismissModal() call in goBack at ReimbursementAccountPage.tsx#L420-L422 (the default switch case that handles currentStep === ENABLE) only fires for the header button — not for the iOS swipe.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92143) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.