[Due for payment 2026-08-28] Expense - Amount page is still displayed before landing on new flow when paying someone.

[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-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
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): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

1. Open the staging.new.expensify.com website.
2. Open any chat with another user,
3. Click on "+" > "Pay User"
4. Note that when flow is started, you land on amount page instead of landing on new details page.
5. Insert any amount and click on "Next"
6. Note that now, you land on the new flow details page, and amount field is focused, despite already being completed.

Expected Result:

When payment flow is started, user should land automatically land on new flow details page.

Actual Result:

When payment flow is started, user lands on amount page before being redirected to the new details page. After completing amount and clicking "Next", user is redirected to the new flow details page, where amount field is automatically focused, despite already being completed.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213199_1784615327752.Payment.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7213199

[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/c059a4ff33d06069f2bdcd6af545103b9d64b92ac93244e262d1a4b06e04bd82

[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

Caused by: Expensify/App#96228 ("feat: remove isNewManualExpenseFlowEnabled beta flag"), which made the new inline-confirmation flow the default — but that flow was only wired up for create/submit, not for the pay/send (Pay User) flow.

Root Cause: The new flow (which embeds the confirmation page and edits amount inline, skipping the standalone Amount page) is gated behind shouldUseTab, which is explicitly false for PAY/SEND:

• IOURequestStartPage.tsx:76 — shouldUseTab = iouType !== SEND && iouType !== PAY && iouType !== INVOICE. When false, the page renders the standalone IOURequestStepAmountWithTransactionOnly instead of the embedded IOURequestStepConfirmation, so Pay User goes through the Amount page first (symptom Some initial fixes and code style updates #1).
• useDefaultParticipants.ts:60 — the global-create participant fallback only recognizes TYPE.CREATE, so pay/send isn't seeded for a direct-to-confirmation path.
• TransactionDetailsFields.tsx:70 — shouldAutoFocusAmountField = !canUseTouchScreen() auto-focuses the amount field on the confirmation page regardless of whether the amount is already filled, which is why the already-completed amount is re-focused (symptom Fix spaces #2).

Recommended Fix:

1. Route pay/send into the embedded confirmation directly. Since Pay User has no Scan/Distance/Per-diem tabs, do not just drop it from the shouldUseTab condition (that would render a tab navigator that doesn't apply). Instead, in the !shouldUseTab branch of IOURequestStartPage, render IOURequestStepConfirmation (with shouldHideHeader) for pay/send instead of the standalone amount step.
2. Extend the new-flow participant seeding in useDefaultParticipants.ts:60 to also cover pay/send (or rely on isFromGlobalCreate/isFromFloatingActionButton being set for this entry point).
3. Stop auto-focusing the amount field when it's already set — gate shouldAutoFocusAmountField on the amount not being pre-filled.

Given this is a deploy blocker introduced by a single PR, reverting Expensify/App#96228 is the fastest way to unblock the deploy if a targeted fix can't land quickly.

Investigation details & data flow

1. User taps + → Pay User → IOU flow starts with iouType = PAY/SEND.
2. IOURequestStartPage computes shouldUseTab = false (line 76), so it renders the standalone IOURequestStepAmountWithTransactionOnly rather than the tab whose MANUAL content embeds IOURequestStepConfirmation.
3. User enters an amount and taps Next → navigates to IOURequestStepConfirmation.
4. On the confirmation page, TransactionDetailsFields sets shouldAutoFocusAmountField = !canUseTouchScreen() (true on web/desktop) and passes autoFocus to AmountField, whose focus effect (AmountField.tsx:129) focuses the already-filled input.

Alternatives considered: The symptom could also be a routing regression in IOURequestStepParticipants, but the participants step still exists and works — the divergence is entirely in the shouldUseTab branch selection, which structurally excludes pay/send from the new flow. Both reported symptoms are explained by the same gating.

Confidence: High — line references verified against merge commit 47f67e5; both symptoms trace to the shouldUseTab exclusion + unconditional amount auto-focus.

---

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

[trjExpensify]

Haha wow, I forgot the ol' "Send money" flow existed. As a P2P flow, I think this can be demoted but we should bring it in-line to not use the BNP screen.

[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.