Billing API: Failed to create usage charge

Hi,

we are getting the following error on some Usage Charges:

{
   "data":{
      "appUsageRecordCreate":{
         "appUsageRecord":null,
         "userErrors":[
            {
               "field":null,
               "message":"Failed to create usage charge"
            }
         ]
      }
   }
}

It’s the same error as described here:

It happens only on very few usage charges. We have 1000s of usage charges that are created normally.

x-request-id: 458ea253-7d25-4d1e-a8b5-cc58895f98df-1732622754

Full Request:

{ "query":"mutation{appUsageRecordCreate(subscriptionLineItemId:\"gid://shopify/AppSubscriptionLineItem/xxxxxxxxxxx?v=1&index=0\",price:{amount:0.27,currencyCode:USD},idempotencyKey:\"41S4QBPNUWAA\",description:\"41S4QBPNUWAA\"){appUsageRecord{id} userErrors{field message}}}"
}

Regards,
Manuel

Hi @manu

We also rely on the usage charge mutations in high volumes.

I haven’t seen this same issue recently, but it has happened to us in the past.

The best solution I’ve found is using background jobs to process usage charges. Make sure that you store the usage charge’s unique ID in your database and associate it with the action that the merchant is being charged for.

That way you can make sure you’re not double charging in case there’s multiple processes by your background job queue.

I’m not sure what your stack is, but I highly recommend switching to processing these charges in a background job queue system, so that way merchants aren’t impacted by elevated error rates, and you don’t miss usage charges.

Hope this helps,

Hi @Dylan,

thanks for your answer. We already do process charges in a background queue as described.

However you are right, the error message seems to say that the idempotencyKey has already been used. Not the most descriptive error message.

We have manually changed the idempotencyKey for the two charges where we have seen the error and the charges got billed.

We will check if those charges have been billed previously to make sure there’s no double charge.

Manuel