onPayPalWebCanceled is not called second time

[yuraj11]

PayPal Android SDK Version

1.7.0

Environment

Sandbox

Android Version & Device

Nexus 6 API 34 Emulator

PayPal dependencies

1.7.0 official demo project dependencies

Describe the bug

I am testing official 1.7.0 Demo application and there is a bug with PayPalWebCheckoutClient. In a specific scenario, when you cancel the payment flow (by closing the webview) it will not inform the app about the cancellation (PayPalWebCheckoutListener#onPayPalWebCanceled). Please check the steps for reproduction.

I noticed that you are using an old version of Browser Switch dependency 2.3.1 so it is possible that migrating to a later version could possibly fix this bug.

Possible bug in Browser Switch library?:
I noticed in BrowserSwichClient is this logic which resets intent in case when the payment was successful:

And here is the probematic condition when intent is actually null (when you do first successful payment and then do the same but instead of checkout you cancel the webview) .

To reproduce

1. Open official Demo app
2. Open PayPal Web -> Authorize -> Create order -> PAYPAL -> Start checkout
3. Do the payment. After that you will see correct state CHECKOUT COMPLETE
4. Return back to main screen in Demo app.
5. Repeat step 2.
6. Don't do the payment, just press "X" to cancel the payment WebView.
7. BUG: You will not receive onPayPalWebCanceled(...) in this scenario. Demo app is stuck in infinite loading state. See picture below:

Expected behavior

PayPal SDK must correctly trigger onPayPalWebCanceled(...) in all scenarios.

Screenshots

No response

[sshropshire]

Hi @yuraj11 thank you for using the PayPal SDK for Android. Unfortunately, this is by design. The Chrome Custom Tabs API historically didn't have a hook for the close button. The canceled event is only sent when a user explicitly cancels by clicking a "Cancel" link in the PayPal web app.

I am noticing though that this may now be possible using engagement signals. Is this something high priority for your use case? We've also considered implementing a catch-all NoResult result type in v2 of our SDK when the application comes into the foreground without a successful deep link, because we can't infer the intent of the user with 100% accuracy.

[yuraj11]

Hi, thanks for the response. Our application shows full-screen loading state until we receive result in listener from the PayPal SDK. I will do a workaround for now, so it's not a high priority.

[gordonchanhk]

Hello, just a sharing.
I used v1.8.0 to build an Android App demo, hit the same issue.
And with Claude help, it explains:

The issue is the stale intent data left over from the first successful checkout.

Here's what happens:

  First flow (works):
  1. startCheckout() → browser opens
  2. User completes PayPal → deep link redirects back → onNewIntent() fires, setting intent = newIntent (which now contains the PayPal return URL)
  3. onResume fires → SDK reads activity.intent, finds the return URL → onPayPalWebSuccess() fires

  Second flow (cancel broken):
  1. startCheckout() → old client's removeObservers() called, new client created, browser opens
  2. User closes the browser without completing
  3. onResume fires → SDK reads activity.intent → it still has the PayPal return URL data from the first successful flow
  4. The SDK sees deep link data in the intent and does not interpret this as a cancellation, so onPayPalWebCanceled() never fires

  The resetState() method only clears your app-level state (state and currentOrderId) but never clears the activity's intent data from the previous successful deep link.

  The fix: Clear the intent data after a successful result is processed. In onPayPalWebSuccess, clear the activity's intent so it doesn't contaminate future browser switch result checks.

So there are 2 lines to add before a new checkout:

See if this is something can help? (I am not expert in Android app development, but look forward this is a way to help resolve the "Close button no cancel event trigger" issue)