[Due for payment 2026-07-17] [$250] Commercial card feed displays an already assigned Visa card as available to assign

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.27-2
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
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. Open New Expensify.
2. Go to Workspaces > [Workspace] > Company cards.
3. Open the Visa cards commercial feed.
4. Search for an existing card using the last four digits.
5. Review the card assignment results.

Expected Result:

The system should only show the current assignment status for the card. If a card is already assigned to a member, it should not also appear as “Unassigned” with an Assign button.

Actual Result:

The same Visa commercial card appears twice in the feed: once as Unassigned with the option to assign it, and once as already assigned to the workspace member. This incorrectly suggests the admin can assign a card that is already assigned.

Workaround:

Unknown

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074493295357525479
• Upwork Job ID: 2074493295357525479
• Last Price Increase: 2026-07-07

Issue Owner

Current Issue Owner: @eh2077

[MelvinBot]

Proposal

What is the root cause of that problem?

The unassigned-card list and the assigned-card list are built from the same WorkspaceCardsList Onyx object but via two different keys, and the de-dup filter that removes already-assigned cards from the unassigned list uses exact string equality — while the app's other card-matching helper deliberately does not.

In getFilteredCardList the commercial-feed branch builds a Set of assigned card names straight from card.cardName and filters the assignable cardList with a raw Set.has — no normalization:

Code references

• Set of assigned names, raw: CardUtils.ts:1013 and :1026
• Commercial-feed filter, raw Set.has: CardUtils.ts:1041-1046
• Sibling matcher that does normalize both sides: isMatchingCard → normalizeCardName, CardUtils.ts:434
• Assignable list & assigned members rendered from these two sources: CardSelectionStep.tsx:64

For commercial feeds both the cardList key and the assigned card's cardName are supposed to be the masked PAN (e.g. 480801XXXXXX2554 / VISA - 1234). But getFilteredCardList compares them byte-for-byte, whereas isMatchingCard runs both strings through normalizeCardName (which strips special characters — "handles differences between OAuth provider card names and stored card names"). So if the two masked strings differ by even one byte (a different mask glyph X/•/*, spacing, or a special character), the already-assigned card is not filtered out and renders both as Unassigned (from cardList) and as assigned to the member (from the card objects) — exactly the screenshot in this issue.

Confidence: Medium. The client-side inconsistency is confirmed in code. What isn't confirmed (the issue is "unable to reproduce") is which divergence occurs for the affected feed. It could instead be a timing window: assignWorkspaceCompanyCard does not optimistically remove the card from cardList, so a just-assigned card legitimately stays assignable until the server pushes a fresh feed. To pin it down, byte-compare the cardList keys against the assigned card objects' cardName in the affected workspace's WorkspaceCardsList blob (or the OpenPolicyCompanyCards feed payload).

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

Make getFilteredCardList use the same normalization contract as isMatchingCard:

• Build assignedCards / allWorkspaceAssignedCards from normalizeCardName(card.cardName) instead of the raw card.cardName.
• Filter the commercial-feed cardList (and the direct-feed accountList) with !assignedCards.has(normalizeCardName(cardName)).

This closes the formatting-mismatch class of bug entirely and keeps the two card-matching paths consistent. Worth adding a getFilteredCardList unit test that uses two differently-masked representations of the same card (the current tests in tests/unit/CardUtilsTest.ts only ever use byte-identical strings, which is why this slipped through).

What alternative solutions did you explore? (Optional)

If log evidence shows the divergence is a timing window rather than a formatting difference, additionally have assignWorkspaceCompanyCard optimistically remove the assigned key from the feed's cardList on assignment so the card leaves the assignable list immediately. The two fixes are complementary; the normalization fix is the higher-confidence root-cause fix.

Related issues

Possibly related company-card feed de-dup issues (different symptoms, worth a glance): #95495, #95492.

---

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

[alazarlemma02]

Proposal

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

When viewing a commercial Visa company card feed, an already assigned card can appear twice in the table: once as assigned to a member, and again as an unassigned card with an Assign button.

This is wrong because the admin is seeing two rows for the same physical card. The card is already assigned, so it should not also be offered as available to assign.

What is the root cause of that problem?

The table data is built by merging two sources in src/hooks/useCompanyCards.ts:

• assigned cards from cardsList
• assignable/unassigned cards from cardsList.cardList

buildCompanyCardEntries() adds assigned cards first, then adds any remaining cardList entries as unassigned:

const {cardList, ...assignedCards} = cardsList ?? {};
const companyCardEntries = buildCompanyCardEntries(selectedFeed?.accountList, cardList, assignedCards, feedName);

The dedupe currently depends on resolveCardListEntry() being able to match the assigned card to the corresponding cardList entry by:

1. exact encryptedCardNumber
2. normalized cardName
3. lastFourPAN || cardName matching the end of a cardList display name

const panSuffix = lastFourPAN || cardName;
const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);

That is fragile for commercial feeds. For Visa commercial cards, cardList is keyed by the assignable display name and stores the encrypted card number as the value, while the assigned card record can have a different display name and may not have the same encrypted value available on the client.

So when the assigned card does not match the cardList row by exact encrypted value or exact normalized name, and the last-four fallback does not resolve the row, Phase 1 stores the assigned card under one identity and Phase 2 still adds the cardList row as unassigned.

That produces both rows for the same card.

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

Steps of changes:

1. In src/hooks/useCompanyCards.ts, make the card identity resolution use a normalized last-four matcher instead of falling back to the full assigned cardName.

Add a local helper:

function getLastFourDigits(value: string | undefined): string {
    return value?.match(/(\d{4})\D*$/)?.[1] ?? '';
}

2. Build a unique last-four lookup for cardList entries, so we only match by last four when the match is unambiguous.

 function resolveCardListEntry(card: Card, cardListEntries: Array<[string, string]>): Card {
     const {cardName, encryptedCardNumber, lastFourPAN} = card;
+    const cardListEntriesByLastFour = new Map<string, [string, string] | null>();
+
+    for (const entry of cardListEntries) {
+        const lastFour = getLastFourDigits(entry[0]);
+        if (!lastFour) {
+            continue;
+        }
+        cardListEntriesByLastFour.set(lastFour, cardListEntriesByLastFour.has(lastFour) ? null : entry);
+    }

     const isLinkedByEncrypted = encryptedCardNumber && cardListEntries.some(([, entryEncryptedCardNumber]) => entryEncryptedCardNumber === encryptedCardNumber);
     if (isLinkedByEncrypted) {
         return card;
     }

3. Replace the raw suffix fallback with the normalized unique last-four lookup.

-    const panSuffix = lastFourPAN || cardName;
+    const panSuffix = lastFourPAN || getLastFourDigits(cardName);

     ...
-    const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);
-
-    // If there are other matched cards, return the original card.
-    if (otherMatchedCards.length > 0) {
+    const matchedCard = cardListEntriesByLastFour.get(panSuffix);
+    if (!matchedCard) {
         return card;
     }

     const [name = cardName, encrypted = encryptedCardNumber] = matchedCard ?? [];
     return {...card, cardName: name, encryptedCardNumber: encrypted};

4. Keep the existing Phase 2 skip logic unchanged.

Once the assigned card is resolved to the canonical cardList display name and encrypted value, this existing check prevents the same card from being added again as unassigned:

if (coveredNames.has(normalizedName) || coveredEncrypted.has(encryptedCardNumber) || entriesMap.has(encryptedCardNumber)) {
    continue;
}

This is a narrow fix because it only changes how useCompanyCards identifies the same card while merging assigned and assignable rows. It does not change assignment APIs, table rendering, or feed loading.

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

• A Visa commercial feed where cardList contains an assignable card and assignedCards contains the same card with a different display name but the same last four digits should render only one assigned row.

• A card that matches by encryptedCardNumber should still render only one assigned row.

• A card that matches by normalized cardName should still render only one assigned row.

• If two different cardList entries share the same last four digits, the last-four fallback should not collapse them into one card.

• Unassigned Visa commercial cards that do not match any assigned card should still render with the Assign button.

What alternative solutions did you explore? (Optional)

I considered filtering duplicates in WorkspaceCompanyCardsTable, but that would hide the symptom after the data was already merged incorrectly.

The better fix is in useCompanyCards.ts, where assigned and unassigned card sources are combined. That keeps the table simple and ensures downstream search/filter/sort all receive the correct single card entry.

[abbasifaizan70]

Proposal

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

• On the workspace's Company Cards page, when searching a Visa commercial feed for a card by its last four digits, the same physical card shows up twice in the results: once as "Unassigned" with an Assign button, and again as already assigned to a member. This wrongly implies an admin can assign a card that's already assigned to someone.

What is the root cause of that problem?

• The card table's rows come from buildCompanyCardEntries, which first walks all assigned cards and tries to link each one to its matching entry in the feed's raw cardList via resolveCardListEntry. When the card's encryptedCardNumber isn't already linked and its cardName doesn't match a cardList key, it falls back to matching by last-four-digit suffix. If more than one cardList entry ends with that same suffix (common for Visa/Mastercard commercial feeds, since several accounts can legitimately share a last-four), the function intentionally gives up and returns the assigned card unmodified, rather than guessing which entry it belongs to:
  

  App/src/hooks/useCompanyCards.ts

  Lines 80 to 92 in 68df9cd

  	if (!panSuffix) {
  	return card;
  	}
  	const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);
  	// If there are other matched cards, return the original card.
  	if (otherMatchedCards.length > 0) {
  	return card;
  	}
  	const [name = cardName, encrypted = encryptedCardNumber] = matchedCard ?? [];
  	return {...card, cardName: name, encryptedCardNumber: encrypted};

• Back in buildCompanyCardEntries, the assigned-card loop only marks coveredNames/coveredEncrypted using whatever resolveCardListEntry returned. Because the ambiguous case returns the card unchanged, none of the actual cardList entries that caused the ambiguity ever get marked as covered — only the assigned card's own raw cardName does:
  

  App/src/hooks/useCompanyCards.ts

  Lines 111 to 135 in 68df9cd

  	// Phase 1: Assigned cards first — these are the source of truth.
  	// Previously assigned parent cards are kept visible so admins can manage/unassign them.
  	for (const card of Object.values(assignedCards)) {
  	if (!card?.cardName) {
  	continue;
  	}
  	const {cardName = card.cardName, encryptedCardNumber = card.cardName} = resolveCardListEntry(card, cardListEntries);
  	const normalizedName = normalizeCardName(cardName);
  	const cardEntryID = encryptedCardNumber ?? normalizedName;
  	const existingEntry = entriesMap.get(cardEntryID);
  	const isRicherRecord = card.lastFourPAN && !existingEntry?.assignedCard?.lastFourPAN;
  	// Skip duplicate when two assigned-card records (e.g. old-format + new-format) resolve to the same cardList entry.
  	if (!existingEntry || isRicherRecord) {
  	entriesMap.set(cardEntryID, {cardName, encryptedCardNumber, isAssigned: true, assignedCard: card});
  	}
  	coveredNames.add(normalizedName);
  	if (encryptedCardNumber !== cardName) {
  	coveredEncrypted.add(encryptedCardNumber);
  	}
  	}

• The second phase then iterates every entry in the feed's cardList and adds it as a fresh unassigned row unless its name/encrypted value was already covered. Since the true cardList entry for that assigned card was never marked covered, it slips through here and gets added a second time as unassigned — producing the duplicate the reporter saw:
  

  App/src/hooks/useCompanyCards.ts

  Lines 137 to 147 in 68df9cd

  	// Phase 2: Add remaining unassigned cards. cardList first so its encryptedCardNumber takes precedence.
  	for (const [cardName, encryptedCardNumber] of cardListEntries) {
  	const normalizedName = normalizeCardName(cardName);
  	if (coveredNames.has(normalizedName) || coveredEncrypted.has(encryptedCardNumber) || entriesMap.has(encryptedCardNumber)) {
  	continue;
  	}
  	entriesMap.set(encryptedCardNumber, {cardName, encryptedCardNumber, isAssigned: false});
  	coveredNames.add(normalizedName);
  	coveredEncrypted.add(encryptedCardNumber);
  	}

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

• Have resolveCardListEntry report which cardList entries it found ambiguous (instead of silently discarding them), so the caller can still mark them as covered even though it can't safely enrich the assigned card with one of them:
  

  App/src/hooks/useCompanyCards.ts

  Lines 62 to 93 in 68df9cd

  	function resolveCardListEntry(card: Card, cardListEntries: Array<[string, string]>): Card {
  	const {cardName, encryptedCardNumber, lastFourPAN} = card;
  	// Using || instead of ?? because an empty-string lastFourPAN should fall through to cardName
  	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
  	const panSuffix = lastFourPAN || cardName;
  	const isLinkedByEncrypted = encryptedCardNumber && cardListEntries.some(([, entryEncryptedCardNumber]) => entryEncryptedCardNumber === encryptedCardNumber);
  	if (isLinkedByEncrypted) {
  	return card;
  	}
  	const normalizedCardName = cardName ? normalizeCardName(cardName) : undefined;
  	const matchedByName = normalizedCardName ? cardListEntries.find(([name]) => normalizeCardName(name) === normalizedCardName) : undefined;
  	if (matchedByName) {
  	return {...card, encryptedCardNumber: matchedByName[1]};
  	}
  	if (!panSuffix) {
  	return card;
  	}
  	const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);
  	// If there are other matched cards, return the original card.
  	if (otherMatchedCards.length > 0) {
  	return card;
  	}
  	const [name = cardName, encrypted = encryptedCardNumber] = matchedCard ?? [];
  	return {...card, cardName: name, encryptedCardNumber: encrypted};
  	}

function resolveCardListEntry(card: Card, cardListEntries: Array<[string, string]>): {resolvedCard: Card; ambiguousCardNames: string[]} {
    const {cardName, encryptedCardNumber, lastFourPAN} = card;

    // eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
    const panSuffix = lastFourPAN || cardName;

    const isLinkedByEncrypted = encryptedCardNumber && cardListEntries.some(([, entryEncryptedCardNumber]) => entryEncryptedCardNumber === encryptedCardNumber);
    if (isLinkedByEncrypted) {
        return {resolvedCard: card, ambiguousCardNames: []};
    }

    const normalizedCardName = cardName ? normalizeCardName(cardName) : undefined;
    const matchedByName = normalizedCardName ? cardListEntries.find(([name]) => normalizeCardName(name) === normalizedCardName) : undefined;
    if (matchedByName) {
        return {resolvedCard: {...card, encryptedCardNumber: matchedByName[1]}, ambiguousCardNames: []};
    }

    if (!panSuffix) {
        return {resolvedCard: card, ambiguousCardNames: []};
    }

    const matches = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);

    // If there are other matched cards, we can't tell which entry the assigned card refers to.
    // Report them so the caller can still mark them as covered and avoid re-adding them as unassigned.
    if (matches.length > 1) {
        return {resolvedCard: card, ambiguousCardNames: matches.map(([name]) => name)};
    }

    const [name = cardName, encrypted = encryptedCardNumber] = matches.at(0) ?? [];
    return {resolvedCard: {...card, cardName: name, encryptedCardNumber: encrypted}, ambiguousCardNames: []};
}

• Use that reported list in buildCompanyCardEntries to mark the ambiguous cardList entries as covered, so phase 2 no longer re-adds any of them as a duplicate unassigned row:
  

  App/src/hooks/useCompanyCards.ts

  Lines 111 to 135 in 68df9cd

  	// Phase 1: Assigned cards first — these are the source of truth.
  	// Previously assigned parent cards are kept visible so admins can manage/unassign them.
  	for (const card of Object.values(assignedCards)) {
  	if (!card?.cardName) {
  	continue;
  	}
  	const {cardName = card.cardName, encryptedCardNumber = card.cardName} = resolveCardListEntry(card, cardListEntries);
  	const normalizedName = normalizeCardName(cardName);
  	const cardEntryID = encryptedCardNumber ?? normalizedName;
  	const existingEntry = entriesMap.get(cardEntryID);
  	const isRicherRecord = card.lastFourPAN && !existingEntry?.assignedCard?.lastFourPAN;
  	// Skip duplicate when two assigned-card records (e.g. old-format + new-format) resolve to the same cardList entry.
  	if (!existingEntry || isRicherRecord) {
  	entriesMap.set(cardEntryID, {cardName, encryptedCardNumber, isAssigned: true, assignedCard: card});
  	}
  	coveredNames.add(normalizedName);
  	if (encryptedCardNumber !== cardName) {
  	coveredEncrypted.add(encryptedCardNumber);
  	}
  	}

for (const card of Object.values(assignedCards)) {
    if (!card?.cardName) {
        continue;
    }

    const {resolvedCard, ambiguousCardNames} = resolveCardListEntry(card, cardListEntries);
    const {cardName = card.cardName, encryptedCardNumber = card.cardName} = resolvedCard;
    const normalizedName = normalizeCardName(cardName);
    const cardEntryID = encryptedCardNumber ?? normalizedName;

    const existingEntry = entriesMap.get(cardEntryID);

    const isRicherRecord = card.lastFourPAN && !existingEntry?.assignedCard?.lastFourPAN;

    // Skip duplicate when two assigned-card records (e.g. old-format + new-format) resolve to the same cardList entry.
    if (!existingEntry || isRicherRecord) {
        entriesMap.set(cardEntryID, {cardName, encryptedCardNumber, isAssigned: true, assignedCard: card});
    }

    coveredNames.add(normalizedName);
    if (encryptedCardNumber !== cardName) {
        coveredEncrypted.add(encryptedCardNumber);
    }
    for (const ambiguousName of ambiguousCardNames) {
        coveredNames.add(normalizeCardName(ambiguousName));
    }
}

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The Company cards page renders rows from companyCardEntries, which are derived in useCompanyCards() from the selected feed’s cards_... Onyx value by combining assigned cards with remaining cardList entries

App/src/hooks/useCompanyCards.ts

Lines 172 to 178 in 110c724

	const [cardsList, cardListMetadata] = useCardsList(feedName);
	const companyCardFeeds = getCompanyFeeds(allCardFeeds);
	const selectedFeed = feedName && companyCardFeeds[feedName];
	const {cardList, ...assignedCards} = cardsList ?? {};
	const companyCardEntries = buildCompanyCardEntries(selectedFeed?.accountList, cardList, assignedCards, feedName);

buildCompanyCardEntries() is intended to treat assigned cards as the source of truth and skip matching unassigned cardList rows afterward

App/src/hooks/useCompanyCards.ts

Lines 95 to 147 in 110c724

	/**
	* Builds a list of card entries by starting from assignedCards (source of truth for assignments),
	* then filling in remaining unassigned cards from accountList/cardList.
	*/
	function buildCompanyCardEntries(
	accountList: string[] | undefined,
	cardList: AssignableCardsList | undefined,
	assignedCards: CardList,
	feedName?: CompanyCardFeedWithDomainID,
	): CompanyCardEntry[] {
	const entriesMap = new Map<string, CompanyCardEntry>();
	const coveredNames = new Set<string>();
	const coveredEncrypted = new Set<string>();
	const cardListEntries = Object.entries(cardList ?? {});
	// Phase 1: Assigned cards first — these are the source of truth.
	// Previously assigned parent cards are kept visible so admins can manage/unassign them.
	for (const card of Object.values(assignedCards)) {
	if (!card?.cardName) {
	continue;
	}
	const {cardName = card.cardName, encryptedCardNumber = card.cardName} = resolveCardListEntry(card, cardListEntries);
	const normalizedName = normalizeCardName(cardName);
	const cardEntryID = encryptedCardNumber ?? normalizedName;
	const existingEntry = entriesMap.get(cardEntryID);
	const isRicherRecord = card.lastFourPAN && !existingEntry?.assignedCard?.lastFourPAN;
	// Skip duplicate when two assigned-card records (e.g. old-format + new-format) resolve to the same cardList entry.
	if (!existingEntry || isRicherRecord) {
	entriesMap.set(cardEntryID, {cardName, encryptedCardNumber, isAssigned: true, assignedCard: card});
	}
	coveredNames.add(normalizedName);
	if (encryptedCardNumber !== cardName) {
	coveredEncrypted.add(encryptedCardNumber);
	}
	}
	// Phase 2: Add remaining unassigned cards. cardList first so its encryptedCardNumber takes precedence.
	for (const [cardName, encryptedCardNumber] of cardListEntries) {
	const normalizedName = normalizeCardName(cardName);
	if (coveredNames.has(normalizedName) || coveredEncrypted.has(encryptedCardNumber) || entriesMap.has(encryptedCardNumber)) {
	continue;
	}
	entriesMap.set(encryptedCardNumber, {cardName, encryptedCardNumber, isAssigned: false});
	coveredNames.add(normalizedName);
	coveredEncrypted.add(encryptedCardNumber);
	}

but resolveCardListEntry() only does suffix matching with lastFourPAN or the entire assigned cardName

App/src/hooks/useCompanyCards.ts

Lines 62 to 92 in 110c724

	function resolveCardListEntry(card: Card, cardListEntries: Array<[string, string]>): Card {
	const {cardName, encryptedCardNumber, lastFourPAN} = card;
	// Using || instead of ?? because an empty-string lastFourPAN should fall through to cardName
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const panSuffix = lastFourPAN || cardName;
	const isLinkedByEncrypted = encryptedCardNumber && cardListEntries.some(([, entryEncryptedCardNumber]) => entryEncryptedCardNumber === encryptedCardNumber);
	if (isLinkedByEncrypted) {
	return card;
	}
	const normalizedCardName = cardName ? normalizeCardName(cardName) : undefined;
	const matchedByName = normalizedCardName ? cardListEntries.find(([name]) => normalizeCardName(name) === normalizedCardName) : undefined;
	if (matchedByName) {
	return {...card, encryptedCardNumber: matchedByName[1]};
	}
	if (!panSuffix) {
	return card;
	}
	const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);
	// If there are other matched cards, return the original card.
	if (otherMatchedCards.length > 0) {
	return card;
	}
	const [name = cardName, encrypted = encryptedCardNumber] = matchedCard ?? [];
	return {...card, cardName: name, encryptedCardNumber: encrypted};

For some Visa commercial cards, the assigned card record does not have lastFourPAN populated and its cardName is not exactly the same as the commercial feed cardList key, even though both names end with the same last four digits. In that case the assigned card does not cover the matching encrypted cardList entry, so Phase 2 adds the same card again as isAssigned: false.

The table then renders that duplicate unassigned entry exactly as instructed: unassigned rows show the “Unassigned” member label and the Assign button

App/src/components/Tables/WorkspaceCompanyCardsTable/WorkspaceCompanyCardsTableRow.tsx

Lines 98 to 115 in 110c724

	const memberColumnTitle = isAssigned ? Str.removeSMSDomain(cardholder?.displayName ?? '') : translate('workspace.moreFeatures.companyCards.unassignedCards');
	const memberCardSubtitle = shouldUseNarrowTableLayout ? narrowWidthCardName : cardholderLoginText;
	const avatarSize = shouldUseNarrowTableLayout ? CONST.AVATAR_SIZE.DEFAULT : CONST.AVATAR_SIZE.SMALL;
	const subscriptCardFeedIconSize = shouldUseNarrowTableLayout
	? {width: variables.cardAvatarWidth, height: variables.cardAvatarHeight}
	: {width: variables.cardAvatarWidthSmall, height: variables.cardAvatarHeightSmall};
	const canOpenCardDetails = !!assignedCard?.accountID && assignedCard?.cardID !== undefined && !!feedName;
	const canAssignCard = !isAssigned && canWriteCompanyCards && !isAssigningCardDisabled;
	const canPressRow = canOpenCardDetails || canAssignCard;
	const handleRowPress = () => {
	if (!assignedCard) {
	if (!canAssignCard) {
	return;
	}
	onAssignCard(cardName, encryptedCardNumber);

App/src/components/Tables/WorkspaceCompanyCardsTable/WorkspaceCompanyCardsTableRow.tsx

Lines 189 to 197 in 110c724

	<View style={[styles.flexRow, styles.alignItemsCenter, styles.justifyContentEnd, styles.gap3]}>
	{!isAssigned && canWriteCompanyCards && (
	<Button
	small
	success
	text={translate('workspace.companyCards.assign')}
	onPress={handleRowPress}
	isDisabled={isAssigningCardDisabled}
	/>

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

Update resolveCardListEntry() in src/hooks/useCompanyCards.ts so the suffix fallback uses the best available last-four value instead of falling back directly to the full cardName. Specifically, import and use the existing lastFourNumbersFromCardName() helper, then compute the suffix as lastFourPAN || lastFourNumbersFromCardName(cardName) || cardName. That preserves the current exact encrypted and normalized-name matching paths, but also handles assigned Visa/commercial card names that end in four digits while lastFourPAN is missing. lastFourNumbersFromCardName() already extracts a trailing four-digit suffix from spaced card names

App/src/libs/CardUtils.ts

Lines 399 to 413 in 110c724

	/**
	* Returns last 4 number from company card name
	*
	* @param cardName - card name with dash in the middle and 4 numbers in the end.
	* @returns - Last 4 numbers
	*/
	function lastFourNumbersFromCardName(cardName: string | undefined): string {
	const name = cardName ?? '';
	const hasSpace = /\s/.test(name);
	const match = name.match(/(\d{4})$/);
	if (!cardName || cardName === '' || !hasSpace || !match) {
	return '';
	}
	return match[1];
	}

so this keeps the fix aligned with existing card-name parsing behavior.

Add a focused unit test in tests/unit/hooks/useCompanyCards.test.ts for a commercial feed where cardList contains something like 553312XXXXXX0487, while the assigned card has a different display cardName ending in 0487 and no lastFourPAN. The expected result should be a single assigned entry using the matching encrypted cardList value, not one assigned row plus one unassigned row.

What alternative solutions did you explore? (Optional)

I also considered hiding duplicate rows in WorkspaceCompanyCardsTable, but that would only mask one UI surface while leaving companyCardEntries with the wrong assignment state. The source-of-truth fix belongs in the card-entry matching logic before rows are rendered.

[aswin-s]

Proposal

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

On Web, when an admin opens the Visa commercial cards feed under Workspaces > [Workspace] > Company cards and searches for a card by its last four digits, the same card can appear twice: once as already assigned to a member, and once as "Unassigned" with an Assign button. The list should show a card exactly once, reflecting its current assignment status.

What is the root cause of that problem?

In src/libs/CardUtils.ts:1006 getFilteredCardList builds the "already assigned" dedup set with raw string equality: new Set(Object.values(cards).map((card) => card.cardName)) at line 1013 (and allWorkspaceAssignedCards.add(card.cardName) at line 1026), and then filters the commercial-feed entries at line 1042 with !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName). The commercial-feed cardList keys (produced by the feed) and the persisted Card.cardName of the assigned card are both display strings, but they are not guaranteed to be byte-identical — differences in punctuation, spacing, or masking characters (the same normalization gap that motivated normalizeCardName at src/libs/CardUtils.ts:439 and isMatchingCard at line 425, which already normalizes both sides before comparing) cause a Set.has miss. When they diverge, the assigned card slips through the filter and is re-emitted as an UnassignedCard, so it shows up a second time in the CardSelectionStep list at src/pages/workspace/companyCards/assignCard/CardSelectionStep.tsx:64 with an Assign action.

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

1. In src/libs/CardUtils.ts around lines 1013–1046, build both assignedCards and allWorkspaceAssignedCards sets using normalizeCardName(card.cardName) (the same helper already used by isMatchingCard) instead of the raw string, so the dedup is punctuation/whitespace/masking insensitive.
2. In the two filter branches (line 1033 for direct feeds, line 1042 for commercial feeds), compare normalizeCardName(cardName) against the sets rather than the raw key, so a commercial-feed key that visually matches an already-assigned card is excluded.
3. Guard against empty/undefined cardName entries after normalization (skip empty strings) so a stray blank key can't collapse multiple unassigned cards into one.
4. Add a unit test in tests/unit/CardUtilsTest.ts (or the equivalent existing CardUtils test file) covering a Visa commercial feed where the cardList key and the assigned Card.cardName differ by punctuation/spacing, asserting the card is filtered out and does not appear twice.

What alternative solutions did you explore? (Optional)

Dedup by encryptedCardNumber (the commercial-feed value / cardID) rather than by name, but the assigned Card record doesn't reliably carry the same encrypted token, so name normalization is the safer canonical key.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 14:02:47 UTC.

Proposal

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

In a Visa commercial feed, the same card shows up twice on the Workspace > Company cards page: once as already assigned to a member, and once as "Unassigned" with an Assign button — suggesting the admin can assign a card that is already assigned.

What is the root cause of that problem?

The client holds two backend representations of the same physical card: the assigned card record (in the cards_ Onyx collection) and the feed's unassigned cardList map (masked display name → encrypted number). The table correlates them with a 3-step cascade in resolveCardListEntry, and when every step fails, the card's own feed entry is re-added as a second, "Unassigned" row.

1. The page builds rows in buildCompanyCardEntries: assigned records first (Phase 1), then any cardList entry not claimed by an assigned card is added with isAssigned: false (Phase 2):

   App/src/hooks/useCompanyCards.ts

   Lines 99 to 158 in f1182da

   	function buildCompanyCardEntries(
   	accountList: string[] | undefined,
   	cardList: AssignableCardsList | undefined,
   	assignedCards: CardList,
   	feedName?: CompanyCardFeedWithDomainID,
   	): CompanyCardEntry[] {
   	const entriesMap = new Map<string, CompanyCardEntry>();
   	const coveredNames = new Set<string>();
   	const coveredEncrypted = new Set<string>();
   	const cardListEntries = Object.entries(cardList ?? {});
   	// Phase 1: Assigned cards first — these are the source of truth.
   	// Previously assigned parent cards are kept visible so admins can manage/unassign them.
   	for (const card of Object.values(assignedCards)) {
   	if (!card?.cardName) {
   	continue;
   	}
   	const {cardName = card.cardName, encryptedCardNumber = card.cardName} = resolveCardListEntry(card, cardListEntries);
   	const normalizedName = normalizeCardName(cardName);
   	const cardEntryID = encryptedCardNumber ?? normalizedName;
   	const existingEntry = entriesMap.get(cardEntryID);
   	const isRicherRecord = card.lastFourPAN && !existingEntry?.assignedCard?.lastFourPAN;
   	// Skip duplicate when two assigned-card records (e.g. old-format + new-format) resolve to the same cardList entry.
   	if (!existingEntry || isRicherRecord) {
   	entriesMap.set(cardEntryID, {cardName, encryptedCardNumber, isAssigned: true, assignedCard: card});
   	}
   	coveredNames.add(normalizedName);
   	if (encryptedCardNumber !== cardName) {
   	coveredEncrypted.add(encryptedCardNumber);
   	}
   	}
   	// Phase 2: Add remaining unassigned cards. cardList first so its encryptedCardNumber takes precedence.
   	for (const [cardName, encryptedCardNumber] of cardListEntries) {
   	const normalizedName = normalizeCardName(cardName);
   	if (coveredNames.has(normalizedName) || coveredEncrypted.has(encryptedCardNumber) || entriesMap.has(encryptedCardNumber)) {
   	continue;
   	}
   	entriesMap.set(encryptedCardNumber, {cardName, encryptedCardNumber, isAssigned: false});
   	coveredNames.add(normalizedName);
   	coveredEncrypted.add(encryptedCardNumber);
   	}
   	for (const cardName of filterAmexDirectParentCard(accountList ?? [], feedName)) {
   	const normalizedName = normalizeCardName(cardName);
   	if (coveredNames.has(normalizedName) || coveredEncrypted.has(cardName) || entriesMap.has(normalizedName)) {
   	continue;
   	}
   	entriesMap.set(normalizedName, {cardName, encryptedCardNumber: cardName, isAssigned: false});
   	coveredNames.add(normalizedName);
   	}
   	return Array.from(entriesMap.values());

2. Whether an assigned card claims its feed entry is decided by the cascade — encrypted-number match, normalized-name match, then a last-four suffix fallback:

   App/src/hooks/useCompanyCards.ts

   Lines 62 to 93 in f1182da

   	function resolveCardListEntry(card: Card, cardListEntries: Array<[string, string]>): Card {
   	const {cardName, encryptedCardNumber, lastFourPAN} = card;
   	// Using || instead of ?? because an empty-string lastFourPAN should fall through to cardName
   	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
   	const panSuffix = lastFourPAN || cardName;
   	const isLinkedByEncrypted = encryptedCardNumber && cardListEntries.some(([, entryEncryptedCardNumber]) => entryEncryptedCardNumber === encryptedCardNumber);
   	if (isLinkedByEncrypted) {
   	return card;
   	}
   	const normalizedCardName = cardName ? normalizeCardName(cardName) : undefined;
   	const matchedByName = normalizedCardName ? cardListEntries.find(([name]) => normalizeCardName(name) === normalizedCardName) : undefined;
   	if (matchedByName) {
   	return {...card, encryptedCardNumber: matchedByName[1]};
   	}
   	if (!panSuffix) {
   	return card;
   	}
   	const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);
   	// If there are other matched cards, return the original card.
   	if (otherMatchedCards.length > 0) {
   	return card;
   	}
   	const [name = cardName, encrypted = encryptedCardNumber] = matchedCard ?? [];
   	return {...card, cardName: name, encryptedCardNumber: encrypted};
   	}

3. The structural flaw is the fallback on line 67: const panSuffix = lastFourPAN || cardName. lastFourPAN is optional on assigned records (

   App/src/types/onyx/Card.ts

   Line 82 in f1182da

   lastFourPAN?: string;

   ). When it's missing, the "suffix" becomes the ENTIRE cardName, and name.endsWith(panSuffix) (line 84) then requires a feed key to end with the whole assigned name. That never happens when the two sides decorate the number differently — assigned record 480801XXXXXX1238 vs feed key CREDIT CARD...1238. The fallback is dead code for exactly the records that need it.
4. The earlier steps can't save such a record: step 1 fails because encryptedCardNumber is also optional/stale on records assigned via Classic or before the feed re-synced (

   App/src/types/onyx/Card.ts

   Line 91 in f1182da

   encryptedCardNumber?: string;

   ), and step 2 fails because normalizeCardName only strips punctuation, so differently-decorated masked names never normalize equal:

   App/src/libs/CardUtils.ts

   Lines 439 to 441 in f1182da

   	function normalizeCardName(cardName: string): string {
   	return cardName.replaceAll(/[^\w\s-]/g, '').trim();
   	}

5. With the card unlinked, Phase 1 marks only the assigned record's own name/number as covered (lines 131–134), so Phase 2 re-adds the card's real feed entry as unassigned (line 144). The table renders both rows (

   App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

   Lines 193 to 210 in f1182da

   	.map(({cardName, encryptedCardNumber, isAssigned, assignedCard}) => {
   	const cardholder = assignedCard?.accountID ? personalDetails?.[assignedCard.accountID] : undefined;
   	return {
   	cardName,
   	keyForList: `${cardName}_${assignedCard?.cardID ?? 'unassigned'}_${encryptedCardNumber}`,
   	encryptedCardNumber,
   	customCardName: getCompanyCardCustomName(assignedCard?.cardID, sharedCardCustomNames, customCardNames) ?? getDefaultCardName(cardholder?.displayName ?? ''),
   	isCardDeleted: assignedCard?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
   	isAssigned,
   	assignedCard,
   	cardholder,
   	errors: isFeedConnectionBroken || assignedCard?.pendingFields?.lastScrape ? undefined : assignedCard?.errors,
   	pendingAction: assignedCard?.pendingAction,
   	onDismissError: () => resetFailedWorkspaceCompanyCardUnassignment(domainOrWorkspaceAccountID, bankName, assignedCard?.cardID),
   	};
   	})
   	.filter((item) => isOffline || item.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);

   ), and searching by last four matches both because the token search runs on cardName (

   App/src/components/Tables/WorkspaceCompanyCardsTable/index.tsx

   Lines 252 to 263 in f1182da

   	const isItemInSearch: IsItemInSearchCallback<WorkspaceCompanyCardTableItemData> = (item, searchString) => {
   	const searchLower = searchString.toLowerCase();
   	// Include assigned/unassigned cards if the user is typing "Unassigned" or "Assigned" (localized)
   	const isAssignedCardMatch = assignedKeyword.startsWith(searchLower) && item.isAssigned;
   	const isUnassignedCardMatch = unassignedKeyword.startsWith(searchLower) && !item.isAssigned;
   	const searchTokens = [item.cardName, item.customCardName ?? '', item.cardholder?.displayName ?? '', item.cardholder?.login ?? ''];
   	const matchingItems = tokenizedSearch([item], searchString, () => searchTokens);
   	return matchingItems.length > 0 || isAssignedCardMatch || isUnassignedCardMatch;
   	};

   ) — exactly the screenshot.
6. Second trigger, same outcome: even with lastFourPAN present, the ambiguity guard (lines 87–89) bails when two feed cards share the same last four, again leaving the assigned card unlinked.

This bug is NOT confined to the table. The Assign-card flow uses getFilteredCardList, which is an even weaker matcher — a raw exact-string Set on cardName with no normalization, no encrypted match, no last-four fallback (

App/src/libs/CardUtils.ts

Lines 1006 to 1047 in f1182da

	function getFilteredCardList(
	list: WorkspaceCardsList | undefined,
	accountList: string[] | undefined,
	workspaceCardFeeds: OnyxCollection<WorkspaceCardsList>,
	feedName?: CompanyCardFeedWithDomainID,
	): UnassignedCard[] {
	const {cardList: customFeedCardsToAssign, ...cards} = list ?? {};
	const assignedCards = new Set(Object.values(cards).map((card) => card.cardName));
	// Get cards assigned across all workspaces
	const allWorkspaceAssignedCards = new Set<string>();
	for (const workspaceCards of Object.values(workspaceCardFeeds ?? {})) {
	if (!workspaceCards) {
	continue;
	}
	const {cardList, ...workspaceCardItems} = workspaceCards;
	for (const card of Object.values(workspaceCardItems)) {
	if (!card?.cardName) {
	continue;
	}
	allWorkspaceAssignedCards.add(card.cardName);
	}
	}
	// For direct feeds (Plaid/OAuth): displayName === cardIdentifier
	if (accountList) {
	return filterAmexDirectParentCard(accountList, feedName)
	.filter((cardName) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
	.map((cardName) => ({
	cardName,
	cardID: cardName,
	}));
	}
	// For commercial feeds: displayName is the key, cardIdentifier is the encrypted value
	return Object.entries(customFeedCardsToAssign ?? {})
	.filter(([cardName]) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
	.map(([cardName, encryptedCardNumber]) => ({
	cardName,
	cardID: encryptedCardNumber,
	}));
	}

, exact match at L1013/L1042). So the already-assigned card is also offered for selection inside the flow, at both call sites:

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

Line 64 in f1182da

const filteredCardList = getFilteredCardList(list, cardFeeds?.[feed]?.accountList, workspaceCardFeeds, feed);

and

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

Line 45 in f1182da

const filteredCardList = getFilteredCardList(list, cardFeeds?.[feed]?.accountList, workspaceCardFeeds, feed);

— the admin can actually walk into the double assignment. Narrow and wide layouts share this data path, and the code is platform-shared, matching the desktop-web repro. This also explains why QA can't reproduce: cards freshly assigned in New Expensify store a matching encryptedCardNumber, so step 1 links them; only records with the older shape (Classic assignments, re-synced feeds) hit the dead fallback.

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

Two small changes at the correlation points:

1. In resolveCardListEntry, derive the actual last four digits when lastFourPAN is missing, instead of using the whole name as a suffix:

// eslint-disable-next-line `@typescript-eslint`/prefer-nullish-coalescing
const panSuffix = lastFourPAN || cardName?.match(/(\d{4})$/)?.at(0);

This makes the fallback live for both decorations (480801XXXXXX1238 and CREDIT CARD...1238 both yield 1238), while keeping the exactly-one-candidate guard so we still refuse to guess when two feed cards share a last four. (We can't reuse lastFourNumbersFromCardName — its hasSpace guard returns '' for space-less masked PANs:

App/src/libs/CardUtils.ts

Lines 405 to 413 in f1182da

	function lastFourNumbersFromCardName(cardName: string | undefined): string {
	const name = cardName ?? '';
	const hasSpace = /\s/.test(name);
	const match = name.match(/(\d{4})$/);
	if (!cardName || cardName === '' || !hasSpace || !match) {
	return '';
	}
	return match[1];
	}

.)

2. Extract the Phase-1 "claimed entries" resolution from buildCompanyCardEntries into a shared CardUtils helper and use it in getFilteredCardList, replacing the exact-string assignedCards.has(cardName) filter — so the Assign flow stops offering cards the table now correctly shows as assigned.

Regression safety in one sentence: both functions keep their return shapes and only widen which feed entries an assigned card claims; a record with no unique confident match behaves exactly as today, and the ambiguity guard is preserved.

Why the obvious spot-fix fails: deduping table rows by trailing digits alone (or always linking on last four) mislinks the moment a feed contains two cards ending in the same four digits — the guard at lines 87–89 was added in #83737 precisely for that, and with ~100+ cards a shared last-four is more likely than not; and patching only buildCompanyCardEntries fixes the table while getFilteredCardList's exact-string match still offers the same assigned card inside the Assign flow. The cascade itself was introduced by PR #83737 ("Fix duplicate assign card rows for commercial feed cards", merged 2026-03-24) to fix this symptom class — this change completes that PR's intent (its fallback shipped dead), it does not revert it.

What alternative solutions did you explore? (Optional)

• Last-four-only row dedup in the table: incomplete — wrongly merges two distinct cards sharing a last four and leaves the Assign flow unfixed.
• Relaxing lastFourNumbersFromCardName's hasSpace guard and reusing it: touches its display consumers (e.g. card-selection labels), a wider blast radius than an inline derivation in the one matcher that needs it.
• The upstream cure is the backend always returning lastFourPAN/current encryptedCardNumber on assigned commercial cards, but the client must still render historical records correctly, so the in-App fix above stands on its own.

[oqildev]

Proposal

What is the root cause of that problem?

getFilteredCardList in CardUtils.ts decides which commercial-feed cards are still "available to assign," and it de-dupes against already-assigned cards using raw cardName string equality only.

It builds the assigned sets purely from card.cardName — both for the current feed and across every workspace feed:

App/src/libs/CardUtils.ts

Lines 1012 to 1028 in f1182da

	const {cardList: customFeedCardsToAssign, ...cards} = list ?? {};
	const assignedCards = new Set(Object.values(cards).map((card) => card.cardName));
	// Get cards assigned across all workspaces
	const allWorkspaceAssignedCards = new Set<string>();
	for (const workspaceCards of Object.values(workspaceCardFeeds ?? {})) {
	if (!workspaceCards) {
	continue;
	}
	const {cardList, ...workspaceCardItems} = workspaceCards;
	for (const card of Object.values(workspaceCardItems)) {
	if (!card?.cardName) {
	continue;
	}
	allWorkspaceAssignedCards.add(card.cardName);
	}
	}

Then, for commercial feeds (Visa/Mastercard/Amex), it filters the assignable pool — cardList, a Record<displayName, encryptedCardNumber> — by that same exact-string set:

App/src/libs/CardUtils.ts

Lines 1040 to 1046 in f1182da

	// For commercial feeds: displayName is the key, cardIdentifier is the encrypted value
	return Object.entries(customFeedCardsToAssign ?? {})
	.filter(([cardName]) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
	.map(([cardName, encryptedCardNumber]) => ({
	cardName,
	cardID: encryptedCardNumber,
	}));

The pool key is the display name returned by the card provider, while the assigned card's stored cardName is not guaranteed to be the identical string. The codebase already knows these two forms drift apart — isMatchingCard treats a card as the same card when encryptedCardNumber matches, and falls back to a normalizeCardName comparison precisely because OAuth/commercial providers return names with special characters (®, ™, ©) that differ from the stored name:

App/src/libs/CardUtils.ts

Lines 425 to 441 in f1182da

	function isMatchingCard(card: Card, encryptedCardNumber: string, cardName: string): boolean {
	if (card.encryptedCardNumber === encryptedCardNumber) {
	return true;
	}
	if (!card.cardName || !cardName) {
	return false;
	}
	return normalizeCardName(card.cardName) === normalizeCardName(cardName);
	}
	// Normalize both strings to remove special characters (®, ™, ©, etc.)
	// This handles differences between OAuth provider card names and stored card names
	function normalizeCardName(cardName: string): string {
	return cardName.replaceAll(/[^\w\s-]/g, '').trim();
	}

Because getFilteredCardList uses Set.has(cardName) instead of the encryptedCardNumber/normalized identity that isMatchingCard encodes, whenever an assigned Visa card's cardName differs even slightly from the pool's display-name key, the filter fails to drop it. The same card then renders twice: the real assigned row, plus a pool row with an Assign button. This matches the "cannot reproduce" nature of the report — it only fires for cards whose provider display name isn't byte-for-byte equal to the stored assigned cardName.

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

Fix the selector getFilteredCardList. The commercial-feed pool already carries encryptedCardNumber as its map value, and assigned commercial cards also carry encryptedCardNumber (that's what isMatchingCard keys on), so match on that stable identifier rather than the fragile display string.

• When building the assigned sets at

  App/src/libs/CardUtils.ts

  Lines 1012 to 1028 in f1182da

  	const {cardList: customFeedCardsToAssign, ...cards} = list ?? {};
  	const assignedCards = new Set(Object.values(cards).map((card) => card.cardName));
  	// Get cards assigned across all workspaces
  	const allWorkspaceAssignedCards = new Set<string>();
  	for (const workspaceCards of Object.values(workspaceCardFeeds ?? {})) {
  	if (!workspaceCards) {
  	continue;
  	}
  	const {cardList, ...workspaceCardItems} = workspaceCards;
  	for (const card of Object.values(workspaceCardItems)) {
  	if (!card?.cardName) {
  	continue;
  	}
  	allWorkspaceAssignedCards.add(card.cardName);
  	}
  	}

  , also collect each assigned card's encryptedCardNumber into a companion set, plus a normalizeCardName(cardName) set.
• In the commercial-feed branch (

  App/src/libs/CardUtils.ts

  Lines 1040 to 1046 in f1182da

  	// For commercial feeds: displayName is the key, cardIdentifier is the encrypted value
  	return Object.entries(customFeedCardsToAssign ?? {})
  	.filter(([cardName]) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
  	.map(([cardName, encryptedCardNumber]) => ({
  	cardName,
  	cardID: encryptedCardNumber,
  	}));

  ), exclude a [cardName, encryptedCardNumber] entry when its encryptedCardNumber is in the assigned-encrypted set, or its normalized name matches an assigned normalized name — i.e. reuse the same identity rule isMatchingCard already applies.

Leave the direct-feed branch (Plaid/OAuth) at

App/src/libs/CardUtils.ts

Lines 1030 to 1038 in f1182da

	// For direct feeds (Plaid/OAuth): displayName === cardIdentifier
	if (accountList) {
	return filterAmexDirectParentCard(accountList, feedName)
	.filter((cardName) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
	.map((cardName) => ({
	cardName,
	cardID: cardName,
	}));
	}

as-is, since there displayName === cardIdentifier and there is no separate encrypted value.

Edge cases the fix touches: the empty pool still returns []; a pool entry with a missing/empty encryptedCardNumber falls back to the normalized-name comparison; and the cross-workspace exclusion keeps working because it now compares on both keys. No offline/optimistic-rollback path changes — this is a pure read-side filter over Onyx card data, so an unassign that rolls back simply re-adds the assigned card to Onyx and the filter recomputes.

What alternative solutions did you explore? (Optional)

Only normalize the cardName on both sides (run normalizeCardName over pool keys and assigned names) without touching encrypted numbers. Rejected: it fixes the special-character case but still keys on display strings, which can differ for reasons beyond punctuation (masking/format from the provider), so a normalized-name-only match can still leak a duplicate. encryptedCardNumber is the authoritative identity for commercial cards and is present on both sides, so it must be the primary key with normalized name as fallback.

Fixing it server-side (stop returning already-assigned cards inside the feed's cardList) is structurally different and would work, but it's out of scope for this repo, and the client already owns the assignable-list computation, so it should de-dupe defensively regardless.

[samranahm]

Proposal

What is the root cause of that problem?

When an admin opens the Visa commercial feed and searches by the last four digits, the same card is listed twice: once as Unassigned with an Assign button, and once as already assigned to a member. This happens because the list of cards that are still available to assign is built from the feed's cardList minus the cards that already have an assignment, and the matching key used to remove assigned cards differs between direct feeds and commercial feeds.

The card identifier semantics are documented in AssignCard.ts:

App/src/types/onyx/AssignCard.ts

Lines 20 to 21 in f1182da

	* - For direct feeds (Plaid/OAuth): equals cardName
	* - For commercial feeds (Visa/Mastercard/Amex): encrypted value from cardList

For direct (Plaid/OAuth) feeds the assigned card key equals cardName, but for commercial feeds (Visa/Mastercard/Amex) it is the encrypted value from cardList. The helper that filters out already-assigned cards from the assignable list (getFilteredCardList in CardUtils.ts) compares the plaintext cardList entry (or last-four) against the assigned card key. For a commercial Visa feed that key is encrypted, so the comparison never matches, the assigned card is not removed from cardList, and it re-appears as Unassigned alongside its real assigned entry.

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

1. In CardUtils.ts, getFilteredCardList builds the assignable card list by removing entries that already exist in the feed's assigned cards. Update the exclusion so it matches commercial feed cards by the encrypted cardList value (the same identifier stored as the assigned card's cardName), not by the plaintext number or last-four.

https://github.com/Expensify/App/blob/f1182daf70096be2ebb544dd40ffea4750a3565a/src/libs/CardUtils.ts

const assignedEncryptedKeys = new Set(Object.values(assignedCards ?? {}).map((card) => card.cardName));
const availableCardList = Object.fromEntries(
    Object.entries(cardList ?? {}).filter(([encryptedCardNumber]) => !assignedEncryptedKeys.has(encryptedCardNumber)),
);

This removes the already-assigned Visa card from the assignable list for commercial feeds, so it no longer shows an Assign button while it is assigned, which matches the expected result.

2. Confirm the assign flow page that renders the "available to assign" selection consumes the deduped output of getFilteredCardList (rather than the raw feed cardList), so the fix flows through to the UI list the admin sees after searching by last four digits.

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.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 14:03:06 UTC.

Proposal

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

In a commercial Visa card feed (Workspace > Company cards), a card that is already assigned to a workspace member also appears as an Unassigned row with an Assign button. The same physical card is listed twice and looks assignable when it is not.

What is the root cause of that problem?

The feed's rows are built by buildCompanyCardEntries in src/hooks/useCompanyCards.ts in two phases. Phase 1 emits the assigned cards (the source of truth) and records each one's identity in coveredNames (normalized cardName) and coveredEncrypted (its encrypted number). Phase 2 walks the feed's cardList and emits every entry as unassigned, skipping only those already covered:

App/src/hooks/useCompanyCards.ts

Lines 137 to 147 in f1182da

	// Phase 2: Add remaining unassigned cards. cardList first so its encryptedCardNumber takes precedence.
	for (const [cardName, encryptedCardNumber] of cardListEntries) {
	const normalizedName = normalizeCardName(cardName);
	if (coveredNames.has(normalizedName) || coveredEncrypted.has(encryptedCardNumber) || entriesMap.has(encryptedCardNumber)) {
	continue;
	}
	entriesMap.set(encryptedCardNumber, {cardName, encryptedCardNumber, isAssigned: false});
	coveredNames.add(normalizedName);
	coveredEncrypted.add(encryptedCardNumber);
	}

So a cardList entry is suppressed only when it shares an exact encryptedCardNumber or an exact normalized cardName with an assigned card. The identity that Phase 1 records comes from resolveCardListEntry, which tries to bind the assigned Card to its cardList entry by encrypted match → normalized-name match → last-4 (PAN) suffix match. The suffix branch is the fragile one: it only binds when exactly one cardList entry ends with that suffix, and bails out otherwise:

App/src/hooks/useCompanyCards.ts

Lines 84 to 89 in f1182da

	const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);
	// If there are other matched cards, return the original card.
	if (otherMatchedCards.length > 0) {
	return card;
	}

For a commercial Visa feed the assigned Card record and its cardList entry routinely carry different masked names/number formats, and the assigned record often doesn't hold the feed's encrypted value. When encrypted and normalized-name both miss and the last-4 is ambiguous (several commercial cards share a last-4), resolveCardListEntry returns the card unbound. Phase 1 then covers only the assigned card's own name/number — which don't equal the cardList entry — so Phase 2 finds nothing to skip and re-emits that same card as unassigned. The result is one row assigned to the member and a second Unassigned row with an Assign button for the identical card.

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

Pair each assigned card that could not be bound to a cardList entry with a cardList entry of the same last-4, one-to-one, so its twin is never re-emitted as unassigned — while any genuinely distinct extra card with that same last-4 still surfaces.

In buildCompanyCardEntries, precompute what the feed actually contains and a multiset of the last-4 suffixes of unbound assigned cards during Phase 1:

const getLastFour = (value?: string) => value?.match(/(\d{4})$/)?.[1] ?? '';

const cardListEncrypted = new Set(cardListEntries.map(([, encrypted]) => encrypted));
const cardListNames = new Set(cardListEntries.map(([name]) => normalizeCardName(name)));
const unboundAssignedSuffixes = new Map<string, number>();

Inside the Phase 1 loop, after cardName / encryptedCardNumber / normalizedName are resolved, flag the cards that never bound to a cardList entry:

const boundToCardList = cardListEncrypted.has(encryptedCardNumber) || cardListNames.has(normalizedName);
if (!boundToCardList) {
    const suffix = getLastFour(card.lastFourPAN ?? cardName);
    if (suffix) {
        unboundAssignedSuffixes.set(suffix, (unboundAssignedSuffixes.get(suffix) ?? 0) + 1);
    }
}

Then in Phase 2, before emitting a cardList entry as unassigned, consume one unit of matching coverage:

const suffix = getLastFour(cardName);
const remaining = suffix ? (unboundAssignedSuffixes.get(suffix) ?? 0) : 0;
if (remaining > 0) {
    unboundAssignedSuffixes.set(suffix, remaining - 1);
    continue;
}

Because coverage is consumed one-to-one, N unbound assigned cards suppress exactly N cardList entries with that last-4; the already-assigned Visa card is emitted once (assigned) and never reappears as Unassigned, and if the feed genuinely holds more cards with the same last-4 than are assigned, the surplus still shows up as assignable.

The same exact-match assumption also lives in getFilteredCardList (the Assign-card selection step), which filters cardList against a Set of raw card.cardName values; it should get the same normalized/last-4 treatment so the assign step and the feed stay consistent.

The more durable direction is data-side: persist the feed's encrypted card number (the cardID used at assignment) onto the assigned Card, so resolveCardListEntry binds deterministically by encrypted number and never has to fall back to ambiguous masked-name/last-4 matching.

What specific scenarios should we cover in automated tests to prevent this bug from happening again in the future? (Optional, but preferred)

Unit tests for buildCompanyCardEntries:

• An assigned card whose encryptedCardNumber and cardName don't match its cardList entry but share the last-4 → returns a single entry with isAssigned: true and no isAssigned: false duplicate.
• Two distinct cardList entries share a last-4 while only one is assigned → returns exactly one assigned entry plus one unassigned entry (no over-suppression of the genuinely distinct card).
• An assigned card that binds by exact encryptedCardNumber or normalized cardName → still yields a single assigned entry (no regression to existing coverage).

What alternative solutions did you explore? (Optional)

I considered de-duplicating in the view by dropping an Unassigned row in WorkspaceCompanyCardsTable when an assigned row with the same last-4 exists, but that pushes identity logic into the render layer and would hide legitimately distinct cards that share a last-4. Fixing the pairing at the source in buildCompanyCardEntries keeps a single correct entry per physical card and preserves genuinely distinct ones.

[lorretheboy]

Note: This isn't a duplicate — The single proposal ProposalPolice flagged us against carries no content — it is only the stub "Duplicated proposal withdrawn by ProposalPolice," stating neither a root cause nor a fix. Ours cannot share "the same root cause AND essentially the same fix" with a proposal that asserts neither, so the duplicate flag against it cannot stand. Our proposal, by contrast, names a concrete, code-verified root cause (the panSuffix = lastFourPAN || cardName whole-name suffix fallback in resolveCardListEntry) and a specific fix (derive the trailing four digits from cardName), so there is nothing in the flagged proposal for it to restate.

Proposal

What is the root cause of that problem?

The Company Cards table builds its rows in buildCompanyCardEntries: assigned cards go in first, and any cardList entry that couldn't be linked to an assigned card is then added as a second, "Unassigned" row:

App/src/hooks/useCompanyCards.ts

Lines 137 to 147 in f1182da

	// Phase 2: Add remaining unassigned cards. cardList first so its encryptedCardNumber takes precedence.
	for (const [cardName, encryptedCardNumber] of cardListEntries) {
	const normalizedName = normalizeCardName(cardName);
	if (coveredNames.has(normalizedName) || coveredEncrypted.has(encryptedCardNumber) || entriesMap.has(encryptedCardNumber)) {
	continue;
	}
	entriesMap.set(encryptedCardNumber, {cardName, encryptedCardNumber, isAssigned: false});
	coveredNames.add(normalizedName);
	coveredEncrypted.add(encryptedCardNumber);
	}

Linking is done by resolveCardListEntry with a cascade: exact encryptedCardNumber match → normalized-name match → last-4-digits suffix match. The suffix fallback is broken: when the assigned card has no lastFourPAN, it uses the entire cardName as the suffix:

App/src/hooks/useCompanyCards.ts

Lines 64 to 92 in f1182da

	// Using || instead of ?? because an empty-string lastFourPAN should fall through to cardName
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const panSuffix = lastFourPAN || cardName;
	const isLinkedByEncrypted = encryptedCardNumber && cardListEntries.some(([, entryEncryptedCardNumber]) => entryEncryptedCardNumber === encryptedCardNumber);
	if (isLinkedByEncrypted) {
	return card;
	}
	const normalizedCardName = cardName ? normalizeCardName(cardName) : undefined;
	const matchedByName = normalizedCardName ? cardListEntries.find(([name]) => normalizeCardName(name) === normalizedCardName) : undefined;
	if (matchedByName) {
	return {...card, encryptedCardNumber: matchedByName[1]};
	}
	if (!panSuffix) {
	return card;
	}
	const [matchedCard, ...otherMatchedCards] = cardListEntries.filter(([name]) => name.endsWith(panSuffix)).slice(0, 2);
	// If there are other matched cards, return the original card.
	if (otherMatchedCards.length > 0) {
	return card;
	}
	const [name = cardName, encrypted = encryptedCardNumber] = matchedCard ?? [];
	return {...card, cardName: name, encryptedCardNumber: encrypted};

Visa commercial feeds have supplied card names in two formats over time (e.g. an assigned card stored as CREDIT CARD - 2554 / VISA - 2554, while the re-synced cardList key is the masked PAN 480801XXXXXX2554). For such a card with an empty lastFourPAN, all three matchers miss: the encrypted value differs between syncs, the normalized names differ, and '480801XXXXXX2554'.endsWith('CREDIT CARD - 2554') is false — the whole-name suffix only works for legacy bare-digit names like 0487. The assigned card is therefore never marked as covering its cardList entry, so Phase 2 re-adds the same physical card as an Unassigned row with an Assign button — the duplicate the issue reports.

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

In resolveCardListEntry, derive the trailing four digits from cardName for the suffix fallback instead of using the raw name, e.g.:

const panSuffix = lastFourPAN || cardName?.match(/\d{4}$/)?.at(0);

480801XXXXXX2554, VISA - 2554, and CREDIT CARD - 2554 all yield 2554, which suffix-matches the differently-formatted cardList key, so the card is linked and only the assigned row renders. Legacy bare names like 0487 still work (their trailing digits are the whole name), and the existing bail-out when several cardList entries share the same last four stays as the ambiguity guard.

The assign-card flow has the same weakness at its own filter — getFilteredCardList only excludes a cardList entry when the assigned card's cardName matches the key exactly:

App/src/libs/CardUtils.ts

Lines 1041 to 1046 in f1182da

	return Object.entries(customFeedCardsToAssign ?? {})
	.filter(([cardName]) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
	.map(([cardName, encryptedCardNumber]) => ({
	cardName,
	cardID: encryptedCardNumber,
	}));

so the same already-assigned card also appears as selectable in CardSelectionStep. We should apply the same last-4 matching there.

What alternative solutions did you explore? (Optional)

Making normalizeCardName comparisons match on extracted last-4 digits globally — rejected because last-4 collisions across genuinely different cards would then merge distinct cards; keeping last-4 as a fallback (with the existing multiple-match bail-out) is safer.