topPresenter selects detached RCTFabricModalHostViewController → drop-in silently fails to present on repeat checkout (iOS, Fabric)

[adibfirman]

Describe the bug

On iOS new architecture (Fabric), the card drop-in presents fine on the first checkout but silently fails on every subsequent checkout in the same app session. No JS error, no callback — the pay button appears to do nothing.

Device console shows:

Attempt to present <Adyen.DropInNavigationController: 0x...>
on <RCTFabricModalHostViewController: 0x...>
(from <RCTFabricModalHostViewController: 0x...>)
whose view is not in the window hierarchy.

Same error string as #905, but different cause. #905 is a first-present timing race (Modal onShow). This one is a stale-presenter bug on repeat present: after a prior flow calls router.dismissAll(), its RCTFabricModalHostViewController is torn down on the React side but left presented-yet-detached at the UIKit level. On the next present(), UIViewController.topPresenter walks presentedViewController to the deepest VC and returns that stale, out-of-window host. iOS silently refuses to present on it.

Root cause (library side)

topPresenter's descent loop walks blindly to the deepest presentedViewController with no check that the VC is still live / in-window. Confirmed still present in latest 2.11.1 (loop adopted scene-aware key-window lookup but no detached/dismissing guard).

Steps to reproduce

1. RN new arch (Fabric) + expo-router (or any RN modal host).
2. Complete/attempt one card checkout (type: 'scheme').
3. Tear down the flow via router.dismissAll().
4. Start a second checkout in the same session → drop-in never appears; console logs the error above.

Physical device only — not reproducible on simulator.

Suggested fix

Guard topPresenter's descent loop to skip detached/dismissing VCs:

while let presented = topController?.presentedViewController,
      !presented.isBeingDismissed,
      presented.viewIfLoaded?.window != nil {
    topController = presented
}

Optionally, in BaseModule.present(), dismiss a leaked presented VC before presenting (belt-and-suspenders):

if let stale = presenter.presentedViewController,
   stale.viewIfLoaded?.window == nil || stale.isBeingDismissed {
    presenter.dismiss(animated: false) { [weak self] in
        self?.present(component)
    }
    return
}

Environment

• @adyen/react-native 2.7.3 (also affects 2.11.1)
• iOS, RN new architecture / Fabric
• Physical device (simulator does not reproduce)

Happy to open a PR with the topPresenter guard if welcome.

[descorp]

Thank you for feedback @adibfirman 💚

This one is a stale-presenter bug on repeat present: after a prior flow calls router.dismissAll(), its RCTFabricModalHostViewController is torn down on the React side but left presented-yet-detached at the UIKit level.

UIViewController.topPresenter fetches top presenter from rootViewController of a keyWindow, so it should never be stale 🤔

Just to make sure: you call component.hide(true/false) once payment is done before RCTFabricModalHostViewController is torn down? It triggers cleanUp and eventually BaseModule.currentPresenter = nil, so next time BaseModule.currentPresenter is refreshed.

---

UPD

What exactly causes "RCTFabricModalHostViewController teer down" ?

---

After investigating, there are two distinct problems here:

Problem 1 — SDK timing (SDK scope)

hide() triggers the dismiss animation and returns immediately. If the one calls open()
straight after (e.g. to retry after an onError), topPresenter can walk into a VC that is
still mid-dismissal and UIKit will silently reject the present() call. We plan to fix this by
making hide() async — merchants will be able to await hide() and be guaranteed the UI is
fully settled before proceeding.

Problem 2 — Navigation reshuffle (consumer scope)

The SDK guarantees(we doing our best 😅) correct behavior when open() is called against a stable VC hierarchy.
Presenting during an active navigation transition — whether a React Navigation stack push/pop,
a modal swap, or a Fabric teardown — is outside the supported usage. The right pattern is to
wait for navigation to settle before calling open(), and to avoid triggering it directly from
effects that fire as a side-effect of navigation state changes.

We will address Problem 1 in an upcoming major release. Problem 2 requires the host app to ensure UI
stability before invoking the SDK.

---

Summary

The SDK has no visibility into the host app's navigation stack and deliberately avoids making
assumptions about it. It presents on whatever VC is topmost when open() is called, and
dismisses only what it presented — which is why hide() must always be called to conclude
a payment flow. Attempting to introspect or compensate for navigation state the SDK does not
own would introduce non-deterministic behavior.

[adibfirman]

Hi @descorp

Thank you for addressing this issue, let me know once the Adyen team bump the version I will try to make sure in our app also address the problem 2 that u mention above.

[descorp]

@adibfirman

FYI, next major release is planed in Q4 2026.
Please keep us updated on the outcome of your "problem 2" investigation.

[descorp]

Hey @adibfirman

We modified presentation logic in 2.12.0. Could you check if new version improves your situation?