What exactly is involved with using Authorize.net?

[Zane]

[note] There's no point in beating a dead horse.  I am already aware that using a third party alternative would be much much better.  I simply want to know how it would be done.[/note]

 

I just finished speaking with my client's credit card agent for their bank.  The most information I could get out of her was that a link would be provided to me for the submission of a credit card number.  Where I am drawing a blank is how to go about sending a CC Number securely.

 

Supposedly, I would set up an HTML form asking for all the credentials: Name, Address, CC#, etc...  and send that form information to the authorize.net link I would be given.  If my understanding is correct though, this information would not go straight to authorize.net.  By looking at the output of a trace route (which I have yet to do), I could see every server it goes through to get to authorize.net.  Are all of those servers in between PCI compliant?  Most likely not. 

 

I image I would need an SSL certificate or something that would encrypt the data sent to authorize.net.

 

Does anyone have any background on how this actually works?  I would love to know just for the sake of knowledge.

[ManiacDan]

You usually post an XML document to the payment processor through cURL (or SOAP), which attaches to a secured endpoint.  The SSL cert is done at the authorize.net end, not on your end.

 

 

[btherl]

If you negotiate an SSL connection with the bank's server, then you know the following:

 

1.  You have negotiated the connection with the bank and not someone else (this is based on checking the SSL cert from the bank)

2.  Only you and the bank know how the data is encrypted.

 

It doesn't really matter how many other servers the data goes through to get there because only you and the bank know how that data is encrypted.

 

So if your client also sends the data to you by SSL, there are 3 points at which the data is unencrypted - the client's computer, your server and the bank's server.  The other servers inbetween just get encrypted data.  Is that what you're asking about?

[jcbones]

Authorize.net says it better than I could even begin to explain it.

[smoseley]

FYI: Authnet is great about documentation and code samples.

 

You can download functional PHP snippets here: http://developer.authorize.net/downloads/samplecode

 

You'll probably want AIM.

[ManiacDan]

FYI: Authnet is great about documentation and code samples.

What?  Really?  Since when?  I last used them in...2006, and their documentation was horrendous.  Plus, my favorite part, their XML error messages weren't valid XML, so their responses couldn't be parsed using an XML parser.

[smoseley]

FYI: Authnet is great about documentation and code samples.

What?  Really?  Since when?  I last used them in...2006, and their documentation was horrendous.  Plus, my favorite part, their XML error messages weren't valid XML, so their responses couldn't be parsed using an XML parser.

I'm talking industry-relative, of course.  Having dealt with numerous gateways, Authorize.net has been my best overall experience.  Reading their docs and sample code, it's easy to get an understanding of how their stuff works and develop a working system in hours.  I've spent days, and even weeks, integrating with other gateways due to shoddy documentation.

[ManiacDan]

Paymentech was the easiest for me.  But again that was 6 years ago.

[requinix]

Speaking as someone who's implemented CIM within the last month, the documentation is pretty good but does have some flaws. Found a few typos here and there and the descriptions of some parts are a little vague. Only a couple statements were actually flat-out wrong. Doesn't talk about some of the weird edge cases but I could find most answers elsewhere on the Internet (and the couple others through testing).

Skimming through AIM's docs I expect it to be about the same story. Haven't seen anything for the other APIs.

[xyph]

As everyone else has said, assuming the connection's on over HTTPS/SSL, the nodes don't _really_ matter.

 

Breaking the encryption is pretty unrealistic, especially on such a low-key target.

[Zane]

So, from what I understand from the replies, connecting with Authorize.net is as easy as using their API?  Does that mean that I do not need SSL?

 

Currently, I have something like this.

http://pay.reallycheapfloors.com

 

A user will be given an invoice number via e-mail and then they will use that page.  Without an invoice number, and error will occur and nothing is sent to Authorize.net.

 

As of right now though, I am not connected to Authorize and this page is yet to be implemented.  Currently, all transactions are done over the phone and email.

[ManiacDan]

You will use SSL, but you will not need to purchase an SSL certificate.  Just like you use SSL when you visit amazon.com without buying a cert for your computer.

[Zane]

You will use SSL, but you will not need to purchase an SSL certificate.  Just like you use SSL when you visit amazon.com without buying a cert for your computer.

Ok.  That's what I needed to know.

 

So I don't need to worry about VeriSign or using the HTTPS protocol.  In other words, my url doesn't need to be https://pay.reallycheapfloors.com

That's a load off.

 

Are there any precautions whatsoever I need to worry about?  Or is my next step with Authorize.net..

[ManiacDan]

Well go back a bit.  You don't need to buy an SSL certificate to communicate with AuthorizeNet.  That was your question.  You still need one to accept payment information.  Now you've changed the question to be about communication between you and your users. 

[Zane]

Sorry if I made my question unclear.  My sole question is,  to accept credit card payments, using Authorize.net, do I simply need to include a library provided from the bank... or AuthorizeNet?

You still need one [sSL cert] to accept payment information.

So, if I am not redirecting to a third party "shopping cart" then I will need an SSL certificate?  I was under the impression that I could use my current page, with the API included, and have the user successfully pay simply by hitting the "Make Payment" button... without a Secure Connection.

 

To put this into context, which I hope helps more in understanding my question..

My client does not want his customers to be redirected off of his site.

[ManiacDan]

If the customer stays on the site, that site must be SSL for the payment acceptance screen.  I believe that's federal law.  If it's not, it's just common sense.

[xyph]

If someone's filling out a form with sensitive data, you really want that form's action to start with https://

[Zane]

If someone's filling out a form with sensitive data, you really want that form's action to start with https://

I believe this is solved now.  Thank you all for your contributions.

[smoseley]

If the customer stays on the site, that site must be SSL for the payment acceptance screen.  I believe that's federal law.  If it's not, it's just common sense.

Required for PCI Compliance, which is necessary if you're accepting payments on your site.

 

If you're building the software / system yourself, you'll also want to get it audited for PA-DSS compliance.

 

Basic rules:

[*]Any page that collects transactional information is SSL

[*]Never store CC# or CVV in your database

[*]Encrypt all other CC-related data (address, etc)

[*]Salt your passwords - best to use a hash like Blowfish for added security

 

Cheers.

[Zane]

Ok. I'm pulling my hair out talking to this Merchant Service Provider agent and trying to understand their requirements.  Allow me to explain the environment and perhaps that will help a lot more.  I probably should have done this to begin with.

 

My client is a retail flooring warehouse.  The client already accepts credit card payments through a terminal, much like a convenience store does.  The client uses a Merchant Service Provider known as Capital Bankcard to get the money from the card to their bank.

 

Now that the client wants to accept payments online, they have called their merchant service provider agent to discuss, with me, the best way to implement online credit card payments.  This website does not act as a normal "shopping cart" website.  If a customer wants a certain product, they must call my client (or email) telling them how many feet of which product they want.  When that is done, my client then writes an invoice, scans it, and emails it the customer.  At this point, no payment is made... rather, the client then calls the dealer and makes sure that amount of footage is available.... at which point he asks that the product be put on hold....

 

As of right now, the customers call-in to make their credit card payment over the phone.  Once the customer's payment is accepted, they are emailed another copy of the invoice which says "Paid in full" or something along those lines......making it a receipt.  They are also emailed a reference number telling them where to pickup their product.  The customer is responsible for picking it up  IT IS NOT SHIPPED TO THEM WHATSOEVER.

 

The obvious problem right now, which I am trying to alleviate, is that most customers do not feel comfortable giving their CC info over the phone.  They would much rather enter it on a secure page.  My client refuses to use Paypal because it would charge a fee for handling the credit cards... while they already have a merchant that makes them happier.  I mentioned to the agent that Paypal would most likely be the best option, but saying that was no different than asking a Linux user to create something with an Adobe product......without a virtualbox.

 

The solution in my head right now is to have some sort of gateway that "acts" like a donation page.  This way, there would be no need for SSL bullshit.  The client could simply email them a link to a "donate" page with a fixed amount.  The closest thing to this idea is something called Simple Checkout from Authorize.net. 

http://developer.authorize.net/api/simplecheckout

 

I suppose here in a few minutes I will call Authorize.net and ask them some questions as well.

I hope I explained everything in detail, if not, don't hesitate to ask.  I need all of the guidance I can get.

[Mahngiel]

The solution in my head right now is to have some sort of gateway that "acts" like a donation page.  This way, there would be no need for SSL bullshit.  The client could simply email them a link to a "donate" page with a fixed amount.

 

I have no knowledge to contribute to this this topic (anxious to learn, though), but this is definitely NOT what you want to do. 

 

A) Customers don't want to feel like they're committing fraud by "donating", B) There are tax ramifications for this, C) This is a cop-out, D) This is not a professional solution

[Zane]

There wouldn't be any committing of fraud.  To me, having this landing page for a customer to enter his/her credit card info is no different than the customer calling and giving the info over the phone.  Well, the actual difference would be that the online payment is secured.

 

This is a very simple concept with Paypal, I don't understand why it cannot be done through Authorize.net in the same way.  I found somewhat of a demo here that does near exactly what I want.

http://www.authorizenetdemo.com/simplecheckout/

The price would be variable though.

 

 

I would just like to skip directly to the payment page.. without clicking a buy now button.  It's more of a Pay Now concept. 

[ManiacDan]

The word "donate" has serious tax ramifications, and falsely labeling something as a donation is fraud.  I am not a lawyer, of course, but that's the truth.

 

Now, as for the rest of your idea:

 

If a credit card number goes onto the page, that page must be https.  you must buy an SSL certificate and have a secured server.  That's the law.  Again, not a lawyer. 

 

Your client wants to make an online store which does not handle shipping.  That's fine, hooray, good for them.  That website, if it accepts credit card numbers, has to be secure.

[xyph]

Couldn't you write a cURL that creates a new product for that given invoice through SimpleCheckout, or better yet implement an API if it exists to add the item as the invoice is created?

 

You can then link to a page on your site within the email that contains JavaScript that'll post to the checkout page for the user?

 

I'm not exactly sure how they generate those Buy It Now links, so I can't help beyond that. If I get some time, or someone could point me to a sample account I can throw some code ideas at, I'll hack some solutions towards this problem.

[boompa]

Is this what you want?