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