eCommerce Demystified – Part 5: Merchant Store

You've decided that you need a complete online store on your own website. That's a big undertaking. In this part of our series, we'll look at what that takes.

But even if you don't want to host a complete online store yourself, this part will begin the discussion of the various components. Much of what we talk about will be applicable in other scenarios.

Overview

In this part, we're going to dig into the Merchant Store scenario (the left-most in our scenario diagram). The distinguishing characteristic of this scenario is that your website is collecting payment card information and interacting directly with the Payment Gateway.

This approach gives the greatest feature flexibility, but requires that you do a full PCI-DSS validation.

In-House or Out-Sourced?

The first decision you'll have to make is who's going to develop your store. If you have no expertise in this area, then the answer is easy—find a web developer to build your store for you.

If you have web development expertise and your eCommerce requirements are simple, you could consider developing your own store. Most eCommerce packages are straightforward to set up if you have some experience and are using standard features.

If your eCommerce requirements are complex, then even if you have web development expertise you probably ought to out-source the job. Your time is better spent running your business rather than learning the ins and outs of eCommerce software.

What Is Required?

The pieces of the total solution are:

• Web server
• eCommerce software
• Secure connection with SSL Certificate
• Payment Gateway
• Merchant Account
• Privacy & Security Policies

We'll assume that you either have a Web server or know how to get one, so we won't cover that here.

In the rest of this installment, we'll briefly cover all of the other aspects.

eCommerce software

Some very large merchants develop their own eCommerce software, but for most of us it makes more sense to use an existing eCommerce software solution.

Criteria

The major criteria in choosing an eCommerce software package are:

• PA-DSS compliance
• Features
• Extensibility
• Cost

Let's look at each of these in turn.

PA-DSS compliance

In an earlier installment, we discussed in some detail the PCI-DSS standards for websites. There are a similar set of standards, the Payment Application Data Security Standard (PA-DSS), for eCommerce software. The PA-DSS applies to any software that stores, transmits or processes payment card data

As of July 1, 2010, Visa International is requiring that all eCommerce software be compliant with the PA-DSS. So, if you want to accept Visa cards, your software will need to comply. Although the other payment card companies do not yet have this strict requirement, it is likely that they will eventually follow suit.

Note that the key word in the requirement is comply. In some cases, software vendors will have had a Qualified Security Assessor (QSA) trained in the PA-DSS assess their software and certify it as compliant. In this case you (the merchant) can simply tell your Acquirer that your software is PA-DSS certified.

But certification is not required. If your software is not certified, then it will be up to you to assure that it is PA-DSS compliant.

Features

When you set out to choose eCommerce software, you should be armed with a list of the features you want. In addition, you should know which features are mandatory and which are simply desirable.

There are a core set of features offered by virtually all eCommerce packages. If your requirements are very simple, then you will likely find many suitable choices.

If your requirements are more complex, then your choice becomes more complicated. Some packages might have all of the features you need. Others might not have the features as standard, but may have options or extensions that provide them. Finally, some may simply not meet your requirements.

If you have requirements that are not supported even as options, then you'll need to look at extensibility.

Extensibility

Suppose that you like or use a particular software package, but need a feature that it does not provide. What do you do then?

Some packages are designed so that they can be extended. This means that you or someone you hire can add new features without changing the base software. This is the ideal scenario, as you have many options for adding the features you need while maintaining the integrity of the underlying eCommerce package.

Other packages are open source, meaning that you have access to the software code. In these cases, you can modify the software to add new features, but at the expense of creating a maintenance burden. You have to re-apply the changes to each new version of the underlying software, or the updates will wipe out your enhancements.

Finally, some packages are proprietary. All changes must be made by the company that provides the package. Clearly, in this case you are dependent on their willingness to do so.

Cost

Cost is one of the more complex considerations when choosing an eCommerce software package. The cost of commercial eCommerce packages varies widely. Further, there are a number of fine free, open-source eCommerce packages.

Interestingly, "more expensive" does not necessarily mean "more feature-rich". In fact, some open-source software is arguably more sophisticated than some commercial software.

What is generally true is that there two things that only come with commercial software:

• PA-DSS Certification
• Support

If you (or your developer) use open-source software, then you will be responsible for both of these. Note that many open-source packages have active forums where you can get advice from other users, but this does not entirely replace a dedicated support organization.

On the other hand, commercial software is often proprietary, meaning that you cannot change or enhance the software yourself.

Although "free" always sounds attractive, you will need to decide for yourself whether the other considerations are more important.

Popular Packages

It's not possible to do a complete survey of eCommerce software packages here. There are hundreds of packages, each with its proponents and detractors. Such a survey could be a whole series of articles in its own right.

Instead, I will highlight a few of the more popular packages so as to give you an idea of what's available.

Magento

Magento is probably the fastest-growing eCommerce solution around. Some of it's strong points are:

• It has lots of features, including more sophisticated capabilities like cross-selling, up-selling, customer reviews, etc.
• There are currently over 2,000 Magento extensions available, so if Magento's many features don't completely meet your requirements, then it's likely that these extensions can fill the gaps.
• It has a clean, modern design, both in the underlying software architecture and the user interface.
• It is open-source, making it straightforward to see exactly what it's doing and develop extensions.
• It's architecture allows developers to extend the functionality without having to change the base Magento software. This means that updates and upgrades will not overwrite your extensions.
• It has good Search Engine Optimization (SEO) features built-in.

There are 3 versions of the Magento software: Enterprise, Professional and Community. The Community version is free and open-source. The Enterprise and Professional versions have more features but are not free. Among the additional features of the Enterprise and Professional versions are PA-DSS certification and support.

There are several points to be aware of when considering Magento:

• Magento's code is very modular, so that it runs much better on a host that has caching (for example, APC) enabled. Most low-end hosting plans are not suitable. If you want maximum performance from a store running on a $5.95/month hosting plan, then Magento is probably not for you.
• There's a fairly steep learning curve for Magento internals. If you need to change Magento or develop extensions, you'll either need to develop that expertise yourself or find someone who already has it.

osCommerce

osCommerce was the most popular eCommerce package before Magento came along, and still has more user's than Magento. So clearly a lot of people have been successful implementing online stores with osCommerce.

That said, there appears to be a definite move away from osCommerce in the developer community. Some of the reasons given are:

• osCommerce is "old and tired". It was developed a long time ago and hasn't been significantly updated in years. It's architecture is considered very outdated.
• Although osCommerce is open-source, so you can make changes to it yourself (or hire someone to do so), the internal architecture is convoluted. This makes development difficult.
• The osCommerce base feature set is limited. You need to install lots of extensions to bring the feature set up to the level that is considered standard for other packages.
• The standard osCommerce user interface is often described as "ugly", and modifying that interface is difficult.
• osCommerce does not have SEO functionality.

osCommerce Off-shoots

osCommerce is open-source, so it's code is available to anyone. A number of groups have taken advantage of this by "branching" off the code (making a complete copy) and developing on top of that code base independently of osCommerce. The best of these seem to be Zen Cart and CRE-Loaded. Zen Cart is open-source, while CRE-Loaded has both open-source and commercial versions.

Both products address many of the deficiencies in osCommerce, and would be worth consideration.

X-Cart

X-Cart is a popular commercial eCommerce solution, with features similar to Zen Cart and CRE-Loaded. The advantages are the benefits that we mentioned earlier—PA-DSS certification and support.

Content Management System (CMS) eCommerce Solutions

Environments that are based on CMS like Drupal or Joomla! require specialized eCommerce implementations, for example Ubercart for Drupal or VirtueMart for Joomla!

Secure Connection with SSL Certificate

Since the customer is going to be entering payment card information on your website, they will want to know that their information is secure. There are two components to establishing this trust:

• A secure connection, using encryption to protect the sensitive data. Browsers indicate whether a connection is secure (for example, using a lock icon), and many users have gotten used to checking for this indication before entering sensitive information.
• Authentication, proving to the user that they are connected to the website they expected.

The connection is made secure using a standard protocol called Secure Socket Layer (SSL). You tell the web server that you want an SSL connection by using a URL with an https:// prefix (rather than http://). Your web server will need to be configured to support SSL. If you are using a hosting service, you will need to make sure that it supports SSL.

The key that's used to encrypt the connection is provided by what's called an SSL Certificate. This is a digital (not physical) certificate that is installed on your web server. When the user requests an SSL connection, the web server sends the information in the certificate to the user's browser.

What's in the certificate? In addition to providing the encryption key, it identifies:

• Who issued the key
• Whom the key is for (that had better be you)
• The domain name it was intended for (that had better match your domain name)
• When the key expires (it had better still be active)

The first item (who issued the key) is critical. Since the whole process depends on the certificate, the user needs to be certain that it was issued by a reputable organization.

There are about 100 or so certificate authorities who are entrusted with creating trusted certificates. Each has what is called a root certificate that can be used to guarantee that your certificate was really created by the organization that it claims created it. Each browser has a database of root certificates. When a user tries to set up a secure connection, their browser validates the SSL certificate using the root certificate of the issuer. If the certificate does not validate, or if any of the information (your organization, your domain name) does not match, then the browser will warn the user that the connection is not secure. At that point, most users will abandon the session.

So you are going to need an SSL Certificate from a certificate authority. Two of the better-known are VeriSign and Thawte, but there are many others. To get one, you will need to go through a process that allows them to validate that you are legitimate. The certificate is also going to cost you at least a few hundred dollars each year.

Some hosting firms advertise that an SSL Certificate is included in the hosting plan. If you're thinking of using one of these, investigate it carefully. This may be a Certificate under the hosting services name instead of yours. The result might be that the hosting service's name shows up on your customer's credit card statement instead of your name. This is potentially confusing and not very professional.

Payment Gateway

As we discussed in an earlier installment, you are almost certainly not going to communicate with directly with your Acquirer. Instead, you will use what is called a Payment Gateway. Your Acquirer will probably have one or more Payment Gateways with whom they partner, and you are probably best served by choosing one of these partners. You may be able to both a Payment Gateway and a Merchant Account bundled together.

The charges will usually be based on what features you choose. They may be calculated as a flat fee, a transaction fee (per-transaction or as a percentage) or both. There can be break points based on volume. In all cases, make sure you understand what you're going to be charged.

All good eCommerce software packages have standard configurations for the most popular Payment Gateways. It's quite likely that you will simply need to enable the right service and enter your specific account information to begin using it.

Merchant Account

As we also discussed in an earlier installment, you will need a Merchant Account from your bank or another financial institution. This allows you to validate payment card transactions and have the payment deposited in your account.

As with the Payment Gateway, make sure that you understand the charges.

Privacy & Security Policies

A Privacy Policy tells the customer what information you are going to collect about them and what you're going to do with it. A Security Policy tells them how you protect their information.

You need to publish both policies, and you need to make sure that you actually live up to what you say. If you do not follow your stated policies, then at a minimum you risk losing credibility. It's even possible that you could face legal action.

Summary and Next Steps

That ends our brief overview of the Merchant Store scenario. In many respects, if you have the resources this approach can give you everything you need, tailored just the way you want. Unfortunately, if you use this approach you are going to have to do a major PCI-DSS compliance assessment and quarterly network scan.

If you're still interested, then I recommend that you:

• Consider a commercial package like Magento Professional that has PA-DSS Certification and support. This minimizes the effort involved in your PCI-DSS self-assessment.
• Make sure that you do not store any cardholder information. This allows you do fill our a SAQ C assessment rather than a SAQ D assessment.

In Part 6, we'll take a look at our next scenario—hosted payment. For many small- and medium-sized merchants, this may be the most promising scenario.

Note: When you're ready, I have the skills to help you implement your online store.

Get a Quote