All OCC files on one store are coming back with invalid signatures - I've tried reverting an original version of: Act_OCCAuthorizeNetTemplate.html without success - any ideas from anyone??
Could it be something straightfoward like the wrong merchant ID and secret key details in Actinic? If you are uploading and downloading on two machines, when check both machines.
I know you have probably thought of this already, but it's worth double-checking.
it's all on one machine - so I don't think that's it - although just in case, I grabbed a fresh copy of the transaction key from a php virtual terminal solution we hacked together - so I know that transaction key is good.
The transactions are being posted correctly, I'm able to see them on the authorize.net side as processing, it's just the OCC file complaining that it has an invalid signature when orders are retrieved. Because there are 10-20% abandoned carts, it means each order must be manually checked in the authorize.net backend... a bit of a pain...
That's a shame. It was the only suggestion I had I'm afraid.
If it's just the one site you have to wonder what's different. Could you try a test and copy the OCC files from the faulty site into a test site to see whether it is the files that are causing the problem, or whether it is the site's account details?
what elements go into the occ file and what determines whether Actinic complains that it's got an invalid signature - if you can provide me some information on that, I'm likely to get some inspiration - at present the OCC files and their makeup are a bit of a black box... more information on how they would would help..
In case of AuthorizeNet, the signature is created using the following
parameters:
- MerchantID
- Merchant Password
- Sum values of the order
- Transaction ID
If any of those parameters doesn't match on both sides (merchant - PSP)
then the signature will be invalid.
The customer should check if the MerchantID and password is set to the
same in EC *AND* at AuthorizeNet too.
yes - that helps - the password was recently changed, and although it isn't used to place transactions (the transaction key taking care of that) - the password is obviously needed for retrieval of OCC files!
hmm.. I've checked, double-checked, and TRIPLE-checked the password in Actinic - it's DEFINITELY the same as the one I use to login - yet I can't get these OCC files to download....
What I would do in your place is to try and eliminate what might be causing the problem.
I suggest you license a brand new vanilla site in Actinic Developer and use Authorize.net for the PSP. Then use the merchant ID and password from the faulty site, and upload the vanilla site to a test directory and see if it works.
That way, you can tell whether the problem is with the online PSP account, or the problem is with the customisations you have made to the site.
I'm thinking that it's an h-sphere issue and might all be wrapped up in another issue we have with Actinic failig to set permissions correctly... possibly an suExec issue... any thoughts?
ok - for future reference - this was the MD5 hash was incorrect in Actinic...
Setup a new MD5 hash and pasted that into the password field in Actinic - refreshed and all new transactions came through without a problem - it was NOTHING to do with the transaction key...
In authorize.net settings, click the Settings and Profile, then MD5 Hash in the Security settings - enter a new MD5 Hash, enter it again in the confirm box and click confirm - now enter the same MD5 Hash into your Actinic in:
View | Business Settings | Payment and Security | Click Authorize.net, then "Configure Method..." - Enter the MD5 Hash in the "Secret Key" and the "Confirm Key" boxes.
Comment