Handling Credit Card Payments

[RandallK]

I was pretty unhappy with most of the so called 'solutions ' out there that always seemed to limit what you can and can't do with your site. I wanted a fully dynamic, database driven site that functioned in real-time, so I have been constructing it myself in mySQL and PHP.

When it comes to the shopping cart... I really would like to have a 'professional' deal with security and payment processing, and I've been looking at SHOPSITE. Which is a couple of thousand to get installed. I would basically just pass a SKU to them through an 'add-to-cart' button.

Should I give any thought to sending payments to Authorize.net directly (which they have extensive documentation on) or should I just rely on a third party?

Anyone have any thoughts, or perhaps other recommendations aside from SHOPSITE?

Thanks in advance.

[rocknbil]

I've no idea what shopsite is, being a coder I don't dabble much in open source or off the shelf solutions.

I really would like to have a 'professional' deal with security and payment processing

By your mention of Authorize.net, I am guessing you're familiar with the two key elements in processing CC's, your gateway and your merchant account.

Some processors are both the gateway and merchant account in one. In either case, a slick setup is:

- install SSL cert on your site. This allows you to accept the credit card info securely (but not "save" it, see below.)

- When submitted, you do what's called a "silent post" to the gateway using curl or some other method. Basically 1) user submits, 2) using curl you post over SSL to the gateway, 3) you receive a response to the attempted auth/charge, then 4) based on the response, act accordingly (update database, send emails, OR return to form with declined message.)

This has the effect of the user never leaving your site.

Note that at no point do you store credit card information: you just build a string in the format supported by the gateway which includes the CC info, send it to them, and receive a response. Storing credit card info pushes your site up to a higher level of PCI compliance, which, while it can be done, is often not possible in most hosting environments.

You wouldn't have to pass any order information, although you can. Generally all the gateway needs is some form of token identifying your account, the basic CC info, and the total. Some gateways require a .pem, like a miniature SSL cert, as part of the authentication token.

[RandallK]

Interesting. Good info as usual from Rocknbil. ;-)

We have a SSL, Gateway and Processor already set up.

If you wouldn't mind taking a minute to go to the authorize.net developer section and look at 'compare e-commerce API' and let me know what you think. The advanced developer guide has lots of information there... how many security issues are there that I'm not thinking of?

I'm mostly worried about the unknowns unknowns... could I use this method without storing the CC info locally I wonder....

[rocknbil]

Without looking . . . <scratches head> . . . as I recall there are two methods, SIM (used to be Simple Integration Method, now Server, I think) and AIM (Advanced Integration Method.) AIM is the one that uses silent post, whether they've moved that functionality into SIM, I don't know. Once I started working with AIM there's no reason to go with SIM, really.

Security issues . . . don't have an answer, the security is basically on you in what you do to filter input from the form. Once it's submitted, it's done via silent post, behind the scenes. The manuals are pretty explicit about what not to do that could cause security issues.

There is a unique transaction key you set in the Merchant interface. This unique key should be stored in some safe location on your server, extracted only just before you post to A.N., it is the identifier for your account.

You should always do an AVS on any transactions, but "the jury is out" on whether you reject a transaction based on the result. For example, people move without updating their card, it's quite common for the billing address not to match. So if you set it to AVS only in the merchant account, you can lose sales. Some of my clients deal in items good for a gift, it's quite common for someone in NY to send something to someone in CA.

What I/we do is have it do the AVS check, allow failed AVS to pass, but use the returned code on AVS to trigger a warning in our order emails. If the billing and shipping differ greatly or triggers anything suspicious, time for a phone call . . . . unless they are in Nigeria.

[xshadow]

I've been looking at SHOPSITE. Which is a couple of thousand to get installed.

Chances are, for a 'couple of thousand' you could get a fully bespoke system provided by a freelancer from Asia/India etc... with all the features you do and more importantly don't want.

Off the shelf cart services are so generic in terms of features and usability. [For example, its easy to tell when a website is running osCommerce because of its cheap and cheesy interface!]

In terms of payments, often you can use a gateway service that provides an API allowing you to 'pass back' payment details to their servers, without needing an expensive direct integration with the bank or similar organisation. This would allow you to keep customers on your pages without them knowing what's going on in the background.

[RandallK]

The more I got into Authorize.net and the issue of PCI compliance, the more I realized we needed a dedicated professional to handle all the (sometimes evolving) issues. I did go with SHOPSITE, and at least so far it appears to do what I need, with the power to customize the cart to match the look/feel of my site.

Thank you for your advice, I appreciate it.

[jsinger]

Where do you come up with a "couple of thousands" to install Shopsite? Their monthly packages range from $35 to $125. You can buy the software if you prefer.

its easy to tell when a website is running osCommerce because of its cheap and cheesy interface.

True with osCommerce, but almost everything about Shopsite is fully customizable.

[RandallK]

Purchasing the license for SHOPSITE PRO, installed, with service contract is a little more expensive.

Customizing the cart is taking time, but they've basically given every element its own class so its just a matter of making tweaks to the CSS file. I'm very happy so far with what I've been able to accomplish. I think it looks very similar to what I would have done if I'd gone a fully customized route.