packages/stripe_platform_interface/lib/src/stripe_platform_interface.dart (1)

199-200: Consider providing a default implementation to avoid breaking custom platform implementations.

Adding a new abstract method to StripePlatform will break any custom platform implementations. While this is likely acceptable for a beta feature, providing a default no-op implementation would be more defensive.

💡 Suggested default implementation

  /// Set the confirm handler for embedded payment elements
- void setConfirmHandler(ConfirmHandler? handler);
+ void setConfirmHandler(ConfirmHandler? handler) {
+   // Default no-op implementation for platforms that don't support embedded payment elements
+ }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe_platform_interface/lib/src/stripe_platform_interface.dart`
around lines 199 - 200, The new abstract method
setConfirmHandler(ConfirmHandler? handler) on StripePlatform will break existing
custom platform implementations; change it to provide a default no-op
implementation on the StripePlatform base class instead of leaving it abstract:
add a concrete method setConfirmHandler(ConfirmHandler? handler) { /* no-op */ }
(or call a protected hook) so existing subclasses are not forced to implement
it, referencing the StripePlatform class and the setConfirmHandler and
ConfirmHandler symbols to locate where to add the default.

packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeSdkModuleExtensions.kt (1)

85-103: List handling could silently drop nested objects/maps.

When a list contains nested Maps or other complex types, the function logs an error but doesn't convert them. This could lead to data loss if the API evolves to pass arrays of objects. Consider documenting this limitation or adding support for List<Map> if needed for future embedded payment element configurations.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeSdkModuleExtensions.kt`
around lines 85 - 103, The code currently logs and drops lists of complex
objects in mapToBundle (seen around result.putStringArrayList /
result.putIntegerArrayList and the android.util.Log.e("mapToBundle"...)), so
update mapToBundle to handle List<Map<*,*>> by converting each Map to a Bundle
recursively (reusing the same mapToBundle logic), collect them into an
ArrayList<Bundle> and call result.putParcelableArrayList(key, arrayList) instead
of logging an error; keep the existing string/int branches as-is and document
the remaining unsupported types if any.

packages/stripe_android/android/gradle/wrapper/gradle-wrapper.properties (1)

3-5: Consider upgrading Android Gradle Plugin (AGP) to 8.13+ for better alignment with Gradle 9.3.1.

Gradle 9.3.1 is compatible with AGP 8.1.3, but not officially tested together. Official recommendations suggest matching major versions (AGP 8.x with Gradle 8.x) for stability. AGP 8.x relies on internal Gradle APIs that may break in future Gradle 9.x releases. For long-term maintainability, either upgrade AGP to 8.13+ (tested with Gradle 9.x) or use Gradle 8.x instead.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe_android/android/gradle/wrapper/gradle-wrapper.properties`
around lines 3 - 5, The project is using Gradle 9.3.1 (distributionUrl) but the
Android Gradle Plugin (com.android.tools.build:gradle) isn’t guaranteed
compatible; either upgrade the AGP to a 8.13+ release by updating the
com.android.tools.build:gradle dependency in your buildscript/classpath or
plugin block (e.g., bump to 8.13.x) to match Gradle 9.x, or instead pin the
wrapper’s distributionUrl to a Gradle 8.x release (replace gradle-9.3.1-bin.zip
with a Gradle 8.x distribution) so AGP 8.x remains supported—update the
classpath/plugin declaration for com.android.tools.build:gradle and/or the
distributionUrl in gradle-wrapper.properties accordingly.

packages/stripe/lib/src/widgets/embedded_payment_element_controller.dart (1)

24-38: Consider throwing instead of assert for consistent debug/release behavior.

The assert followed by _context?.confirm() creates inconsistent behavior:

• Debug mode: Assert fires, throws if not attached
• Release mode: Assert stripped, silently returns null

For a payment flow, silent failures in release could mask bugs.

♻️ Option: Throw StateError for consistent behavior

   Future<Map<String, dynamic>?> confirm() async {
-    assert(
-      hasEmbeddedPaymentElement,
-      'Controller must be attached to an EmbeddedPaymentElement',
-    );
-    return await _context?.confirm();
+    final context = _context;
+    if (context == null) {
+      throw StateError('Controller must be attached to an EmbeddedPaymentElement');
+    }
+    return await context.confirm();
   }

   Future<void> clearPaymentOption() async {
-    assert(
-      hasEmbeddedPaymentElement,
-      'Controller must be attached to an EmbeddedPaymentElement',
-    );
-    await _context?.clearPaymentOption();
+    final context = _context;
+    if (context == null) {
+      throw StateError('Controller must be attached to an EmbeddedPaymentElement');
+    }
+    await context.clearPaymentOption();
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe/lib/src/widgets/embedded_payment_element_controller.dart`
around lines 24 - 38, Replace the debug-only asserts in confirm() and
clearPaymentOption() with explicit runtime checks that throw a descriptive
StateError when hasEmbeddedPaymentElement is false so behavior is consistent in
release builds; specifically, in both methods (confirm and clearPaymentOption)
check hasEmbeddedPaymentElement and if false throw StateError('Controller must
be attached to an EmbeddedPaymentElement'), then call the non-null _context
methods (e.g., _context!.confirm() and _context!.clearPaymentOption()) to avoid
silent null returns.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt (2)

134-183: ⚠️ Potential issue | 🟠 Major

Guarantee JS-awake cleanup and bound JS waits.

keepJsAwakeTask.stop() and embeddedIntentCreationCallback reset still only happen after successful awaits. Move cleanup/reset into finally blocks and wrap JS deferred awaits with a timeout so a lost JS response cannot leak the awake task or suspend indefinitely.

Also applies to: 217-221

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt`
around lines 134 - 183, The keep-awake task and embeddedIntentCreationCallback
reset are only performed after successful awaits which can leak the awake task
or suspend forever; update the coroutine in EmbeddedPaymentElementView (the
coroutineScope.launch block around KeepJsAwakeTask and
stripeSdkModule.customPaymentMethodResultCallback) to ensure
keepJsAwakeTask.stop() and resetting embeddedIntentCreationCallback happen in a
finally block (so cleanup always runs) and wrap the suspend call to
stripeSdkModule.customPaymentMethodResultCallback.await() with a timeout (e.g.,
using withTimeout or withTimeoutOrNull) so the coroutine unblocks if JS never
responds; also apply the same pattern to the other occurrence around lines
217-221 to guarantee cleanup and bounded waits.

---

114-132: ⚠️ Potential issue | 🟠 Major

Return a failed CPM result when setup cannot start.

If starting CustomPaymentMethodActivity fails, or requireStripeSdkModule() fails, the callback returns without calling CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(...), leaving Stripe waiting for a terminal result.

Suggested direction

           } catch (e: Exception) {
             Log.e("StripeReactNative", "Failed to start CustomPaymentMethodActivity", e)
+            CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(
+              reactContext,
+              CustomPaymentMethodResult.failed(displayMessage = "Unable to start custom payment method confirmation"),
+            )
+            return@remember
           }
@@
             } catch (ex: IllegalArgumentException) {
               Log.e("StripeReactNative", "StripeSdkModule not found for CPM callback", ex)
+              CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(
+                reactContext,
+                CustomPaymentMethodResult.failed(displayMessage = "Unable to confirm custom payment method"),
+              )
               CustomPaymentMethodActivity.finishCurrent()
               return@remember
             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt`
around lines 114 - 132, When CustomPaymentMethodActivity cannot be started or
requireStripeSdkModule() throws, ensure you return a terminal failed CPM result
instead of early returning: catch the Exception in the startActivity block and
call CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(...) with
a failure/terminal result (indicating setup failure) before logging; similarly,
in the catch for requireStripeSdkModule() (where you log and call
CustomPaymentMethodActivity.finishCurrent()), invoke
CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(...) with a
failed result prior to returning from the remember block so Stripe receives a
terminal CPM response.

packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementViewManager.kt (2)

137-167: ⚠️ Potential issue | 🟠 Major

Thread returnURL into the Android embedded configuration.

The builder still ignores caller-supplied returnURL, while the iOS embedded path validates it. This can break redirect-based payment methods and creates cross-platform behavior drift.

Verify the Stripe Android builder setter name and the platform parity points before patching:

#!/bin/bash
# Description: Confirm Android omission and compare existing returnURL handling.
rg -n -C4 'returnURL|returnUrl|return_url|EmbeddedPaymentElement\\.Configuration|Configuration\\.Builder' \
  --type kt --type swift --type dart

Expected patch shape

     val primaryButtonLabel = readableMap?.getString("primaryButtonLabel")
     val paymentMethodOrder = readableMap?.getStringList("paymentMethodOrder")
+    val returnURL = readableMap?.getString("returnURL")
@@
     primaryButtonLabel?.let { configurationBuilder.primaryButtonLabel(it) }
     paymentMethodOrder?.let { configurationBuilder.paymentMethodOrder(it) }
+    returnURL
+      ?.takeIf { it.isNotBlank() }
+      ?.let { configurationBuilder.returnUrl(it) }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementViewManager.kt`
around lines 137 - 167, The builder never applies caller-supplied returnURL to
EmbeddedPaymentElement.Configuration.Builder, so extract the return URL from
readableMap (e.g., val returnUrl = readableMap?.getString("returnURL") or
"returnUrl") and, after verifying the exact Android setter name on
EmbeddedPaymentElement.Configuration.Builder (returnUrl, returnURL, or similar),
call that setter on configurationBuilder (e.g.,
configurationBuilder.returnUrl(returnUrl)) guarded by a null check; place this
call alongside the other optional setters (near
primaryButtonLabel/paymentMethodOrder) so Android mirrors iOS behavior.

---

97-115: ⚠️ Potential issue | 🔴 Critical

Don’t convert recoverable config errors into bare Errors.

These catches discard the original PaymentSheetException / PaymentSheetAppearanceException and can crash the prop setter instead of reporting onLoadingFailed with useful details. Preserve the cause and route the failure through the loading-error path.

Suggested direction

       try {
         buildCustomerConfiguration(readableMap)
       } catch (error: PaymentSheetException) {
-        throw Error()
+        throw IllegalArgumentException("Invalid customer configuration", error)
       }
@@
       try {
         buildPaymentSheetAppearance(readableMap?.getMap("appearance"), context)
       } catch (error: PaymentSheetAppearanceException) {
-        throw Error()
+        throw IllegalArgumentException("Invalid payment sheet appearance", error)
       }

Prefer catching these in setConfiguration(...) and invoking view.onLoadingFailed(...) rather than rethrowing from the React prop setter.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementViewManager.kt`
around lines 97 - 115, In EmbeddedPaymentElementViewManager (e.g., in the prop
handling where buildCustomerConfiguration and buildPaymentSheetAppearance are
called), stop converting PaymentSheetException/PaymentSheetAppearanceException
into bare Error() throws; instead catch those exceptions and route them to the
view's loading-error path—call view.onLoadingFailed(error) (or a similar failure
callback) and return/assign a safe fallback (e.g., null) so setConfiguration or
the host can handle the failure without crashing; do this in the
setConfiguration/property setter surrounding buildCustomerConfiguration and
buildPaymentSheetAppearance so the original exception is preserved and
propagated via onLoadingFailed rather than rethrown.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeSdkEmbeddedPaymentElementPlatformView.kt (2)

29-47: ⚠️ Potential issue | 🟠 Major

channel.invokeMethod must run on the main thread.

These callbacks are driven from EmbeddedPaymentElementView's Compose effects and onSizeChanged. While those typically run on main, reportHeightChange is reached via onSizeChanged (main) but embedded.paymentOption.collect { ... onPaymentOptionChanged?.invoke(...) } runs on whichever dispatcher the coroutine scope was created in. Dispatching each channel.invokeMethod through Handler(Looper.getMainLooper()).post { ... } (or verify-then-document the dispatcher invariant) would eliminate a latent threading violation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeSdkEmbeddedPaymentElementPlatformView.kt`
around lines 29 - 47, The channel.invokeMethod calls in
StripeSdkEmbeddedPaymentElementPlatformView's embeddedView callbacks
(onHeightChanged, onPaymentOptionChanged, onLoadingFailed,
onRowSelectionImmediateAction, onFormSheetConfirmComplete) must be executed on
the Android main thread; update each callback to post the invokeMethod
invocation to the main looper (e.g., use Handler(Looper.getMainLooper()).post {
... } or an equivalent runOnUiThread) so that channel.invokeMethod(...) is
always called from the main thread to avoid threading violations.

---

92-98: ⚠️ Potential issue | 🟠 Major

confirm path still leaks onConfirmResult / hangs Flutter on a synchronous throw.

If viewManager.confirm(embeddedView) throws synchronously (e.g., the view manager's confirm() raises before trySend queues the event), the onConfirmResult callback is never invoked and Flutter's confirm() future hangs forever. Wrap in try/catch, clear the callback, and surface via result.error(...).

🔧 Proposed fix

             "confirm" -> {
                 embeddedView.onConfirmResult = { resultMap ->
                     result.success(resultMap)
                     embeddedView.onConfirmResult = null
                 }
-                viewManager.confirm(embeddedView)
+                try {
+                    viewManager.confirm(embeddedView)
+                } catch (e: Exception) {
+                    embeddedView.onConfirmResult = null
+                    result.error("confirm_failed", e.message, null)
+                }
             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeSdkEmbeddedPaymentElementPlatformView.kt`
around lines 92 - 98, The confirm branch sets embeddedView.onConfirmResult but
does not handle synchronous exceptions from viewManager.confirm, which can leak
the callback and hang Flutter; wrap the call to
viewManager.confirm(embeddedView) in try/catch/finally: set
embeddedView.onConfirmResult before the call, in catch call result.error(...)
with the exception details, and in finally clear embeddedView.onConfirmResult =
null to ensure it is never left set; use the same symbols
(embeddedView.onConfirmResult, viewManager.confirm, result.success/result.error)
so the fix is applied to StripeSdkEmbeddedPaymentElementPlatformView.

packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt (4)

265-275: ⚠️ Potential issue | 🟠 Major

rowSelectionBehaviorType default (null) currently maps to ImmediateAction.

rowSelectionBehaviorType is initialized to null (L90). During the first composition before props settle, type != RowSelectionBehaviorType.Default (because it's null), so the builder installs immediateAction {...} — flipping the default UX for callers that never asked for it. Match the intended branch explicitly.

🔧 Proposed fix

           .rowSelectionBehavior(
-            if (type == RowSelectionBehaviorType.Default) {
-              EmbeddedPaymentElement.RowSelectionBehavior.default()
-            } else {
-              EmbeddedPaymentElement.RowSelectionBehavior.immediateAction {
-                onRowSelectionImmediateAction?.invoke() ?: run {
-                  requireStripeSdkModule().eventEmitter.emitEmbeddedPaymentElementRowSelectionImmediateAction()
-                }
-              }
-            },
+            if (type == RowSelectionBehaviorType.ImmediateAction) {
+              EmbeddedPaymentElement.RowSelectionBehavior.immediateAction {
+                onRowSelectionImmediateAction?.invoke() ?: run {
+                  requireStripeSdkModule().eventEmitter.emitEmbeddedPaymentElementRowSelectionImmediateAction()
+                }
+              }
+            } else {
+              EmbeddedPaymentElement.RowSelectionBehavior.default()
+            },
           )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt`
around lines 265 - 275, The current branch for .rowSelectionBehavior treats a
null initial prop as non-default and installs ImmediateAction; update the
conditional to explicitly check for the Default enum value (and treat null as
Default) so only when type == RowSelectionBehaviorType.Default call
EmbeddedPaymentElement.RowSelectionBehavior.default(), otherwise call
EmbeddedPaymentElement.RowSelectionBehavior.immediateAction { ... }. Locate the
code building rowSelectionBehavior (the variable named type and the call to
.rowSelectionBehavior, and the enum RowSelectionBehaviorType) and change the
condition to explicitly compare type to RowSelectionBehaviorType.Default (or
treat null via a safe coalescing/defaulting expression) before choosing
immediateAction.

---

99-99: ⚠️ Potential issue | 🟡 Minor

Hard-cast to ThemedReactContext and module lookup couples the view to RN.

context as ThemedReactContext will crash if this view is ever constructed from Flutter with a non-RN context (the Flutter factory side already builds a ThemedReactContext to satisfy this coupling — see StripeSdkEmbeddedPaymentElementPlatformView.kt L24). Injecting StripeSdkModule and the event callbacks as constructor parameters would remove the hidden requirement and make multi-host usage (RN + Flutter) safer.

Also applies to: 412-412

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt`
at line 99, The view currently hard-casts context in the reactContext property
(reactContext get() = context as ThemedReactContext) which ties
EmbeddedPaymentElementView to React Native and can crash under other hosts;
change the constructor of EmbeddedPaymentElementView to accept a
ThemedReactContext (or a generic Context) plus injected dependencies: the
StripeSdkModule instance and any event callback lambdas, remove the hard-cast
reactContext property and use the injected references instead, and update all
usages (including the other occurrence where reactContext is referenced) to use
the injected module/callbacks so the view no longer assumes RN-specific context.

---

191-232: ⚠️ Potential issue | 🟠 Major

createIntentCallback leaks state on failure and silently serializes multi-instance flows.

1. Cleanup ordering: keepJsAwakeTask.stop() (L221) and embeddedIntentCreationCallback = CompletableDeferred() (L219) run only on the happy path. If the await throws / is cancelled, the keep-awake lock leaks and the next confirm() will pick up the stale deferred. Wrap both lines in try { … } finally { … }.
2. embeddedIntentCreationCallback and customPaymentMethodResultCallback live on the StripeSdkModule singleton, so two concurrent EmbeddedPaymentElement instances (or overlapping confirm retries) share the same CompletableDeferred — the first to resolve it wins and the other call suspends indefinitely. Worth documenting this as a known limitation for multi-instance use, or routing these callbacks per-view.
3. Consider withTimeoutOrNull(...) on await() so a lost JS response surfaces as a CreateIntentResult.Failure rather than a hang.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt`
around lines 191 - 232, The createIntentCallback leaks state and can deadlock
across instances: wrap the await and subsequent cleanup in a try/finally so
keepJsAwakeTask.stop() and stripeSdkModule.embeddedIntentCreationCallback =
CompletableDeferred() always run even if await() throws or is cancelled; replace
the direct await() call with a timed wait (e.g., withTimeoutOrNull) so a missing
JS response returns a CreateIntentResult.Failure instead of hanging; and
eliminate the singleton-per-process collision by routing callbacks per-view
(e.g., include a unique requestId when emitting event and store
CompletableDeferred objects in a map keyed by that id, or document the
single-instance limitation) — update references: createIntentCallback,
KeepJsAwakeTask, stripeSdkModule.embeddedIntentCreationCallback,
stripeSdkModule.eventEmitter.emitOnConfirmHandlerCallback, and
embeddedIntentCreationCallback.await().

---

113-183: ⚠️ Potential issue | 🟠 Major

Missing CustomPaymentMethodResult.failed(...) on every early-exit path — Stripe SDK hangs.

Three related paths still don't notify Stripe:

• L114–123: startActivity failure only logs and falls through; the coroutineScope.launch below then awaits customPaymentMethodResultCallback, which no JS listener will ever resolve → the payment flow hangs forever.
• L125–132: requireStripeSdkModule() failure returns from the outer lambda without calling CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(...) — Stripe keeps waiting on our callback.
• L138–183: If customPaymentMethodResultCallback.await() throws (e.g., cancellation), keepJsAwakeTask.stop() on L152 is skipped; the only finally is for finishCurrent().

Put keepJsAwakeTask.stop() in finally, and on every error path call CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(reactContext, CustomPaymentMethodResult.failed(...)) before returning. Also consider withTimeoutOrNull(...) around the await to bound hangs when JS never answers.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementView.kt`
around lines 113 - 183, The startActivity catch, the requireStripeSdkModule()
catch, and the coroutine await failure paths never return a failed
CustomPaymentMethodResult to Stripe, causing hangs; update the startActivity
exception handler and the requireStripeSdkModule() catch to call
CustomPaymentMethodResultHandler.handleCustomPaymentMethodResult(reactContext,
CustomPaymentMethodResult.failed(displayMessage = "...")) before returning, and
inside the coroutineScope.launch wrap the await call
(stripeSdkModule.customPaymentMethodResultCallback.await()) with a bounded
timeout (e.g., withTimeoutOrNull) and ensure KeepJsAwakeTask.stop() is invoked
in a finally block so it always stops, and on any null/exception path convert to
CustomPaymentMethodResult.failed(...) and pass it to
CustomPaymentMethodResultHandler before finishing and calling
CustomPaymentMethodActivity.finishCurrent().

packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementViewManager.kt (2)

137-167: ⚠️ Potential issue | 🟠 Major

returnURL is silently dropped on Android — cross-platform parity gap.

iOS validates returnURL as required (StripeSdkImpl+Embedded.swift Lines 64–68), but this builder never reads readableMap?.getString("returnURL"), so any caller-supplied value is discarded on Android. At minimum, pass it through to EmbeddedPaymentElement.Configuration.Builder so apps relying on Link/redirect flows behave the same on both platforms.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementViewManager.kt`
around lines 137 - 167, The builder chain for
EmbeddedPaymentElement.Configuration in EmbeddedPaymentElementViewManager.kt is
missing the returnURL from the incoming readableMap, causing returnURL to be
dropped on Android; update the configuration building to read
readableMap?.getString("returnURL") and call the corresponding Builder method
(e.g., .returnURL(...)) before .build() so the value is passed through (locate
the EmbeddedPaymentElement.Configuration.Builder(...) block and add the
.returnURL(readableMap?.getString("returnURL")) invocation, preserving
null-safety consistent with other fields like linkConfig and googlePayConfig).

---

97-115: ⚠️ Potential issue | 🔴 Critical

Still rethrowing recoverable parse failures as Error — drops the original cause.

throw Error() creates a bare kotlin.Error / java.lang.Error (the superclass of OutOfMemoryError etc.), which:

1. Loses the caught exception entirely (no cause, no message).
2. Is semantically reserved for unrecoverable VM errors — most frameworks (including RN's error boundary) won't catch it, so it propagates out of setConfiguration and can crash the host.

Surface failures through view.onLoadingFailed(...) / event emission with the original PaymentSheetException / PaymentSheetAppearanceException as cause, the same way PaymentSheetManager does.

🔧 Suggested direction

     val customerConfiguration =
       try {
         buildCustomerConfiguration(readableMap)
       } catch (error: PaymentSheetException) {
-        throw Error()
+        view.onLoadingFailed?.invoke(
+          EmbeddedPaymentElementLoadingError(
+            message = error.message ?: "Invalid customer configuration",
+            code = "invalid_customer_configuration",
+            details = null,
+          ),
+        )
+        return@setConfiguration // caller path needs a matching early-return
       }

(You'll also need to propagate that early-return through setConfiguration or guard subsequent access.)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/reactnativestripesdk/EmbeddedPaymentElementViewManager.kt`
around lines 97 - 115, The try/catch blocks in EmbeddedPaymentElementViewManager
(around buildCustomerConfiguration and buildPaymentSheetAppearance) currently
throw a bare Error, losing the original exception and risking an uncaught VM
error; instead catch PaymentSheetException and PaymentSheetAppearanceException
and surface the original exception via view.onLoadingFailed(...) or an RN event
(include the caught exception as the cause/message), then abort or return from
setConfiguration (or guard later usage of customerConfiguration/appearance) so
subsequent code doesn’t run after a parse failure—mirror the behavior used in
PaymentSheetManager for error propagation.

packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/EmbeddedPaymentElementFactory.swift (2)

190-192: ⚠️ Potential issue | 🟠 Major

window?.rootViewController misses modals/navigation stacks.

Assigning window?.rootViewController will present authentication / form sheets from the wrong controller when a modal is active. The codebase already has findViewControllerPresenter() in StripeSdkImpl.swift that traverses presentedViewController — please use it in both attachEmbeddedView and embeddedPaymentElementWillPresent.

Also applies to: 248-251

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/EmbeddedPaymentElementFactory.swift`
around lines 190 - 192, Replace direct use of window?.rootViewController when
setting embeddedElement.presentingViewController with the app's view-controller
traversal helper to avoid presenting behind modals; specifically, in
attachEmbeddedView and embeddedPaymentElementWillPresent locate the presenting
controller via StripeSdkImpl.findViewControllerPresenter() (or the equivalent
function that walks presentedViewController) and assign that controller to
embeddedElement.presentingViewController instead of using
embeddedView.window?.rootViewController so presentation honors active
modal/navigation stacks.

---

120-163: ⚠️ Potential issue | 🟠 Major

Shared-singleton routing still present; confirm/clear will misroute with multiple views.

StripeSdkImpl.shared.createEmbeddedPaymentElement(...) stores the created element on self.embeddedInstance (see StripeSdkImpl+Embedded.swift line 78). Creating a second EmbeddedPaymentElement widget while the first is still on screen will overwrite embeddedInstance, and since handle(...) at Lines 200–213 routes confirm/clearPaymentOption through the same shared impl, actions from the first widget's Flutter channel will silently operate on the second widget's element (and its delegate/attachedView). Please either reject creating a second instance explicitly, or refactor the iOS side to key embedded instances per viewId.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/EmbeddedPaymentElementFactory.swift`
around lines 120 - 163, The code stores the created element in a shared
singleton (StripeSdkImpl.shared.embeddedInstance) which allows a second
EmbeddedPaymentElement to overwrite the first and misroute confirm/clear calls;
change createEmbeddedPaymentElement usage in EmbeddedPaymentElementFactory.swift
so it either (A) rejects creation when StripeSdkImpl.shared.embeddedInstance is
already non-nil/attached by returning an error via the
reject/embeddedPaymentElementLoadingFailed callback (use the same error payload
shape), or (B) refactors the iOS side to track instances per viewId (e.g., keep
a dictionary keyed by viewId inside StripeSdkImpl and update
createEmbeddedPaymentElement, embeddedInstance references, and
handle(confirm/clearPaymentOption) to use the viewId key) so
confirm/clearPaymentOption/handle(...) route to the correct instance instead of
the single shared embeddedInstance.

packages/stripe/lib/src/widgets/embedded_payment_element.dart (1)

120-144: ⚠️ Potential issue | 🟠 Major

Config changes aren't propagated after initial creation, and dispose() wipes a global handler unconditionally.

Two pre-existing concerns still apply after this round:

1. didUpdateWidget only handles controller changes — if the caller rebuilds with a new intentConfiguration, configuration, or confirmHandler, the live native instance stays on the stale config (native only reads creationParams once). Consider mirroring the card_field.dart pattern and invoking a method-channel update, or at least calling setConfirmHandler again when widget.intentConfiguration.confirmHandler changes.
2. dispose() calls Stripe.instance.setConfirmHandler(null) whenever the outgoing widget had a handler. Since setConfirmHandler operates on shared global state, unmounting one EmbeddedPaymentElement can blow away another live instance's handler. Track whether this state installed the handler and only clear it when that's still the active one.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe/lib/src/widgets/embedded_payment_element.dart` around lines
120 - 144, Update didUpdateWidget and dispose to correctly propagate config
changes and avoid clobbering global state: in didUpdateWidget (in addition to
controller changes) detect changes to widget.intentConfiguration,
widget.configuration, and widget.intentConfiguration.confirmHandler and call the
native update path (mirror card_field.dart — e.g., invoke the existing
method-channel update or re-send creationParams) and re-run
Stripe.instance.setConfirmHandler when the confirmHandler reference changes; in
dispose, stop unconditionally clearing the global handler by tracking ownership
(add a private field like _installedConfirmHandler or _confirmHandlerOwner set
when you call Stripe.instance.setConfirmHandler(thisHandler)) and only call
Stripe.instance.setConfirmHandler(null) if this widget installed the active
handler, leaving other widgets’ handlers untouched.

packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeAndroidPlugin.kt (1)

13-13: Redundant import — already covered by wildcard.

Line 10 already wildcard-imports com.reactnativestripesdk.*, so this explicit import is dead noise and can be removed.

♻️ Diff

 import com.reactnativestripesdk.*
 import com.reactnativestripesdk.addresssheet.AddressSheetViewManager
 import com.reactnativestripesdk.pushprovisioning.AddToWalletButtonManager
-import com.reactnativestripesdk.EmbeddedPaymentElementViewManager
 import com.reactnativestripesdk.utils.getIntOrNull

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeAndroidPlugin.kt`
at line 13, Remove the redundant explicit import of
EmbeddedPaymentElementViewManager since com.reactnativestripesdk.* already
covers it; locate the import line importing EmbeddedPaymentElementViewManager in
StripeAndroidPlugin.kt and delete that single import so only the wildcard import
remains (no other code changes needed).

packages/stripe/lib/src/stripe.dart (1)

571-575: Doc nit: mention the clear-handler semantics.

Passing null to this setter unregisters the handler on the native side — worth calling out so consumers of EmbeddedPaymentElement know to clear the callback on dispose to avoid retaining stale closures.

💡 Suggested docstring

-  /// Registers a callback that the native embedded element invokes when it
-  /// needs the app to create an intent client secret.
+  /// Registers a callback that the native embedded element invokes when it
+  /// needs the app to create an intent client secret.
+  ///
+  /// Pass `null` to clear a previously registered handler (e.g. when the
+  /// embedded element widget is disposed).
   void setConfirmHandler(ConfirmHandler? handler) {
     _platform.setConfirmHandler(handler);
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe/lib/src/stripe.dart` around lines 571 - 575, The docstring
for setConfirmHandler should mention that passing null unregisters the native
callback so callers can clear it (e.g., on dispose) to avoid retaining stale
closures; update the comment on void setConfirmHandler(ConfirmHandler? handler)
(and mention ConfirmHandler and _platform.setConfirmHandler) to explicitly state
the clear-handler semantics and recommend calling setConfirmHandler(null) when
disposing EmbeddedPaymentElement.

packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/Stripe Sdk/StripeSdkImpl+Embedded.swift (1)

58-68: Nitpick: simplify the nil/empty checks.

The == nil || ?.isEmpty == true pattern is a bit verbose — an empty-or-nil check via ?? or isNilOrEmpty helper reads cleaner and avoids the redundant optional ladder.

♻️ Suggested simplification

-    if STPAPIClient.shared.publishableKey == nil || STPAPIClient.shared.publishableKey?.isEmpty == true {
-      let errorMsg = "Stripe publishableKey is not set"
-      resolve(Errors.createError(ErrorType.Failed, errorMsg))
-      return
-    }
-
-    if configuration.returnURL == nil || configuration.returnURL?.isEmpty == true {
-      let errorMsg = "returnURL is required for EmbeddedPaymentElement"
-      resolve(Errors.createError(ErrorType.Failed, errorMsg))
-      return
-    }
+    if (STPAPIClient.shared.publishableKey ?? "").isEmpty {
+      resolve(Errors.createError(ErrorType.Failed, "Stripe publishableKey is not set"))
+      return
+    }
+
+    if (configuration.returnURL ?? "").isEmpty {
+      resolve(Errors.createError(ErrorType.Failed, "returnURL is required for EmbeddedPaymentElement"))
+      return
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/Stripe`
Sdk/StripeSdkImpl+Embedded.swift around lines 58 - 68, Replace the verbose
nil-or-empty checks with concise empty-or-nil checks: for
STPAPIClient.shared.publishableKey and configuration.returnURL use a single
condition that treats nil as empty (e.g. coalesce to "" or use a helper like
isNilOrEmpty) so the ifs become simpler and equivalent; update the branches
around STPAPIClient.shared.publishableKey and configuration.returnURL in
StripeSdkImpl+Embedded.swift (the resolve(Errors.createError(...)) calls and
returns remain unchanged).

packages/stripe/lib/src/widgets/embedded_payment_element.dart (2)

302-302: Hard-coded fallback height of 400 can clip content on first render.

Before the first onHeightChanged arrives, the platform view is forced into a 400 logical-pixel box. On screens/themes where the initial natural height exceeds 400 (saved payment methods + link/apple pay), the view will be vertically clipped (ClipRect on iOS) for the brief window until native reports back. Consider using double.infinity with a parent constraint, or at least plumbing a initialHeight parameter through the widget for callers who know the expected size.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe/lib/src/widgets/embedded_payment_element.dart` at line 302,
The hard-coded fallback of 400 in the EmbeddedPaymentElement causes clipping
before native onHeightChanged reports; update the widget to accept an optional
initialHeight parameter (e.g., add final double? initialHeight to the
EmbeddedPaymentElement constructor) and change the height decision from
"_currentHeight > 0 ? _currentHeight : 400" to use the initialHeight or an
unconstrained alternative (e.g., "_currentHeight > 0 ? _currentHeight :
(widget.initialHeight ?? double.infinity)"), or document callers should wrap in
a parent with constraints if double.infinity is used; ensure any platform view
container code that references _currentHeight uses this new fallback so initial
render won't be clipped.

---

176-224: Blanket catch (e) + debugPrint hides real bugs from callers.

Wrapping all method-call handlers in a single try / catch and only debugPrinting is convenient but swallows parse/serialization bugs (e.g., malformed paymentOption payloads) so onLoadingFailed / onPaymentOptionChanged silently fail. At minimum, surface unexpected errors through widget.onLoadingFailed (or a dedicated diagnostics callback) so callers can actually observe them.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe/lib/src/widgets/embedded_payment_element.dart` around lines
176 - 224, The blanket try/catch around the platform method dispatch swallows
real errors; change the catch block in the method that processes `call` (the
handler containing switch on call.method) to forward unexpected exceptions to
the consumer via `widget.onLoadingFailed` instead of only calling debugPrint:
capture the caught exception and convert it into the same error type returned by
`_parseLoadingError` (or construct a simple loading error wrapper) and invoke
`widget.onLoadingFailed?.call(...)`, then still log the error with debugPrint;
leave regular per-case error handling (e.g. parsing for
`onPaymentOptionChanged`, `onHeightChanged`) intact so parse/serialization
failures are surfaced to callers.

packages/stripe/lib/src/widgets/embedded_payment_element_controller.dart (1)

3-53: Controller extends ChangeNotifier but never notifies — release-mode assertions also silently pass.

1. The controller extends ChangeNotifier but attach/detach/dispose never call notifyListeners(). Anyone who adds a listener (e.g., a UI that wants to react to hasEmbeddedPaymentElement changes) will see nothing. Either call notifyListeners() on attach/detach, or drop the ChangeNotifier base if listener-based reactivity isn't the design intent.
2. confirm() and clearPaymentOption() protect against "not attached" only via assert(...) which is stripped in release. If detached in release, they silently resolve to null / no-op, which is a tricky-to-debug footgun. Consider throwing a StateError so misuse is loud in production too.

♻️ Suggested refactor

   void attach(EmbeddedPaymentElementContext context) {
     assert(
       !hasEmbeddedPaymentElement,
       'Controller is already attached to an EmbeddedPaymentElement',
     );
     _context = context;
+    notifyListeners();
   }

   void detach(EmbeddedPaymentElementContext context) {
     if (_context == context) {
       _context = null;
+      notifyListeners();
     }
   }

   Future<Map<String, dynamic>?> confirm() async {
-    assert(
-      hasEmbeddedPaymentElement,
-      'Controller must be attached to an EmbeddedPaymentElement',
-    );
-    return await _context?.confirm();
+    final context = _context;
+    if (context == null) {
+      throw StateError('Controller is not attached to an EmbeddedPaymentElement');
+    }
+    return context.confirm();
   }

   Future<void> clearPaymentOption() async {
-    assert(
-      hasEmbeddedPaymentElement,
-      'Controller must be attached to an EmbeddedPaymentElement',
-    );
-    await _context?.clearPaymentOption();
+    final context = _context;
+    if (context == null) {
+      throw StateError('Controller is not attached to an EmbeddedPaymentElement');
+    }
+    await context.clearPaymentOption();
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stripe/lib/src/widgets/embedded_payment_element_controller.dart`
around lines 3 - 53, The controller currently extends ChangeNotifier but never
calls notifyListeners and its methods confirm, clearPaymentOption, and
disposeView only assert attachment (stripped in release), so update
EmbeddedPaymentElementController: call notifyListeners() at the end of
attach(EmbeddedPaymentElementContext), detach(EmbeddedPaymentElementContext) and
override dispose() (notifyListeners before clearing _context) to inform
listeners of state changes; replace the assert guards in confirm(),
clearPaymentOption(), and disposeView() with runtime checks that throw a
StateError with a clear message (e.g., "Controller must be attached to an
EmbeddedPaymentElement") when _context is null so misuse fails loudly in
production; keep using _context?.method() only after verifying non-null.

packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeSdkEmbeddedPaymentElementPlatformView.kt (1)

55-67: Consider renaming the ReadableMap wrapper to avoid shadowing React Native's interface.

Lines 57 and 67 use ReadableMap(configMap as Map<String, Any>), which compiles because a custom wrapper class named ReadableMap is defined in packages/stripe_android/android/src/main/kotlin/com/facebook/react/bridge/ReadableMap.java. However, this wrapper intentionally shadows React Native's ReadableMap interface—both share the identical package name com.facebook.react.bridge. While this works today, it creates confusion and maintainability risk, as developers may mistakenly assume they're working with the RN interface. Rename the wrapper class to a distinct name (e.g., RNReadableMap, ReadableMapWrapper) and update all usages across the codebase to make the shadowing explicit and avoid future errors.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/stripe_android/android/src/main/kotlin/com/flutter/stripe/StripeSdkEmbeddedPaymentElementPlatformView.kt`
around lines 55 - 67, The custom wrapper class ReadableMap (in package
com.facebook.react.bridge) shadows React Native's ReadableMap interface; rename
the wrapper to a distinct name (e.g., RNReadableMap or ReadableMapWrapper) and
update all usages: replace constructor calls in
StripeSdkEmbeddedPaymentElementPlatformView (where ReadableMap(configMap as
Map<String, Any>) and ReadableMap(intentConfigMap as Map<String, Any>) are
used), and update any other references across the codebase (including the
wrapper class file and imports) so parseRowSelectionBehavior,
parseElementConfiguration, and other call sites use the new wrapper type and
imports to avoid name collision with RN's interface.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes