CBSubs gateway notifications and errors

beat wrote:

itsjeff wrote: Thanks for continuing to help with this. I tested myself and the x_MD5_Hash value in the notification's raw post data did not match the hashed value when I put the values into the formula you gave, md5(MD5setting+x_trans_id+x_amount) = x_MD5_hash

I will PM you the new data to verify. I wonder why the hash values would be different.

If it doesn't match for you too, then you need to contact authorize.net with those 4 values and ask them, because then there might be a bug on their side (one i can think of is that they don't take the newest MD5 hash key setting, but by error an old one ?)

Progress! I don't know how to go about fixing it, but I think I found the problem. I searched "authorize.net x_MD5_hash doesn't match" and the first result was an Authorize.net Developer Support forum topic that seemed to be the same issue. There is a different formula for ARB silent posts and non-ARB silent posts.
Non-ARB: md5(MD5setting+authNetAPILoginID+x_trans_id+x_amount)
ARB: md5(MD5setting+x_trans_id+x_amount)
That would explain why it didn't log the error for the users who opted in for auto-recurring payments, but not for one-off.

I tested this and the hashed value matched what was in the raw data. So the Authorize.net name (API login id) needs to be part of the formula. Can you advise how I can do this, if it's through settings/config or code?

That IS very strange, as, as you correctly summarized above, ARB silent posts specifically doesn't include the authNetAPILoginID!

Just 2 questions that maybe we should have asked first:
1. Did you by any chance enable non-ARB silent posts ? Ony ARB silent posts should be enabled.

CBSubs doesn't need them and doesn't handle them, so that could result in those ARB validation errors.

2. Are any valid transactions not properly recorded by CBSUBS into subscriptions ?

I checked the code and indeed if a non-ARB silent notification comes in it leads to such a log, but without other consequences.

So I would bet that we nailed it, and that your question #1 above is solved ?

Question #2 is indeed unrelated (attempts of duplicate payments) are there to avoid double-payments. They typically come through page reloads by the customer, or by the site itself (sometimes templates or other extensions reload a page. In that case, the right-click / inspect page / Network tab activation before tests can show this easily in most browsers)

beat wrote: 1. Did you by any chance enable non-ARB silent posts ? Ony ARB silent posts should be enabled.

In the Gateway settings of CBSubs, I have selected AIM+ABR: Single payments or Automated Recurring Billing at user's choice for autorecurring plans. If the user isn't opting in for recurring (ARB) isn't it a non-ARB transaction? Am I missing some other setup in the gateway settings or at Authorize.net?

beat wrote: 2. Are any valid transactions not properly recorded by CBSUBS into subscriptions ?

While they do seem to be processed, it does in a weird order. My suspicion is that this is somehow connected to the Gateway Error 11 (duplicate transaction) message. See the screenshot; it fails at the same time it processes. If it was a rare event I would agree it's user error, but it's been more than a few times.


Thanks again for continued support.

beat wrote: 1. Did you by any chance enable non-ARB silent posts ? Ony ARB silent posts should be enabled.

In the Gateway settings of CBSubs, I have selected AIM+ABR: Single payments or Automated Recurring Billing at user's choice for autorecurring plans. If the user isn't opting in for recurring (ARB) isn't it a non-ARB transaction? Am I missing some other setup in the gateway settings or at Authorize.net?

It's on authorize.net side where you enable the silent posts types that you wish. Only ARB Silent-Posts are required by CBSubs.

While they do seem to be processed, it does in a weird order. My suspicion is that this is somehow connected to the Gateway Error 11 (duplicate transaction) message. See the screenshot; it fails at the same time it processes. If it was a rare event I would agree it's user error, but it's been more than a few times.

Thanks for the screenshot, helps!

First 2 seem related to an AIM-silent-post (should not be enabled on authorize.net's side in your settings on authorize.net site).

Third is the reply of CBSub's AIM payment. Authorize.net attempts 2 silent posts before it returns from the AIM POST with the result.

4th is probably a reload of the page, by user OR by template or other extension (yes, seen that more often than it should, also on large sites), or an image on page with wrong url that points to same page and re-does a fetch of the page. Firebug/Page inspection/Network tab is your friend there to find the culprit...

Hi Beat, I was not sure where to disable silent post for AIM, so I got in touch with Authorize.net support.

The only way to disable Silent Post in Authorize.net is to remove the link in the Silent Post URL setting. This disables the feature entirely, there aren't separate controls for AIM and ARB. If the gateway is configured to give user choice between AIM+ARB, it needs to be on for both or off for both?


That said, the support agent also said (direct quote) "Silent Post does not even touch anything ARB related within Authorize.net"

I'm confused and stuck. The Auth.net gateway plugin settings in CBSubs has the section about Silent Posts, with the explanation and link to copy and paste over there. Any new ideas based on this info?

I apologize for having what's become two separate discussions, but just want to point out in the screenshot that the "4th" item is the first in chronological order. Why would it fail first with error 11? Is it just returned faster? It always shows up before the completed and IPN notifications in the logs. I will try to test and watch the network tab, but not sure how given the site is live.

Hi again, still looking for assistance on this. Authorize.net support said they only have one option for Silent Post and it's either on or off. There's no control to have it on for ARB and off for AIM.

If CBSubs is configured to offer user's choice of ARB or AIM (which is great to give choice) is there something to adjust in code for the hash formula so they match? Would that resolve the errors?