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.