A place to discuss charging merchants for your apps and services using the billing API.
Hi all,
I'm working on my app's subscription charges, which will consist of a monthly recurring charge and usage-based charges too.
I've been creating test subscriptions with trials using the GraphQL API, and it's been going fine. However, for one of my test stores, I set a 14-day trial test subscription up 3 weeks ago, and have been applying usage charges for it (successfully), but the recurring application charge that it belongs to has a `billing_on` (REST) / `currentPeriodEnd` (GraphQL) value in the past...
Am I right in assuming the `billing_on` / `currentPeriodEnd` value is supposed to indicate the next date the merchant will be billed for their subscription, i.e. in my case it should be 1 month from the end of the trial?
I was wondering if that's a "bug" when using test mode, and that it would update automatically after a trial ends for live recurring charges / subscriptions...
If not, I have two smaller questions:
Thanks in advance!
Hey
I have also the same question. anyone answer this question then it will be very helpful
Thanks
Gabbar Sisodiya
Did you figure this out? I'm seeing the same thing
Can anyone provide any information on this?
I'm also seeing this on `Test` charges and would like to be sure it's only a development issue.
Currently we intend to rely on `currentPeriodEnd` to reflect the end of the next billing cycle after the trial has expired.
Hello everyone!
I have been also playing with subscriptions lately, and I do not understand what is going on exactly.
For example:
Subscription info I get back from graphQL is the following and does not change:
"createdAt": "2021-01-05T14:13:10Z",
"trialDays": 1,
"currentPeriodEnd": "2021-01-06T14:13:21Z"
It might be that I was messing around with subscriptions a bit and dates got messed up...but... Is there a way to test this? Is there any proper documentation about it? I would really hate to test this in production...
Hi @GrowthSteam
welcome to the forums!
Just to clarify, are you talking about RecurringApplicationCharge or SubscriptionContracts? I think its the first one, just be aware there is some conflicting terminology here.
My bad, I just realised the AppSubscription object is a GraphQL. I wrote my Admin parts in REST - old skool you know... 😂 Recurring Application Charges here would be the same as an AppSubscription.
A lot of this can be answered by saying that apps sending RecurringApplicationCharges in 'test' mode will not be updated. Sorry, thats just how it is.
As you can see, subscription was created on the 5th. I would expect currentPeriodEnd to be next month + 1 day, but it is not.Until today, the response from the API did not change.
Also, as far as I know, there is no way of knowing when the subscription was accepted, which is not the same as when it was created.
You've set it to be a trial period of 1 day, so it would be the next day, not the next month. Is that what you intended? If its a test charge, then it wont update. You should capture when the RAC is accepted as part of the OAuth flow in the callback.
Another thing is, that it is really hard to prevent users simply re-doing subscription and always staying in trial period.There is also no web-hooks triggered, after the initial one
Yeah, there isn't much stopping them from uninstalling it and then reinstalling for a new trial period. There are ways in which you can identify a reinstall (they would already be in your database for instance) and then shorten the number of trial days, but I've never done that and never had a problem with people churning to get a further free trial. Its just as much work for them! There is no webhook triggered for Recurring Application Charges.
Hope this helps! Good luck!
Hi @estrats
Yes you are correct, its only in test mode that this behaviour is observed. currentPeriodEnd is perfect for this.
Thank you for such a quick update!
Well, I just switched from REST because it looks like Shopify is promoting GraphQL recently...:)
Just to be clear, the only way I can test this is by running it in production?
Could you please confirm that this is how the subscription endpoints work:
Happy to try and help!
I think that looks pretty right, but not sure what webhooks you are referring to? I don’t think there are any webhooks for app/installed?
There is an APP_SUBSCRIPTIONS_UPDATE hook. Not 100%, but it might only be available on GraphQL.
This is what you get back:
{
app_subscription: {
admin_graphql_api_id: 'gid://shopify/AppSubscription/xxxxxxx',
name: 'Pro',
status: 'ACTIVE',
admin_graphql_api_shop_id: 'gid://shopify/Shop/xxxxxxx',
created_at: '2020-09-15T02:30:40-04:00',
updated_at: '2020-09-15T02:31:14-04:00'
}
}
Then you can query for actual subscription data using a REST/GraphQL call to get relevant info.
But I don't wanna be hijacking this thread any more. We can swap to another, since this might be off topic?
In my limited, recent experience the APP_SUBSCRIPTIONS_UPDATE webhook is only triggered when the app subscription status changes. Since it doesn't change between billing periods, I think you can safely assume that you won't receive that hook. FWIW - I've seen that I also don't receive it when the user uninstalls the app (even though that should change the status). Like you mentioned though, you will receive an uninstall webhook and since your app will no longer have api access there's a lot of info in that payload (not much about the app subscription or trial days though I dont think)
you can get this object from the REST API too.