Expense - Invalid amount error is not shown when paying amount USD 0 with wallet

[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.41-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96228
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open 1:1 DM.
3. Click + > Pay.
4. Enter amount > Next.
5. Change the amount to 0 and currency to USD.
6. Click Pay > Mark as paid.
   → Invalid amount error is shown.
7. Click Pay > Pay with wallet.

Expected Result:

Invalid amount error will be shown when paying amount USD 0 with wallet.

Actual Result:

Additional details page opens. Invalid amount error is not shown.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213667_1784651174258.24.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7213667

[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/1177fb960517d1616b663e21d1ab6d77284c71666ab3bce1d0f1c7b83c5bd3e7

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #96228

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Issue Analysis

Root Cause: The regression was introduced by #96228 ("remove isNewManualExpenseFlowEnabled beta flag"). Removing that flag made the confirmation-page amount an always-inline editable input, so in the Pay flow you can now set the amount to $0 directly on the confirmation page — which was not possible before (the amount used to be a read-only row that routed to a separate amount step). That new precondition exposes a pre-existing asymmetry in the Pay dropdown: only "Mark as paid" runs amount validation, while "Pay with wallet" bypasses it.

• Mark as paid (ELSEWHERE) → SettlementButton calls onPress → confirm → validate(), which flags the $0 P2P amount with common.error.invalidAmount. ✅ Error shown.
• Pay with wallet (PERSONAL_BANK_ACCOUNT → EXPENSIFY) → routes into selectPaymentMethod → triggerKYCFlow. Since the tester has no activated wallet, KYCWall navigates straight to the enable-payments / "Additional details" page and returns before onPress/validate ever runs. ❌ No error.

The routing that skips validation on the wallet path is SettlementButton/index.tsx:582-599 and the early-return navigation is KYCWall/BaseKYCWall.tsx:344-354. The $0 guard that never gets a chance to run lives at useConfirmationValidation.ts:185-186.

Recommended Fix: This is already resolved by a revert — #96661 ("[No QA] Revert #96228") merged at 16:41 UTC, ~9 minutes before this blocker was auto-filed. The tester's build (9.4.41-1) still contained #96228, so this should no longer reproduce on the next staging build. Please re-verify on a build that includes the revert and close if resolved.

When #96228 is re-landed, it needs to also close the underlying gap so an invalid amount blocks the wallet path (e.g. run validate() / gate on formError before triggerKYCFlow in the Pay dropdown, or disable the Pay button while the amount is invalid).

Investigation details

Why it's staging-only / not in production: With the beta flag off (production), the confirmation amount was a read-only MenuItemWithTopDescription, so a user couldn't set $0+USD inline on the Pay confirmation page. #96228 removed the isNewManualExpenseFlowEnabled guard around the editable NumberWithSymbolForm in AmountField.tsx, making the field editable in the Pay flow and enabling the $0 precondition. It also removed the footer fallback for common.error.invalidAmount in useFormErrorManagement.ts (the error now surfaces inline on the amount input). Both changes are in merge commit 47f67e5.

Control-flow evidence (all at HEAD dcd250e, post-revert — these files pre-date #96228):

• Pay button wires onPress={confirm}: ConfirmationFooterContent.tsx — confirm is the only entry point that calls validate().
• confirmAction.ts runs validate(paymentMethod) and sets formError before any pay side-effect.
• getActivePaymentType maps PERSONAL_BANK_ACCOUNT → EXPENSIFY with shouldSelectPaymentMethod = true, while ELSEWHERE → false (PaymentUtils.ts:298-334) — this is the branch that decides KYC vs onPress.
• handlePaymentSelection: shouldSelectPaymentMethod true → selectPaymentMethod → triggerKYCFlow (never reaches onPress); false → selectPaymentType → onPress → confirm → validate.
• KYCWall continueAction: for a non-expense (P2P) report with no activated wallet, Navigation.navigate(enablePaymentsRoute) + return before onSuccessfulKYC.

Alternative explanations considered: (1) validation itself gating on payment type — ruled out; the $0 P2P check at useConfirmationValidation.ts:185 is not payment-type-gated, it simply never runs on the wallet path. (2) confirmation amount being read-only in the Pay flow — ruled out; isReadOnly is false here, the amount is inline-editable, which is exactly why the $0 value is reachable.

Confidence: High — deterministic client-side control flow, corroborated by two independent traces.

---

Next Steps: Re-verify on the next staging build (with the #96661 revert). Reply with @MelvinBot <feedback> to refine this analysis.

[trjExpensify]

"Send money" P2P flow, lower priority. We should fix it though, 0.00 wouldn't be valid "to pay" here. CC: @thelullabyy

[yuwenmemon]

The offending PR that caused this deploy blocker was reverted with #96661.

@Expensify/applause please retest this issue on the latest staging build now that the PR has been reverted, and confirm whether it still reproduces.

[puneetlath]

PR reverted.