[#7495] triple charge - no record of subscription

I am having the same issue but the user is double charged. There are 2 payment baskets, LESS than 2 minutes apart for each user who has been double charged. It does not happen all the time. About every 20 transactions over the past week. We have all the latest software to date.

I do not see any setting for turning on or off the duplicate transaction window in Authorize.net either.

We're now having more and more incidents where the user begins a subscription, the subscription is charged with Authorize.net, but the basket either is not there or we have a payment basket in the history/log area, but nothing in the subscriptions area.

We've done nothing to change anything on the system, other than to update to J3.9.4 and update CB (and CB extensions).

Not sure what else might be causing this as the system has worked as it should for well over a year.

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.

FYI ... we've contacted Authorize.net and the duplicate protections are always enabled (unless you set the x_duplicate_window setting to zero).
So either CBSubs is sending a zero in that field 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.

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?

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.

Thanks for that info about Authorize.net. I was not aware of the issues (as all my other sites all use Stripe already).
Guess it's time to migrate this last client over to Stripe.