Recurring charge in test mode (with trial) has `billing_on` value in the past

Retired Boards Appdev Billing
1

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:

  1. Is there a field returned / way of finding out when the merchant will be billed next for the subscription?
  2. Do recurring monthly application charges with a trial period start automatically (assuming they are active)?

Thanks in advance!

2

Hey

I have also the same question. anyone answer this question then it will be very helpful

Thanks
Gabbar Sisodiya

3

Did you figure this out? I’m seeing the same thing

4

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.

5

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”

  • 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.
  • 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

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…

6

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… :joy: 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!

7

Hi @estrats

Yes you are correct, its only in test mode that this behaviour is observed. currentPeriodEnd is perfect for this.

8

Thank you for such a quick update!

Well, I just switched from REST because it looks like Shopify is promoting GraphQL recently…:slight_smile:

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:

  1. create initial charge on 1st of January with 10 days trial.
    • currentPeriodEnd will show 1st + 10 days = 10th of January, I receive a webhook
    • after 10 days, currentPeriodEnd changes to next month, 10th of February, since the subscription is monthly. I DO NOT receive any webhooks.
    • on 10th of February, currentPeriodEnd changes to 10th of March. No webhook
  2. BUT on 5th of January pricing plan is changed by the user
    • I have to calculate how many trial days are left from the previous plan, and set that as new trial days (If I want to keep 10 days trial)
    • createdAt is changed, and I guess subscription ID is different than in step 1.
    • the rest is exactly the same as step 1 (the same dates, since 5 trial days are left)
  3. My app is crap, so user uninstalls.
    • shopify forgets everything about my shop for that user. I need to get a new access token, and all new subscriptions
9

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?

10

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?

11

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)

12

you can get this object from the REST API too.

13

@rorz
here is some way to
replace with the app Query for get the app active Subscription info Also you see into the your Partner portals.

mutation appSubscriptionCancel($id: ID!) {
appSubscriptionCancel(id: $id) {
appSubscription {
# AppSubscription fields
id
status

}
userErrors {
field
message
}
}
}

you have call the cancel App Subscription before that you Create or update the existing one. Also I have same issue I am working on that.