fix(android): forward stripeAccountId and catch errors in retrievePaymentIntent / retrieveSetupIntent

[adityapsbisht]

Summary

On Android, retrievePaymentIntent and retrieveSetupIntent have two defects that together cause a hard, un-catchable app crash whenever the underlying PaymentIntent/SetupIntent belongs to a connected Stripe account:

1. stripeAccountId is not forwarded to the native call. Every other public API in StripeSdkModule.kt that touches the Stripe Android SDK passes stripeAccountId (createCardTokenSynchronous, createPiiTokenSynchronous, createBankAccountTokenSynchronous, every PaymentLauncherFragment.forXxx, and the module's own internal Google Pay path). But retrievePaymentIntent / retrieveSetupIntent were calling the 1-arg overloads:

   stripe.retrievePaymentIntentSynchronous(clientSecret)   // drops stripeAccountId
   stripe.retrieveSetupIntentSynchronous(clientSecret)     // drops stripeAccountId

   So the request hits the platform account rather than the connected account, and Stripe responds with InvalidRequestException: No such payment_intent: 'pi_…'.

2. The coroutine body is unguarded. The network call runs inside CoroutineScope(Dispatchers.IO).launch { … } with no try/catch / runCatching, so InvalidRequestException escapes the coroutine and becomes an uncaught exception. The app crashes before the Promise is ever rejected, so a JS-side try/catch around retrievePaymentIntent cannot help.

The matching iOS implementation already forwards stripeAccountId and resolves errors via the Promise — this PR brings Android behavior in line.

Reproduction

1. Stripe account configured with connected/custom accounts.
2. Create a PaymentIntent on a connected account, hand the client its client_secret.
3. On Android, await retrievePaymentIntent(clientSecret) (even with a JS try/catch).
4. App crashes:

   com.stripe.android.core.exception.InvalidRequestException: No such payment_intent: 'pi_…'
     at com.stripe.android.networking.StripeApiRepository.handleApiError(StripeApiRepository.kt:1705)
     at com.stripe.android.Stripe.retrievePaymentIntentSynchronous(Stripe.kt:441)
     at com.reactnativestripesdk.StripeSdkModule$retrievePaymentIntent$1.invokeSuspend(StripeSdkModule.kt:645)
   

iOS with the same client secret works correctly.

Fix

Two targeted changes to android/src/main/java/com/reactnativestripesdk/StripeSdkModule.kt:

• Pass stripeAccountId to retrievePaymentIntentSynchronous / retrieveSetupIntentSynchronous (the 2-arg overloads already exist on Stripe).
• Wrap the coroutine body in runCatching { … }.onFailure { … } and resolve the promise with a structured error via createError(RetrievePaymentIntentErrorType.Unknown, …) / createError(RetrieveSetupIntentErrorType.Unknown, …) — both enums already exist in utils/Errors.kt.

Net diff: 20 insertions, 4 deletions, one file.

Impact

• Resolves an app-terminating crash for any app using connected accounts that calls retrievePaymentIntent/retrieveSetupIntent on Android (PaymentSheet flows that need to re-read intent status post-confirmation, amount display after deep-linking back from SCA, etc.).
• JS consumers now receive a structured rejection that can be handled identically to iOS.

Verified

• Bug is present from at least v0.50.3 through v0.64.0 (current master) — the 1-arg overload has been used since the original implementation and was never updated alongside other native calls that adopted stripeAccountId.
• Change is Kotlin-only, no TS/JS surface changes, no behavioral difference for non-connected-account use (since stripeAccountId is nullable and the 2-arg overload accepts null).

Related

• retrievePaymentIntent with stripe Custom Connect  #322 — same retrievePaymentIntent + Custom Connect bug, reported in 2021, closed without a code fix.
• Potential Device Specific Bug: Stripe Pay (Platform and Not Platform) Works on Samsung Galaxy S9+ and Google Pixel but does not on Samsung Galaxy S24. Error: No such payment_intent: 'pi_fkjehgfi3y45743y76e' #1800 — open report of No such payment_intent misdiagnosed as device-specific; almost certainly this same issue surfacing on devices that happen to exercise the connected-account path.

Happy to add an e2e test if there's a reasonable way to set one up against example-stripe-connect/ — pointers welcome.

Made with Cursor

[cla-assistant]

All committers have signed the CLA.