[Due for payment 2026-04-30] [Due for payment 2026-04-28] App crashes after going back from Onfido page & tapping Pay with wallet option

[mitarachim]

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: v9.3.60-6
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: Exploratory around https://test-management.browserstack.com/projects/2219752/test-runs/TR-19604/folder/13177075/41237820/1336304256
Email or phone of affected tester (no customers): kaitest.78+ck416261@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 16/iOS 18.7.1
App Component: Money Requests

Action Performed:

1. Launch Hybrid app & log in with new validated account
2. Open 1:1 chat with any user
3. Open the + menu and click "Pay [user]" >> Enter any amount & continue
4. Tap Pay button >> Pay with personal account
5. Go through the flow adding personal bank account
6. Tap Pay button >> Pay with wallet
7. Go through the KYC verification flow adding additional details
8. Tap continue on Verify identity page
9. Once user lands on Onfido page, tap back button
10. Tap Pay button >> Pay with wallet page

Expected Result:

User should able to proceed further with Onfido flow. App should not crash after going back from Onfido page & tapping "Pay with wallet" option

Actual Result:

App crashes after going back from Onfido page & tapping Pay with wallet option

Note: On Android app- App does not crash, instead an error occurred processing this step message is displayed and user stays on confirm details page only

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7131592_1776360817346!Crashlog20.txt

Bug7131592_1776360817352.ScreenRecording_04-16-2026_13-18-13_1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

[melvin-bot]

Triggered auto assignment to @inimaga (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

Proposal

What is the root cause of that problem?

The Onfido native iOS SDK presents a fullscreen UIViewController via OnfidoFlow.run(from:presentationStyle:animated:). When the user taps the back button, the SDK begins dismissing that VC with an animation, but calls reject() synchronously in the cancellation handler before the dismiss animation completes.

This immediately fires the JS .catch() in src/components/Onfido/index.native.tsx:53, which calls onUserExit(true) with no delay. That triggers Navigation.goBack() to dismiss the EnablePayments modal (a RightModal navigator screen), which is another native UIViewController transition. Now two VC transitions are in flight simultaneously.

When the user then taps "Pay with wallet" again, a third presentViewController is attempted while a transition is still in progress, and iOS throws the SIGABRT.

Note: Android doesn't crash because it goes through the async AppStateTracker.getWasAppRelaunchedFromIcon().then(...) path (line 47-49), which introduces enough async delay for the Onfido VC to finish dismissing.

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

In src/components/Onfido/index.native.tsx, wrap the iOS onUserExit(true) call in InteractionManager.runAfterInteractions() so the navigation only fires after the Onfido native VC dismiss animation has fully completed:

// Before:
onUserExit(true);

// After:
InteractionManager.runAfterInteractions(() => {
    onUserExit(true);
});

This ensures Navigation.goBack() doesn't trigger a competing UIViewController transition while the Onfido SDK's dismissal is still in progress.

What alternative solutions did you explore? (Optional)

• Adding a guard in OnfidoStep.goBack: Could add a setTimeout delay before calling Navigation.goBack(), but this is a blunt workaround — InteractionManager.runAfterInteractions() is the idiomatic React Native approach for waiting for animations to settle.
• Native-level fix: Could modify the Onfido SDK bridge to only call reject() in a dismiss completion handler, but that requires patching a third-party dependency.

---

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.

[pranjal2410719]

Proposal

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

On iOS, after exiting the Onfido verification flow and tapping "Pay with wallet" again, the app crashes. This happens due to conflicting navigation transitions triggered before the native Onfido view controller has fully dismissed.

What is the root cause of that problem?

The Onfido iOS SDK dismisses its native view controller asynchronously with an animation. However, the cancellation handler triggers onUserExit(true) immediately, which leads to Navigation.goBack() being called before the dismissal animation completes.

This creates overlapping UIViewController transitions:

1. Onfido VC is dismissing
2. React Navigation tries to dismiss modal
3. User triggers another navigation (Pay with wallet)

iOS does not allow multiple simultaneous transitions, causing a crash (SIGABRT).

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

We should ensure navigation is triggered only after native transitions are fully completed.

Proposed fix:
InteractionManager.runAfterInteractions(() => {
requestAnimationFrame(() => {
onUserExit(true);
});
});

This improves upon the base solution by:

• Waiting for all interactions to complete
• Ensuring execution happens in the next frame
• Avoiding edge cases where InteractionManager alone may still fire too early

What alternative solutions did you explore? (Optional)

1. Using setTimeout → unreliable and timing-dependent
2. Modifying native SDK behavior → not feasible (third-party dependency)
3. Navigation state guards → adds complexity and does not solve root issue

What specific scenarios should we cover in automated tests?

1. Exit Onfido flow and retry payment → no crash
2. Rapid navigation after exit → stable behavior
3. Multiple retries of payment flow → no regression
4. Android behavior remains unchanged

Additional consideration

We should ensure this fix does not delay navigation excessively. The combination of InteractionManager + requestAnimationFrame provides a minimal delay while guaranteeing transition safety.