The long reply time at authorize.net seems to be with the ARB setup http-request for auto-recurring payments. Will look into this tomorrow. The AIM http-request seems quick as always. Those are at their sandbox test server.

I don't have a real account, only a sandbox one, and after having had to wait for the minimal 7 days period to get the first few auto-recurring ARB silent posts from their sandbox server, I see that there is no MD5 anymore but also no SHA2_Hash despite a configured key.

So if you have a sample ARB silent post notification from your CBSubs install from the production server could you please check if you see a populated x_SHA2_Hash POST variable in the CBSubs notifications for the ARB silent post ? On the sandbox server there is no x_MD5_Hash nor x_SHA_Hash variables posted, and according to the auth.net community forum this seems to be a known bug at authorize.net side. The ARB silent posts documentation has simply disappeared on their devleoppers site. So it's hard to debug.

Btw. lack of hash in ARB is weaker than using MD5 (especially that those silent posts are never exposed to users, and thus the hashes are not exploitable to guess the key, so MD5 was not a major issue for silent ARB posts).

We will release a CBSubs nightly soon that allows to leave the MD5 key field empty and in that case to skip that verification (like most subscriptions systems have done it), so that sites can continue working until either authorize.net sorts out their lack of hash, or customers find an alternative payment processor for their sites.

Btw, tbh, looking at the authorize.net handling of customers, developers, and of the bugs in the transition, and handling of these situation by authorize.net, for now, I can unfortunately not recommend authorize.net as a payment gateway anymore right now.

This sudden very long delay is most probably caused by Authorize.net (CBSubs is just doing a http request to authorize.net, and it hangs there for minutes), and is most probably a different issue of their single-handed MD5 removal.

I have seen this for ARB auto-recurring payments on the test server. But it seems that you are only using single payments and still experiencing it ?

I'll try to reproduce your problem, which is yet different, find if there is a way to work around it. But your customer should complain at authorize.net for this sudden extremely slow and business-killing delay.

Just as reference, authorize.net has been working with CBSubs for over 8 years without such issues, and nothing in that gateway changed since around 5 years, so it's quite obvious that the recent changes at authorize.net are cause of this sudden headache.

I can't give a resolution delay, as the problem originates at authorize.net, but it is my current high-priority task.