Describe the bug
The confirmTokenHandler callback on initPaymentSheet is non functional. Currently only checked iOS, and Web has no createConfirmationToken bridge implementation from what I can see offhand. I've yet to check Android.

To Reproduce
Steps to reproduce the behavior:

1. Initiate a payment using Stripe.instance.initPaymentSheet

await Stripe.instance.initPaymentSheet(
        paymentSheetParameters: SetupPaymentSheetParameters(
          intentConfiguration: IntentConfiguration(
            mode: const IntentMode.paymentMode(
              amount: 12000,
              currencyCode: 'USD',
            ),
            confirmTokenHandler: (result) {
              print(result.id);
            },
          ),
          merchantDisplayName: 'Example Inc.',
        ),
      );
      await Stripe.instance.presentPaymentSheet();

3. Fill in credit card details and hit submit
4. confirmTokenHandler is never called, and in fact confirmHandler is attempted to be called from the native implementation, even though it isn't defined here.
   Expected behavior
   confirmTokenHandler is successfully called.

Smartphone / tablet

• Device: iPhone 17 Pro Max Simulator
• OS: iOS 26.0
• Package version: 12.4.0
• Flutter version: 3.38.9

Additional context
I started investigating this on iOS (after seeing Web has no plumbing for this in the first place) and found a few areas that are causing the issue. Of note, the underlying SDK does successfully generate the confirmation token when the following changes are made.

1. The methodChannel handler is expecting the wrong successResult value: https://github.com/flutter-stripe/flutter_stripe/blob/main/packages/stripe_platform_interface/lib/src/method_channel_stripe.dart#L82
   This should be confirmationToken instead of paymentMethod.
2. The reason confirmHandler is always invoked is due to this hard coded logic, which originated from this PR. For my testing, I changed this to mutable["confirmationTokenConfirmHandler"] = true; instead, and this allows the confirmTokenHandler to be invoked, though obviously this isn't the solution.
3. confirmHandler or confirmationTokenConfirmHandler need to be set to true from the dart side so the code in issue 2 can be removed entirely. I don't use freezed, but my assumption on the best approach is to have the boolean value serialized from the IntentConfiguration class if either confirmHandler and/or confirmTokenHandler are not null (the native layer already has checks to throw an error if both or neither of these are provided).

I haven't checked the Android implementation but I can only assume it's similar