DefaultCheckoutEventProcessor events not being called after first checkout

[mauro-poq]

What area is the issue related to?

Checkout Sheet Kit

What version of the package are you using?

3.0.1 and 3.3.0

Reproducible sample code

I’m running into a strange issue that only occurs in the production environment—everything works perfectly in lower environments.

I’ve implemented a custom DefaultCheckoutEventProcessor, focusing mainly on the onCheckoutCompleted and onCheckoutFailed callbacks. I’ve also added onWebPixelEvent, which currently just logs the received events without handling them.

Here’s where it gets odd:
On a fresh install, when a user performs the checkout for the first time, all the expected callbacks are triggered correctly. But on subsequent checkout attempts, although the checkout flow appears to work fine on the screen, none of the callback methods are called.

I’ve traced this down to CheckoutBridge.postMessage—it’s only being triggered on the first attempt, and doesn’t fire at all from the second checkout onward.

Given that everything behaves as expected in lower environments, I suspect this could be related to some configuration or environment-specific setup in production.

Has anyone encountered something similar, or have thoughts on what might be causing this?

Steps to Reproduce

• Perform a fresh install of the app.
• Start the checkout flow using a valid URL.
• First Checkout Attempt:
  • All callback methods (onCheckoutCompleted, onCheckoutFailed, onWebPixelEvent, etc.) are called as expected.
• Complete the first checkout flow.
• Start a second checkout flow using a valid URL.
• Second Checkout Attempt:
  • The checkout process appears to work visually.
    -No callback methods are triggered this time.

Expected Behavior

Callback methods are to be executed in all flows.

Actual Behavior

Callback methods are executed only on the first flow.

Screenshots/Videos/Log output

No response

Storefront domain

https://ecomodernessentials.com.au

[kiftio]

Hi @mauro-poq, do you think you'd be able to provide a minimal reproduction perhaps as a GitHub link?

If the issue is specific to production, it may be worth checking any production specific files (e.g. ProGuard config, environment variables/config files, prod specific gradle tasks, permissions, feature flags etc).

Where possible, you can try running our sample app and plugging in your event processor to see if you observe the same behaviour.

[mauro-poq]

Hey @kiftio, thanks for your answer.

I forgot to mention that all Shopify configurations stay on my BE and that we are using a Multipass URL to do the checkout, so on every checkout start, I call my BE, which will return me a URL, and I will call ShopifyCheckoutSheetKit.present to show the checkout flow. Sorry about forgetting this part previously.

Regarding the Sample app, I just did the test using the SampleCheckout, which is near what I have, but I just did some changes to instead of having the products being fetched, I put a button to show the checkout and the method below into the ViewModel:

fun showCheckout(activity: ComponentActivity) {
        eventProcessor?.let {
            Handler(Looper.getMainLooper()).post {
                ShopifyCheckoutSheetKit.present(
                    "URL From BE",
                    activity,
                    it
                )
            }
        }
    }

I have also changed the eventProcessor to log anything I receive:

fun setEventProcessor(activity: ComponentActivity) {
        eventProcessor = object : DefaultCheckoutEventProcessor(activity) {
            override fun onCheckoutCompleted(checkoutCompletedEvent: CheckoutCompletedEvent) {
                Log.e("TEST_CHECK", "onCheckoutCompleted: $checkoutCompletedEvent")
                checkoutCompleted()
            }

            override fun onCheckoutFailed(error: CheckoutException) {
                Log.e("TEST_CHECK", "onCheckoutFailed: $error")
                checkoutFailed(error)
            }

            override fun onCheckoutCanceled() {
                Log.e("TEST_CHECK", "onCheckoutCanceled: ")
                checkoutCanceled()
            }

            override fun onWebPixelEvent(event: PixelEvent) {
                Log.e("TEST_CHECK", "onWebPixelEvent: $event")
                super.onWebPixelEvent(event)
            }
        }
    }

As in my application on a fresh install, the first attempt will execute the events, but from the second attempt, it will not happen. I attached the Android Log Cat logs, but I'm not sure if it will help.

In the first log you will be able to see the onWebPixelEvent logs, while it is not present on the second, once it is present in all attempts all the rest should work.

FirstAttemptWorks.txt
SecondAttemptDoesNotWork.txt

Regarding the other points you have asked me to check, everything looks fine from my point of view, the points you mentioned are basically the same for all environments.

If necessary, I can provide some checkout URLs to help with debugging.

[kiftio]

You may be running into a current web-pixels limitation, where pixel events are not currently emitted for Shop Pay (or more specifically for checkouts on the shop.app domain).

There's some mention of that here - https://community.shopify.dev/t/shoppay-and-checkout-events/1268/12

The reason I'm saying that is that I see https://shop.app in your second attempt logs, but not in the first. Maybe you could validate this by going through a non-Shop Pay checkout twice and checking whether you get events in that case.

N.b. the other (non web pixel) events (checkoutCompleted, checkoutCancelled, etc) should continue to be fired for Shop Pay checkouts.

[mauro-poq]

Hey @kiftio , thanks for the response!

Could you clarify how I can force the Checkout Sheet Kit to use the non–Shop Pay checkout flow?
Do you think this behavior could be related to how the Multipass URL is generated on our backend?

As for the events—I'm using the web pixel events as a reference because they consistently fire when the checkout behaves as expected. However, starting from the second checkout attempt onwards, the checkoutCompleted event doesn’t fire anymore, which causes us to miss some orders on our end.

It’s working fine in our lower environments, so I suspect we might be missing some configuration in the production setup.
From what I can see, the Android implementation looks ok.

[kiftio]

Could you provide a bit more information about the different environments? E.g. would that mean a different (staging) store, or is it more of a release variant, or different backend delivering multipass URLs for example?

R.e. non-Shop Pay checkouts - you should remain in guest until you login to Shop Pay, so a reinstall should clear the Shop Pay preference for testing purposes.

But missing checkoutCompleted events is definitely unexpected.

[mauro-poq]

Hey @kiftio , sorry about the delay in getting back to you.

Regarding the environment setup — yes, we have three environments: DEV, Staging, and Production. Each environment is linked to its own Shopify instance, and my backend handles the integration and data exchange with Shopify. The Android app itself doesn’t communicate with Shopify directly.

On DEV and Staging, everything works as expected: when I fetch the checkout URL from my backend and open it using the Checkout Sheet Kit, it consistently works fine. However, in Production, the first checkout goes through successfully, but on any subsequent attempts, the checkoutCompleted callback doesn’t fire.

One potentially relevant detail: this issue seems to be exclusive to Android — everything works fine on iOS.

Also, I don’t have visibility into the Shop Pay login process, so I’m not sure if that’s being handled on our backend.

Is there any specific configuration I should ask my backend team to check for the Production environment?

[mauro-poq]

Hey @kiftio, any news about this?

[kiftio]

I haven't been able to reproduce it yet, I'm seeing all events being emitted on subsequent checkouts. I'll take another look today using Multipass

One potential issue could be Multipass URLs being reused.. A given Multipass token can only be used once as noted here https://shopify.dev/docs/api/multipass#step-6-redirect-your-customer-to-your-shopify-store. So a new one needs to be generated before each call to present()

It's not clear how that'd only present itself in production or only in Android though

[mauro-poq]

Hey @kiftio
I don't think it's reused, as a different URL is returned to FE every time I query my BE, however, I asked the BE developers to be sure about it.
I don't know about the lifetime of each URL, but I can generate some URLs and send them here for you to test, hoping it will not expire before you have time to check.

[kiftio]

I've done some testing with multipass, and everything seems to be OK in my tests.

Yeah, if you could send over some URLs, that might be helpful, if you have a screen recording that would also be useful. Thanks

[mauro-poq]

Hey @kiftio, sure, please find it below, as I said, I'm not sure about the lifetime of the URLs, but I can send more if necessary:

https://ecomodernessentials.com.au//account/login/multipass/UOo__Se1kME_Qm3KZyPK8p9LREfozDrqKKdvA3cR_zjbJpcW9V6vM8RVIV0GavKBs-iN0p2SVp7SQDnh0oSfcDWG_btzRgPdV9YLv5vBJyr5Jx15GWiUQmYLpjzuc5VTuHw588XwAR-1hsbeob2DSGYuGf5xzu_WL_0PuYXRl87qCyFHnkDGpgh1wc7EDY29Xc8GHPUjhgJjHPAg9aF6PFyfupM8c_o1w1cDKHKvRxm5bjr8Cdiue2oU5vXjIp1RMswYj5Srqdoy-rlzNfib13uxSSSw-DVfu2uI_dknZg4CtwgnyBf8DnAi9PHBiSX4Ohm6Pmnvhh3kpxItQrVMnsIbXqTIqky-f0Uq6Txlc75N8jvvY5sDu1l0FkEh6yVtrkzI2ml6aql6Z-vidEjElw==

https://ecomodernessentials.com.au//account/login/multipass/L8lDox0DkVUhWXO7srx09ffI7BXjUH7hYsm7IizPK6tFEkYyA42Ka_igFgz0Cnk8ocpX6eet-kZYAs0yoYUbfZshMGyeWRwTwmn5HsLYrUxvSTzehYEaiWGO893lfLGK3ygfqcSH5MMbTAi61U9CdBGxGdVwKaGbGgNQOPoH6lQv1Z24hu7bk5snw-A7BZNmPDjNxyk2kfjjawuAOUKTIsN-NkYGq_ibl3zRUudyzqH0rJ_LecoRxGwMjY2nKNCaqLZGeHj5KOZUPclXXiP7qQrHvdRlrDqoi2DPRCmlc2GLR8y5b90NMiDkVcnPQS4huiazs1TvIe-klIzCtSPiGonbKeOyMPJ7ezZqDU1dcVLDXScEG1pky8cUm9hxnAZw-7q3_mzocZIDicD7p_UZVA==

https://ecomodernessentials.com.au//account/login/multipass/zgQhp1CzIxXjOEZfFvk33mwVnHSQ5KkCOyGh2sz1c8lxF90rmde3vcKf-AAtgDOIvP4lSJQRabb4mnFwVJvF7d8so1gBRUn-GxkeFqMuS30b-N_H2MBxp6ZHRijba-MMNqU3rsoqj6slpxKl2r5t6nAIA6AZ2RSJNGCnuc54BPZBXtAhTjJwL9GwAJiZr_QGG8jP-Rovn87FEOTEJH9EfyFF7BGSbKGFZ1vpvOi_JUO0WaIliQE0zplLaDvoxmhbA6ryR8f31v5LkHPradE-8YogDXLHmmiEOTGKFalTtSeAlfJs3mwurExfuhjRGSwnazvU_3VD7euCt2F-wovDidw0W365Rs-Pla8VNsETwOOovkUq6vt4cUrlIfWAOhKRglNYJJQJu5xExwwlYT2Riw==

Let me know if you need more

[kiftio]

I think I got to some of these a little late. I'll grab somebody else on the team tomorrow and see if they have any more success in reproducing

[mauro-poq]

Hey @kiftio, no problems, here are more 3 in case the previous ones died:

https://ecomodernessentials.com.au//account/login/multipass/pOtizR-OBELYsWFCGj4kjGsr1RK1SlxzvNPHiA1iiWkne9Vkko_d3oqt9Q63dR96Ei_0INfo-f89xWaIzHXTm-Wv-3Jkyam5fPicWgRAxMOIfeOTTwbE4JyFOvi5vjtMJ16fYIZukAlhwpBKS4qs-wQX8pSVIFe_yBffxocHITWkE1zsTyQvlEiZew3DlqtGxP8h-nN9h24-RnxsrV3Zr2DaYYBnKMVMrUxKO86FGHNUepZqcCT0iMQ_RkkXc0ZXQXn3PQKa1CAYFs18pQ1ubXGM8liCqx58LlPgCDZWO43Cl_hIC15_TLSXxzSy6kt3ondpAcZ4lo8c5n7QVhqA98253cEQKZWzpYSfpMDQ_DKC0oy_DB6P0VTbFrlGiqSWcTfGonxQHrwEtMSfrX-ICw==

https://ecomodernessentials.com.au//account/login/multipass/Vbx74RIrS1g3MGOgKDWdKsagjmU4MAp6ko8CEdhzsUGwM2fdikapkVxRFByhhwj8NSRsaQUg8P5U0PjhyTC4-MkeSA0s03jE_RDriE_5skD4yC-h2TNWKoSoflkqTtF4fVbp7LmLHVDBQ2Z-FVu_fAN-mKEovQ4BQjs-_YnHAyAu6dAJNpBp6nRL05HS_lKmHG0xYZKLQ_B7a9JfZ5zYj1rb11s1XlJ1UaubsqvruVF1rWsJ6owMdRZDGGuRtQGIdVk4nCZoxCeAAsxBY0qhGdQd4oDWWBuncozB-CPULtx_hIMTdHfysGmqFXVSdl2Ub3mhX9Z3BsfhO4fJIEZ44D4U1NUg-QfDvKgP6SJ2vBk9_jyKPl8FbQ_PmKoEeJfbM-cK9IBR9HTOwM1ZeUg4hA==

https://ecomodernessentials.com.au//account/login/multipass/BJMF_k5RYVynJvuFu7qKPCzdgTOcMyOKJZzZmyGlCYMlkW7d6q3XYUtJ_xyKC_4nsYyXivJNKRSPRoPDQGJ33MDpcjZtNny2LOVcwSv008Zs275DYkhG6QdKMMFWd--8wz7rp5rfUCwTeMZAdugrHB5NVyM5JyTcZFzkRcwzra78tIhPwW1rl15v_EOKu6YtEyzm_nHenObGNBZAz-b7q8oWghO1beq7w27eeBhyaOvNp3bJjIi0m-2FByPJYwF0GwW7Hm-Mi2XAtPIVEGHjXkawDsZanOcVQOh9iUQiFSMe3Ryrm7o9DbYdjQ3M33nw___CDSy6fnTwwp0tlbAvQt5h-weIAth0PDvwPysTGZSz3Ia45DE5D_Kj5PXWJt-Obx9LUwpn4VlHWI-nNpkfpg==

[kiftio]

OK, we tried opening these not long after you commented, but got Invalid multipass request so they had potentially already expired.

I think maybe the best option is for us to setup a branch with lots more logging, and for you to go through the flow again on that branch to see if the logs give any more hints what's about happening. We'll set that up soon and let you know

[kiftio]

@mauro-poq It's still a bit of a work-in-progress, but there's a branch here.

Would you be able to build and run a test against that branch with your production URLs (also important to configure debugging to be enabled)?

I'll see what the team's thoughts are r.e. merging something like this into main otherwise

[mauro-poq]

Hey @kiftio I have tested the code. If I understood correctly, it was merged to the main branch, so I got it, set the log level to DEBUG, the behaviour is the same, please find attached the Logs.

Let me know if I did something wrong and if you need more data.

FirstAttemptWorks.txt
SecondAttemptDoesNotWork.txt

[kiftio]

Thanks, there's nothing that looks incorrect in the android logs. I'm thinking we may need to add some additional logging in the web code. Apologies it taking a while to get to the bottom of

[mauro-poq]

Hey, no worries. I think there's some redirection happening that's pointing to outdated content.
Do you have any idea how we could add logging to help track it down?

[mauro-poq]

Hey @kiftio , any news?