We build a delivery date picker as a checkout UI extension. Date selection has to happen on every order or the merchant can’t fulfil it.
Express checkout skips the extensions completely. This causes big problems for our merchants as they see orders with no date, and have to contact the customer.
Our workaround is a payment customisation function that hides express methods until the extension has written a date to the cart. In practice it barely helps. Express buttons render at the top of checkout, our extension renders further down. The buyer scrolls past the buttons before they’ve touched the picker, and by the time the flag is set the express options are behind them. So the merchant loses most of their express usage anyway, which was the whole point of having it.
So the choice we’re currently giving merchants is:
“Turn off express methods, which allows all journeys to flow through regular checkout (and therefore hit our extension)”
OR
“Turn on express checkouts and accept that some orders wont have the data the extension sets (a date, in our case)”
this feels like a compromise that merchants shouldn’t have to make.
Two questions:
Folks @ Shopify: is extension support in express/wallet flows on the roadmap?
Other devs building extensions that must run on every order - have you found anything better than suppressing express payment methods?
We recommend turning off express checkouts. Since Apple Pay became a regular payment method some time ago, it makes more sense to disable it as an express checkout option. Unfortunately, Google Pay is still express checkout only, as far as I know.
Hey @Alex_Hooper - just looping back after checking on our end. There isn’t currently another supported approach that guarantees required extension data will be collected across every accelerated checkout flow.
Apple Pay and Google Pay don’t currently support cart mutations such as writing attributes or metafields from a Checkout UI extension. Shop Pay is slightly different, since merchants can enable eligible extensions using “Include app in Shop Pay,” but that still doesn’t provide a universal solution across all wallet flows.
For data that must be present on every order, the options are essentially the tradeoff you mentioned: hide the unsupported accelerated methods until the date is set, or disable them entirely. @Patrick_Jakubik is on point that disabling them is currently the safest way to guarantee the field is collected.
I definitely get that this isn’t super ideal. I don’t have a public roadmap or timeline I can share, but I’ve shared this use case internally, so this is something we’re aware of. Let me know if I can clarify anything on our end here.