Issue is with 99.9% probability due to recent changes at authorize.net side and actual bugs on their side.

We do tests with their staging server, and see new problems there, that others are also reporting in authorize.net community forums.

We see that AIM and ARB requests are sometimes taking several minutes to complete. This is way too long, so probably your server PHP script time (usually 30 seconds) times out and CBSubs can't treat the Authorize.net reply, resulting in a charged card and no corresponding records in CBSubs.

Please contact authorize.net to complain. and urgently consider a backup payment provider, or changing to a much better payment solution provider. Currently we do not recommend Authorize.net (actuallly if this can't be solved we will have no choice than to pull our support of authorize.net!). Our current recommendation is Stripe or Paypal, who have way more stable and working APIs. Sorry about that inconvenience that is beyond our control.

or Authorize.net is having problems with it's duplicate handling with the original issue posted here (triple billing) because all the visible data in the Authorize.net record is identical across all 3 charges.

The changes happening at Authorize.net are likely the culprit. There is no reason for a implementation that has been stable for 8 years to suddenly be doing this beyond a change at Authorize.net.

Can you confirm that CBSubs is NOT sending "0" for x_duplicate_window - just so that I can go back to Authorize.net with that info?

We are not sending 0, we are sending 28800 which is the 8 hour maximum imposed by Authorize.net.