CBSubs gateway notifications and errors

krileon wrote: Are you altering the price at Authorize.net? Adding a fee of some sort? That sometimes can cause the validation checks to fail as it also is trying to be sure they're paying the right amount for the basket.

To my knowledge there's nothing extra set up at Authorize.net.

beat wrote: I'll be looking into this Authorize.net MD5 issue. Something has changed on Authorize.net side for recurring payments with ARBs. Would it be possible to send me by Private Message (PM) or embed in here with the [ confidential ] tag (lock in full editor), one of the notifications entries corresponding to the failed MD5 hash, in particular the raw part ? Thank you in advance.

Beat, I will PM you shortly. I don't know if it makes a difference, but these are happening when it is a single payment, not a recurring renewal payment. AIM + ABR are enabled at user's choice.

Authorize.net uses MD5 Hash only for auto-recurring subsequent payments. That explains why single payments and first payments of auto-recurring payments don't have this issue.

Thank you for your PM with the notification, the good news is that authorize.net provides the x_MD5_Hash.

I strongly suspect that your "Authorize.net MD5 Hash" has a small difference between authorize.net and the CBSubs setting (e.g. a space at begin or end of the key at one place and not at the other.

If that's not the case, could you please also provide the configured MD5 hash of gateway and authorize.net (should be same) by PM so I can redo the MD5 hash check manually ?

beat wrote: Authorize.net uses MD5 Hash only for auto-recurring subsequent payments. That explains why single payments and first payments of auto-recurring payments don't have this issue.

This issue is being logged for one-time payments. It was only recently that auto-recurring payments were fully operational (long story) but the couple I saw in the logs looked to work fine, no errors. It's weird if it's not used for single payments but those are the ones with an issue. Perhaps this is the cross-up?

beat wrote: I strongly suspect that your "Authorize.net MD5 Hash" has a small difference between authorize.net and the CBSubs setting (e.g. a space at begin or end of the key at one place and not at the other.

If that's not the case, could you please also provide the configured MD5 hash of gateway and authorize.net (should be same) by PM so I can redo the MD5 hash check manually ?

I wondered this as well and changed it to make sure. I will try once more to be extra-thorough. Hopefully some payments are made over the next few days to check on. I'll PM you the hash in a moment.

This is perhaps a separate discussion, but Authorize.net is warning about phasing out the MD5 Hash option. Is there a plan for this, should I just follow the directions there? developer.authorize.net/support/hash_upgrade/

Thank you, I will wait for your PM with the new MD5 hash value and transaction result. The values specifically of interest are: in the $_POST:

x_trans_id
x_amount
x_MD5_hash

and your MD5setting

The match that must be valid is as follows: "+" below means concatenating, which means just appending: And the check is case-INsensitive:

md5(MD5setting+x_tans_id+x_amount) = x_MD5_hash

You can do the check yourself too: e.g. if in the $_POST you have:

x_trans_id = 4321098765
x_amount = 123.00
x_MD5_hash = ABCDEF87A14397AE55D4277DB26B77A0

And your MDsetting is MySecretHashKey

then:

md5(MySecretHashKey4321098765123.00) must be ABCDEF87A14397AE55D4277DB26B77A0

for the ARB silent post to be matching the md5 test.

You can do the md5 in with md5() function in PHP, or in an online tool (search the internet for md5 online).

Regarding the silent posts with SHA512:

I see in your ARB silent post a x_SHA2_Hash which is now empty. I guess this is due to fact that you are on MD5 now (which is as it should be as CBSubs only supports MD5 for now).

Thanks for the hint about the programmed obsolescence of authorize.net's MD5. Hope authorize.net notified you of that in advance as you were using it. We will implement transHashSHA2 (now planed new feature #7418),

MD5 will continue to work with authorize.net for a , just make sure to have your MD5 setting working by end of January 2019 to keep things running.

To be checked once you get MD5 running: I'm wondering if you can simultaneously hash your silent posts with MD5 and with SHA2. I don't see a technical reason why not, and I see a practical reason why it could be possible to smooth transitions.

Ok, waiting for your reply and/or PM with the new tests (and md5 check results if you did it yourself )

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.

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 ?)