[$250] Expensify Card - Error assigning virtual card when card feed is not from the current workspace

[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.1.77-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp https://expensify.testrail.io/index.php?/tests/view/6436913
Email or phone of affected tester (no customers): applausetester+0700798ekh@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 15.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace A and B are set up with Expensify Card.
• Workspace A has at least one other member other than the workspace owner.

1. Go to staging.expensify.com
2. Go to Workspace A settings > Expensify Card.
3. Open the Expensify Card feed selector.
4. Select the card feed from Workspace B.
5. Go to Members.
6. Click on the member.
7. Click + New card.
8. Go through the process of adding VIRTUAL card and reach confirmation page.
9. On the confirmation page, click Issue card.
10. Enter magic code - Error shows up.
11. Go back to Expensify Card.
12. Open the Expensify Card feed selector.
13. Select the card feed from Workspace A (the current worksapce).
14. Repeat Step 5 to 10.

Expected Result:

In Step 10 and 14, the card will be issued successfully.

Actual Result:

In Step 10, error "Oops... something went wrong and your request could not be completed. Please try again later." shows up when assigning virtual card to member on Members while card feed is from another workspace.

In Step 14, after changing Expensify Card feed back to the current workspace, virtual Expensify Card still cannot be assigned. It shows another error "Unable to create your virtual card. If the problem persists please contact support".

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

Bug6881335_1751970709079.20250708-173650_powDG2hL.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021942997172474660437
• Upwork Job ID: 1942997172474660437
• Last Price Increase: 2025-07-23
• Automatic offers:
• aimane-chnaif | Contributor | 109343806

Issue Owner

Current Issue Owner: @mehrozone

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[mehrozone]

Proposal

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

Expensify Card - Error assigning virtual card when card feed is not from the current workspace

What is the root cause of that problem?

The core of the problem is a mismatch of parameters in the card issuance API calls. what is happening now:

In the scenario where a user toggles their Expensify Card feeds to show cards from Workspace B while they are actively working in Workspace A, the system becomes ambiguous as to which workspace should be used for the issuance of the new card.

The useDefaultFundID hook uses the fundID of the selected feed, which is in this case Workspace B’s fundID. This is used as domainAccountID for issueExpensifyCard API call. However, the backend expects this parameter to be the workspace where the card should actually be issued. In this case, it is supposed to be issued in Workspace A (current workspace), not Workspace B (the selected feed’s workspace).

Therefore, what happens is that when a card is to be issued, the backend receives Workspace B’s fundID as the target workspace while the user is actually in Workspace A’s context. This scenario creates a mismatch in logic resulting in the backend attempting to issue the card in a wrong workspace, and thus the API calls to fail.

Call Stack:

• When a user switches to Workspace B's card feed while in Workspace A
• The useDefaultFundID hook returns the fundID of Workspace B (the selected feed)
• API call issueExpensifyCard use this fundID as the domainAccountID/workspaceAccountID parameter
• This causes the BE to try to issue card in the wrong workspace context, leading to failures

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

Replace the incorrect usage of defaultFundID with workspaceAccountID in submit for ValidateCodeActionModal

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

Update This

issueExpensifyCard(defaultFundID, policyID, CONST.COUNTRY.US, validateCode, data);

To This

issueExpensifyCard(workspaceAccountID, policyID, CONST.COUNTRY.US, validateCode, data);

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

Basic cross-workspace card feed switching

• Set up two workspaces (A and B) with Expensify Cards
• Switch card feed from Workspace A to Workspace B
• Attempt to issue virtual card in Workspace A
• Verify card is issued successfully in Workspace A context

What alternative solutions did you explore? (Optional)

• Modify useDefaultFundID hook: This would break other legitimate uses of the hook where the selected feed's fundID is actually needed
• Create separate hooks for different contexts: This would add unnecessary complexity when the issue is simply using the wrong parameter

[melvin-bot]

@getusha Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@getusha 6 days overdue. This is scarier than being forced to listen to Vogon poetry!