[$250] [VBBA] connectBankAccountWithPlaid can send bankAccountID as NaN after verify-account resume flow

[c3024]

Problem

In the USD reimbursement bank account flow, the CONNECT_BANK_ACCOUNT_WITH_PLAID request can be sent with bankAccountID=NaN.

Reproduction

1. Use an account where account.validated is false.
2. Go to workspace bank account setup.
3. Choose Connect online with Plaid.
4. App redirects to verify account (ROUTES.BANK_ACCOUNT_VERIFY_ACCOUNT.getRoute(policyID, backTo)).
5. Complete validation and return to the reimbursement flow.
6. Complete Plaid auth, select a bank account (Savings/Checking), and continue (quick click on Next makes this easier to hit).
7. Inspect the API payload for CONNECT_BANK_ACCOUNT_WITH_PLAID:
   • bankAccountID is sent as "NaN".

Root Cause

• The unvalidated path in VerifiedBankAccountFlowEntryPoint.handleConnectPlaid() returns early and navigates to verification.
• After validation, flow resumes via reimbursementAccountOptionPressed state.
• In this resumed path, reimbursementAccount.achData.bankAccountID can still be missing.
• BankInfo computes:
  • Number(reimbursementAccount?.achData?.bankAccountID)
  • If source is undefined, result is NaN.
• connectBankAccountWithPlaid() builds request params with this value, so payload can contain NaN.

Impact

• Frontend logic that relies on bankAccountID === 0 (notably Chase manual fallback checks) can be bypassed when value is NaN.
• Backend coercion currently masks this in some cases ("NaN" -> 0), which hides the client-side correctness issue.

Expected Behavior

bankAccountID should never be NaN in client payloads. For new/setup flows, it should consistently be 0.

PR Scope

• Normalize bankAccountID before request creation in connectBankAccountWithPlaid (non-finite -> CONST.DEFAULT_NUMBER_ID).
• Ensure resumed post-validation flow initializes bank setup state consistently.

Issue Owner

Current Issue Owner: @ikevin127

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034553283540872833
• Upwork Job ID: 2034553283540872833
• Last Price Increase: 2026-03-19

[c3024]

This is not open for proposals. I am working on this issue.

[MelvinBot]

Proposal

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

In the USD reimbursement bank account flow, CONNECT_BANK_ACCOUNT_WITH_PLAID can be sent with bankAccountID=NaN. This happens when a user with an unvalidated account goes through the verify-account redirect, then resumes the Plaid connect flow. The NaN value bypasses frontend logic that relies on bankAccountID === 0 (e.g., Chase manual fallback checks).

What is the root cause of that problem?

BankInfo.tsx at line 54 computes:

const bankAccountID = Number(reimbursementAccount?.achData?.bankAccountID);

When achData.bankAccountID is undefined (which it is for new account setups before the backend allocates one, and specifically after the verify-account resume flow where removeExistingBankAccountDetails() is not called), Number(undefined) produces NaN.

This NaN is passed directly to connectBankAccountWithPlaid() at BankAccounts.ts:257-271, which forwards it into the API request params with zero validation.

Why the resume flow specifically triggers this: In VerifiedBankAccountFlowEntryPoint, the happy path (handleConnectPlaid) calls removeExistingBankAccountDetails() which sets bankAccountID: 0 via updateReimbursementAccount. But the resume-after-validation path (the useEffect that fires when isAccountValidated becomes true) skips removeExistingBankAccountDetails(), leaving bankAccountID as undefined.

Two additional components have the same vulnerability:

Component	File	Line	Status
BankInfo	src/pages/ReimbursementAccount/USD/BankInfo/BankInfo.tsx	54	Missing fallback
PersonalInfo	src/pages/ReimbursementAccount/USD/Requestor/PersonalInfo/PersonalInfo.tsx	40	Missing fallback
CompleteVerification	src/pages/ReimbursementAccount/USD/CompleteVerification/CompleteVerification.tsx	35	Missing fallback

Three sibling components already use the correct pattern:

Component	File	Line
BusinessInfo	src/pages/ReimbursementAccount/USD/BusinessInfo/BusinessInfo.tsx	68
BeneficialOwnersStep	src/pages/ReimbursementAccount/USD/BeneficialOwnerInfo/BeneficialOwnersStep.tsx	72
BankAccountValidationForm	src/pages/ReimbursementAccount/USD/ConnectBankAccount/components/BankAccountValidationForm.tsx	93

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

1. Add the ?? CONST.DEFAULT_NUMBER_ID fallback to all three vulnerable components to match the established pattern:

   • BankInfo.tsx:54 → Number(reimbursementAccount?.achData?.bankAccountID ?? CONST.DEFAULT_NUMBER_ID)
   • PersonalInfo.tsx:40 → same pattern
   • CompleteVerification.tsx:35 → same pattern

2. Add a defensive guard in connectBankAccountWithPlaid (BankAccounts.ts) to normalize non-finite bankAccountID values to CONST.DEFAULT_NUMBER_ID before building the request params. This provides a safety net at the API boundary regardless of which component calls it.

3. Fix the resume flow in VerifiedBankAccountFlowEntryPoint to call removeExistingBankAccountDetails() (or at minimum initialize bankAccountID: 0) when resuming after validation, matching the happy path behavior.

What alternative solutions did you explore? (Optional)

• Guard only at the API layer (in connectBankAccountWithPlaid): Simpler but doesn't fix the same pattern in PersonalInfo and CompleteVerification which call different API functions.
• Guard only at the component level: Fixes the immediate symptom but leaves the API function vulnerable to future callers passing NaN.
• Applying both layers (component + API) is the most robust approach and matches the defensive pattern already used in BankAccountValidationForm.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[c3024]

@MelvinBot this is not open for proposals by external contributors.

[MelvinBot]

Understood — I've removed the External label. My earlier comment was an analysis posted in response to a /analyze-issue request, not an external proposal. The analysis and root cause findings are still available above for reference as you work on the fix.