Balance used, balance remaining not updating incurring usage charge in recurring application charge

Retired Boards Appdev Graphql Basics And Troubleshooting
1

Hi all,

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

  • “price” : “0.00”,
  • “status”: “active”,
  • “activated_on”: ,
  • “cancelled_on”: null,
  • “capped_amount”: 200,
  • “balance_used”: 0.0,
  • “balance_remaining”: 200.0,

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?

Thanks!

3 Likes
2

Hey @LetterT , 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.

3

Hi @awwdam ,

Thanks for your reply, I wondering if anyone from Shopify would take notice…

The recurring application charge id is (“capped_amount”: “87.00”)

22693642448

Sorry I didn’t log the ‘X-Request-ID’ for that.

But, for each usage charge (“price”: “29.00”)

a2fa6015-c7d1-44cc-819b-786ba6536a5b
f756a2f3-50d0-4cf2-964f-813b3fdd15a7
815df51e-13de-4ab8-8149-80e1334e87c1
0868eef1-8a77-44d8-b99e-833b8d9f1a0a
3cfac598-1d04-4206-8d57-8a2be4578027
baa95a1c-db76-4bdc-9d4a-deb96600d300
79978f5e-f637-4678-9a2a-fb47fd986bd1
8b00ca3c-7d94-4fde-9b95-fece60eb832f
eb653d14-abdb-441f-ae27-6116b20b6c5b
554a5451-06f1-442d-840b-17e8ac0b5aaa
ade0953d-85c1-4004-9c26-6808f438172c
0dad4f46-7027-4577-87a6-3717b109bf91
ea7edb95-7c69-43c2-86a0-784c61aa24ee
17401cc7-f2b7-4f15-ab9e-407d4cab4a7b
3d456fb2-c5d1-4d85-935b-0edf68746eb2

and corresponding ids:

“id”: 95448407,
“id”: 95448431,
“id”: 95448447,
“id”: 95448465,
“id”: 95448479,
“id”: 95448521,
“id”: 95448533,
“id”: 95448541,
“id”: 95448557,
“id”: 95448573,
“id”: 95448979,
“id”: 95449087,
“id”: 95449173,
“id”: 95449401,
“id”: 95449459,

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

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!