GraphQL appSubscriptionCreate mutation with "test: true" always returns incorrect "currentPeriodEnd"

[amardeep]

During development whenever I create a test recurring charge subscription, it always returns the "currentPeriodEnd" as few seconds ahead of the "createdAt" time instead of the expected "30 days" ahead of "createdAt". Here is a sample response from a test recurring charge.

{"name":"Basic","createdAt":"2019-08-12T08:29:20Z","currentPeriodEnd":"2019-08-12T08:29:33Z","id":"gid://shopify/AppSubscription/9596502116","status":"ACTIVE","test":true,"trialDays":0,"__typename":"AppSubscription"}

This makes development of billing flow very difficulty. I believe there are others as well who have raised this issue earlier but it still remains as it is. 

Another question which is difficult for me to test is the response of activeSubscriptions graphql query when the user has cancelled his subscriptions but has some days left in the current app billing cycle. Since the "test subscription" is not working properly I am unable to test this scenario. 

Please advise. 

[Josh]

Hey @amardeep ,

When creating a test charge, the billing period's end date will be the same time that the charge was activated. I imagine this is by design since there is never any intent to have an actual full billing period or charge generated. This behaviour is the same both in GraphQL or REST.

With regards to testing your GraphQL query, If a user cancelled their subscription that would presumably be because they have uninstalled your app - which would prevent you from being able to run any queries on the shop anyway. So you wouldn't be able to see the response of activeSubscriptions anyway, so I'm not sure if there's much value in testing that response. If there's something I haven't considered here though please let me know! 

With that being said, if a user uninstalls your app and cancels their recurring subscription before their billing period ends, we will pro-rate the charge and will still invoice the merchant for the period of time they did use your app for. 

[amardeep]

Hi Josh,
I think it is not a fair assumption that the only case of cancelling the charge is when the user uninstalls the app. For example, in our use case there are few features allowed in the free plan and some additional features in the paid subscription plan so we do give an option to our users to switch back to a free plan if they want to use only the basic features. In this case user does not uninstall the app, just cancels it.

Second, the test feature should always simulate the actual features and that is the whole point of having a test feature. If they behave differently then we can never test things in development and would have to just hope that everything works fine in production. I will give you a simple example, say, a user installs our app on 5th Aug., after trying the basic features he decides to buy the paid plan on 6th Aug. After using it for 2 weeks he figures that the basic free plan was enough for his use case and he decides to switch back to free plan on 20th without uninstalling the app. Now, since the user has cancelled the plan he will be billed for the full month.
Ref: https://help.shopify.com/en/api/guides/charging-for-your-app/faq#how-is-prorating-handled-for-recurr...
As the app developer we still would want to provide him the 'premium' features until 5th Sept. since he has paid for the full month.

How do you suggest I should test this flow? Since the test subscription charge works different than the actual one, it makes it very tedious to test this.

I strongly recommend you to give it another thought and make it same as the real request. I understand REST and GRAPHQL both have this issue but I have also seen other developers complaining about this issue.

Looking forward to a speedy solution.
Thanks & regards
Amardeep Singh

[amardeep]

@Josh What are your thoughts on my previous response?

[Josh]

Hey @amardeep , 

You've made some fair points - I'll log a request to make test charges behave the same as real ones, but can't promise what the result of doing so would be as of yet. In terms of testing the same behaviour as a real charge as of today, the only way that I can see to do so would be by creating an actual, non-test recurring charge - which I can understand not being ideal. 

[amardeep]

Thanks @Josh for taking it up. Hoping for a solution. 

Testing by creating a non-test charge would have been fine if it was a one time thing; development and testing are always an ongoing activity and debugging the whole flow would require a lot of non-test charges which seems not so ideal. 

[amardeep]

@Josh  Any update on this?

[Josh]

Hey again @amardeep , 

No new news to share as of yet I'm afraid, but I'll check back in to see if I can get some attention on this.

[amardeep]

@Josh I have also detailed out more issues with the Billing API in a separate thread https://community.shopify.com/c/Shopify-APIs-SDKs/Major-short-comings-with-Billing-API-amp-Proposed-... 

I would like to bring your attention to that as well. I am sure this is an issue with other developers as well. 

Thanks

[Nesto]

Hi @Josh ,

I just spent over an hour worrying about our users not having access to our app because I thought the currentPeriodEnd time was being returned incorrectly by the Graph API due to this strange behavior. Our app relies on accurate renewal dates to determine if a customer is still active, we also use this date to determine when to reset any app usage for usage-based charges.

Having different behavior for test charges vs real charges makes an already difficult API to consume even more difficult/impossible to test. Like others have mentioned, I just have to hope that it works in production and ask the finance office if it's OK for us to bill ourselves for subscription charges.

It looks like this issue was opened nearly three years ago, so I don't have much hope that it will be solved, but please count me as a +1 in the level of frustration related to working with billing within Shopify. Now that Shopify REQUIRES that app developers use Shopify app billing for application charges, it needs to be a robust, testable solution. 

Here is the example query I made:

```

{
  node(id: "gid://shopify/AppSubscription/26434896088") {
    ...on AppSubscription {
      createdAt
      currentPeriodEnd
      id
      name
    }
  }
}

Here is the response from the Graph API:

{
    "data": {
        "node": {
            "createdAt": "2022-07-14T20:18:57Z",
            "currentPeriodEnd": "2022-07-14T20:19:02Z",
            "id": "gid://shopify/AppSubscription/26434896088",
            "name": "cloudeng-nesto.myshopify.com Cartr Subscription"
        }
    }
}

As you can see, the createdAt and currentPeriodEnd are only about a minute apart. This makes the aforementioned testing in our development and local environments impossible.

[timglabisch]

Same problem here. We need to know the currentPeriodEnd to rely on accurate renewal dates. 

@Josh even the simplest flows like buying subscriptions are impossible to test because we don't know how long the subscription is valid. If a customer buys a subscription, it would immediately become invalid again.

any news on this? what workarounds did you choose to recreate the productive behavior (as closely as possible)?

[barnabycollins]

Same complaint here. I was about to implement (incorrect and dodgy) functionality to extrapolate the billing period end by adding 30 days because it seemed like currentPeriodEnd was being set to the end of the last billing period rather than the end of the current billing period, and I assumed that was normal behaviour.

This lack of functionality is really concerning, and nearly caused us to make a major implementation mistake that would have broken our user subscriptions once the Shopify billing was pushed to production.