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

rorz
Shopify Partner
17 0 6

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!

Replies 11 (11)

gabbar94
Visitor
1 0 0

Hey 

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

 

Thanks
Gabbar Sisodiya

Brian_S
Shopify Partner
153 19 39

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

 

Brian Singer
CTO & Cofounder of Subscription Service - Awtomic

estrats
Tourist
6 0 5

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.

GrowthSteam
New Member
5 0 0

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

BStubbs
Shopify Partner
136 16 62

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!

Was this helpful? Press like!
Did it fix the problem? Mark it as the solution for others!
Buy me a beer? Well, sure!
BStubbs
Shopify Partner
136 16 62

Hi @estrats 

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

Was this helpful? Press like!
Did it fix the problem? Mark it as the solution for others!
Buy me a beer? Well, sure!
GrowthSteam
New Member
5 0 0

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:

  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
BStubbs
Shopify Partner
136 16 62

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?

 

Was this helpful? Press like!
Did it fix the problem? Mark it as the solution for others!
Buy me a beer? Well, sure!
GrowthSteam
New Member
5 0 0

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?

Brian_S
Shopify Partner
153 19 39

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)

 

Brian Singer
CTO & Cofounder of Subscription Service - Awtomic
zksumon
Shopify Partner
9 0 1

you can get this object from the REST API too.