[Due for payment 2026-01-21] [$250] Free trial ended-"Add payment card" RHP opens on the Profile page instead of Subscription

[nlemma]

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.2.13-0
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2219752/folder/13176677/test-cases/41237668
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: MacBook Air 15.6.1 Chrome
App Component: Other

Action Performed:

1. Login as the account that has a free trial
2. Open console and run the following snippets:

Onyx.merge('nvp_private_lastDayFreeTrial', '2025-09-12 01:01:00');

(change the date to your current date for the above snippet)

Onyx.merge('nvp_private_amountOwed', 1000);

Onyx.merge('nvp_private_billingGracePeriodEnd', 1719792000);

They will end the free trial and leave the user in a "expired" state.
3. Navigate to the workspace chat, start an expense creation flow
4. On a “Restricted” screen click the "Add payment card”
5. Verify you are brought to the Subscription tab

Expected Result:

"Add payment card" RHP opens on the Subscription page

Actual Result:

"Add payment card" RHP opens on the Profile page instead of Subscription

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6943011_1757698057838.Add_payment_card_wrong_tab.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021968321142284671725
• Upwork Job ID: 1968321142284671725
• Last Price Increase: 2025-09-24

Issue Owner

Current Issue Owner: @CortneyOfstad

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (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.

[ryntgh]

Proposal

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

Add payment card RHP opens on wrong background page

What is the root cause of that problem?

WorkspaceOwnerRestrictedAction is opened as a RIGHT_MODAL with an isolated navigation context. When addPaymentCard navigates to ROUTES.SETTINGS_SUBSCRIPTION_ADD_PAYMENT_CARD , the RHP background determination logic cannot access the proper screen context to utilize the existing mapping in SETTINGS_TO_RHP. The isolated modal context prevents the navigation system from determining that SCREENS.SETTINGS.SUBSCRIPTION.ROOT should be the background screen

App/src/pages/RestrictedAction/Workspace/WorkspaceOwnerRestrictedAction.tsx

Lines 22 to 25 in 3938e13

	const addPaymentCard = () => {
	Navigation.closeRHPFlow();
	Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_ADD_PAYMENT_CARD);
	};

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

We can navigate to the subscription root page first to establish the proper navigation context, then navigate to the add payment card RHP

    const addPaymentCard = () => {
        Navigation.closeRHPFlow();
        InteractionManager.runAfterInteractions(() => {
            Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION.getRoute());
            Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_ADD_PAYMENT_CARD);
        });
    };

Or

    const addPaymentCard = () => {
        Navigation.closeRHPFlow();
        Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION.getRoute());
        InteractionManager.runAfterInteractions(() => {
            Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_ADD_PAYMENT_CARD);
        });
    };

App/src/pages/RestrictedAction/Workspace/WorkspaceOwnerRestrictedAction.tsx

Lines 22 to 25 in 3938e13

	const addPaymentCard = () => {
	Navigation.closeRHPFlow();
	Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_ADD_PAYMENT_CARD);
	};

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

N/A

[ShridharGoel]

Proposal

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

After a free trial expires and the user attempts a billable action (e.g., creating an expense), the "Restricted" flow shows an action to "Add payment card". Clicking it should open the RHP on the Subscription page (Add Payment Card). Instead, it opens the Settings RHP with the Profile central pane underneath, causing the RHP to appear in the wrong context.

What is the root cause of that problem?

When deep-linking to an RHP screen, we compute a matching full-screen navigator (e.g., Settings) that should be shown under the RHP and push it onto the root stack. The previous logic only pushed the full-screen navigator name if that navigator had been preloaded, without specifying the nested target screen. For Settings, this causes the central pane to fall back to its default (Profile) instead of the intended Subscription screen.

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 129 to 141 in 3938e13

	if (matchingFullScreenRoute && lastFullScreenRoute && matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
	const isMatchingRoutePreloaded = currentState.preloadedRoutes.some((preloadedRoute) => preloadedRoute.name === matchingFullScreenRoute.name);
	if (isMatchingRoutePreloaded) {
	navigation.dispatch(StackActions.push(matchingFullScreenRoute.name));
	} else {
	const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
	const additionalAction = StackActions.push(matchingFullScreenRoute.name, {
	screen: lastRouteInMatchingFullScreen?.name,
	params: lastRouteInMatchingFullScreen?.params,
	});
	navigation.dispatch(additionalAction);
	}
	}

Because the preloaded case omits the nested {screen, params}, the Settings split navigator defaults to the Profile central screen.

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

Always push the matching full-screen navigator together with its nested target screen and params, regardless of whether it was preloaded. This guarantees that the correct central pane (Subscription) is set under the RHP when navigating to settings/subscription/add-payment-card and for similar RHP deep links.

Updated code:

if (matchingFullScreenRoute && lastFullScreenRoute && matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
    // Always include the nested screen so the central pane matches the RHP relation
    const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
    const additionalAction = StackActions.push(
        matchingFullScreenRoute.name,
        lastRouteInMatchingFullScreen
            ? {
                  screen: lastRouteInMatchingFullScreen.name,
                  params: lastRouteInMatchingFullScreen.params,
              }
            : undefined,
    );
    navigation.dispatch(additionalAction);
}

Screen.Recording.2025-09-13.at.4.45.41.PM.mov

• It aligns with the defined relations (e.g., SETTINGS_TO_RHP) that map RHP screens to their underlying central panes.
• It fixes the mismatch introduced by preloading, ensuring consistency across narrow/wide layouts and all Settings/Workspace RHP deep links.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can add new unit tests for this navigation scenario.

[lorretheboy]

Proposal

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

"Add payment card" RHP opens on the Profile page instead of Subscription

What is the root cause of that problem?

The issue was in the getAccountTabScreenToOpen function

Here's what happening:
When a user has an expired free trial, their subscriptionPlan becomes null because they don't have any owned paid policies
When clicking "Add payment card" from the WorkspaceOwnerRestrictedAction screen, it attempts to navigate to the payment card page.

App/src/pages/RestrictedAction/Workspace/WorkspaceOwnerRestrictedAction.tsx

Lines 22 to 25 in 3938e13

	const addPaymentCard = () => {
	Navigation.closeRHPFlow();
	Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_ADD_PAYMENT_CARD);
	};

However, the Settings Split Navigator uses getAccountTabScreenToOpen(subscriptionPlan) to determine which central screen to show underneath the RHP

App/src/libs/Navigation/helpers/getAccountTabScreenToOpen.ts

Lines 23 to 28 in 4677f8f

	const focusedRoute = findFocusedRoute(settingsTabState) as NavigationPartialRoute<keyof SettingsSplitNavigatorParamList> | undefined;
	if ((!subscriptionPlan && focusedRoute?.name === SCREENS.SETTINGS.SUBSCRIPTION.ROOT) || !focusedRoute) {
	return {screen: SCREENS.SETTINGS.PROFILE.ROOT, params: {}};
	}
	return {screen: focusedRoute.name};

But... the above that when subscriptionPlan was null AND the user was trying to access the subscription screen, it would redirect them to the Profile page instead

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

Update getAccountTabScreenToOpen logic to

    // If no focused route, default to Profile
    if (!focusedRoute) {
        return {screen: SCREENS.SETTINGS.PROFILE.ROOT, params: {}};
    }

    // Allow navigation to subscription screen even when subscriptionPlan is null (e.g., expired free trial users)
    // This is needed so users can access payment card screens to add payment methods
    if (focusedRoute.name === SCREENS.SETTINGS.SUBSCRIPTION.ROOT) {
        return {screen: SCREENS.SETTINGS.SUBSCRIPTION.ROOT, params: {}};
    }

    // For other routes, if subscriptionPlan is null, redirect to Profile to maintain existing behavior
    if (!subscriptionPlan) {
        return {screen: SCREENS.SETTINGS.PROFILE.ROOT, params: {}};
    }

    return {screen: focusedRoute.name};

By fixing in the root cause like this, it would fix all other similar places in codebase if exists and also we can ensure that this issue won't happen in anywhere in the future

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

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.

[dmkt9]

Proposal

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

"Add payment card" RHP opens on the Profile page instead of Subscription

What is the root cause of that problem?

1. The last Settings tab path are stored in session storage when accessed. If the app is opened for the first time and the Settings tab hasn’t been visited yet, it will always preload with SCREENS.SETTINGS.PROFILE.ROOT:
   

   App/src/libs/Navigation/helpers/getAccountTabScreenToOpen.ts

   Lines 18 to 21 in d8adfa5

   	const settingsTabState = getSettingsTabStateFromSessionStorage();
   	if (!settingsTabState) {
   	return {screen: SCREENS.SETTINGS.PROFILE.ROOT, params: {}};
   	}

2. When the button is clicked, navigation is triggered here:
   

   App/src/pages/RestrictedAction/Workspace/WorkspaceOwnerRestrictedAction.tsx

   Lines 22 to 25 in d8adfa5

   	const addPaymentCard = () => {
   	Navigation.closeRHPFlow();
   	Navigation.navigate(ROUTES.SETTINGS_SUBSCRIPTION_ADD_PAYMENT_CARD);
   	};

3. During navigation handling, if the name of the fullscreen route of the target route matches the name of the preloaded fullscreen route, the preloaded route will be reused:
   

   App/src/libs/Navigation/helpers/linkTo/index.ts

   Lines 126 to 141 in d8adfa5

   	const matchingFullScreenRoute = getMatchingFullScreenRoute(newFocusedRoute);
   	const lastFullScreenRoute = currentState.routes.findLast((route) => isFullScreenName(route.name));
   	if (matchingFullScreenRoute && lastFullScreenRoute && matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
   	const isMatchingRoutePreloaded = currentState.preloadedRoutes.some((preloadedRoute) => preloadedRoute.name === matchingFullScreenRoute.name);
   	if (isMatchingRoutePreloaded) {
   	navigation.dispatch(StackActions.push(matchingFullScreenRoute.name));
   	} else {
   	const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
   	const additionalAction = StackActions.push(matchingFullScreenRoute.name, {
   	screen: lastRouteInMatchingFullScreen?.name,
   	params: lastRouteInMatchingFullScreen?.params,
   	});
   	navigation.dispatch(additionalAction);
   	}
   	}

   
   As a result, the Profile page is opened by default instead of the Subscription page. If we access a different tab in the Settings page, it will reflect the last tab we visited.

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

We should compare both the last route of the target route and the last route of the preloaded fullscreen route. Only if they match should we consider them the same route.

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 126 to 141 in d8adfa5

	const matchingFullScreenRoute = getMatchingFullScreenRoute(newFocusedRoute);
	const lastFullScreenRoute = currentState.routes.findLast((route) => isFullScreenName(route.name));
	if (matchingFullScreenRoute && lastFullScreenRoute && matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
	const isMatchingRoutePreloaded = currentState.preloadedRoutes.some((preloadedRoute) => preloadedRoute.name === matchingFullScreenRoute.name);
	if (isMatchingRoutePreloaded) {
	navigation.dispatch(StackActions.push(matchingFullScreenRoute.name));
	} else {
	const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
	const additionalAction = StackActions.push(matchingFullScreenRoute.name, {
	screen: lastRouteInMatchingFullScreen?.name,
	params: lastRouteInMatchingFullScreen?.params,
	});
	navigation.dispatch(additionalAction);
	}
	}

             const matchingFullScreenRoute = getMatchingFullScreenRoute(newFocusedRoute);
+            const lastRouteInMatchingFullScreen = matchingFullScreenRoute?.state?.routes?.at(-1);
 
             const lastFullScreenRoute = currentState.routes.findLast((route) => isFullScreenName(route.name));
-            if (matchingFullScreenRoute && lastFullScreenRoute && matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
-                const isMatchingRoutePreloaded = currentState.preloadedRoutes.some((preloadedRoute) => preloadedRoute.name === matchingFullScreenRoute.name);
+            const lastRouteInLastFullScreenRoute = lastFullScreenRoute?.state?.routes?.at(-1);
+            if (
+                matchingFullScreenRoute &&
+                lastFullScreenRoute &&
+                (matchingFullScreenRoute.name !== lastFullScreenRoute.name || lastRouteInMatchingFullScreen?.name !== lastRouteInLastFullScreenRoute?.name)
+            ) {
+                const isMatchingRoutePreloaded = currentState.preloadedRoutes.some(
+                    (preloadedRoute) =>
+                        preloadedRoute.name === matchingFullScreenRoute.name &&
+                        (!lastRouteInMatchingFullScreen?.name ||
+                            (preloadedRoute.params && 'screen' in preloadedRoute.params && preloadedRoute.params.screen === lastRouteInMatchingFullScreen?.name)),
+                );
                 if (isMatchingRoutePreloaded) {
                     navigation.dispatch(StackActions.push(matchingFullScreenRoute.name));
                 } else {
-                    const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
                     const additionalAction = StackActions.push(matchingFullScreenRoute.name, {
                         screen: lastRouteInMatchingFullScreen?.name,
                         params: lastRouteInMatchingFullScreen?.params,

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

NA

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.

2025-09-15.22-12-46.mp4

[melvin-bot]

@CortneyOfstad Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

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