[$250] Admin is prompted with a bank credentials error when assigning an existing Capital One Direct Connection cards to a second workspace.

[m-natarajan]

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.77-3
Reproducible in staging?: Needs Reproduction (Reproduction blocked)
Reproducible in production?: Needs reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Admin connects a Capital One Direct Connection card feed to one workspace.
2. Admin attempts to assign cards from that same Capital One feed to a second workspace.
3. The system displays an error and blocks the card assignment.

Expected Result:

Admin should be able to assign cards from the Capital One Direct Connection to the appropriate workspace without needing to create a duplicate bank connection.

Actual Result:

The admin receives the following error when assigning cards to the second workspace:
“Your bank credentials have expired. Please reconnect your account to assign cards.”

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057104894128540746
• Upwork Job ID: 2057104894128540746
• Last Price Increase: 2026-05-20

[MelvinBot]

Proposal

What is the root cause of that problem?

Capital One uses OAuth Direct Connection, where credentials are scoped per domain/workspace. Each workspace gets a unique domain name via PolicyUtils.getDomainNameForPolicy(policyID). When the admin connects Capital One to workspace A, the OAuth credentials are stored for workspace A's domain only.

When assigning cards on workspace B, the frontend calls assignWorkspaceCompanyCard() which sends the AssignCompanyCard API command with workspace B's domainAccountID. The backend looks up OAuth credentials for workspace B's domain, finds none (they only exist for workspace A), and returns the "Your bank credentials have expired" error.

The frontend's isSelectedFeedExpired guard in ConfirmationStep.submit() doesn't catch this case because when the feed data for workspace B is undefined, it returns false — allowing the request through to the backend where it fails with the generic credentials error.

Additionally, getDomainOrWorkspaceAccountID() falls back to workspace B's own workspaceAccountID when cardFeedData is undefined, causing a domain ID mismatch that propagates through the assignment flow.

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

This appears to be a backend/internal issue. The error originates from the backend AssignCompanyCard command's credential validation, which is scoped per domain. The backend should either:

1. Resolve the credentials from the original domain (workspace A) when the feed has been linked to workspace B via LinkCardFeedToPolicy, rather than requiring separate credentials per domain, OR
2. Return a more specific error that guides the user to reconnect the feed for workspace B specifically.

On the frontend side, the ConfirmationStep could be improved to detect when a linked feed's credentials haven't been established for the current workspace and proactively redirect the user to the bank connection flow before sending the API request — rather than showing the generic backend error.

What alternative solutions did you explore?

The frontend could prevent the mismatch by always using the original feed's domainID (from the feed that was linked) rather than falling back to the current workspace's workspaceAccountID in getDomainOrWorkspaceAccountID(). However, this wouldn't resolve the underlying backend credential scoping issue — the backend needs to recognize that a linked feed should share credentials across the workspaces it's linked to.

---

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.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The error text — "Your bank credentials have expired. Please reconnect your account to assign cards." — is server-generated; it does not exist anywhere in the App (NewDot's own broken-feed copy reads differently). So AssignCompanyCard is rejecting the write on the backend. NewDot's assign flow is mostly a pass-through, but there is one place where it can hand the backend the wrong target account.

When assigning a card, ConfirmationStep scopes the request with getDomainOrWorkspaceAccountID:

App/src/libs/CardUtils.ts

Lines 836 to 838 in cfeaadd

	function getDomainOrWorkspaceAccountID(workspaceAccountID: number, cardFeedData: CardFeedData | undefined): number {
	return cardFeedData?.domainID ?? workspaceAccountID;
	}

function getDomainOrWorkspaceAccountID(
  workspaceAccountID: number,
  cardFeedData: CardFeedData | undefined,
): number {
  return cardFeedData?.domainID ?? workspaceAccountID;
}

companyCardFeedData here is the second workspace's copy of the feed (cardFeeds?.[feed] from useCardFeeds(policyID), policyID = workspace B):

App/src/pages/workspace/companyCards/assignCard/ConfirmationStep.tsx

Line 64 in cfeaadd

const domainOrWorkspaceAccountID = getDomainOrWorkspaceAccountID(workspaceAccountID, companyCardFeedData);

A Capital One Direct Connection feed lives at the domain level — one bank connection shared by every workspace in the domain — so the assignment must be scoped to the domain account, where the connection credentials live. But getDomainOrWorkspaceAccountID returns the domain account only when the local feed copy carries a domainID; otherwise it falls back to workspaceAccountID, i.e. workspace B's own account. That value is sent as domainAccountID on AssignCompanyCard:

App/src/libs/actions/CompanyCards.ts

Line 417 in cfeaadd

domainAccountID: domainOrWorkspaceAccountID,

If workspace B's feed copy is missing domainID (workspace B has no Direct Connection of its own — it's meant to reuse the domain's), the App scopes the request to workspace B. The backend looks for the bank connection under that account, finds none, and returns the generic "credentials expired / reconnect" error — even though the domain's connection is valid. This fits the report: it happens only on the second workspace (the first owns the connection, so its feed copy is scoped correctly), and it tells the admin to reconnect a connection that already works.

Caveat: the issue is Needs Reproduction (Reproduction blocked), and the App code alone can't confirm whether domainID is actually absent on workspace B's feed copy — that depends on backend feed data. This is a code-review hypothesis for the most likely NewDot-side contribution; the backend rejection itself still needs server-side confirmation.

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

The actionable next step is to pull the AssignCompanyCard request for the failing workspace from server logs and compare the domainAccountID it received against the account that owns the Capital One connection. The fix then follows from what that shows:

• If workspace B's feed copy is missing domainID — the feed payload is incomplete. A domain-shared Direct Connection feed should always carry the owning domainID on every workspace's copy, so getDomainOrWorkspaceAccountID resolves to the domain account everywhere. That's a backend/feed-payload fix.
• If domainID is present and the backend still rejects — AssignCompanyCard is incorrectly requiring per-workspace credentials for a domain-level connection, which is purely server-side.

There is no confident NewDot code change to make until that's known: getDomainOrWorkspaceAccountID is correct given the data it is handed — the ?? workspaceAccountID fallback is right for genuinely workspace-scoped feeds and only misfires when a domain-scoped feed arrives without its domainID.

What alternative solutions did you explore? (Optional)

• I first checked the NewDot isSelectedFeedExpired pre-check in ConfirmationStep, which routes to the broken-feed page before assigning:

  App/src/pages/workspace/companyCards/assignCard/ConfirmationStep.tsx

  Lines 94 to 107 in cfeaadd

  	const isFeedExpired = isSelectedFeedExpired(cardFeeds?.[feed]);
  	const institutionId = !!getPlaidInstitutionId(bankName);
  	if (isFeedExpired) {
  	if (institutionId) {
  	const country = getPlaidCountry(policy?.outputCurrency, currencyList, countryByIp);
  	setAddNewCompanyCardStepAndData({
  	data: {
  	selectedCountry: country,
  	},
  	});
  	}
  	Navigation.navigate(ROUTES.WORKSPACE_COMPANY_CARDS_BROKEN_CARD_FEED_CONNECTION.getRoute(policyID, feed));

  — I ruled it out, because that path shows a full page with different wording, whereas the reporter received an inline error. The user passed the pre-check and the backend rejected the write.
• Treating this as backend-only without checking the App scoping. Rejected because the domainAccountID the App computes is the single most likely reason the backend can't locate the connection, so it should be verified before being assumed correct.

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

Admins can link an existing Capital One Direct Connection card feed from one workspace to another workspace, but when they try to assign cards from that shared feed on the second workspace, Expensify blocks the assignment with a credentials-expired/reconnect error.

The expected behavior is that the second workspace can assign cards from the same existing bank feed without requiring a duplicate Capital One bank connection.

What is the root cause of that problem?

The App client already treats this as a shared feed. When a feed from another workspace is selected, it calls LinkCardFeedToPolicy with the source domainAccountID, target policyID, feed type, country, and feed name, then selects the same source feed key for the target workspace:

App/src/pages/workspace/companyCards/WorkspaceCompanyCardFeedSelectorPage.tsx

Lines 146 to 150 in eaaffe3

	const feedValue = getCardFeedWithDomainID(feed.feed, feed.fundID) as CompanyCardFeedWithDomainID;
	linkCardFeedToPolicy(feed.fundID, policyID, CONST.COMPANY_CARD.LINK_FEED_TYPE.COMPANY_CARD, feed?.country, feed.feed)
	.then(() => {
	updateSelectedFeed(feedValue, policyID);
	goBack();

useCardFeeds() also includes feeds whose linkedPolicyIDs contain the current policy, so the second workspace should be operating on the original feed record rather than creating or requiring a separate credentials record:

App/src/hooks/useCardFeeds.tsx

Lines 52 to 62 in eaaffe3

	let workspaceFeeds: CombinedCardFeeds | undefined;
	if (policyID && allFeeds) {
	const shouldIncludeFeedPredicate = (combinedCardFeed: CombinedCardFeed) => {
	const validLinkedPolicyIDs = combinedCardFeed?.linkedPolicyIDs?.filter(Boolean);
	if (validLinkedPolicyIDs?.length) {
	return validLinkedPolicyIDs.includes(policyID);
	}
	return combinedCardFeed.preferredPolicy ? combinedCardFeed.preferredPolicy === policyID : combinedCardFeed.domainID === effectiveWorkspaceAccountID;
	};
	workspaceFeeds = getCombinedCardFeedsFromAllFeeds(allFeeds, shouldIncludeFeedPredicate, feedKeysWithCards);
	}

The assignment request then sends the original feed owner identifier as domainAccountID together with the target policyID and stripped bankName:

App/src/libs/actions/CompanyCards.ts

Lines 416 to 425 in eaaffe3

	const parameters: AssignCompanyCardParams = {
	domainAccountID: domainOrWorkspaceAccountID,
	policyID: policy.id,
	bankName,
	encryptedCardNumber,
	cardName: customCardName,
	email,
	startDate,
	reportActionID: optimisticCardAssignedReportAction.reportActionID,
	};

Direct feed credentials/expiration live on the feed owner's oAuthAccountDetails, not on each linked policy:

App/src/types/onyx/CardFeeds.ts

Lines 140 to 149 in eaaffe3

	/** Direct card feed data */
	type DirectCardFeedData = OnyxCommon.OnyxValueWithOfflineFeedback<{
	/** List of accounts */
	accountList: string[];
	/** Credentials info */
	credentials: string;
	/** Expiration number */
	expiration: number;

App/src/types/onyx/CardFeeds.ts

Lines 230 to 237 in eaaffe3

	/** Company cards feeds */
	companyCards?: Partial<Record<CardFeedWithNumber, CustomCardFeedData>>;
	/** Account details */
	oAuthAccountDetails?: Partial<Record<CardFeedWithNumber, DirectCardFeedData>>;
	/** Collection of card feeds status by domain ID */
	cardFeedsStatus?: WorkspaceCardFeedsStatus;

So the server-side assignment path is resolving/validating Capital One credentials from the target workspace/policy context instead of the source feed/domain context supplied by the client. For a second workspace, that lookup has no local Capital One credentials and is misclassified as "credentials expired", even though the shared feed itself is the valid credential owner.

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

1. Update the backend handler for AssignCompanyCard so credential lookup and expiration validation are based on the supplied source domainAccountID + bankName feed, not the target policyID workspace.
2. Before assigning, verify that the target policyID is allowed to use that feed by checking that it is either the feed's preferredPolicy or is present in linkedPolicyIDs. If not linked, return a permission/linking error rather than a credentials-expired error.
3. Use the same shared-feed resolution helper/logic as OpenPolicyCompanyCardsFeed/LinkCardFeedToPolicy so card loading and card assignment agree about which feed owns the OAuth credentials.
4. Add regression coverage for a Capital One/OAuth direct feed with preferredPolicy = workspace A, linkedPolicyIDs = [workspace B], and an unexpired oAuthAccountDetails[feed]; assigning a card to workspace B should succeed without asking to reconnect. Add a negative case for an unlinked workspace to ensure permissions still fail.

Scope boundaries: this change should be limited to the company-card shared-feed assignment path and the relevant API regression tests. It should not change CSV feeds, Expensify Card feeds, personal card broken-connection handling, or the App-side RHP flow, because the App already passes the source domain/feed identity into AssignCompanyCard.

What alternative solutions did you explore? (Optional)

I considered changing the App to create a duplicate Capital One connection for each workspace, but that contradicts the issue's expected behavior and the existing shared-feed model.

I also considered changing the App request shape to send the full feed#domainID value to AssignCompanyCard, but the client already sends the source domainAccountID and bankName. The failure is that the assignment endpoint is not using that source feed as the credential owner consistently.

[melvin-bot]

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

[yusufdeveloper2903]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @yusufdeveloper2903 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[github-actions]

⚠️ @dilshodmackbook-sketch Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).