Wednesday, September 9, 2009

Is Your Website Credit Card Friendly?

In my last column I discussed the process of credit card enabling your brick-and-mortar business. I pointed out that research has shown that accepting credit cards can help increase revenue and enhance cash flow. I also pointed out that you may have to look beyond your local bank for help in getting things set up. This week we will look at setting up an online payment system for your business website. If you think hooking up a brick-and-mortar location with a credit card system stymies most bankers, try asking them how to do it on your website.

If you'll recall, the question that spurred this topic came from a lady who went to her local bank for help in setting up a credit card acceptance system for her business and her banker wasn't very knowledgeable on the subject. I pointed out that her banker's ignorance of the subject probably wasn't a reflection on his skills as a banker, but a reflection on the compartmentalization of the credit card aspect of banking.

The fact is, most banks can provide you with the merchant account needed to accept credit card payments, but beyond that have little to do with the process. Even larger banks may only have a single person on staff who is tasked as the "credit card expert" and if that person ever goes on vacation, you're pretty much out of luck (voice of experience talking here, folks).

I have helped many clients set up online credit card processing systems and more than once I've had to sit down with the bank issuing the merchant account and educate them on how online payment systems work. Don't believe me? This is a direct quote (here's the Bible, here's my hand) from the bank employee who was in charge of processing internet merchant account applications, "When someone pays online how do they swipe the credit card in their computer…"

Much like a brick and mortar credit card processing system, you will need the following to accept credit cards on your website: (1) an electronic shopping cart system that allows the customer to select products and checkout when ready; (2) a payment gateway service to get approval or declination of the credit card; (3) a credit card processor who will process the transaction; and (4) an internet merchant account issued by an acquiring bank in which processed funds are deposited.

We covered most of these elements last week. Here's a quick refresher for those who missed the basics, then we'll talk about a shopping cart system.

Payment Gateway Service: The payment gateway service comes into play when a customer submits their credit card information to the webpage form. Think of the gateway service as the middleman in the process. The website's shopping cart checkout system electronically submits the credit card to the gateway service who then routes the information to the processor for approval. Depending on the reply from the processor, the gateway service will return an approval or declination for the purchase. This entire process takes just seconds to perform.

Credit Card Processor: The credit card processor is an electronic data center that processes the credit card transactions coming from the gateway company, ensures that the charge is valid, then settles the funds in your merchant account.

Internet Merchant Account: An Internet merchant account is a bank or financial institution account in which funds from online sales are deposited. Merchant accounts are usually issued by banks who are associated with the major credit card services like Visa and MasterCard. Be aware that many banks will not grant merchant accounts to Internet merchants as they are often categorized as "high risk ventures." This policy varies widely and in the end, the granting of the merchant account will come down to economics from the bank's point of view. If the bank sees even the smallest iota of risk, you will not be granted the account. Fortunately, the growth of online sales has given rise to an entire industry of merchant service bureaus that will grant you a merchant account and everything else you need to accept online payments. The fees are usually higher, but it's better than not having an online payment system at all.

Shopping Cart System. To accept online payments you must have what's called a "shopping cart system" that allows your customer to choose and purchase products. Adding a shopping cart system to your website can be simple or complex, cheap or very expensive. It depends on the product you're selling and the options you wish to offer your customers. As in everything, you get what you pay for.

A shopping cart system typically consists of three components: a product catalog, the shopping cart, and a checkout/payment system. The product catalog is your inventory component and displays the items you have for sale on the website. The checkout/payment system is the part of the program that allows your customers to "add this to my cart," and the checkout/ payment system is the component that allows the customer to checkout and pay for their purchase.

There is a wide variety of shopping cart software on the market and the price is dependent on the features you want. Shopping cart systems range from simple HTML form insertions to full- blown catalog and inventory systems like those used by Amazon or Dell.

You can spend from zero to tens of thousands of dollars. Some of them you can set up on your site yourself while others should be set up by someone who knows what they're doing.

You can get a free Paypal.com shopping cart system which is the most simplistic in nature, but the easiest to implement. Using Paypal also alleviates the need for a bank merchant account because everything is handled by Paypal, for a fee of course. You insert HTML forms into your website code and when an item is purchased.

There are also numerous online companies who will assist in the setup of your ecommerce / credit card system. These companies charge several hundred to several thousand dollars for their services, so it would be wise for you to have an idea of exactly what you need before calling them into play.

Customer submits credit card. The site sends the transaction to the gateway. The gateway sends the info to the processor. The processor contacts the issuing bank of the customers credit card. The issuing bank returns the result of the processor. The processor routs the result to the gate. The gateway passes the result to the website. The website displays the result.

One thing to remember when setting up an ecommerce system on your site is this: online it's all about security and privacy. Though online credit card processing has been around for years there are still many people who are uncomfortable giving their credit card number online. These are the same folks that do not hesitate to give their credit card number over the phone to a complete stranger or hand their credit card to a waiter who disappears with it for ten minutes. Online credit card processing is much less susceptible to fraud and abuse than either telephone processing or giving it to a waiter.

Eighty-five percent of internet users surveys said that a lack of security made them uncomfortable sending credit card information over the Web.

It's up to you to instill a sense of security and make the customer comfortable shoving their card into their computer.

Here's to your success.

XHTML - Kicking And Screaming Into The Future

XHTML, the standard, was first released back in 2000. Roughly five years later we begin to see major websites revised to use this standard. Even the favorite whipping boy of standards-compliance punditry, Microsoft, presents their primary homepages, msn.com and microsoft.com in XHTML. Standards compliant XHTML sites are still the minority. The reason is simple. When the W3C released the new standard, the rest of the web running on HTML did not cease to function. Nor will the rest of the web, written in various flavors of HTML, cease to function any time soon. Without any pressing need to conform to the new standard, designers continue to use old, familiar methods. These methods will perform in any modern browser, so why bother switching?

These sentiments are similar to ones I experienced. A kind of "if it's not broke, don't fix it" mentality sets in. Whether HTML was "broken" or not is a different argument. To the casual Internet user, their standards are fairly direct. If a site displays without noticeable error and functions to their satisfaction, these standards are met. Whatever additional steps the browser took to make such display possible is irrelevant to most users. This kind of mentality is difficult to overcome in designers accustomed to their old methods.

Technical obstacles to adopting XHTML may be quite steep as well, especially as regards large, existing websites with complex scripting. Yet the time may eventually come where yesterday's "tried and true" HTML is little more than an ancient language, unable to be interpreted by modern electronic devices. Whether one agrees with the direction the W3C takes in the development of HTML is irrelevant, you are just along for the ride. With some perseverance, getting the hang of XHTML is possible. In form, it is not as different from HTML as Japanese is from English. Knowing HTML grants a basic knowledge of the language, it simply becomes a matter of learning a particular dialect. Even an original nay-sayer such as myself managed to do it.

Benefits of XHTML
There are 2 primary benefits to using XHTML. First is the strict nature of valid XHTML documents. "Valid" documents contain no errors. Documents with no errors can be parsed more easily by a browser. Though the time saved is, admittedly, negligible from the human user's point of view, there is a greater efficiency to the browser's performance. Most modern browsers will function well in what's usually referred to as "quirks" mode, where, in the absence of any on-page information about the kind of HTML they are reading, present a "best guess" rendering of a page. The quirks mode will also forgive many errors in the HTML. Modern browsers installed on your home computer have the luxury of size and power to deal with these errors. When browser technology makes the leap to other appliances it may not have the size and power to be so forgiving. This is where the strict, valid documents demanded by the XHTML standard become important.

The second benefit is in the code itself, which is cleaner and more compact than common, "table" based layout in HTML. Though XHTML retains table functionality, the standard makes clear tables are not to be used for page layout or anything other than displaying data in a tabular format. This is generally the primary obstacle most designers have with moving to XHTML. The manner in which many designers have come to rely on to layout and organize their pages is now taboo. Simple visual inspection of XHTML code reveals how light and efficient it is in comparison to a table based HTML layout. XTHML makes use of Cascading Style Sheets (CSS), which, when called externally, remove virtually all styling information from the XHTML document itself. This creates a document focused solely on content.

XHTML makes use of "div" tags to define content areas. How these "divisions" are displayed is controlled by CSS. This is known as CSS-P, or CSS Positioning. Trading in "table" tags for "divs" can be tough. Learning a new way of accomplishing an already familiar task is generally difficult. Like learning to use a different design program or image editor, frustration can be constant. Looking at "divs" as a kind of table cell might be helpful, though they are not entirely equivalent. As required by the XHTML standard, always make sure there is a DOCTYPE definition at the top of the document. This is not only required by the standard, but it will force Internet Explorer 6, currently the most common browser, to enter its "standards compliance" mode. IE6 and Firefox, both operating in standards compliance mode will display XHTML in much the same way. Not identical, but far better than IE6 operating in quirks mode. Learning how to iron out the final differences between displays is the final obstacle and can require a bit of tweaking in the CSS.

Clean code has multiple benefits. It creates a smaller page size which, over time, can save costs associated with transfer usage. Though the size difference may appear small, for someone running a highly trafficked site, even saving a few kilobytes of size can make a big difference. Further, some believe search engines may look more kindly on standards complaint pages. This is only a theory, though. In a general sense, any page modification that makes the content easier to reach and higher in the code is considered wise. Search engines, so it is believed, prefer to reach content quickly, and give greater weight to the first content they encounter. Using XHTML and "div" layout allows designers to accomplish this task more easily.

Conclusions
XHTML is the current standard set by the W3C. The W3C continues development of XHTML, and XHTML 2.0 will replace the current standard in the future. Learning and using XHTML today will help designers prepare for tomorrow. Valid XTHML produces no errors that might slow down a browser, and the code produced is clean and efficient. This saves in file size and helps designers better accomplish their search engine optimization goals. Learning XHTML is primarily about learning a new way to lay out pages. Though frustrating at first, the long term benefits far outweigh any initial inconvenience.