Hi everyone.
For our app, we are using Shopify Managed Pricing, which is overall working well.
But we have encountered two major problems which are kind of hard to work around.
- Client transfers stores after they went live: UI on managed pricing page doesn’t have the option to activate a real subscription!
We got a customer who had a client transfer store went live. So he did activate the test subscription when it was the client transfer plan. But after his store went live, he is navigating to the app’s Shopify managed pricing page: they see the subscription for the app is totally fine and active, even though it’s a TEST subscription which is no longer valid!!!
So he had to downgrade to another subscription plan and then upgrade to his original subscription plan because he physically could not reactivate his subscription (real subscription instead of test subscription with the managed pricing UI).
- Shopify could have I stores with “Plus“ or “Staff“ plans with isDevelopment=FALSE, but still triggering a test subscription for the app.
It’s usually stores who belong to …@shopify.com emails. So it’s obviously internal testing or demonstration stores for potential merchants. But it’s very hard to work with this Shopify admin API. Because it’s just not possible to distinguish which stores are allowed to have test app subscriptions and which stores are not allowed to have test app subscriptions.
It’s just inconvenient for app developers. Because these two problems appear at the same time, it’s hard to identify which stores are eligible for test subscriptions. And which stores have to upgrade to a real subscription.
Hopefully this topic will get some attention, so Shopify might improve this managed pricing page to show if it’s a test subscription or a real subscription and give them the option to upgrade to a real subscription after the store went live.
Also, it would be nice to add something like an “eligible for test subscription” field in the admin API because it is pretty confusing now.
Hi @Angelina_Prokopeva! When a development or client transfer store goes live, Managed Pricing does not automatically cancel the test subscription. The merchant keeps their test subscription in an “active” state and the UI doesn’t surface an option to switch to a real one.
The docs do note that “test subscriptions don’t convert to paid when you transfer a store” but the wording is not the clearest. What it means in practice is that the test subscription simply persists as-is, and your app needs to handle the transition. This was confirmed in a previous thread on the same topic where multiple developers reported the same behavior.
Until the platform handles this automatically, the workaround is to monitor it on your app’s side. Subscribe to the shop/update webhook to detect when a store’s plan changes from development to a paid plan. When that fires, query the active subscription and check the test field on the AppSubscription object. If you find a live store with a test subscription, cancel it via appSubscriptionCancel and redirect the merchant to your Managed Pricing plan selection page so they can pick a real plan.
I’ve submitted feedback internally on the test subscription behavior so the team has continued visibility on this from developers like yourself.
On your second point about Plus/Staff stores with isDevelopment=FALSE still triggering test subscriptions, that’s harder to diagnose without specifics. If you can share more context/examples I’ll be happy to take a look!
Yes, for sure! Regarding the confusion with isDevelopment=false, here are a couple of examples:
- You can see that it’s showing as Plus store, but they did trigger a test subscription, and it’s definitely a Shopify email:
- The second example is the “Custom” plan that triggered a test subscription:
But that was returned from Shopify API tells that it’s a “Staff” plan with isPartnerDevelopment=false:
{
“shopDomain”: “se-***-obhv6v.myshopify.com”,
“event”: “INSTALL”,
“shopEmail”: “***@shopify.com”,
“shopEmailForCustomers”: “***@shopify.com”,
“displayName”: “Staff”,
“isPartnerDevelopment”: false,
“isShopifyPlus”: false
}
Another issue with subscribing to shop/update webhook - it just sends a lot of data on every update made by the merchant, such as: name, address, etc.
If webhook is the right way to do that, it would be useful if Shopify released a special webhook related to Shopify subscription or store type.
Because if the Shopify fires a webhook on any shop update (name, address, etc.) - We still have to understand the exact backend logic of test subscriptions in Shopify. Which is definitely confusing with these Plus stores with test subscription and “Staff” plan stores with test subscription too.
Thanks for sharing those examples @Angelina_Prokopeva. The behavior you’re seeing with Plus/Staff stores that have isPartnerDevelopment=false but still create test subscriptions is actually expected. These are internal Shopify stores (you can tell by the @shopify.com emails), and Managed Pricing handles test charge eligibility for them automatically. They’ll always get test subscriptions regardless of what the plan flags say, and they’ll never become paying customers, so you don’t need to build any special logic to handle them.
The practical approach is to treat partnerDevelopment=true stores as the ones you need to monitor for the dev-to-live transition. For everything else, check the test field on the active AppSubscription. If test=true on a non-development store, it’s an internal Shopify store and can stay on test indefinitely. This was confirmed in a similar thread about BFS review stores where Kyle noted that “managed pricing handles the test charge override automatically so that’s not logic you would really need to account for.”
On the shop/update webhook being noisy, you’re right that it fires on any store update. Unfortunately there isn’t a more targeted webhook for just plan changes. However, you can minimize unnecessary processing by checking the plan_display_name field in the payload before doing anything. If plan_display_name is “Development”, ignore it. If it changed from “Development” to something else, that’s when you need to act. The payload includes this field regardless of what triggered the update, so you can filter quickly without extra API calls.
The feature request for an “eligible for test subscription” field has already been filed, so hopefully that’ll make this easier down the road.
1 Like
