We recommend Internet Explorer set to 1024x768.

© 2004 Brian F. Schreurs
Even we have a disclaimer.

Though this sounds like a simple enough proposition, accepting credit cards online requires three components: a way to tell the merchant what the customer wants (a shopping cart), a way to collect credit card information without exposing the customer to a risk of credit card theft (a secure server), and a way for the merchant to collect the amount due from the credit card company (a merchant service). All three of these components can be set up in-house or farmed out to contract firms. Over the course of operating my own online business, I've tried several combinations.

The easiest solution to implement from the start-up business point of view is a total-package shopping/merchant service. Companies like CCNow will take control of customer transactions, from the moment the customer clicks "buy" to mailing a check of sales receipts to the merchant. In this type of service, the merchant logs certain item information with the provider, such as price and weight. Then the merchant puts a tag on his website that creates a "buy" button that forwards the customer to the provider's secure shopping cart. Immediately, this causes two problems for the customer: he is now on a different website, and the shopping cart looks nothing like the site he was just on. Most customers will press on regardless, but a few will get cold feet and back out. Those that finish the transaction will be able to pay by credit card; the provider will handle charging the card, holding the funds in reserve on behalf of the merchant until the reserve reaches a predetermined dollar amount. Once the fund reaches its limit, the provider mails a check to the merchant.

Other than losing a few people to cold feet, this plan seems quite favorable for the merchant: he sets up a website, punches in a little bit of information for a database, and sits back and waits for the checks to roll in. And for a startup company, it's not a bad way to go. My company operated on a plan like this for two years. The advantages of virtually zero startup costs and very little work are hard to ignore. Yet there are some pitfalls worth noting, pitfalls that ultimately caused my company to move away from this solution.

First, the long-term cost is substantial. While the upfront cost is small, the per-transaction fee is high compared to a more hands-on solution -- approaching 10%. Even the greenest startup business will qualify for a better merchant discount than that -- but of course then the merchant would have to process his own cards. More on that later.

Second, as the merchant doesn't handle the card, he cannot make adjustments to the tab. It's an all-or-nothing deal: accept it all or refund it all. Adjusting shipping charges, or offering a discount to a good customer, are not available options.

Third, as the provider makes its money as a percentage of credit card sales, it's not likely to support other payment options. Mail-in payments, PayPal, or other non-credit-card alternatives will have to be integrated back at the merchant's website, forcing the customer to select a payment method before he's even finished deciding what to buy.

Fourth, depending on an outside provider always opens the possibility of their system going down, leaving customers with a 404 error when they're ready to buy.

PayPal, without a doubt the most familiar credit card processor, solves some of the financial problems by allowing partial refunds and requests for more money, but in turn adds an additional layer to the transaction by requiring membership from both buyer and seller. Their fees are reasonable, and it's always worth accepting and indeed encouraging PayPal use, but the membership requirement precludes it from being a viable single-source solution. Many customers balk at joining a service simply to make a purchase.

After two years, my company grew weary of the non-integrated shopping cart and separate payment paths for separate payment methods. The next step was to bring credit-card processing in-house while still using a contractor to provide the shopping cart. We established a merchant account with our local bank and set up card processing software -- software like PC Authorize that uses a computer and modem in place of the bank's card terminal -- then sought out a shopping cart provider.

Shopping cart providers like Pageville stand up a secure server and handle all transactions. Some use a database to track items for sale, while others rely on code on the merchant's website for all item information. These providers offer varying degrees of look-and-feel integration with the merchant's site, but ultimately everything is hosted on the provider's equipment.

Providers like this typically charge by subscription, so they have no qualms about rigging up nearly any payment method the merchant could ask for. This subscription is usually quite reasonable for the young company; it requires some technical knowledge to configure the cart to work with the merchant website, but certainly it is well within reach of whoever set up the merchant's website to begin with.

Such an arrangement is a viable step for the small but growing online merchant. It has the advantage that the merchant handles the customer's credit card information, making it easy to manually adjust invoices. It allows merchants to accept cards by telephone or mail. And it leaves all the secure-server hassles to someone else.

However, it is not entirely without hazard. Entrusting the shopping cart with a third party leaves the merchant's site open to downtime. It also requires putting full faith in the provider's test regimen -- making sure that the cart actually works for customers. It is critical to test a third-party shopping cart's function using the same operating systems and browsers that the customers are using. Most web logs collect this information.

A few customers with particularly cold feet might also back away from a purchase because the cart address is not the same as the site address.

My company maintained this sort of arrangement for six months, but ultimately decided the hassles of dealing with someone else's shopping cart were little reduced from the hassles of maintaining our own. We moved on.

Bringing the shopping cart in-house introduces a few new challenges. The first is a webhosting upgrade. Because credit cards must be handled on a secure network, the merchant will have to get a secure server. Getting a secure server certified requires a static IP address. Static IP addresses usually cost extra. Tech support to set up a secure zone usually costs extra. The certification definitely costs extra -- starting around $100 for a GeoTrust certificate.

Then, once all that is set up and paid for, there's the cart itself.

Carts vary substantially in cost and complexity. It's possible to find plug-n-play carts that require little more than dropping them on a server, and also carts that require more intense installation but offer nearly unlimited customization and integration. These latter carts, such as MerchantPal, will offer the greatest returns to the merchant with the patience to learn how to make them work.

The complete integration of the cart can be reassuring to skittish customers, and in truth 95% of the work is in the setup phase. Once running properly, it requires no more effort to keep running than a third-party cart. There's just more bills to pay, covering the cart, bandwidth, and secure server requirements. If there's enough traffic on the site, the extra peace of mind of having full control of the cart system may well justify the cost. This in-house integrated cart is the method my company currently uses.

Any of these methods may prove perfectly adequate for an internet-based business, depending on the volume of sales and technical knowledge available on staff. The most important step is to thoroughly evaluate actual needs and select the combination that makes the most business sense. These experiences with different cart strategies should help with that evaluation. Good luck.