I`m developing an app and I`ll use Recurring Application Charge.
Shopify API says;
Once a recurring application charge is activated and approved, the system has to handle the case where future payments are declined for some reason. If a shop stops paying its bills, Shopify will freeze the account. This means that your recurring application charge will be frozen as well and you will not get paid. In the event that a shop starts payments again the shop will be unfrozen and charges will resume.
Can I see that status(frozen) when I check created Recurring Application Charge? Or how can I know a user in frozen status and disable his account on my side?
When you try and access a frozen shop using the API, Shopify returns a 402/422 or something like that. So your App no longer works with a frozen store. So the merchant cannot use their Shopify store, they cannot use your App, so the moral of the story is, there is nothing you have to do. Just ride it out till they pay their Shopify bills again.
Fine. So just loop through your shops, and when you get 402/422 you know they are frozen. Your problem is then having to turn them on again too.
Why do you have an App that is useful to a merchant with a login separate from Shopify? One would think that without API calls, there is little they could do.
cool...I never use that webhook for anything as it sounds vague.
Could Shopify perhaps make the effort to detail what would trigger a shop update webhook and what is included in the payload?
For example, a merchant could add a new product type or vendor when creating a product, which affects the Liquid Shop object dramatically. Would that trigger a Shop update even though that might not affect Shop details as per the API call? It does seem that there are many many vectors by which that webhook could be called, making listening to shop/update a real resource hog...
The shop/update webhook will return a Shop object as documented in the API Reference. The plan_name and plan_display_name parameters will be frozen in the case where a shop is frozen. We don't document all of the possible field values for plan, but in general you'll be concerned with the following plan_name values:
Update webhooks will generally fire any time the data exposed in the relevant object is updated. So, if any of the fields contained in the shop object are modified (such as plan name), the resource will be updated and the webhook will fire. There are some minor exceptions to this rule, for example a shop/update webhook is also fired when shipping zones are updated on a shop.