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.