SSL vs authorize.net???

[SgtPepper]

I have a question regarding SSL and authorize.net for Zen Cart. (I'm a fairly experienced web developer however I've somehow never actually setup an e-commerce's security and payment processing so I'm green on this bit)

My client currently uses authorize.net, and I'm moving their site over to godaddy's servers. Do I need to purchase SSL for the new godaddy account or does authorize.net cover the SSL? Can I just leave the authorize.net info in the "Payments Module" as it is now, and that enables everything including the SSL? Or is there more I need to do?

Also, does authorize.net allow for two sites to be run off the same account? Or does an additional account need to be set up for that?

Thanks!!

[Kim]

Before moving the site may I suggest you do a search for the host on the forum and see what others have experienced?

[Merlinpa1969]

Yes an SSL is required,
yes you can run more than one site off an account
best of luck with godaddy and anything that requires cURL

[SgtPepper]

Thanks guys.

I'll continue to hope that godaddy plays nice with me as they're who my client wants.

[the_ancient]

Thanks guys.

I'll continue to hope that godaddy plays nice with me as they're who my client wants.

as the developer it is your JOB to not only build the site but educate your client on the development process, if godaddy will not support common and REQUIRED features like cURL, then you client needs to be educated on why godaddy is a bad choice (as well as a bad name)

[rtw819]

I'll continue to hope that godaddy plays nice with me as they're who my client wants.

Hi SgtPepper,

For what it's worth, we've been running a production cart site for years on GoDaddy's Economy shared linux hosting, using PHP-based cURL strangely with no significant issues (though using a different SSL payment module). Perhaps we are an exception to the norm.

Be sure to set your cURL proxy: http://proxy.shr.secureserver.net:3128

I did also have to bump our cURL timeout to 30 seconds since the default of 8 seconds or whatever had proven to be too tight for both the proxy connection and transactions, which (either) can be a little slow at times. You may want to look at adjusting this timeout value to suit as well.

A lot of the payment module operational concerns also depend on how the modules handle (and report) any cURL responses and/or error messages to the End User (and Admin for that matter). While I haven't looked at the Authorize.net mod specifically, having written a couple of other payment modules, a little bit of good error checking and reporting goes a long way.

Hope this helps some.

[SgtPepper]

Thanks rtw819. I've actually had a great track record with godaddy in the years that I've used them and I certainly hope my Zen Cart experience there is similar to yours, despite everything I've read here on the forums in months past. And if not, the picture will become clear to my client and the site will move elsewhere, heh, ces't la vie.

[the_ancient]

Be sure to set your cURL proxy: http://proxy.shr.secureserver.net:3128

.

I hope you mean httpS://proxy.......

[rtw819]

Well, the Proxy Server actually handles the request for the HTTP CONNECT to the SSL port (443) of the processor's web site where the SSL negotiation proceeds, and the data passing _through_ the proxy to the credit card processor is encrypted.

The important HTTPS entry is in the Credit Card Processor's URL setting. This is where the encryption is truly required. The proxy simply passes the HTTPS requests along through to the processor's web server as encrypted data.

So, since the SSL connection is passed through the proxy inherently, the "https" versus "http" in the PROXY URL itself does not matter (and is not used, although it does work in some cases, it doesn't provide anything additional - a proxy is just a proxy AFAIK).

Hope this makes sense.