Skip to content

Fix: #2382 confirm token handler on payment sheet#2400

Merged
remonh87 merged 1 commit into
mainfrom
2382-confirmtokenhandler
May 8, 2026
Merged

Fix: #2382 confirm token handler on payment sheet#2400
remonh87 merged 1 commit into
mainfrom
2382-confirmtokenhandler

Conversation

@remonh87

@remonh87 remonh87 commented Apr 22, 2026

Copy link
Copy Markdown
Member

Fixes #2382

Summary by CodeRabbit

  • Bug Fixes
    • Fixed confirmation token parsing in payment callbacks so the correct token field is used.
    • Improved payment sheet initialization to properly detect and enable available confirmation handlers, ensuring handlers are invoked as expected.

@remonh87 remonh87 requested a review from jonasbark April 22, 2026 19:00
@coderabbitai

coderabbitai Bot commented Apr 22, 2026

Copy link
Copy Markdown
📝 Walkthrough

Walkthrough

Dart now precomputes and mutates the serialized intentConfiguration to set boolean flags indicating which confirm handler(s) are provided, and it fixes the confirmation-token parsing key. iOS no longer forcibly overwrites intentConfiguration to force confirmHandler = true; that mutation was removed and params are forwarded as-is.

Changes

Cohort / File(s) Summary
Platform interface — method channel & param preprocessing
packages/stripe_platform_interface/lib/src/method_channel_stripe.dart
Precompute paramsJson and mutate intentConfiguration map to set confirmHandler: true and/or confirmationTokenConfirmHandler: true when corresponding Dart callbacks are provided; fix onConfirmationTokenHandlerCallback parsing key from 'paymentMethod' to 'confirmationToken'.
iOS plugin — removed forced mutation
packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift
Removed code that unconditionally mutated params["intentConfiguration"] to force confirmHandler = true; now native receives params as provided by Dart. No public API signatures changed.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Suggested reviewers

  • jonasbark

Poem

🐰 A little token, quick and bright,
Hops from Dart into the night,
Flags set true where handlers dwell,
Native listens—no more knell,
Pipes lined up and all is right. ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically references the issue being fixed (#2382) and describes the main change: implementing the confirm token handler on payment sheet.
Linked Issues check ✅ Passed The PR addresses all three coding requirements from issue #2382: fixes the method-channel success key from 'paymentMethod' to 'confirmationToken', sets confirmTokenConfirmHandler boolean from Dart side, and removes hard-coded confirmHandler forcing logic from iOS.
Out of Scope Changes check ✅ Passed All changes are directly related to fixing the confirmTokenHandler flow: platform interface, iOS native code, and Dart serialization of intent configuration flags.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch 2382-confirmtokenhandler

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Comment thread packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift (1)

202-209: ⚠️ Potential issue | 🔴 Critical

Match the confirmation-token completion payload key used by Dart.

MethodChannelStripe.confirmationTokenCreationCallback sends params, but iOS only reads result, so after _confirmTokenHandler is invoked the completion callback is rejected as invalidParams on iOS.

🐛 Proposed fix
         case "confirmationTokenCreationCallback":
-            guard let arguments = call.arguments as? FlutterMap,
-                  let res = arguments["result"] as? NSDictionary else {
+            guard let arguments = call.arguments as? FlutterMap else {
+                result(FlutterError.invalidParams)
+                return
+            }
+            guard let res = (arguments["result"] as? NSDictionary)
+                    ?? (arguments["params"] as? NSDictionary) else {
                 result(FlutterError.invalidParams)
                 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/StripePlugin.swift`
around lines 202 - 209, The iOS handler for the
"confirmationTokenCreationCallback" case is reading the wrong payload key
("result") causing invalidParams; update the guard in StripePlugin.swift (inside
the switch case for "confirmationTokenCreationCallback") to read let res =
arguments["params"] as? NSDictionary (keeping the existing call.arguments as?
FlutterMap guard) and pass that res into
confirmationTokenCreationCallback(result: res) so the iOS key matches the Dart
MethodChannelStripe.confirmationTokenCreationCallback payload.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift`:
- Around line 456-458: The code incorrectly synthesizes
mutable["confirmHandler"] = true when mutable["confirmationTokenConfirmHandler"]
is nil, which can mark a confirm handler as present even when Dart didn't
provide one; update the logic in StripePlugin.swift where mutable is constructed
(look for keys "confirmationTokenConfirmHandler" and "confirmHandler" and the
downstream onConfirmHandlerCallback usage) so that you only set "confirmHandler"
when an explicit Dart flag for it exists (or when
confirmationTokenConfirmHandler is truthy), otherwise leave it unset/null to
allow native “missing handler” validation to catch absent callbacks.

---

Outside diff comments:
In `@packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift`:
- Around line 202-209: The iOS handler for the
"confirmationTokenCreationCallback" case is reading the wrong payload key
("result") causing invalidParams; update the guard in StripePlugin.swift (inside
the switch case for "confirmationTokenCreationCallback") to read let res =
arguments["params"] as? NSDictionary (keeping the existing call.arguments as?
FlutterMap guard) and pass that res into
confirmationTokenCreationCallback(result: res) so the iOS key matches the Dart
MethodChannelStripe.confirmationTokenCreationCallback payload.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

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

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 89f71c4d-1382-4854-a74d-2866df89e85d

📥 Commits

Reviewing files that changed from the base of the PR and between 21cf701 and c744634.

📒 Files selected for processing (2)
  • packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift
  • packages/stripe_platform_interface/lib/src/method_channel_stripe.dart

Comment thread packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift Outdated
@remonh87 remonh87 force-pushed the 2382-confirmtokenhandler branch from c744634 to a50fd50 Compare April 22, 2026 19:44

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
packages/stripe_platform_interface/lib/src/method_channel_stripe.dart (1)

246-258: Move handler-presence flag serialization into IntentConfiguration.toJson().

The native side checks for key presence (not boolean values)—absent keys are treated as false. Since IntentConfiguration already knows whether each handler is non-null, deriving confirmHandler and confirmationTokenConfirmHandler flags inside its own toJson() method would keep serialization logic self-contained and eliminate the post-mutation pattern and is Map<String, dynamic> guard here.

This requires a custom toJson() override since the handlers are marked @JsonKey(includeToJson: false).

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/stripe_platform_interface/lib/src/method_channel_stripe.dart` around
lines 246 - 258, The post-serialization mutation that sets
'confirmHandler'/'confirmationTokenConfirmHandler' on paramsJson (using
params.toJson(), intentConfig, and the is Map guard) should be removed and
instead implemented inside IntentConfiguration.toJson(): update
IntentConfiguration.toJson() to return a Map that includes 'confirmHandler' when
its confirmHandler field is non-null and 'confirmationTokenConfirmHandler' when
confirmTokenHandler is non-null (these handlers are currently annotated
`@JsonKey`(includeToJson: false)), then remove the extra mutation logic around
paramsJson/intentConfig in method_channel_stripe.dart and keep the invokeMethod
call as-is so the native side sees the presence (key existence) of those flags.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@packages/stripe_platform_interface/lib/src/method_channel_stripe.dart`:
- Around line 246-258: The post-serialization mutation that sets
'confirmHandler'/'confirmationTokenConfirmHandler' on paramsJson (using
params.toJson(), intentConfig, and the is Map guard) should be removed and
instead implemented inside IntentConfiguration.toJson(): update
IntentConfiguration.toJson() to return a Map that includes 'confirmHandler' when
its confirmHandler field is non-null and 'confirmationTokenConfirmHandler' when
confirmTokenHandler is non-null (these handlers are currently annotated
`@JsonKey`(includeToJson: false)), then remove the extra mutation logic around
paramsJson/intentConfig in method_channel_stripe.dart and keep the invokeMethod
call as-is so the native side sees the presence (key existence) of those flags.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: c80e9856-88ba-4e8b-9435-8a2c09309d9c

📥 Commits

Reviewing files that changed from the base of the PR and between c744634 and a50fd50.

📒 Files selected for processing (2)
  • packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift
  • packages/stripe_platform_interface/lib/src/method_channel_stripe.dart
🚧 Files skipped from review as they are similar to previous changes (1)
  • packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift

result(FlutterError.invalidParams)
return
}
if (params.object(forKey: "intentConfiguration") != nil && params.object(forKey: "intentConfiguration") is NSDictionary) {

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not needed anymore: Now that Dart explicitly sends exactly the right flag (confirmHandler or confirmationTokenConfirmHandler), the iOS layer should just pass the params through unchanged.

@scott-pestshare

Copy link
Copy Markdown

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift (1)> 202-209: ⚠️ Potential issue | 🔴 Critical

Match the confirmation-token completion payload key used by Dart.
MethodChannelStripe.confirmationTokenCreationCallback sends params, but iOS only reads result, so after _confirmTokenHandler is invoked the completion callback is rejected as invalidParams on iOS.

🐛 Proposed fix

         case "confirmationTokenCreationCallback":
-            guard let arguments = call.arguments as? FlutterMap,
-                  let res = arguments["result"] as? NSDictionary else {
+            guard let arguments = call.arguments as? FlutterMap else {
+                result(FlutterError.invalidParams)
+                return
+            }
+            guard let res = (arguments["result"] as? NSDictionary)
+                    ?? (arguments["params"] as? NSDictionary) else {
                 result(FlutterError.invalidParams)
                 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/StripePlugin.swift`
around lines 202 - 209, The iOS handler for the
"confirmationTokenCreationCallback" case is reading the wrong payload key
("result") causing invalidParams; update the guard in StripePlugin.swift (inside
the switch case for "confirmationTokenCreationCallback") to read let res =
arguments["params"] as? NSDictionary (keeping the existing call.arguments as?
FlutterMap guard) and pass that res into
confirmationTokenCreationCallback(result: res) so the iOS key matches the Dart
MethodChannelStripe.confirmationTokenCreationCallback payload.

🤖 Prompt for all review comments with AI agents

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

Inline comments:
In `@packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift`:
- Around line 456-458: The code incorrectly synthesizes
mutable["confirmHandler"] = true when mutable["confirmationTokenConfirmHandler"]
is nil, which can mark a confirm handler as present even when Dart didn't
provide one; update the logic in StripePlugin.swift where mutable is constructed
(look for keys "confirmationTokenConfirmHandler" and "confirmHandler" and the
downstream onConfirmHandlerCallback usage) so that you only set "confirmHandler"
when an explicit Dart flag for it exists (or when
confirmationTokenConfirmHandler is truthy), otherwise leave it unset/null to
allow native “missing handler” validation to catch absent callbacks.

---

Outside diff comments:
In `@packages/stripe_ios/ios/stripe_ios/Sources/stripe_ios/StripePlugin.swift`:
- Around line 202-209: The iOS handler for the
"confirmationTokenCreationCallback" case is reading the wrong payload key
("result") causing invalidParams; update the guard in StripePlugin.swift (inside
the switch case for "confirmationTokenCreationCallback") to read let res =
arguments["params"] as? NSDictionary (keeping the existing call.arguments as?
FlutterMap guard) and pass that res into
confirmationTokenCreationCallback(result: res) so the iOS key matches the Dart
MethodChannelStripe.confirmationTokenCreationCallback payload.

🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:

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

ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 89f71c4d-1382-4854-a74d-2866df89e85d

📥 Commits
Reviewing files that changed from the base of the PR and between 21cf701 and c744634.

📒 Files selected for processing (2)

I'm finding that this feedback is valid and needs to be applied, as InvalidParams is otherwise always thrown.

@remonh87 remonh87 merged commit 4f38dbd into main May 8, 2026
9 checks passed
@coderabbitai coderabbitai Bot mentioned this pull request Jun 4, 2026
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

confirmTokenHandler flow is not implemented

2 participants