Based on that, I hope registering a webhook for the “APP_SUBSCRIPTIONS_UPDATE” topic is what I am looking for (although I did not find in the docs what the typical payload sent to the webhook would look like. So let’s try triggering it to obtain that information, I suppose).
After registering a webhook for the “APP_SUBSCRIPTIONS_UPDATE” and granting access when the event indicating that the subscription is “ACTIVE” arrives, everything works fine except for one thing:
It takes about 2min and 30 seconds for the event to arrive.
The customer is stuck waiting 2min and 30 seconds. This is not optimal to say the least. Would anyone have a suggestion ?
I tend to setup a slightly different onboarding flow ( and use GQL for most of the checks )
On install I show a grid of plan/packages that a user can select from.
When the user selects one it takes them to payment
2.1 if they close the window or cancel it just takes them back to the same screen when they try and access the app.
No webhooks needed!!!
Alternatley
2.2 they accept the charge they are redirected back to the url you specify ( including a query string ) and a charge ID I think ( woul dneed to check )
2.2.1 I then look up the charge check its active and let them in. No delays and pretty secure.
On additonal entries into the app I just do a billing check when they land on the dashboard or whatever silently int he background ( I tend to have a timeout on that so it only runs once a day )
Might be worthwhile taking a look at your flow, not auto redirecting to the payment screen and having an access wall in your app.
"I tend to setup a slightly different onboarding flow ( and use GQL for most of the checks ) "
What GraphQL endpoints do you query to check that the payment went through ?
" if they close the window or cancel it just takes them back to the same screen when they try and access the app. "
But where in your code (and how) do you check that the subscription was indeed confirmed (Do you use a GraphQL endpoint or is there a simple callback ) ?
"2.2 they accept the charge they are redirected back to the url you specify ( including a query string ) and a charge ID I think ( woul dneed to check )
2.2.1 I then look up the charge check its active and let them in. No delays and pretty secure. "
I found out that this solution will not hide app blocks in the theme editor.
Most app creators don’t use app blocks anyway, but I don’t understand why they don’t explain this, since in my view app blocks are better for everyone.