[$250] All - Expense - Admin receive error if cancel payment for employee with BA in 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.3.83-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: https://test-management.browserstack.com/projects/2219752/folder/13176702/test-cases/41236798
Email or phone of affected tester (no customers): fischer9966+052626adm01@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: MacOS 26.5 / Safari, Chrome. iPhone 17 Pro / 26.5. Google Pixel 5 / Android 14
App Component: Money Requests

Action Performed:

1. Create Admin account with Gmail
2. Create Collect workspace, set Workflows to enabled
3. Enable Workflows > Delay submissions and set it to Manually
4. Enable Approvals in Workflows and set Admin as Approver
5. Enable Payments and connect bank account (eq Regions Bank, Savings account 1111)
6. Invite Employee with Gmail accounts to this workspace
7. Login as Employee and add bank account in the Wallet (eq Regions Bank, Checking account 0000)
8. As employee submit an expense in the workspace
9. Login as Admin
10. Approve employee's payment from step 8
11. Pay this payment with Bank account
12. Open this expense, click More > Cancel payment

Expected Result:

Admin can successfully cancel а payment for an expensе of employee with a configured bank account in the wallet

Actual Result:

Admin receive error if cancel а payment for an expensе of employee with a configured bank account in the wallet. Admin can not cancel this payment.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7163894_1779841111854.Web-Admin-receive-error-after-cancel-payment.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059555586462039722
• Upwork Job ID: 2059555586462039722
• Last Price Increase: 2026-05-27

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

[MelvinBot]

Proposal

What is the root cause of that problem?

This appears to be a backend/internal issue. The App-side cancelPayment() function in PayMoneyRequest.ts:481-691 sends a CancelPayment API call to the backend with iouReportID, chatReportID, managerAccountID, and reportActionID. The client-side code has no bank-account-specific logic in the cancel payment path — it treats all cancellations identically regardless of whether the employee has a bank account in their wallet.

When the backend rejects the cancellation, the App's failure handler at PayMoneyRequest.ts:600-678 shows a generic "Unexpected error" (iou.error.other) message and reverts the optimistic state. The actual error originates from the backend CancelPayment command handler, which likely has a validation check that fails when the employee's wallet has a configured bank account (e.g., the ACH destination account or payment processing state may trigger a different code path on the backend).

The client-side visibility gate isCancelPaymentAction() correctly allows the cancel button to appear (it checks admin status, payer status, payment processing state, and NACHA cutoff time), but the backend rejects the actual cancellation — a mismatch between client-side eligibility and backend validation.

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

A separate internal investigation is needed to identify the specific backend validation that rejects the CancelPayment command when the employee has a bank account configured in their wallet. The fix will likely be in the backend CancelPayment handler, either by:

1. Fixing the backend logic to allow cancellation in this scenario, or
2. If the backend rejection is intentional (e.g., ACH already initiated), then updating the client-side isCancelPaymentAction() to also hide the cancel button in this scenario to prevent the mismatch.

Investigation details

Cancel Payment Flow:

1. UI trigger: useLifecycleActions.tsx:341-361 — "Cancel payment" in More menu, shows confirm dialog, then calls cancelPayment()
2. Visibility gate: ReportSecondaryActionUtils.ts:380-440 — requires admin + payer, checks payment type and NACHA cutoff
3. API call: WRITE_COMMANDS.CANCEL_PAYMENT with params {iouReportID, chatReportID, managerAccountID, reportActionID}
4. On failure: generic iou.error.other ("Unexpected error") — no specific error from backend is surfaced

What the client does NOT check: Whether the employee has a bank account in their wallet. The CancelPaymentParams don't include any employee bank account information — the backend must look this up independently.

No related open issues found matching this specific cancel-payment-with-employee-wallet-BA scenario.

---

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

[melvin-bot]

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

[lxyct825-ops]

Proposal

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

[$250] All - Expense - Admin receive error if cancel payment for employee with BA in wallet

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!