IOU - An expected error when Pay with wallet to user without wallet

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.55-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #95005
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, Android 13 / Xiaomi Poco F5
App Component: Money Requests

Action Performed:

Preconditions:

• User A: Enable the wallet as payer account
• User A and B set the USD currency

1. Login as user A (payer)
2. Start chat with user B > click + button > Pay B
3. Enter any amount > Pay with wallet
4. Open the expense details

Expected Result:

User A successfully Pay with wallet to a user without a wallet

Actual Result:

An expected error when Pay with wallet to user without wallet

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7237070_1787131969332.98919_-_PR95005_-_IOU_-_An_expected_error_when_Pay_with_wallet_to_user_without_wallet.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022090013411646587648
• Upwork Job ID: 2090013411646587648
• Last Price Increase: 2026-08-19

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

[MelvinBot]

Issue Analysis

Root Cause: The App is correctly rendering an error that the backend returns. Paying a wallet‑less recipient with the Expensify Wallet should hold the funds (a "Payment is on hold until they enable their wallet" state), but the backend command is instead responding with a failure jsonCode. The frontend only ever attaches this generic error on an API failure of the wallet‑payment command — there is no client‑side/optimistic path that produces it — so the red "Unexpected error. Please try again later." on the expense is a faithful reflection of a backend rejection, not an App bug.

This almost certainly means the frontend for the held‑payment feature (PR #95005) merged ahead of its companion backend support. That PR's own description notes it "relies on the companion backend change… so the user‑initiated cancel actually returns the held wallet funds." If the backend doesn't yet accept/hold a wallet payment to a wallet‑less recipient, the very first step (Pay) errors out and QA never reaches the new Cancel‑payment flow.

Recommended Fix: This requires a change outside the App repo — the wallet‑payment backend command must accept a payment to a wallet‑less recipient and place it in the held/queued state instead of returning an error. Please escalate to an internal engineer with backend access (this ties to the internal issue linked from PR #95005). No App‑repo code change is needed to stop the error; the App is behaving correctly.

Investigation details & evidence

How the error surfaces (all in the public App repo, SHA 07a4f68):

• The "Pay with wallet" path routes to WRITE_COMMANDS.PAY_MONEY_REQUEST_WITH_WALLET (or SEND_MONEY_WITH_WALLET for the + → Pay send‑money flow): PayMoneyRequest.ts:930-938.
• The error is set only in failureData (applied by Onyx only on a non‑200 API response) — it attaches iou.error.other to the PAY IOU report action: PayMoneyRequest.ts:416-425 (and the send‑money equivalent in SendMoney.ts). Optimistic/success data never sets it.
• It renders as the red brick‑road row via getLatestErrorMessageField(action) inside OfflineWithFeedback: ReportActionItem.tsx:596-604.
• Copy: iou.error.other = "Unexpected error. Please try again later." — en.ts:1597.

What the correct (non‑error) outcome looks like: a REIMBURSEMENT_QUEUED action rendered by ReimbursementQueuedContent.tsx showing "started settling up. Payment is on hold until {name} enables their wallet." with an "Enable wallet" button — iou.waitingOnEnabledWallet at en.ts:1626. Seeing a red error instead of this queued action is the tell that the backend rejected the payment.

Alternative explanations considered:

• Frontend optimistic bug — ruled out: no optimistic/success branch sets this error; it exists only in failureData.
• Missing receiver‑wallet pre‑check in App — the KYCWall path checks the payer's wallet, not the recipient's, so the App legitimately hands the "held payment" decision to the backend by design.

Production log confirmation: I was unable to pull VictoriaLogs in this run (the log tooling wasn't available). To close this out definitively, an engineer can check the jsonCode returned by the wallet‑payment command for a wallet‑less recipient in the reported window (~2026‑08‑19, v9.4.55‑4) — a non‑200 code with no REIMBURSEMENT_QUEUED action confirms the backend rejection.

Possibly related: #96345 — "[Exploratory] Report - Error appears on the report when Cancel Payment" (same P2P‑wallet cancel/hold feature area; may share the same backend dependency).

---

Next Steps: This needs a backend change and can't be fixed in the App repo — an internal engineer should verify/deploy the held‑payment backend support behind PR #95005. Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@Krishna2323 Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

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

[melvin-bot]

@Krishna2323 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[Krishna2323]

@MelvinBot can you please check #95005 (comment) and confirm this issue can be closed?