PDA

View Full Version : authorize.net down



ILoveHostasaurus
02-24-09, 09:48 PM
Several customers reporting this over the past half hour during checkouts:

Unable to authorize payment: Error reading from '
https://secure.authorize.net/gateway/transact.dll': Invalid HTTP response

ibemiked
02-25-09, 05:32 AM
Thank you. I tried updating our Transaction Key in case it had somehow expired, but this does not fix the issue. I mention this to save others time in trying this.

ILoveHostasaurus
02-25-09, 06:01 AM
Anyone know when their support opens so we can call them? Or do they have a status website like payflow?

ILoveHostasaurus
02-25-09, 06:12 AM
I've had a report that a site not using Miva Merchant is not having this issue...

klassic
02-25-09, 06:19 AM
From Live Chat Support on Authorize.net

At this time we are getting reports from Meva Merchant with this error. We have escalated this issue on and are working with Meva to correct the issue. You will need to contact Meva Merchant's customer support to find more on this error.

I am assume this affects MIVA Merchant too ;)

nixusr
02-25-09, 06:19 AM
I am experiencing this issue as well. I am currently trying to get a response from AuthNet to see what is going on.

klassic
02-25-09, 06:22 AM
They also claim that the problem is on Miva's end and they do not have any more information.

ILoveHostasaurus
02-25-09, 06:26 AM
Interesting how they're working with Miva when no one is there yet this morning. :)

It's not the request itself that is failing, I'm able to make a connection successfully to https://secure.authorize.net/gateway/transact.dll via a MivaScript file that just makes web requests, so it's something deeper than that which occurs after the real transaction data is sent.

May end up being a Miva issue but seems odd that all stores, regardless of version, would break at the same time last night without authnet changing something.

klassic
02-25-09, 06:30 AM
Our last successful transaction was 10:38 pm Central time. Luckily customers can still use their credit cards on PayPal even without an account. I have posted a message on our payment selection page to inform customers of the problem and how to get around it by selecting PayPal as the payment type.

zscg
02-25-09, 06:59 AM
Having the same issue, and with our bad luck we relaized it a bit late, and missed a bunch of orders at night.

We live and learn no doubt.

Authorize.net better fix this problem, because they have been extremely reliable over the years, and their system works excellent (used to).

ILoveHostasaurus
02-25-09, 07:02 AM
My theory on what has happened is that authorize.net changed something last night around 10 to 10:30 PM EST that has resulted in a new response code being sent back to Merchant after a successful request. For example, if it's just using normal HTTP status codes, there are eight pre-defined codes in the 200-series of success codes, but if Merchant was only expecting a specific one, such as 200 and nothing else, and they started sending a different one, that could cause the failure.

I've been in touch with someone at Miva and they are looking into it now, 7 AM out there.

JoeG
02-25-09, 07:03 AM
I spoke with Authorize.net...they say it is a MIVA problem.

Does anyone know if the "MIVA folks" are looking into this?

ocpxc02
02-25-09, 07:09 AM
Just to support the specificity of the problem, we use Stone Edge to manage orders and it is not having any trouble processing transactions through Authnet.


Paul

wsmith
02-25-09, 07:19 AM
We have reached out to the CEO and others below at Authorize Net regarding this issue. We are currently waiting to hear back from Authorize Net. Anyone experiencing this issue please open up a ticket with our support team (support@mivamerchant.com).

Support can also be reached via phone at 866-284-9812 x3.

chmatt
02-25-09, 07:29 AM
We've had customers switch to AuthNet recently due to the Payflow Pro issues of a few weeks ago. Unfortunate timing.

Our customers are reporting that AuthNet is in fact blaming "Miva" for the issue, so I hope this is identified fairly soon.

bcannon
02-25-09, 07:37 AM
I don't know if this means anything but I just tryed to process a card in test mode and got this message.

Runtime error in 5.00/merchant.mvc @ [0000000d:00000076]: merchant.mv: Line 989: MvLOCKFILE: Error creating lockfile 'Merchant5/3b13a6b602fc5b91bb7f91e98329b935': Timed out waiting for lock

nixusr
02-25-09, 07:55 AM
Has anyone heard from Miva on this? Seems like they are going to have to beat down AuthNet's doors to get this resolved.

dtebbe
02-25-09, 07:56 AM
It is a clearly a problem specific to Miva. We are processing cards fine in Mail Order Manager (MOM) which uses Authorize.net.

This kind of thing makes my blood boil. Authorize.net clearly changed something without testing first. I used to work with a bunch of idiots like that... key word USED to work. Heads should roll.

We turned on simple validation and are going to manually run the cards in MOM.

DT

ILoveHostasaurus
02-25-09, 07:56 AM
Just an FYI for store owners who are not able to process payments and
want to implement a workaround. In your store under Payment
Configuration, you can put a check next to Credit Card Payment with
Simple Validation and click update. Now go into the new tab for that
module and remove any card types you do not accept, hit update. Now go
to the authorize.net tab and turn off ALL card types. This will leave
the module there but it will not be used during checkout.

Later on when the issue is resolved, you can go back in and turn those
card types back on, then go to the simple validation tab and delete all
the cards from there (you won't be able to remove the module itself
since orders have been placed with it). Now, you have the manual task of
processing those orders that were placed with simple validation because
it just collected the cards and didn't actually do anything with them.
You can run them manually via your authorize.net virtual terminal.

If you have done this in the past and your simple validation module is
missing its payment types, you can add the cards back in using the
following rules:

American Express begins with 34,37 and is 15 digits in length, Discover
begins with 6011 and is 16 digits in length, Mastercard begins with 5
and is 16 digits in length. Visa should begin with 4 and is 13,16 in
length.

Brandon MUS
02-25-09, 08:05 AM
Thank you thank you. This should at least work as a bandaid for now.

Rick Wilson
02-25-09, 08:06 AM
I just got off the phone with the CEO of Auth.net and one of their head techs. They are tracking it down as we speak and I will post something as soon as we know more information. This is our highest priority.

theresa
02-25-09, 08:06 AM
Just to throw in 2 more cents. We are also able to charge thru authorize.net in Stoneedge but have not received any orders using authorize.net on the website since 10 something last night. Simple validation is working thank god.

theresa

dtebbe
02-25-09, 08:12 AM
At least Authorize.net seems to have improved their customer service a little. At least someone answers the phone & chat now. They may still deny they caused the problem, but at least you get to hear that before the problem is fixed. :)

DT

bcaviary
02-25-09, 08:15 AM
Would it not be a good idea for MIVA to be part of Authorize.net beta testing of code changes. Wonder if anyone from MIVA ever approached Authorize.net with this idea?
Of course maybe Authorize.net doesn't have a beta testing team with outside testers.

JoeG
02-25-09, 08:30 AM
David,

Once again, you have saved the day!

Nice work around...my store is taking orders again.

Now the first TWO are on me at the MIVA Conference.

Thanks to you and Hostasaurus for your top notch support!!!

Joe
Pinewood Pro

tantus
02-25-09, 08:43 AM
So irritated right now.

We had just done an email blast yesterday. Missed a ton of orders, now I have to answer a bunch of customer service emails instead of doing dev work.

On top of that I'll be out of office till the first for the Miva conference and had a ton of things to take care of already.

Partypalooza.com
02-25-09, 08:44 AM
Does anyone know if Stone Edge Order Manager will actually receive the credit card information on download using Simple Validation, or will we have to decrypt it in the Admin & enter it manually? Thanks!

nixusr
02-25-09, 08:57 AM
Miva said their development team is working on it. I would have to agree with David about AuthNet saying they were working with Miva when more than likely Miva wasn't aware until 7AM PST.

Jim Cockerham
02-25-09, 08:59 AM
Same problem here with Miva Merchant 4.20. Last order for us went through at 9:36pm eastern.

Rick Wilson
02-25-09, 09:06 AM
Would it not be a good idea for MIVA to be part of Authorize.net beta testing of code changes. Wonder if anyone from MIVA ever approached Authorize.net with this idea?
Of course maybe Authorize.net doesn't have a beta testing team with outside testers.

According to Auth.net "they didn't change anything" so all the beta testing in the world wouldn't have prevented whatever is causing this.

We work very closely with Auth.net but sometimes in large distributed systems like this, there's unintended consequences. My guess is we'll find out "oh we only changed that one little thing but that shouldn't have mattered..." as I've seen this play before.

perholmes
02-25-09, 09:10 AM
Hi Rick,

I really have to commend you on your prompt attention to this, I think that's great. Very reassuring.

Best,

Per Holmes

ecentralstores.com
02-25-09, 09:15 AM
Dear David at Hostasaurus,

Thanks for the work around using the Credit Card Payment with Simple Validation. Thanks for your time posting this quick solutions for our customers. We personally want to thank you for you efforts.

Hope Authorize.net and Miva can get this issue corrected.

Have a great day.

Thomas
www.ecentralstores.com

GDesigns
02-25-09, 09:24 AM
Anybody going to post when it's working again? So we can switch back from simple validation? What a mess, especially since we are leaving to San Diego - bad timing if I've ever seen it...

Hopefully it gets fixed today though - thanks for all your support and temp fixes...

Brandon MUS
02-25-09, 09:28 AM
I'm just grateful that this happened today and not tomorrow. I'd hate to see an issue like this appear when most of the top devs and techs are busy at a conference and possibly away from their computers.

Rick Wilson
02-25-09, 09:30 AM
We've identified the root of the problem, Auth.net rolled out an unannouned API change last night. They're seeing about rolling it back and we're writing an updated module in case they're unable to roll back.

We'll keep posting status updates here until it's resolved.

klassic
02-25-09, 09:33 AM
As reported earlier. Auth.net says we didn't do it. Later oh we did, oops.

chmatt
02-25-09, 09:34 AM
One of our customers has reported that he received an e-mail from Authorize.Net to a developer mailing list. This e-mail states that Authorize.Net is going to discontinue SSL 2.0, so anything that communicates with their gateways must do so over SSL 3.0/TLS1.0. They are doing this because of PCI.

The e-mail states that they're not doing this until mid March, but it's possible they pulled the lever a bit early, and it would in fact explain the error message that users are experiencing.

tantus
02-25-09, 09:34 AM
That's a relief :D

Eric
02-25-09, 09:51 AM
Authorize.net sent out an email back on 2/19/09. Below is quick summary on dates of change, not sure if related or not.

"During the week of March 16 - 20, 2009, Authorize.Net will be deprecating all legacy support for the SSL 2.0 protocol. Changes have recently been made to the Payment Card Industry Data Security Standard (PCI DSS) which have made the use of SSL 2.0 a PCI DSS violation"

Eric

ILoveHostasaurus
02-25-09, 10:00 AM
That is not related; we tested the https://secure.authorize.net/gateway/transact.dll URL via mvcall this morning and it works fine when requested in that manner, the problem occurs after the communications begin.

Eric
02-25-09, 10:02 AM
Good to note just following-up on what Cybrhost wrote.

Eric

morditech.com
02-25-09, 10:04 AM
The e-mail states that they're not doing this until mid March, but it's possible they pulled the lever a bit early, and it would in fact explain the error message that users are experiencing.

Our servers are PCI compliant which means that SSLv2 is disabled and we are having this issue with our Authorize.net clients. This leads me to believe that SSLv2 is not the problem.

ILoveHostasaurus
02-25-09, 10:07 AM
Our servers are PCI compliant which means that SSLv2 is disabled and we are having this issue with our Authorize.net clients. This leads me to believe that SSLv2 is not the problem.

That would have nothing to do with it regardless since disabling SSLv2 on the server is specific to incoming requests to sites on the server, not outgoing requests made by software programs running on the server such as Merchant. However Miva Empresa does not have a problem making an SSLv3 connection so when they do implement that change on their side, it should still be able to communicate with them correctly.

chmatt
02-25-09, 10:15 AM
I'm tempted to tcpdump and see which SSL version is being negotiated between authnet and miva during a transaction. I'd hate to see this get fixed and another issue in a few weeks if there are problems speaking SSLv3.

But, we're a little off topic.

digitalsweetspot
02-25-09, 10:16 AM
We've identified the root of the problem, Auth.net rolled out an unannouned API change last night. They're seeing about rolling it back and we're writing an updated module in case they're unable to roll back.

We'll keep posting status updates here until it's resolved.


rick...

i hate to be the guy that's asks this, but any idea either from Auth.net or from Miva when the fix can be expected? i have a handful of clients who have been affected by this "oopsies" and i would like to give them a ballpark estimate.

some are reluctant to do the work-around (using simple validation)...especially if the fix will be coming shortly. however, if this is looking like it will be a day resolution, they might reconsider their choice of action.

any ideas would be much appreciated.

thanks in advance for all of your (and your team) support.

cheers!
-jon-

chia0367
02-25-09, 10:27 AM
Does anybody have an idea as to when this will be resolved?

The clock is ticking.
So is the cash register.

steveschumes
02-25-09, 10:48 AM
Does anyone know if switching to simple validation requires deleting all batches as well as orders?

Brandon MUS
02-25-09, 10:52 AM
Does anyone know if switching to simple validation requires deleting all batches as well as orders?
You don't switch, you add. Here are the steps that Miva gives:

To enable Credit Card with Simple validation
1) Log into the administration of Miva Merchant (Version 5 users go directly to step 3)
2) expand Stores and expand your store name
3) click directly on Payment Configuration (Payment settings in version 5)
4) Click on the active link for Authorize Net (blue link above the list of modules)
5) Remove the available credit card methods (Visa, Mastercard and such) and hit Update
6) Click on the "Modules" link (to the left of the active Authorize Net Payment Services v3.1).
7) Enable Credit Card with Simple Validation by checking the open box to the left and hit update (lower right).
8) Click on the active link for Credit Card with Simple Validation and remove any methods (Visa, MasterCard, American Express or Discover) that you DO NOT wish to accept.
The one caveat is that once you enable this payment method and receive an order, you cannot delete this module.

Rick Wilson
02-25-09, 10:59 AM
UPDATE:

We're in the final testing stages of an updated module. I'll post the module here as soon as I have it.

GDesigns
02-25-09, 11:00 AM
Thanks Rick

kayakfishingstuff
02-25-09, 11:05 AM
Thank you very much, waiting patiently for an updated module.

We are very appreciative that you're keeping us updated via this thread.

Eric
02-25-09, 11:09 AM
Rick,

Is updated module also going onto the update wizard? Or will this be a manually update to download from here/patches page?

Also is status same for Miva 5 and Miva 4 module or is priority on Miva 5 1st?

Thanks!
Eric

Rick Wilson
02-25-09, 11:11 AM
Eric,

Good questions. The 4 module is a higher priority that getting the update wizard ready (which will take about a day). So right now here's the priority list:

1. Put out the updated 5 module via Support, Forums and Hosts
2. Put out the updated 4 module via Support, Forums and Hosts
3. Put the 5 module in the Update Wizard (may not happen until next week)

In the meantime Authorize.net is in the process of rolling back, so at some point today our fix will be optional but still recommended.

Jonathan-Driftwood
02-25-09, 11:14 AM
The caveat is there for sure - but only until you delete the orders used by the Simple Credit Card module. Once they have been processed and removed, Merchant's need for the module is no longer there.

Once AuthNet fixes their error(s), you will have to reverse the steps to disable the cards used by the SCC module and then re-enable them in the AuthNet module. The SSC module will run 'piggyback' until the orders it took in are deleted, then it can be disabled back to oblivion.

And don't know if it was mentioned - but you really ought to only make the payment module changes AFTER you have put your store in maintenance mode during the transition.

Jonathan




You don't switch, you add. Here are the steps that Miva gives:

The one caveat is that once you enable this payment method and receive an order, you cannot delete this module.

Eric
02-25-09, 11:16 AM
Rick,

Thanks for the very fast reply! I think I speak for all in saying we all feel your pain and appreciate Miva's rapid response to this problem!

Problems will occur and its judged on how companies respond to those problems.

All the best to you and the staff.

Thanks
Eric

Jonathan-Driftwood
02-25-09, 11:17 AM
Hey Rick - does that mean the new/updated module will accommodate the changes implemented before the rollback? Will it cover when they do it again?

Jonathan




Eric,

Good questions. The 4 module is a higher priority that getting the update wizard ready (which will take about a day). So right now here's the priority list:

1. Put out the updated 5 module via Support, Forums and Hosts
2. Put out the updated 4 module via Support, Forums and Hosts
3. Put the 5 module in the Update Wizard (may not happen until next week)

In the meantime Authorize.net is in the process of rolling back, so at some point today our fix will be optional but still recommended.

Rick Wilson
02-25-09, 11:19 AM
Hey Rick - does that mean the new/updated module will accommodate the changes implemented before the rollback? Will it cover when they do it again?

Precisely. They will eventually roll this API change back out and this will cover stores when they do that (hopefully next time they'll warn us).

Jonathan-Driftwood
02-25-09, 11:22 AM
Warning of a payment gateway change? Perish the thought. Where else can we all find such a wonderful source of early morning adrenilin?

Jonathan




Precisely. They will eventually roll this API change back out and this will cover stores when they do that (hopefully next time they'll warn us).

traver
02-25-09, 11:25 AM
They did this about 3 or 4 weeks ago with the CIM API as well...broke some of my code, and I had to scramble to modify the sent parameters...

nice of them to warn anyone when they do those sort of changes.

Tim.

Jeff - Wolfpaw Hosting
02-25-09, 11:34 AM
Rick, what change did Authorize.net make that broke everything? I guess you must know since you're writing a module to address it.

Jim McCormick
02-25-09, 11:36 AM
Hello,

There is a newer Authnet commerce library for any host that is running Linux. You can download it here:

https://support.smallbusiness.miva.com/supportsuite/index.php?_m=downloads&_a=viewdownload&downloaditemid=48

dotCOM_host
02-25-09, 11:37 AM
nice of them to warn anyone when they do those sort of changes.
They did... they sent a note to all registered developers... Alas, someone pulled the trigger a bit early and made the change last night, not March 16-20 like they were supposed to.

Ever since they were bought out by CyberSource they've gone downhill. Not unlike Payflow Pro, when they were bought out by PayPal. I see a trend developing...

Rick Wilson
02-25-09, 11:37 AM
Rick, what change did Authorize.net make that broke everything? I guess you must know since you're writing a module to address it.

Prior to 9PM yesterday a particular field was not case sensitive, they rolled out an update that required it to be in upper case (and assumed it wouldn't impact anyone).

Rick Wilson
02-25-09, 11:38 AM
They did... they sent a note to all registered developers

Remik this issue has nothing to do with their SSL 3 issue coming up in a few weeks.

dotCOM_host
02-25-09, 11:39 AM
Hmmm, interesting. Thanks for the clarification, Rick.

copshoespatrick
02-25-09, 11:40 AM
Prior to 9PM yesterday a particular field was not case sensitive, they rolled out an update that required it to be in upper case (and assumed it wouldn't impact anyone).


Um.. That was not the smartest thing to do.

traver
02-25-09, 11:41 AM
Hello,

There is a newer Authnet commerce library for any host that is running Linux. You can download it here:

https://support.smallbusiness.miva.com/supportsuite/index.php?_m=downloads&_a=viewdownload&downloaditemid=48


and whats the chance of getting a freebsd module out here pretty soon too?

Tim.

steveschumes
02-25-09, 11:46 AM
To everyone at Miva, thanks for the hard work on this issue. Will we be notified when Authorize.net completes the rollback?

beamer
02-25-09, 11:49 AM
I actually find it pretty damn amazing they rolled this out without significant beta testing. I'm pretty pissed. What is even worse is when you talk to them they blame it on Miva but its pretty damn clear they created the mess.

Eric
02-25-09, 11:54 AM
Rick,

What about uncomplied stores running on miva 3.97 is their updated commerce library for that version.

Eric

dotCOM_host
02-25-09, 11:54 AM
Just to let everyone know - we installed the new Authorize.net commerce library in a few stores and run a number of test transactions. Everything appears to be working perfectly. We are rolling it out to all servers so we can quickly activate it on any affected sites using Authorize.net

Thank you Rick and everyone at Miva for such speedy update.

beamer
02-25-09, 11:54 AM
Well I thought a few may get a kick out of this:

AuthNet_Support: Hello Ron! How can I help you today?
ME: Hello we are having problems with the transaction gateway.
AuthNet_Support: What problem is that Ron?
ME: It is giving us an Invalid HTTP response
ME: We have not changed anything in our store
AuthNet_Support: We are aware of this matter and we are working to determine the cause. If they have further questions, they are to contact MIVA Merchant at 1-866-284-9812 for further assistance
ME: Okay but there have been no Miva changes to my store. This store has been running for better than five years. There are no code changes to my store so calling Miva is not the answer.
AuthNet_Support: We understand. Again for now, questions needs to go through MIVA. This is a problem we are finding in general with the MIVA carts. They are working on it with Miva, but for now the support is through Miva
ME: That is just great, thanks. Your management sure makes a case for changing gateways.
ME: Good bye
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. https://admin.instantservice.com/htmlclient/images/spacer.gif

beamer
02-25-09, 12:01 PM
Just to let everyone know - we installed the new Authorize.net commerce library in a few stores and run a number of test transactions. Everything appears to be working perfectly. We are rolling it out to all servers so we can quickly activate it on any affected sites using Authorize.net

Thank you Rick and everyone at Miva for such speedy update.

Remik, are you going to post here once you have completed the process?

Wil
02-25-09, 12:04 PM
and whats the chance of getting a freebsd module out here pretty soon too?


Pretty please?

Eric
02-25-09, 12:05 PM
I know the uncompiled version is in process.

We have updated all of our servers and things are working well for 4.13 and higher and 5 stores.

Eric

vickeryhill
02-25-09, 12:08 PM
Our storefront is on a Windows hosting platform with Intermedia.net.

I saw an earlier update for a Linux server. Are there any updates for Windows?

Is Intermedia.net one of the Miva partners that received the update?

whona
02-25-09, 12:11 PM
Since I am hosted on Hosting4Less, does that mean that this issue is resolved for me?

Eric
02-25-09, 12:13 PM
Whona,

Yes since you are running Miva 5 Store this is resolved.

Eric

Jim McCormick
02-25-09, 12:14 PM
Hello,

We have a new v5 module that will allow you to not use a commerce library. Any merchant using Miva Merchant v5 on any platform (server operating system) can and should update to this module.

https://support.smallbusiness.miva.com/supportsuite/index.php?_m=downloads&_a=viewdownload&downloaditemid=49

Rick Wilson
02-25-09, 12:14 PM
Attached is an Updated module for 5.x that does not require a commerce library (this is the module we'll stream out next week).

This can be installed by the Store Owner and doesn't require Host assistance.

Go to Modules in the Left Navigation and search for authnet
-> Click Edit to right of the Authorize.net module
-> Click the tab that says Files
-> Click Upload, check the box that says Overwrite, and browse to the new module on your local computer, then click Upload.
-> Once the module is Uploaded, click Update
-> Click the Information Tab and check the module version number, if it says 5.5004 then you've successfully updated (and your Authorize.net issues should be solved)

Jim McCormick
02-25-09, 12:14 PM
Yes, a v4.X module is on it's way....

chmatt
02-25-09, 12:15 PM
CybrHost has updated all shared servers with the new commerce library, so CybrHost subscribers on shared servers should not need to update their modules.

zscg
02-25-09, 12:23 PM
If the host has already updated the new commerce library, and we updated the module itself, will that cause any issues?

ILoveHostasaurus
02-25-09, 12:26 PM
Should not matter since the new mod doesn't use the commerce library.

Rick Wilson
02-25-09, 12:26 PM
There would be no conflict.

Eric
02-25-09, 12:27 PM
Zscg,

NO their are no issues if the hosts have updated the commerce library and customer updates the module.

Eric

scott
02-25-09, 12:28 PM
What about Hostasaurus servers? What's the time frame?

deebeedee
02-25-09, 12:30 PM
Hi David,

Our store is a Miva 5 store on the Hostasaurus servers. Is the issue resolved for us?

Thanks,
Daniel


Should not matter since the new mod doesn't use the commerce library.

SNAGuy
02-25-09, 12:31 PM
Thanks. Just did the module upload per Rick's instructions and it is working now.

Glad this happened today and NOT Friday!

Good going Miva!

Rick Wilson
02-25-09, 12:35 PM
Jim will be posting the updated 4.14+ (compiled) module here in a few moments.

For stores 4.13 and older, the only fix is to use an updated Commerce Library. We're working diligently to get an Empressa 3.x Commerce Library completed.

scott
02-25-09, 12:41 PM
Hooray!

Wil
02-25-09, 12:42 PM
Jim will be posting the updated 4.14+ (compiled) module here in a few moments.


Commerce library for FBSD pthreads would also be superb since we would be able to do this server side and not have to login to every customer's account to click the update button. Makes rollout much easier. Thanks.

Manoj
02-25-09, 12:43 PM
After updating the 5.x module has anyone else had a problem downloading orders through SHIPWROKS I get the following message

"mysql_stmt_prepare:MYSQL has gone away"

Rick Wilson
02-25-09, 12:44 PM
Manoj,

The Auth.net module doesn't impact the database in any way, you should contact Shipworks.

Jim McCormick
02-25-09, 12:45 PM
New Authorize.net module v4.2402. This will work for any merchant using Miva Merchant v4.14-4.24. Just like the module for v5 this module does not require a commerce library, only OpenSSL.

https://support.smallbusiness.miva.com/supportsuite/index.php?_m=downloads&_a=viewdownload&downloaditemid=50

Kenny
02-25-09, 12:47 PM
So to clarify, we're running 4.23 hosted by Hostasaurus. Will our host take care of this or is this something that we will manually have to do?

Kenny
PS: Thanks also to everyone who is busting their humps to get this resolved!

Jim McCormick
02-25-09, 12:51 PM
We now have commerce libraries for all platforms running compiled Merchant.

https://support.smallbusiness.miva.com/supportsuite/index.php?_m=downloads&_a=viewdownload&downloaditemid=48

If you have installed the newer module, v4.2402/v5.5004, you do not need to install a commerce library as the module does not require one.

BrokenGlass
02-25-09, 12:55 PM
So to clarify, we're running 4.23 hosted by Hostasaurus. Will our host take care of this or is this something that we will manually have to do?

Kenny
PS: Thanks also to everyone who is busting their humps to get this resolved!

Same question here, and I also want to thank everyone for kicking some butt on fixing this problem! You all rock!

Hostasaurus
02-25-09, 01:02 PM
Kenny, we've updated the commerce library for 4.14 - 4.24 and 5+ stores, which will fix the issue if you are using one of those versions.

You are welcome to update the payment module itself via the Modules menu in the admin if you like, but you only need the library or the new module to fix it.

Jen

Ksaluzzi
02-25-09, 01:04 PM
Hello,

Just to let some folks mind to rest, I installed the latest Authorize.Net module v4.2402 and it tested OK.

My store's specs:
MM: v4.24 / MVM: v5.03
OpenUI: [4.958/4.984]

hosted by Hostasaurus.

Thank you Rick and your Miva Team for providing a fix in such short notice! Thank you to everyone else who provided a helpful workaround.

Ken

benjamintr
02-25-09, 01:04 PM
Thanks to Miva for tackling this so quickly!

Rick Wilson
02-25-09, 01:05 PM
FYI - This problem only impacted Miva Merchant 4.14 - 5.5 stores, older stores using the 3.x (or older) Commerce Libraries were not impacted.

Rick Wilson
02-25-09, 01:06 PM
So at this point all the Com Libs are updated (for hosts to update) and Modules updated if the Merchant wants to update.

chmatt
02-25-09, 01:08 PM
Also, at this point we have updated all of our shared and dedicated servers (thanks to a little shell scripting), so CybrHost customers do not need to do a thing.

Nice work Miva for identifying the issue and releasing updates before lunchtime (in their timezone anyway!)

beamer
02-25-09, 01:12 PM
The new library is working just fine!

RMWAnnie
02-25-09, 01:12 PM
Many thanks to the Miva team for getting this resolved so quickly. Also, special thanks to David and Jen at Hostasaurus for helping me solve my related issues! I do love Hostasaurus!!

Barbara

Jim Cockerham
02-25-09, 01:13 PM
Just for the record....I ran orders through both my 4.20 and 5.5 stores with the new modules installed and all is well!!

A big thanks to all who worked out this problem so quickly.

Jim

Club RSX.com
02-25-09, 01:20 PM
we just ran into an error where orders were not producing authorization codes but it seemed to be a temporary issue.

Kenny
02-25-09, 01:22 PM
Thanks Jen, and thanks to everyone who had a hand in this fix! As of 3:17 pm Central, we're back in business.

bcannon
02-25-09, 01:31 PM
I'll bet there's some HIGH FIVES going on at Miva right now.

Thanks guys

zscg
02-25-09, 01:34 PM
Great job guys. Thanks for the quick work on this issue. In this environment no merchant wants to lose sales even for a single minute.

Thanks to Miva Merchant staff (and all the hosts who informed us on the issue right here )...

WaterLeslie
02-25-09, 01:44 PM
I believe it's fixed. The visa payment works now, and we are going to try other method of payment. Good luck to you all too.

INTENSE
02-25-09, 01:52 PM
We are up and running as well. Appreciate all the hard work!

Jeff - Wolfpaw Hosting
02-25-09, 02:18 PM
Two things. We have updated all of our servers with the new Authnet module. Some of our customers already have reported that it works.

Second, does anyone have the email address of Authorize.net's CEO? I'd like to talk to him about an apology and what they plan to do to make our Miva customers whole for losing almost a day's worth of business.

Jim McCormick
02-25-09, 02:28 PM
I'll bet there's some HIGH FIVES going on at Miva right now.

Thanks guys

If we didn't have 100 merchants to reply to with the fix we could pick our heads up enough to do just that....

Rick Wilson
02-25-09, 02:32 PM
Supposedly Auth.net has just finished rolling back the change, so everyone should be working at this point regardless of module or commerce library.

DunkirkSystems
02-25-09, 02:42 PM
Kenny, we've updated the commerce library for 4.14 - 4.24 and 5+ stores, which will fix the issue if you are using one of those versions.

You are welcome to update the payment module itself via the Modules menu in the admin if you like, but you only need the library or the new module to fix it.

Jen

Hi Jen - I just ran a test order thru the one store I have hosted with you that uses Authorize.net, and all worked perfectly. There were no other reported order errors from this particular site earlier, FYI.

Thanks for your help with this!

mp/m

DunkirkSystems
02-25-09, 02:45 PM
Two things. We have updated all of our servers with the new Authnet module. Some of our customers already have reported that it works.

Second, does anyone have the email address of Authorize.net's CEO? I'd like to talk to him about an apology and what they plan to do to make our Miva customers whole for losing almost a day's worth of business.

I had moved from Authorize.net for several of my sites because of their poor service. If you don't get a reply, there's the best way to communicate your concerns.

mp/m

zscg
02-25-09, 02:57 PM
Supposedly Auth.net has just finished rolling back the change, so everyone should be working at this point regardless of module or commerce library.

In the future when they reimplement this change the new Auth.net module from Miva will work without a problem right?

elcucococo
02-25-09, 03:02 PM
Thank you Miva and Hostasaurus for being there supporting us through today! We are SOOOO lucky to be in the Miva Merchant Community!!!! WAR MIVA!

2CDev
02-25-09, 07:00 PM
Everyone at Miva and these dedicated Miva hosts worked in lightning fast timing today to avert an otherwise wicked situation. I cannot tell you how helpful and kind everyone was in an otherwise stressful situation. You all ROCK!!

Happy Conf...

ILoveHostasaurus
02-26-09, 12:10 PM
I think authnet may have put the change back in, if they ever reversed it to begin with; just an FYI for anyone who's host didn't update the commerce library or for those who didn't update the module in their store on the assumption it wouldn't be necessary.

perholmes
02-26-09, 03:36 PM
Hi,

Our store crashed as everyone elses, and the new Authnet module fixed it. At least I thought. I ran a test order and everything was fine.

Then later in the day, a customer called, and he was getting an error saying MD5 Mismatch. I ran a test order again, and sure enough, I got the MD5 mismatch again.

I went to Authorize.net and created a new transaction key and also made a new MD5 while I was at it, and it again works. I hope.

I would recommend that everyone at least be aware of a possible MD5 issue, as I'm not inclined to believe it's a coincidence.

Best,

Per

ILoveHostasaurus
02-26-09, 03:50 PM
Remove the md5 value altogether, that 'feature' has never worked reliably in any version of Miva Merchant, not sure who's fault it is but it just doesn't work.

jb77
02-26-09, 10:20 PM
Remove the md5 value altogether, that 'feature' has never worked reliably in any version of Miva Merchant, not sure who's fault it is but it just doesn't work.

Sorry to hijack the thread, but David, could you elaborate on how the MD5 never works "reliably", we are ignorantly using it in our store - does it cause errors or something else?? Authorize says that once you set it it cannot be removed - thanks Authorize! I wish USAePay would make a Miva 5 payment module, they were light years better than Authorize, but now I'm just ranting...

Thanks,
Jordan

ILoveHostasaurus
02-27-09, 03:17 AM
Yep, for years we've seen customers have errors related to the md5 hash and not using it seems to be the only reliable 'fix'.

perholmes
02-28-09, 02:34 AM
I want to confirm that removing the MD5 value (leaving the field blank) is the way to go. Since Authorize.net's update and Miva's fix, about every 10th order would get the MD5 error, and the customer would be on the phone. They would already have retried several times, resulting in multiple charges to their credit card.

Deleting the MD5 did the trick. Nothing needs to be done on Authorize.net's portal.

Thanks! That REALLY helped us. We're about to run a major blast, and this would have been catastrophic.

Best,

Per

JoeG
02-28-09, 09:19 PM
Since the Authorize.net crash on Wed, my "failed payments" have been 12, 15 and today 21! ("failed payments" are reported by Truxoft's MMTicker module.)

I normally get no more than 4 in a day.

I upgraded the Authorize.net module to 4.2402 on Thurs and have been taking orders but clearly something is still wrong.

Anyone else getting excessive failed payments? BTW, where is this MD5 setting??

Jim McCormick
02-28-09, 09:51 PM
]
Anyone else getting excessive failed payments? BTW, where is this MD5 setting??

In the module configuration. Go into Payment Configuration and then then Authnet module tab. You'll see the filed for md5hash. If you have anything in there, delete it.

JoeG
02-28-09, 09:58 PM
OK, see it...field is blank, so it's not the MD5 hash.

Any other idea that could be causing sharp increase in failed payments?

Thanks in advance for the help...

Jim McCormick
02-28-09, 10:18 PM
What is the error on the failure?

JoeG
03-01-09, 09:17 AM
I don't know...all I see is the warning message about "failed payments".

I'm at the conference...are you here so we can "go live" and talk?

Jim McCormick
03-01-09, 10:17 AM
Yes, I'm here at the registration table. Where is this "failed payments" message?

ILoveHostasaurus
03-01-09, 03:48 PM
It's coming from a Truxoft module he's running which monitors his version 4 store's checkout. I spoke to him about it too and he's trying to get in touch with one of the customers who had a failure to see what the message displayed to them was.

perholmes
03-04-09, 11:32 AM
Hi,

After loading the new Authorize.net module, we've had some customers having their payment processing time out. I've already talked with Miva support, and we agreed that while it's not very likely that something is wrong with the module, that it would be valuable to post it to the community.

Here's a chronology:

Of course, Authorize.net broke last week for us as well as everyone else. When we installed the new module, we were suddenly having intermittent MD5 problems, so we cleared that field, ran some test orders, and everything has been fine.

BUT, since last week, our sales have mysteriously dropped down to 50%, so we ran some more test orders, everything seemed fine, so we just sort of blamed the economy.

But in the meanwhile, we have started getting an unusual amount of Restock Shelves emails, with an unusual amount of abandoned shopping carts with Customer Contact Information, hinting that they went halfway through checkout.

Then a customer just called, who had been trying to put his order through twice, where payment processing timed out, so he called us, I when through the exact same checkout procedure, and it worked just fine.

So obviously, we've put a sign up on our website to make sure that people don't panic, but instead call us.

But the key here is that I think it would be worthwhile for everyone to at least check if their payment processing actually works every single time.

In the meanwhile, since it's a timeout, I'll also contact the webhost (WestHost), to see if they have experienced a DNS issue, which could explain a timeout.

So this posting is intended as an alert. I would like nothing more than being wrong. But if there's an issue, even intermittent, we should investigate it.

Best,

Per

ILoveHostasaurus
03-04-09, 11:38 AM
In the meanwhile, since it's a timeout, I'll also contact the webhost (WestHost), to see if they have experienced a DNS issue, which could explain a timeout.


Do you know the specific error that is seen at checkout when this occurs?

ibemiked
03-04-09, 11:56 AM
David, we are also having the MD5 HASH error. They payments are going through, but the order never gets created or registered with MIVA Merchant. We took out the field for the time being, but are obviously concerned that this may cause other issues. What Exactly is this 'feature' for authorized.net doing?

ILoveHostasaurus
03-04-09, 12:02 PM
David, we are also having the MD5 HASH error. They payments are going through, but the order never gets created or registered with MIVA Merchant. We took out the field for the time being, but are obviously concerned that this may cause other issues. What Exactly is this 'feature' for authorized.net doing?

In theory the MD5 hash is used to ensure the data being sent has not been corrupted (unrelated to encryption) but for whatever reason it has never worked reliably; we've always told customers to not put anything in that box and it should always work without anything there.

ibemiked
03-04-09, 12:10 PM
Okay great, I am assuming the issues 'Per' is having are unrelated then... thanks.

Jim McCormick
03-12-09, 02:16 PM
We found a bug in the way that md5hash handled the address of customers. If the customer had a comma in their address it would reject the order in Merchant but would authorize the card in Authnet. We have fixed this bug and have tested and are now releasing newer modules, v4.2403 and v5.5005. Here are the links:

v4.2403 - https://support.smallbusiness.miva.com/supportsuite/index.php?_m=downloads&_a=viewdownload&downloaditemid=50

v5.5005 - https://support.smallbusiness.miva.com/supportsuite/index.php?_m=downloads&_a=viewdownload&downloaditemid=49

ILoveHostasaurus
04-21-09, 01:35 PM
Since the release of the fixed version 4 module, we've had several customers report occurrences of 'duplicate order' errors when customers are submitting their card info; there used to be a check box to discard failed order id's but that is gone; is there a chance that feature was intended to have been built in but was left out?

Rick Wilson
04-21-09, 03:45 PM
Let me find out.

LBS
05-24-09, 06:39 AM
Anybody else getting the error below? Been happening since Sat. morning.

Unable to authorize payment: Unable to open URL 'https://secure.authorize.net/gateway/transact.dll': Connection Timed Out
Unable to authorize payment:

We're on Miva 5, also tried updating the Authorize.net module and that didn't help either. Our host tried "pinging" them, etc. and said it seems Authorize.net is down.

Club RSX.com
05-24-09, 06:51 AM
just tested and it worked for me at 8:05 AM MST

ILoveHostasaurus
05-24-09, 07:48 AM
Our host tried "pinging" them, etc. and said it seems Authorize.net is down.

Authorize.net blocks ping traffic so that is normal.

ILoveHostasaurus
07-03-09, 04:05 AM
Just FYI, appears they are down again this morning; two other threads about it in the mm4 and mm5 sections of the forum; their website is down too....

Ksaluzzi
07-03-09, 04:58 AM
Thank you David for letting us know. I also want to add if anyone has the Authorize.net badge on their page, to comment it out so it will not slow down your page load. The code in Miva to comment code is


%COMMENT% text %COMMENTEND%

Ecentral
07-03-09, 06:46 AM
Power Outage all Authnet services are down for several hours

TotalVac
07-03-09, 07:09 AM
authorize.net's website is down and I hae been trying to call their 877-447-3938 number. A recording comes on that sasy we are closed for the week-end and then it hangs up.

We are unable to process credit cards.

TotalVac
07-03-09, 07:11 AM
Thanks, for the updates. I have been trying to get through to their 877-447-3938 number but it is disconnected. Don't they have generators for back-up power?

Ksaluzzi
07-03-09, 07:36 AM
Unfortunately, it's worse than a power outage. Looks like there's been a fire at their data center. You can follow updates on the Authorize.net problem here: http://hashtags.org/tag/Authorize.net

dtebbe
07-03-09, 08:01 AM
Just FYI, appears they are down again this morning; two other threads about it in the mm4 and mm5 sections of the forum; their website is down too....

So, did you get shaken out of bed at 4am or are you just an early riser?

We need David in charge at Authorize.net!

DT

ILoveHostasaurus
07-03-09, 08:09 AM
So, did you get shaken out of bed at 4am or are you just an early riser?

We need David in charge at Authorize.net!

DT

I woke up to go to the gym, backed my truck into my girlfriend's car (the truck won), then authnet is down; it's going to be a good day. :)

Ecentral
07-03-09, 08:29 AM
Authnet responds on Twitter to be operational by 1pm

Foreman2
07-03-09, 08:31 AM
David,

I have followed your instructions regarding Credit Card Payment with Simple Validation. However, only Visa is showing up on our website. Discover, Amex, and MC are listed on the Simple Validation page in the admin but do not appear as an option at checkout. We are on Miva 3. Let me know if you have any suggestions on how to fix this! Any help would be greatly appreciated!

Thanks,
Jon

GDesigns
07-03-09, 08:36 AM
is that 1 PM time pretty reliable? is it PST or EST?? thanks!

ibemiked
07-03-09, 08:37 AM
Is that EST?

Rick Wilson
07-03-09, 08:40 AM
Their twitter page http://twitter.com/AuthorizeNet suggests some services are back up.

AlAlvin
07-03-09, 08:57 AM
David,

Simple Validation is only showing Visa for me even though we have Visa, Amex, Mastercard, and Discover listed. I have unchecked all cards from the Authorize.net module and the Quickcommerce AIM module.

Any help would be greatly appreciated.

Thank you

ILoveHostasaurus
07-03-09, 08:58 AM
David,

Simple Validation is only showing Visa for me even though we have Visa, Amex, Mastercard, and Discover listed. I have unchecked all cards from the Authorize.net module and the Quickcommerce AIM module.

Any help would be greatly appreciated.

Thank you

You can add the others back in:

American Express begins with 34,37 and is 15 digits in length, Discover begins with 6011 and is 16 digits in length, Mastercard begins with 5 and is 16 digits in length. Visa should show begins with 4 and is 13,16 in length.

dotCOM_host
07-03-09, 08:59 AM
More info also available at http://www.techcrunch.com/2009/07/03/authorizenet-goes-under-e-commerce-vendors-left-hanging/

AlAlvin
07-03-09, 09:00 AM
You can add the others back in:

American Express begins with 34,37 and is 15 digits in length, Discover begins with 6011 and is 16 digits in length, Mastercard begins with 5 and is 16 digits in length. Visa should show begins with 4 and is 13,16 in length.

I have all of those cards listed under Simple Validation module with those #'s and still the only card showing up on the live site is Visa. FYI it is Miva 3.

ILoveHostasaurus
07-03-09, 09:01 AM
Do you have any third party modules that interact with what payment methods are displayed, some have to be made aware of what methods are active at the moment, check in system extensions or utilities for anything like that.

AlAlvin
07-03-09, 09:21 AM
Do you have any third party modules that interact with what payment methods are displayed, some have to be made aware of what methods are active at the moment, check in system extensions or utilities for anything like that.

David,

We did have a Payment Method Display module under utilities that was causing the simple payment methods not to display. Thank you very much for your help, it is greatly appreciated!!!

wcw
07-03-09, 09:23 AM
You have to go to the module's admin and set the display order of the shipping methods. If they are 0 they won't display. They have to be 1 or higher.

Eric
07-03-09, 09:42 AM
Hi there,

Just thinking outloud. I wonder if it is worth developing an error routine into the Auth module that if it is unable to connect to the service it leave the order in a "Pending State" that can than be manually processed so at least customers could order.

This procedure above could than be utilized for other payment methods as well perhaps.

Eric

dotCOM_host
07-03-09, 09:43 AM
This has been requested many more times than you'd probably want to hear about... a "fallback" mechanism to just save CC number info so it can be processed manually at a later date. Rick probably has a 200 page notebook filled with requests for this option, dating back to the dark ages (Miva Merchant v2.x).

Ecentral
07-03-09, 10:12 AM
Another great option for anyone that has a business PayPal account.

Payment Settings > PayPal Website Payments Standard > Follow instructions.

In you mm authnet settings uncheck all credit cards and post a message on your shipping and payment screen.

takes about 2 min and all cc are procesed thru PayPal until Authnet fixes issues.

Ecentral
07-03-09, 10:19 AM
Authnet seems to be back up.

Eric
07-03-09, 10:25 AM
I too am from the dark ages although prior to Findwhat was not dark! :-)

Unfortunately, like many things in life it sometimes takes a couple incidents to bring something to the forefront and see about a problem that needs to be maybe moved up the priority list. We see it all the time here in LA on intersections where their is no left turn signal and lots of accident they finally decide its worthwhile to put a turn signal in after a bunch of bad accidents.

Maybe Rick wants to chime in after the holidays and PR6 is completed.

Eric

Eric
07-03-09, 10:26 AM
Ecentral,

No post on their twitter yet. :(

Eric

Ecentral
07-03-09, 10:27 AM
Authnet is working fine on our MM5 stores

Eric
07-03-09, 10:46 AM
From Authnet's Twitter about 7 min ago.

FYI: The Web site at www.authorize.net (http://www.authorize.net/) is not up yet. Access the merchant interface directly at https://account.authorize.net (https://account.authorize.net/). Transactions are up except for Global processing and Concord. No ETA on those, but we are working on in.

Eric

Ksaluzzi
07-03-09, 10:49 AM
Good News. Authorize.net's web admin is working and we are able to process orders via our website and retail store.