Development discussions around Shopify APIs
I have a question re "balance_used" & "balance_remaining" fields not updating when using recurring application charge (REST API 2021-07) + usage charge (REST API 2021-07)
I am able to create a recurring application charge (POST) and can view it (GET).
FYI, "test": true, and
For my development store, I created multiple usage charge(s) ("price":"50.00") at intervals of a minute or so, and the "balance_remaining" OR "balanced_used" DOES NOT UPDATE, definitely exceeding "capped_amount"!
The odd thing is, coming back to this a few hours later, when again trying replicate the above create usage charges, the "balance_used" & "balanced_remaining" are now updating as expected, and I cannot exceed the "capped_amount" this time.
Finally, when i retrieve a list of usage charges, all the usage charges are there, the totals of all the "price" fields clearly exceeds "capped_amount".
This seems to be a bug, so:
Is this bug only when "test": true? Obviously it would be impossible/expensive to test otherwise.
Was I able to do this because I created multiple usage charges in succession, if so what is a "safe" time interval NOT to? or ...?
If this can occur when "test": null or whatever it is for the REAL situation, will I get paid the total usage charges and do I have to prove it somehow since the "capped_amount" was exceeded?
If it's not a bug, can anyone tell me what is incorrect, and/or what I should check?
Hey @SteveTT, would you be able to provide me with an example of an x-request-id header from an API request where this unexpected functionality is present? I would be happy to take a closer look and pass back any insights I can - Cheers.
awwdam | API Support @ Shopify
- Was my reply helpful? Click Like to let me know!
- Was your question answered? Mark it as an Accepted Solution
- To learn more visit Shopify.dev or the Shopify Web Design and Development Blog
Thanks for your reply, I wondering if anyone from Shopify would take notice...
The recurring application charge id is ("capped_amount": "87.00")
Sorry I didn't log the 'X-Request-ID' for that.
But, for each usage charge ("price": "29.00")
and corresponding ids:
I count 15 usage charges, so that's ($15 * 29) which is way more than $87.
FYI, the "balance_used" stayed at "0" and "balance_remaining" stayed at "87" for both the active recurring application charge, and the subsequent usage charges GET responses throughout my simulated merchant's frenzied buying spreed. 🙂
By the time you read this, however, I'll bet it will have reverted to balance_used=87, balance_remaining=0. But nevertheless, the usage charges still stand right?
Also FYI, my app IS checking prior if the merchant CAN purchase by checking the "balance_used" & "balance_remaining" vs "price". eg in this example, I am charging $29 per purchase and check that against "balance_used", "balance_remaining" BEFORE attempting to incur the usage charge.
Thanks for looking into this!
As a business owner, have you ever wondered when your customer's first impression of yo...By Skye Jun 6, 2023
We're excited to announce improvements to the threaded messaging experience in our communi...By TyW May 31, 2023
Thank you to everyone who participated in our AMA with Klaviyo. It was great to see so man...By Jacqui May 30, 2023