It isn't clear to me in the docs how a recurring charge is handled after the initial install, and how we'd get notified that subsequent charges were made. Is there a webhook to pass for when recurring charges are charged? If the initial charge is successful on installation, do we just assume that it will be charged every month unless we've received an uninstall webhook event? Is it possible to be notified on the date of the recurring charge?
I see the status property in the endpoint for the recurring charge, but I do not see a way to register a webhook to be called when the status changes. Likewise, I do not see a way to be notified when the customer changes (upgrades/downgrades) their recurring charge plan.
What do folks do to keep up with the status of a customers payment plan? Is everyone just running a process every day against all customers to check the status of the accounts?
These are some pain points that we do not presently cover, but it's an issue we're very aware of. We don't currently offer a notification mechanism for when a recurring application charge is paid. The best way you can resolve this is with your payouts interface in the partner dashboard, and unless your app is uninstalled you can assume that the charge exists, the problem can be when the shop enters a frozen state though. To cover this, some apps do a pulse check against any endpoint; if the response is a 402, then you know the shop is frozen, and so too is your recurring charge until they pick their subscription back up.
I hope that helps a little. I welcome any added community input on other things they might do to cover this gap for now.
You will have to keep a track of which payment plan your client is using on your own end i-e in your database.
There is no webhook and periodically checking all shops is not a solution.
You will have to use your own logic in the controller that handles the return_url of Recurring Application Charge.
Hope this helps.
Thanks for the response. So I'm assuming that means whenever the user changes the plan, that a specific endpoint is called on our end, correct? Is essentially a re-install? From the docs, I believe that is the case.
But, what is not clear, is that if we list our app with 3 plans, how do I know which plan to charge them for when they install/re-install? Is that part of the data that is passed in the call to authorize (below)? How do we test payment plans in a dev store? I don't see a way to set that up for a test app.
Again, you'll have to use your own logic and implementation.
You will have to build a page and have the customer select which plan they want from that page, then create the respective Recurring Application Charge. When the return_url is called you can confirm that the user has activated the charge and keep a track in your database.
When the app/uninstall webhook is called you can remove the shop and all of its details from your database. So when they reinstall they will have to select a plan again. Or you can keep the plan info, when the customer reinstalls the app confirm that they still want to use that plan.
Use whatever logic you think is best for you Application flow.
Is this detailed in the docs somewhere? This flow, with the user clicking install, choosing a plan, and us submitting a charge, didn't feel clear at all how it should be done in reading the docs, but I may have missed it. There is an oauth flow in one diagram somewhere, and then I saw a charge related diagram in the graphql section, but I did not see a connection between install and charging, nor did I see anything describing presenting a payment plan to the user. Is there an overall description/diagram in the docs for this?
Thanks for the info.
2 years passed since this question was asked, is this solved?
I see this new events launched this year, for ex. https://shopify.dev/docs/partner-api/reference/apps/subscriptionchargeaccepted
Are those events available via webhooks? Or we need to query them using the API ?