While eCommerce has been a standard online for quite some years now, the back-end logic has changed quite a bit to handle how this works. Many of these changes have come about because of security concerns with handling sensitive data (like credit card numbers) and the decreasing costs in real-time credit card processing.

Several years ago, smaller sites couldn't afford the costs associated with integrating their shopping carts into a real-time credit card processing systems. These costs often included a flat monthly fee, a
gateway fee, and per-transaction fees that meant small sites had to do a certain volume of online sales just to break even on merchant fees. So smaller sites would have their shopping carts store the credit card data to be later processed manually and offline through a non-web-based credit card processor, such as a retail key-in terminal.

This method worked alright for businesses doing only a few transactions per month online, but resulted in the need for the customer to have their credit card number communicated directly to the merchant for
manual processing. This usually meant that the credit card number would be stored on the merchant's web-server, and often it wasn't deleted at the completion of the order. In addition, most sites are not built using proper security practices that would prevent someone from acquiring this stored data if the server were compromised.

From this came the requirement from most merchant accounts that credit card data not be stored electronically by the merchant. This almost forced merchants to comply (on a side note, there's no real ability to enforce this), but changing wasn't much of an issue as integrated solutions became less expensive and easier to setup.

For instance, PayPal now provides a basic payment gateway that allows merchants to accept credit cards without the need for a merchant account. No monthly or gateway fees are charged, only a percentage of
the total transaction. This percentage is often higher than other more "professional" methods of accepting payment, but these other methods often include some sort of monthly fees. Even with a higher discount rate, this is often preferable as it removes the liability of the merchant with credit card data security, providing an SSL certificate, and removes the risk associated with a low volume of transactions in the form of "only pay a percentage of what you're paid."

Other integration options exist now for less than previous costs as well. An Authorize.net account, which works completely in the background and your visitors never see it, is about $20/month and ties
in to your existing merchant account. This is a little more difficult to setup, though, as it requires installation of additional libraries on your server, like cURL, and the ability to script in languages like PHP. The benefits of this are very worth it, though, since your site is now instantly made aware of what was purchased and if the credit card was approved. And, it still removes the liability of storing sensitive
customer data.

Nick Coons