[Payment Due][$250] Expensify Card - App reopens Expensify Card page after issuing card and swiping right

[mitarachim]

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.6-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: #75096
Email or phone of affected tester (no customers): applausetester+210101abc@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.1
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace is set up with Expensify Card feature.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Expensify Card.
3. Click Issue card.
4. Select details and proceed to confirm page.
5. Enter magic code if needed.
6. After landing on Expensify Card page, swipe right using iOS gesture.

Expected Result:

App will return to workspace settings.

Actual Result:

App reopens Expensify Card page after issuing card and swiping right.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7055292_1769062764611.ScreenRecording_01-22-2026_14-15-30_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022015914170538376511
• Upwork Job ID: 2015914170538376511
• Last Price Increase: 2026-02-02

Issue Owner

Current Issue Owner: @cead22

[melvin-bot]

Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[Eskalifer1]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Expensify Card - App reopens Expensify Card page after issuing card and swiping right

What is the root cause of that problem?

We do not completely close RHP (one page remains in the stack), which leads to unexpected behavior when using native history controls (such as the back button in a browser or swipe on iOS).

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

To fix this, we need to make several changes in several places:

1. On the Confirmation step:
   

   App/src/pages/workspace/expensifyCard/issueNew/ConfirmationStep.tsx

   Lines 70 to 74 in 31bd051

   	if (isSuccessful) {
   	Navigation.navigate(ROUTES.WORKSPACE_EXPENSIFY_CARD.getRoute(policyID), {forceReplace: true});
   	clearIssueNewCardFlow(policyID);
   	return;
   	}

If you don't need to enter a magic code, navigation happens here, so you need to add rhp closing logic, as we do in other parts of the application:

Navigation.closeRHPFlow();

2. If you need to enter a code, the redirection logic will happen here:
   

   App/src/pages/workspace/expensifyCard/issueNew/IssueNewCardConfirmMagicCodePage.tsx

   Lines 40 to 44 in 31bd051

   	if (backTo && shouldUseBackToParam) {
   	Navigation.goBack(backTo);
   	} else {
   	Navigation.navigate(ROUTES.WORKSPACE_EXPENSIFY_CARD.getRoute(policyID), {forceReplace: true});
   	}

For backTo, you need to add compareParams:

 Navigation.goBack(backTo, {compareParams: false});

For the other case, use the same logic as in the first point:

Navigation.closeRHPFlow();

We can discuss whether we need forceReplace in this case. If not, it can also be removed.

Additionally, we can delay the clearing of clearIssueNewCardFlow data so that it is not cleared during navigation, but only after it.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.

After issuing an Expensify Card on iOS, using the right-swipe back gesture opens the Expensify Card page again instead of going back to Workspace Settings. The RHP screen is still in the navigation stack after the flow finishes, so the back gesture returns to the RHP instead of the previous central pane screen.

What is the root cause of that problem?

The earliest wrong assumption is that using forceReplace: true fully removes the RHP from navigation. This is wrong because forceReplace only replaces the current RHP screen and does not remove the RHP navigator from the root stack. Because of this, the navigation history still contains the RHP, which causes the back gesture to return to it.

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

When leaving the RHP and going to a central pane screen after the flow completes, the RHP must be removed from the navigation stack first.

To fix this, we should dismiss the RHP before navigating to the central pane screen.

This follows the same pattern already used in
src/pages/workspace/companyCards/assignCard/ConfirmationStep.tsx.

The change is in
src/pages/workspace/expensifyCard/issueNew/IssueNewCardConfirmMagicCodePage.tsx.

We modify the useEffect hook.

File: src/pages/workspace/expensifyCard/issueNew/IssueNewCardConfirmMagicCodePage.tsx

useEffect(() => {
    if (!isSuccessful) {
        return;
    }

    if (backTo && shouldUseBackToParam) {
        Navigation.goBack(backTo);
    } else {
        Navigation.dismissModal();
        Navigation.navigate(ROUTES.WORKSPACE_EXPENSIFY_CARD.getRoute(policyID), {forceReplace: true});
    }

    clearIssueNewCardFlow(policyID);
}, [backTo, isSuccessful, policyID, shouldUseBackToParam]);

What alternative solutions did you explore? (Optional)

• Closing the RHP after navigation was not chosen because the RHP is still in the history when navigation happens.
• Removing forceReplace was not chosen because the RHP would still stay in the stack.
• Using Navigation.goBack without a valid backTo value was not chosen because there may be no valid screen to return to.
• Using Navigation.closeRHPFlow() was not chosen because dismissModal() is the standard pattern used in similar completed flows.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022015914170538376511

[melvin-bot]

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

[ZhenjaHorbach]

Thanks for your proposals
But @Eskalifer1' proposal looks a bit better for me
Since this proposal covers all cases(including a case without a magic code screen)

🎀👀🎀 С+