How to differentiate Shops with Checkout UI Extensions enabled?

[dylanpierce]

Hello,

Our app currently relies on using script tags (`ONLINE_STORE` and `ORDER_STATUS` scopes) in order to function properly.

We are developing the Checkout UI Extensions that port this functionality over. However, the set up process for merchants using our app is vastly different from script tags vs Checkout UI Extensions.

In fact, we need to disable script tags if the Merchant uses Checkout UI Extensions, otherwise they'll have a poor experience.

We cannot find any indication on the GraphQL Admin API to tell if the current Shop has Checkout UI Extensions enabled or not.

Is there some hidden API endpoint or GraphQL object that will help us differentiate between stores with Checkout UI Extensions enabled or not?

This is really important for app developers so we can craft the appropriate onboarding experience for merchants.

[Liam · Accepted solution]

Hi Dylan - we dove into this a bit more, and the CheckoutProfile object might be helpful here - a published profile indicates the merchant has published checkout with extensibility. 

Would this work for you?

[Liam]

Hi Dylan - looking into this now with the checkout extensibility product team and will report back asap.

[Liam]

Hi Dylan - after checking with the product team, it appears there's currently no plan for this kind of API endpoint to check for a checkout version. They advised adding a manual check on your apps' dashboard asking the merchant/user to choose what checkout they are using, then disable the scriptTag API usage if they choose checkout extensibility. 

Not ideal - but hopefully this helps.

[dylanpierce]

Thanks Liam, a disappointing answer, especially since as an app developer we'll be seen as the cause of any issues if the merchant makes the upgrade and doesn't realize the ramifications.

Ideally the merchant shouldn't even have to think about the consequences of all their apps, they should be able to make the upgrade and the apps can subscribe to `update/shop` webhooks and make the corresponding changes.

Now shops will have to check each app, see if the app even offers this bespoke toggle and enable it.

I suspect this is going to cause operational issues, especially when Checkout Extensibility is applied to on all merchants.

[Liam · Accepted solution]

Hi Dylan - we dove into this a bit more, and the CheckoutProfile object might be helpful here - a published profile indicates the merchant has published checkout with extensibility. 

Would this work for you?

[dylanpierce]

Awesome! Nice find. Let me test and get back to you.

[dylanpierce]

Awesome! It works.

For a shop with Checkout Extensibility enabled, you can view their published checkout profiles:

If the shop does _not_ have Checkout Extensibility, an error is thrown:

 

So that elegantly solves the issue of at least showing the appropriate onboarding guide.

The last missing feedback piece is letting the merchant know that they've successfully added the checkout app block to their checkout page.

If this `CheckoutProfiles` Graphql object could also list active extensions by public ID, then we can find ours and then give the appropriate feedback to the merchant that they've completed set up.

We'll also be using the `shop/updated` webhook with this graphql query to detect when merchants upgrade to Checkout Extensibility to notify them that they need to use our checkout app block in order to continue using our app.

[bekanur98 · Accepted solution]

After the latest updates, all shops will now have checkoutProfile: {isPublished: true}. To find out if a shop supports thank you page and order status page extensions, you need to send a request to the 'unstable' version of the GraphQL API, where the field 'typOspPagesActive: boolean' is available. The GraphQL body looks as follows:

{ 
 checkoutProfiles(first: 10) {
  nodes {
   isPublished
   typOspPagesActive 
  } 
 } 
}