Bank Account - Country field missing in Address section on Personal Info page

[applause-bot]

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.4.25-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93137
Email or phone of affected tester (no customers): jose.sat94+999aiiaa@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: MacBook Pro/13.7.8, Samsung Galaxy S21/Android 15, iPhone 13/18.6.2
App Component: Other

Action Performed:

1. Launch Expensify app
2. Log in with valid credentials
3. Start the Add bank account flow from Workflows or Accounts > Wallet
4. Go to the Owner info page
5. Return to the Address section

Expected Result:

The Country field should be displayed in the Address section so the user can change the selected country, verify that the hint text updates accordingly, and validate the ZIP/postal code format

Actual Result:

The Country field is not displayed in the Address section on the Personal Info page, preventing the user from changing the country and completing the expected validations

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7195883_1782854512302.WEB-repro.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7195883

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/45f4f1b2428f0ea1a239ff1ea93edb1f7bd2d72f0a042fc087e8a22cc39add92

[MelvinBot]

Proposal

What is the root cause of that problem?

The Country field on the Personal Info → Address page is never rendered because that sub‑step doesn't pass shouldDisplayCountrySelector to the shared AddressStep, and the prop defaults to false.

The country selector in AddressFormFields is gated behind that flag:

• AddressFormFields.tsx:201 — {shouldDisplayCountrySelector && ( …country selector… )}
• AddressFormFields.tsx:109 — shouldDisplayCountrySelector = false (default)

The two Personal Info address sub‑steps render AddressStep without that flag, so the field is omitted:

• USD/Requestor/PersonalInfo/subSteps/Address.tsx:54-66 (add‑bank‑account from Workflows)
• EnablePayments/Wallet/PersonalInfo/substeps/AddressStep.tsx:44-60 (Wallet from Accounts)

By contrast, the flow that PR #93137 was actually built for — the international/NonUSD add‑bank‑account address — does pass it (read‑only): NonUSD/BusinessInfo/subSteps/Address.tsx:68.

⚠️ Design decision needed first. These Personal Info pages are US‑only (USD reimbursement‑account requestor and the US Expensify Wallet), so the requestor address is fixed to the US — the Requestor step even sets shouldAllowCountryChange={false}. The reporter's expected result ("so the user can change the selected country") does not apply here; a US requestor can't pick a different country. The real question is whether these US‑only pages should display a read‑only "United States" country field (for consistency with the NonUSD flow and so the ZIP hint/validation are visibly country‑scoped), or whether omitting it is correct.

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

If the team decides the field should appear, mirror the NonUSD pattern: pass shouldDisplayCountrySelector with shouldAllowCountryChange={false} (and include the country input in INPUT_KEYS/STEP_FIELDS) in the two Personal Info sub‑steps above. This shows a locked "United States" field and keeps the country‑aware ZIP hint/validation from PR #93137 consistent.

If omitting the field on US‑only pages is intended, this should be closed as working as designed and the QA test step corrected.

What alternative solutions did you explore? (Optional)

Leaving the pages as‑is (no country field) — appropriate if product prefers a minimal US‑only address form, since country is not user‑editable there anyway.

Investigation details

• Symptom: Country field absent in the Address section of the Personal Info page in the Add bank account / Wallet flows (Android, iOS, macOS Chrome).
• Not a regression from PR fix: update zip code validation when address country changes #93137. That PR touched AddressStep.tsx, ValidationUtils.ts, and AddressFormFields.tsx to add country‑specific ZIP validation/hints; it did not add or remove the country selector on these Personal Info pages. A history search shows the two Personal Info sub‑steps have never passed shouldDisplayCountrySelector. This bug was found during QA of that PR, not caused by it.
• Origin: PR fix: update zip code validation when address country changes #93137 fixed [Due for payment 2026-07-08] [$250] Zip Code Validation Does Not Update After Changing Address Country #90491 ("Zip Code Validation Does Not Update After Changing Address Country"), which was specifically about the flow where the country can be changed (they reproduced with "Canada BA flow changed to UK") — i.e. the NonUSD business address that already renders the selector. QA then checked the Personal Info address, saw no country field, and filed this.
• Fix location: front‑end only, in Expensify/App. No backend/API change is required to render the field.

Note on labels: this issue is currently labeled Internal, but the code fix (if pursued) is a small front‑end change in App. Flagging in case BugZero wants to re‑route.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95021) to create a draft PR (only after the design decision above is settled).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[nabi-ebrahimi]

@nabi-ebrahimi This PR is failing because of a regression issue #95021

@mitarachim,I reverted this PR locally and was able to reproduce the issue as well. Based on my review, this does not appear to be a regression caused by the code changes by our PR.

@Pujan92 Could you please check this.

thanks

Reverted Demo:

Screencast.From.2026-07-01.11-50-30.mp4

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[melvin-bot]

12 days overdue now... This issue's end is nigh!

[melvin-bot]

this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!