Hi @vanomak, that's indeed not communicated back to the Dart end at the moment. Is that something you'd find useful? What's the use case you have?

It fees to me that, at the very least, the call should return in every scenario, to allow the execution to continue.

@JlUgia here is my scenario:

1. Client select payment method (GooglePay in that case) via custom button.
2. It's navigated in so called "payment progress screen" (if it's card payment there will be card details etc)
   If GooglePay selected on step 1. i am calling showPaymentSelector and if it's successfull i will communicate to payment gateway using returned token.
   However if client for some reason pressed back button or close GooglePay selector screen (swipe down for example) i cant detect it because code after showPaymentSelector not called at all (see my first message)
   So i have payment screen in waiting state and dont know that previous call was failed.
   If something goes wrong after client select googlePay details and press continue here, then everything is going well as intended.

Thank you for sharing this @vanomak.
There are three potential ways to notify the Dart side about this:

• Responding with an error (eg.: PlatformException): Similar to how errors are returned today, we can include dismissing the selector as one of them.
  • Cons: Dismissing the selector is not necessarily an error.
• Returning an empty or null value when the selector is dismissed. That is, assuming that dismissing the selector is not an error, but an intended user flow, no Exception is issued.
  • Cons: Using an optional or null value is not deterministic and somewhat uninformative.
• Creating an obect that holds the result and includes other details about it.
  • Cons: Creating a wrapping class can add unnecessary complexity that users will need to deal with for every call to the API.

I'm personally navigating between the first and second options, that although not being entirely appropriate, they keep the API simple, solving for a problem and flow that is at the same not complex nor too frequent. What do you think?

/cc @socsieng @jamesblasco @domesticmouse @Arkangel12 for additional thoughts.

@JlUgia
Faced this issue today.
From my perspective custom exception with custom error codes will be great and flexible for further updates.
However platform exception with code = canceled might do the same thing as well.

The second option (return null or empty) might be misleading.

My hotfix is here

We are facing this issue as well. I don't see how we can show an error, or cancel our loading state, if the user goes back from showPaymentSelector. We receive nothing. The result isn't even null.

Is there a workaround for this?

Same here, as far as I remember paying with apple will throw a PlatformException under similar circumstances.

Update: It will sometimes throw a PlatformException.

Exceptions are for exceptional cases, right? Like errors. Flutter's showDialog (and related) returns null if dismissed by e.g. tapping the background. Like many other UI frameworks. I don't see how that can be nondeterministic, and it's only uninformative if it's not documented what happens when the user cancels the payment.

Thank you for the thoughts @kristoffer-zliide. I generally agree with that rationale.
In this context, and with the platform effectively using an exception to send errors back to the Flutter end, I see the cancellation of a payment more as an error to the action of starting a payment than as an actual result (as opposed to dismissing a dialog, which can be considered a valid result or exit path to the action of showing it).
All in all, with the three potential approaches having equivalent pros and cons, I personally feel more inclined towards erring on the side consistency and alignment with the platform, even if in detriment of fundamental correctness.

Thank you for the contributions and thoughts and feel free to suggest additional ideas.

The PR has been merged and a new version is out. Take a look at 1.0.6.

In case of exceptions you generally need to 1) inform the user that something has gone wrong, and 2) report the error back to the development team for further investigation. When the user cancels the payment you need to do neither of those. So throwing the cancel scenario in with the error scenarios just complicates the handling of those cases.