[$250] Generic Error When Adding Canadian Bank Account Due to Untrimmed Whitespace in Input Fields

[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: v9.3.61-4
Reproducible in staging?: Unable to reproduce (Reproduction blocked)
Reproducible in production?: Unable to reproduce
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: @marianaabussamra
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to Account → Wallet
2. Select an existing bank account to continue setup
3. Proceed through the flow until Step 5 (Director information)
4. Select “No” for being a director
5. Enter a director’s email address
6. Submit and observe behavior

Expected Result:

User should:
Successfully proceed to the next step after entering a valid director email
All input fields should:
Be trimmed (remove leading/trailing whitespace) before API submission

Actual Result:

User receives:
Generic error: “Oops, an error has occurred”
Flow does not proceed despite valid input

Note:

It seems like this bug is caused by an extra whitespace in the bankPostal field in the flow not being trimmed before being sent to the API, and we want to fix this in all the fields (bankPostal, bankCity, bankRegion, bankAddressLine1, bankAddressLine2, bankName, accountNumber}

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

Issue Owner

Current Issue Owner: @Tony-MK

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049135246401806293
• Upwork Job ID: 2049135246401806293
• Last Price Increase: 2026-04-28

[MelvinBot]

Proposal

What is the root cause of that problem?

String fields (e.g. bankPostal, bankCity, bankRegion, bankAddressLine1, bankAddressLine2, bankName, accountNumber) entered during the Canadian (NonUSD/Corpay) bank account setup flow are never trimmed of leading/trailing whitespace. The values flow from the UI through Onyx draft storage and are serialized directly via JSON.stringify(fields) in createCorpayBankAccount before being sent to the backend. When a field like bankPostal contains a trailing space (e.g. "M5V 2T6 "), the backend validation rejects it, producing the generic "Oops, an error has occurred" error.

The same issue applies to createCorpayBankAccountForWalletFlow which follows the identical pattern.

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

In BankAccounts.ts, trim all string field values before serialization in both functions:

1. In createCorpayBankAccount (~line 681): before JSON.stringify(fields), iterate over fields and .trim() every string value.
2. In createCorpayBankAccountForWalletFlow (~line 1375): same treatment on inputData before JSON.stringify(inputData).

A simple helper like StringUtils.trimAllStringValues(obj) that maps over an object's values and trims strings would keep both call sites clean.

What alternative solutions did you explore? (Optional)

• Trimming at the form/UI layer (in useStepFormSubmit or FormProvider): This would be more systemic but has a wider blast radius — it would affect all forms in the app, not just the bank account flow. A targeted fix at the API submission point is safer and sufficient.
• Trimming individual fields by name: More brittle — the Corpay fields are dynamic (fetched from the API), so hardcoding field names would miss future fields.

---

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 - @ShridharGoel (External)

[melvin-bot]

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

[aswin-s]

Proposal

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

When a user enters leading or trailing whitespace in the Canadian Corpay bank-account flow, the confirmation step and final BANK_ACCOUNT_CREATE_CORPAY request can still be built from the untrimmed draft values, so Corpay rejects the request and the user only sees a generic add-bank-account failure.

What is the root cause of that problem?

The root cause is in the shared multi-step submit flow, not in the final JSON.stringify() call.

1. src/components/Form/FormProvider.tsx already submits sanitized values.
   Before calling onSubmit, it runs prepareValues() from src/libs/ValidationUtils.ts, which uses StringUtils.removeInvisibleCharacters() and ends with .trim().

2. At the same time, draft-backed inputs save raw keystrokes directly into ${formID}Draft.
   In FormProvider.registerInput().onInputChange(), any input with shouldSaveDraft writes the raw value to draft immediately.

3. src/hooks/useStepFormSubmit.ts only persists submitted step values to draft when shouldSaveDraft === true.
   In the initial create flow, these Corpay steps pass shouldSaveDraft: isEditing, so on first-time entry that branch is false. The hook just calls onNext() and never overwrites the raw autosaved draft with the already-trimmed submit values.

4. Both affected Corpay flows rebuild later screens and final payloads from that draft-backed state:

   • Wallet flow:
     • src/pages/settings/Wallet/InternationalDepositAccount/InternationalDepositAccountContent.tsx
     • src/pages/settings/Wallet/InternationalDepositAccount/utils.ts#getSubstepValues()
     • src/pages/settings/Wallet/InternationalDepositAccount/subPages/Confirmation.tsx
     • src/libs/actions/BankAccounts.ts#createCorpayBankAccountForWalletFlow()
   • Reimbursement flow:
     • src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx
     • src/pages/ReimbursementAccount/NonUSD/utils/getBankInfoStepValues.ts
     • src/libs/actions/BankAccounts.ts#createCorpayBankAccount()

5. There is also a sequencing flaw in useStepFormSubmit.
   Even when it does call FormActions.setDraftValues(), it immediately calls onNext() without waiting for the draft write to complete. In both navigation helpers:

   • src/hooks/useSubPage/index.tsx
   • src/hooks/useSubStep/index.ts

   edit-mode navigation ignores the stepValues argument and re-renders confirmation from draft, so the draft update should complete before navigation. There is already a working analog for this pattern in src/pages/settings/Wallet/InternationalDepositAccount/subPages/AccountType.tsx, which does setDraftValues(...).then(() => onNext()).

So the actual defect is: submitted, normalized step values are not reliably persisted to draft before the next screen depends on that draft.

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

Add an opt-in path to useStepFormSubmit that persists submitted values to draft even in create mode, and make all draft-backed navigation wait for that write before moving forward.

1. Update src/hooks/useStepFormSubmit.ts

Add shouldSaveSubmittedValuesToDraft?: boolean to UseStepFormSubmitParams, defaulting to false.

Compute stepValues once, and if either:

• shouldSaveDraft is true, or
• shouldSaveSubmittedValuesToDraft is true

then call FormActions.setDraftValues(formId, stepValues) and only call onNext(...) in .then(...).

The behavior should be:

• shouldSaveDraft === true
  Save stepValues to draft, then call onNext(stepValues).
• shouldSaveDraft === false && shouldSaveSubmittedValuesToDraft === true
  Save stepValues to draft, then call onNext().
• neither flag set
  Keep the current onNext() behavior.

This fixes both parts of the bug:

• create flow now replaces raw autosaved draft values with trimmed submit values
• navigation waits for draft persistence before the confirmation screen reads from draft

2. Update src/hooks/useInternationalBankAccountFormSubmit.ts

Hardcode shouldSaveSubmittedValuesToDraft: true.

All four callers are Corpay wallet steps whose confirmation screen is draft-backed:

• subPages/BankAccountDetails.tsx
• subPages/AccountType.tsx
• subPages/BankInformation.tsx
• subPages/AccountHolderInformation.tsx

So the wallet flow can be fixed in one place.

3. Update src/hooks/useReimbursementAccountStepFormSubmit.ts

Add shouldSaveSubmittedValuesToDraft?: boolean to the params and pass it through to useStepFormSubmit.

4. Update src/pages/ReimbursementAccount/NonUSD/BankInfo/subSteps/BankAccountDetails.tsx

Pass shouldSaveSubmittedValuesToDraft: true.

That is the affected create-flow reimbursement step. AccountHolderDetails.tsx already uses shouldSaveDraft: true, so it does not need the new flag, but it will still benefit from the setDraftValues(...).then(...) sequencing fix in useStepFormSubmit.

What alternative solutions did you explore? (Optional)

Trimming only in:

• createCorpayBankAccountForWalletFlow()
• createCorpayBankAccount()

would fix the final API payload, but it is a later symptom-level patch. The confirmation screen, resumed flow, and edit/create consistency would still be driven by stale raw draft values.

Changing useStepFormSubmit to always save submitted values for every caller would also work, but it broadens behavior for unrelated flows. An opt-in shouldSaveSubmittedValuesToDraft flag keeps the fix scoped to the Corpay flows that actually depend on draft-backed confirmation, while still correcting the draft-write sequencing bug in the existing shouldSaveDraft branch.

[neerajbachani]

Proposal

What is the root cause of that problem?

In BankAccounts.ts, the functions createCorpayBankAccount and createCorpayBankAccountForWalletFlow pass field values directly to JSON.stringify() without trimming leading/trailing whitespace first. Since Corpay field names are dynamic (fetched from the backend), a user can unknowingly submit values with extra whitespace (e.g. "M5V 2T6 " in bankPostal), which the backend rejects — surfacing only a generic error with no actionable feedback.

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

Trim all string values at the point of serialization in BankAccounts.ts, just before JSON.stringify() is called in both createCorpayBankAccount and createCorpayBankAccountForWalletFlow. Since the fields are dynamic, a single utility pass over the object (trim every value that is a string) handles all current and future fields without needing to enumerate them by name.

No changes needed in the UI layer or FormProvider — the fix is scoped entirely to the two API submission points.

What alternative solutions did you explore? (Optional)

• Trim at the form/input level (FormProvider or useStepFormSubmit): Would cover more cases globally but risks unintended side effects on other forms across the app.
• Trim only the known fields by name: Too brittle — Corpay fields are fetched dynamically, so hardcoding names would miss any fields added in the future.

[github-actions]

⚠️ @neerajbachani 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).

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @KJ21-ENG 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.