Printable View
Twice today I've had payments from Authorize.net (SIM), but the orders are missing. Debug modes was on and these are the last 2 lines:
[HashValidationValue] => 5AAC581C2A8477E26DE8F1F4EFA3CED6
[HashMatchStatus] => FAIL
Would the [HashMatchStatus] => FAIL be the cause of no order created? And why would it have failed?
Anita
There has been an error processing your credit card. Please try again.
This is the error message that my customers are getting when they try to pay with a credit card.
One customer was making a purchase on the phone with me I was stepping her through it, and she got this message "There has been an error processing your credit card. Please try again." BUT I checked in the authorize.net and the credit card went through.
I called authorize.net and they said they dont see a problem maybe i should do a test purchase.
I did a test purchase with my credit card and got the same error. BUT the card went through, I tried to call them back but they are gone for the day now
The order did NOT come up on Zen Cart.
I checked the HASH, transaction key, and the login id and they were all correct. I changed the hash and implemented the new hash and still getting the same error.
I am using Zen 1.3.8A
I set the authorize module to log and email.
I got some emails, some saying SIM alert, but the transaction went through, but weird at the end it says
[HashMatchStatus] FAIL
Please please, someone help me with this.
The last time a credit card went through was 2 days ago.
The only thing I did today was to clean out the admin activity log in the morning,
My processing is off site, the authorize gateway,
I do have SSL.
Please help me. Thanks :mellow:
So after upgrading, I didn't notice since I never order personally.
But i've been receiving complaints about a difficult ordering process of late. so I setup a fake product for 25cents, that way I dont test around with too much money, but found the following problems.
Once I confirm the order and payment information and hit COMPLETE, it shoots me to this link:
http://www.sjolietanning.com/error1.gif
now it asks me if I want to display only secured information only, and I click YES:
now it shoots this:
http://www.sjolietanning.com/error2.gif
as you can see its only text, but the BIGGEST problem is it sends me to step 2 of 3... well, the check Authorize.net, and it charged my card and went through perfectly fine. But on the customer side it looks like it didn't complete, and in admin, it wont show a new order.
What could be causing this?
Thank you.
-Mike Sjolie
I would like to add that I just changed my MD5 Hash on the Auth end, updated thru zen admin with the new code. Ran a test through my site using my own credit card.
My Zen cart gave me the error "There has been an error processing your credit card. Please try again."
Authorize.net did let the charge go through.
Got the same [HashMatchStatus] => FAIL in the error log.
I have 1.3.8a
http://www.sjolietanning.com/error3.gif
This link above shows the order being returned as NOT VALID CREDIT CARD, but when you look at the bottom half of Authorize.net Admin panel, it shows that three charges were successful?
What would do this?
Very important to fix this fast as we do $2k+ a day in volume and been cut off for past week, we thought it was a bad week, but realize this is the issue we were having with people just logging off instead of figuring out what happens.
Just noticed the kicked back page saying it was declined has a Authorize.net .DLL link instead of our website address. Thought this was interesting, but might be completely common:)
I'm having this same exact issue!
Something is up....
Me too. I posted the same problem over in the payment and shipping modules section almost at the same time you started this thread.
I just posted my own thread: http://www.zen-cart.com/forum/showth...=Authorize.net
It seems like this is my EXACT issue for the most part. anyone have any idea why it is doing this?
I had a good 20 customer calls today wanting to know why the credit card wasn't working, when really it did. Wont even show orders in admin.
Here is a screenshot of the problem: https://www.sjolietanning.com/error3.gif
seems like multiple people are having the same issue.
I emailed authorize.net support
Has anyone heard anything yet?
This sucks!
Haven't heard anything yet, I emailed authorize.net as well to see if they know anything... .
Here is the contact info for Authorize:
877-447-3938
Oh, and just a side note, I just did a test purchase with paypal and everything works fine. Just authorize.net is not working, so it has to be a problem on their end. Please when anyone has updates, let me know,, I will be calling tomorrow right when they open to ask
Have you tried to do an order via PayPal?
If that works fine then try to reinstall the Authorize.net module (take note of your configurations before uninstalling and reinstalling)
Looks like an Authorize.net problem.
Will be interesting to hear what Authorize.net says when you contact them.
Why was this thread moved to the upgrade forum? Doesn't it belong in payment module or general?
I'm running 1.3.8. Is everyone else having this problem using 1.3.8?
To anybody that is wondering what is going on, this issue seems to have been caused by Authorize.net changing their API without any warning or explanations.Quote:
Originally Posted by DrByte
In their silent POSTback, they are now passing the x_amount parameter as 19.9500 (for example) but still using 19.95 as the amount for the x_MD5_Hash parameter.
I'm not sure what they'll do about it tomorrow, but an immediate fix would require stripping out the last two 0's from x_amount when calculating the MD5 hash so that the computed md5 hash matches the x_MD5_Hash passed.
I just had to cancel a bunch of transactions from folk who had tried to put their orders through. This "little issue" is making me lose money!
Is there some kind of fix I can do on my zencart end to cope with the changes made by Authorize.net?
Sharni
So I got into a chat session with an Authorize.net support person .. end result they were contacting engineering ... they suggested I fix my cart to cope with their changes, but I am not "zenned" enough to figure that one out. Hopefully the log below will help someone post a fix.
Welcome to the Authorize.net chat forum. For your security, account updates can’t be processed through chat. Please don’t send any credit card or SSN information. For further help, please visit our Knowledge Base: http://www.authorize.net/help
You are currently at position number 1 in the queue. An Authorize.net representative will assist you shortly. We appreciate your patience.
You have been connected to Brandon S.
Brandon S: Hello Sharni! How can I help you today?
Sharni : Morning Brandon
Sharni : I use zencart and authorize.net is no longer working with my cart as of yesterday
Sharni : it processes transactions, takes the money, but no order comes through my system
Sharni : So I went to zencart forums to see if the fault laid there.
Sharni : http://www.zen-cart.com/forum/showth...777#post903777
Sharni : Seems I was not alone
Sharni : Apparently any zencart user that uses authorize.net is having the same problem
Brandon S: What is the error being returned?
Sharni : are you able to access that post I just linked to you?
Sharni : Towards the bottom someone has figured out the problem on your end
Sharni : it has to do with your API and the decimal places being increased to 4 from 2
Sharni : There has been an error processing your credit card. Please try again.
Sharni : This is the error I get on my cart end
Brandon S: Please hold while I review your account information. Thank you.
Sharni : There is no email error being sent to me from you. As you guys are processing payment.
Sharni : ok
Brandon S: It seems like it has to do with the md5 hash. Let me see if the are others reporting this issue.
Sharni : ok
Brandon S: Ok we do not have any further information at this time. I am going to have to escalate this issue and I can email you back once I have some more information.
Sharni : Thank you. Should I turn it off on my cart in the meantime?
Sharni : Just direct people through paypal for now
Sharni : I dont want frustrated customers
Brandon S: Or you can remove the md5 hash from your cart. That is what seems to be causing this issue.
Sharni : Ok I will see if I can figure out how on earth I can do that
Brandon S: You just need to remove the variable from your script.
Sharni : This is software that I am not that familiar with the back end of
Sharni : I do some modifications, but not to that depth
Sharni : I installed the authorize.net module as you guys were recommended
Sharni : and to date its been working fine
Sharni : There is an option under the set up that has my putting in an encryption key for MD5 Hash
Sharni : Do I just take out the key?
Brandon S: Yes that is correct.
Sharni : Ok trying that now and will run a test transaction right now
Brandon S: Ok
Sharni : That didnt work.
Sharni : Still got an error
Sharni : And the system just billed my credit card
Brandon S: We need more specifics. That is just a general error zen cart is displaying. We need the specific reason code that is being returned when the transaction is passed to us.
Sharni : yeah that is just being passed to the customer.
Sharni : Let me see if there is log files I can turn on
Brandon S: Ok
Sharni : ok in the auth.net module there is such an option, but there is no error at that end, so nothing is being generated.
Sharni : I am not saavy enough to figure it out in zencart
Brandon S: Unfortunately that is not something we can assist with. We do not work directly with zen cart.
Sharni : understand
Sharni : however it is a change made by your end that is causing zencart to error
Brandon S: Unfortunately at this time we do not have any specifics or more information to give you. I will pass this information on our engineers then email you once I have some more information.
Sharni : ok I guess that is the best we can do. I will turn off CC payments for now and leave it with just paypal
Sharni : Thank you for your time.
Brandon S: Thank you for contacting Authorize.Net Support, Sharni! Please contact us if you need further assistance. If you would like a copy of this session for reference, click on the "Print" icon.
Thank you for using Authorize.Net. Please search our new online Knowledge Base for answers to Frequently Asked Questions: http://www.authorize.net/help
Your session has ended. You may now close this window.
FYI: This is in the upgrade errors thread. I have not upgraded, so I do not believe this issue is related to upgrading.
I hope this helps.
Sharni
Does anyone know how to turn the Hash value back to blank on our Authorize.net account?
Omg authorize.net is saying that this is not their problem and that there is nothing that they can do. What the hell is going on?
Does someone know what we can do>>??
Everyone affected needs to be calling, using the support chat for authorize.net. Annoy them enough about this they should fix it pronto. If I am the only one complaining, I am only one voice. The more who speak up, the more aware they are that this is a problem.
And yes, if someone knows how we can turn off the MD5 thingy, please speak up. I tried making the field blank (as seen in the log I posted above) but it didn't help.
Sharni
They told me the same deal "Please fix your code to work with our system". Terrible support on thier end.
Is there anything we can change on ours?
I just had a chat with authorize to see if I could get the md5 hash cleared:
You have been connected to Brandon S.
Brandon S: Hello anita! How can I help you today?
anita : Hi Brandon, I am running a zen cart shopping cart and according to the zen cart forum there was a change in the API going from 2 decimal places to 4 causing the Hash value to fail. I had the problem several times yesterday.
anita : I would like to change my hash value to blank, but I can't seem to get it done
Brandon S: This can not be disabled in your account. If you do not want to use the md5 hash you need to disable it in your shopping cart.
anita : I did change the md5 hash to blank in the cart, but since I have a value set up here I thought there would still be an error. Is that not true?
Brandon S: No that should not be the case. All you need to do is disable the md5 hash in your account.
Brandon S: Sorry in your shopping cart.
anita : Ok thanks I'll give it a test
It did NOT work
Alright guys, I talked to a floor supervisor now, been on the phone running test transactions and stuff. They are saying that they will really get a hold of the engineers, but that they wont be in for a few hours.
If everyone calls to log their problem it would be better. Basically the more people who complain, the faster they will work on the problem. in my eyes.
On the phone with the guy I changed the MD5 has in zen and authorize.net ans it still failed.
He said on the authorize side there is no way to disable the md5 hash once you have one set, so that is not an option.
Please anyone else who had this problem , post on here and call authorize.net
Now to the person who was saying about adding 2 zeros, what were you talking about>? I see you are a new zenner with one post, they have not changed the api
ALso on the phone with the guy we tested a mastercard and a visa and got the same error, he thought it might be because of the new mastercard implementation but that was not so.
Anyone with any information, please post here.
If you experienced Zen cart people can look real good on our end to make sure the problem doesnt lie with zen, that would be great.
I have version 1.3.8A
I cant upgrade because I dont know how, so that is not an option for me right now, and I am sure that is not the problem
Everyone please post your findings here. :unsure:
Dont use chat, those guys are do do's call the number 1-877-447-3938
I just got off the phone with support and they have received a few calls. They are going to issue an Alert whatever that means.. To get this issue solved quicker I'd recommend calling. The more people calling the quciker this issue will get resolved.
I am talking to one lady who is saying that she talked to someone yesterday who was having the same problem and they found the error to have something to do with this in the error logs
[x_amount] => 0.9800
[x_tax] => 0.0000
[x_duty] => 0.0000
[x_freight] => 0.0000
about adding the extra zeros.
she says that the guy she talked to yesterday added some extra zeros somewhere to zen cart and that his worked then
any info>?????
they say they will fix it they are working on it, but cant do anything till the developer engineers get in around 9:30 pacific
oh, and its not just zen it is anyone using the md5 has, they say just not many people use that feature. keep calling and bugging
community.developer.authorize.net/
that is a place they say you can look
any updates or notices?
I am having the ssme problem.
I just spoke with Authorize.net and let them know that the response code from Authorize.net is no longer containing x_response_subcode, and that [HashMatchStatus] now says "FAIL" for every entry.
I just noticed that the new responses now contain an extra field: [x_account_number]. If anyone talks to Auth.net let them know in case it matters.
I called and spoke with one of the supervisors and they are working on it, it is with the engineers and listed as a priority one problem.
You can call them direct, or email it to them. I forwarded some of the error logs to them directly. I havent tried a test in a few hours, but I dont think there is a point of another test until I think it is fixed.
nothing new on my end. anyone else?
Nothing yet, they responded to my e ticket saying that they are working on it and will have a fix later today. They close in 4 hours. :frusty:
still waiting :censored:
From the Authorize.net Forums at http://community.developer.authorize...m-p/3791#M3467 for those who haven't seen it:
"06-30-2010 11:39 AM
I'm sorry everybody! There definitely are strange things afoot with the SIM responses. We're looking into it right now. Please check this post for updates to the issue and for what to tell your merchants.
Thanks
Michelle
Developer Community Manager"
And a follow up post from a non Auth.net employee posted after:
06-30-2010 11:56 AM
I just talked with support. I was told that the change had to do with this:
http://www.authorize.net/support/pafaqs/
And as far as the support agent was concerned there was no "fix" coming. This is going to be there permanantly.
Love how the FAQ for what we needed to do still reads:
"We will have more information soon on what changes you need to make if you use the Server Integration Method (SIM), Simple Checkout, Customer Information Manager (CIM), Virtual Point of Sale (VPOS) or the Virtual Terminal. Please check back regularly as more information will follow, including how the changes will affect the Advanced Fraud Detection Suite (AFDS)."
Anyway, as karenb points out you'll have to strip the extra trailing "00" from the x_amount field because the hash they generate is based on the amount without the trailing 00.
If somebody at A.Net knows if this situation is going to change please let us know.
I just called right now, again. I talked to a rep and he said that the latest news is:
They have found the root of the problem, it was not supposed to affect people, but of course it did
they will be releasing a "hot fix" later today and it should not affect the servers. We will see.
Still waiting :yuck:
I got a response to my ticket: They are acknowledging a problem and say they are working on it. In the mean time I am losing money :(
Hello Sharon,
We understand you are getting MD5 Hash errors.
We are aware of this issue and are working on a resolution to the issue. We will be releasing a fix for it tonight.
If the information provided above satisfies your needs, please close this ticket. Otherwise, please send a reply message with your follow-up questions so I can further assist you. For your convenience the Authorize.Net Knowledge Base, located at http://www.authorize.net/help, is available 24x7.
Sincerely,
Emily F
Authorize.Net
Customer Support
And no I don't plan on closing this ticket until CC works on my website!
Sharni
I have a feeling they are going to leave for the day and leave us hanging.... :(
Dont they rely on our fees for an income? So every sale we lose they lose their fee. So hopefully that will spur them on. Right now I am only taking payments through paypal, and while I lost some sales, I know some just used paypal instead of cc like they would have otherwise.
Sharni
Good idea. I will disable AuthorizeNet until this issue is resolved...
I think if anything they are make more money. All my customers have paid multiple times. They see the try again error and try again. One of my customers tried 5 times and was billed all 5 times. I had to void 4 of them. :no:Quote:
Originally Posted by Sharni
Yes I figured it was better to remove the option than have customers being charged and getting mad at me for the whole mess.
Sharni
I am having this issue as well... just started out of the blue yesterday. Authorize.net says nothing has changed, but if all of us are having this issue... I know nothing changed on my side. I did today changed and double checked the hash value in both Zen cart and Authorize.net, I reissued a new transaction key and copied and pasted it as well as the login id to make sure all was correct! still having the same issue
Its not your fault. They made changes on their end regardless of what they say.Quote:
Originally Posted by jbartoli
AuthorizeNet or Zen Cart is going to have to come up with a fix.
Hi fellow frustrated zenners!
I have 10 zen carts all with Auth.net :shocking:
From the looks of things we have a choice to use a MD5 Hash value for responses. Can we (as a temporary fix) remove this Hash value in our auth.net admin and remove the corresponding value in the zen payment module?
Thoughts?
Thank you,
MC
You'd think they would rollback the changes until this was fixed on their side first. just an idea.
No, No No...that would be way to easy. First the fire without backups, now this.
what do you think about removing the MD5 hash value on auth.net?
MC
Auth.net AIM does not produce this error.
MC
It does if you are using the Silent POST functionality, which is required in order to use the Automated Recurring Billing features.Quote:
Originally Posted by mcarbone
I'm using SIM now. I don't need Automated Recurring Billing. Is there a reason why I shouldn't use AIM?
AIM is more secure, you should use SIM if you don't have a SSL.
MC
I have SSL. I'll give AIM a try. Thank you :)
This is punked! They promised a fix and now they are gone, they wont answer the phones. What the hell Mike D Floor Supervisor>>?? You PROMISED, I know you have been reading this forum,.:censored::censored::censored::censored::censored::lamo:
Do you zen gurus know any temporary fix? Please help.
I am no guru, but if you have SSL, use AIM! I did and I am now getting orders...:clap:
If not, use the "credit card" module until fixed. You can always go back to the customer if it doesn't go through.
Its all better than loosing customers!
MC
Using SIM worked. Thanks mcarbone! :hug:
Awesome I think you mean AIM..but I know what you meant! Glad to hear it!:smile:
MC
Just call us twinkle fingers huh?
I cannot use AIM,
Here are the differences
SIM doesn't collect credit cards on your own site. It sends the customer to authorize.net's website to checkout on their secure page.
AIM collects credit card info on your own site and processes the cards in real time while the customer waits and never leaves your payment process. A ssl certificate is required and Curl+SSL is required to be compiled into php for AIM to work.
##############################___
I have an SSL certificate but I process from authorize.net because I do not want to be liable for anything.
So that is not an option for me.
ANyone know coding can fix the SIM>>>???:blink:
Based only on the vague information describing the problem, the following *might* provide temporary relief:
Edit /includes/modules/payment/authorizenet.php around line 430, adding the new lines as shown:If this works as expected, it should be reasonably safe to leave even after Authorize.net fixes their system bug (but it will NOT be included in future releases of Zen Cart, as it should NOT be needed under normal circumstances).Code:function before_process() {
global $messageStack;
$this->authorize = $_POST;
// temporary workaround for Authorize.net system bug
$fixAuthnetSystemErrorVal = $this->authorize['x_amount'];
if (substr($fixAuthnetSystemErrorVal, -2) == '00' && substr($fixAuthnetSystemErrorVal, -5, 1) == '.') $this->authorize['x_amount'] = substr($this->authorize['x_amount'], 0, -2);
// end workaround
unset($this->authorize['btn_submit_x'], $this->authorize['btn_submit_y']);
I was using SIM before and customers were putting their credit card info in on my site... I've always had the page on SSL though.Quote:
Originally Posted by WiccanWitch420
When you use SIM the customer was sent to a page on AuthorizeNet? How come when I was using SIM that didn't happen?
I'm using AIM now and the problem is fixed.
I process ofline as an option.
I LOVE YOU DrByte!!!!Quote:
Originally Posted by DrByte
This worked! I can now receive CC payments again!!!!
Yesterday was such a quiet day for me. About half my normal orders that were processed through PayPal. It was weird getting my settlement report with all zeros.
Thank you so much!
Sharni
I am pleased to announce that the SIM issue has been fixed. I have done 3 test purchases just to make sure and they all went through smooth.
! Finally!:clap:
I just got a test order and credit card payment to go through correctly also.(without the code changes Dr Byte suggested).
Thank you Dr. Byte for taking the time to find that work around! I'm going to keep it just in case something like this were to happen again.
I'm using Authorize dot Net's SIM api to process CCs. I'm also using ZC 1.3.8a (I know I know). The problem is that in the last 3 days we suddenly started getting multiple charges for the same order. Sometimes they're separated by up to 8 hrs. One of the orders that this happened too (chartge 6 times in this case!) Is missing from Zen-cart all together. :unsure:
Any ideas on this?
see above