Getting Started With E-Commerce: Your Options When Selling Online
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
Take a break with a 3D game built on Netlify!
Start with a free demo —
Check the frontend report!
The world of online sales, whether of products or services, can be daunting at first; the options seem confusing and the information conflicted. Yet as the designer or developer of an online store, you will need to guide your client through the maze of choices in order to get it up and running.
I have developed many e-commerce websites during my career as a Web developer. I’ve used and modified off-the-shelf software and have also developed custom solutions — so I know from experience that there are a number of important questions to answer before presenting possible solutions to a client. Getting all the pertinent information up front is vital if such a project is to run smoothly, and it can save you from delays during the process. It can also help you advise the client on whether they need a full custom cart or an open-source or off-the-shelf product.
Further Reading on SmashingMag:
- How To Use Photos To Sell More Online
- Design To Sell: 8 Useful Tips To Help Your Website Convert
- E-Commerce Copywriting: The Guide to Selling More
- Fundamental Guidelines Of E-Commerce Checkout Design
This article responds to some questions you should be asking of your client before putting together a proposal for the development of an e-commerce website. I’ll explain the most important things to think about in terms of taking payments and credit card security. It should give you enough information to be able to guide your client and to look up more detailed information about the aspects that apply to your particular situation.
What this article doesn’t cover is the design and user experience side of creating an e-commerce website, because gathering this information would normally occur alongside the designing and branding of the website.
What You Need To Know
It is really tempting to select a solution based on something you have used before or perhaps after asking around to see what others recommend. But you can get stuck in a rut this way. Every online business has different needs, so one solution is unlikely to fit all. Before writing any code or trying an off-the-shelf package, you need to ask yourself or your client a few questions:
- What are you selling?
- What shopping functionality should you offer?
- How will you take payment?
- How will items be delivered?
- What reporting and other functionalities are required?
What Are You Selling?
Your online store may be selling physical products that are shipped by the postal service or a courier to the customer after a completed purchase. Or it might be selling products that are delivered electronically, such as e-book downloads, MP3 music or software. Donations and subscriptions are types of transactions to consider as well.
What Shopping Functionality Should You Offer?
Will you be selling a single item, (such as an e-book) or will visitors need to be able to browse and add multiple items to their cart? Are these items associated with distinct options? If you’re selling t-shirts, for example, size and color might be options to include. Are categories needed to make ordering easier? Will a given item be listed in only one category, or could it be found in several? Would the ability to tag items be useful, or the ability to link them to related items (thus allowing the store owner to promote accessories for items that the customer has added to their cart)?
Items on the Hicksmade website can be displayed in categories. (Large view)
Will there be special offers on the website? Standards ones are “Buy one, get one free,” “20% discount,” “two for one” and “buy item x and get item y at half price.” Setting up these kinds of offers can be quite complex if you are developing a custom system; and if you’re buying an off-the-shelf solution for the store, then you’ll need to know whether it supports them.
The devil (and the budget) is in the details. If your client is expecting particular functionality, find out about it now.
Accounts and Tracking Orders
Part of the user experience could include managing an account and tracking orders. Must users create accounts, or is it optional? Can they track their order and watch it move from “processing” to “shipped”? Account functionality must include basic management functions, such as the ability to reset a forgotten password and to update contact details.
How Will You Take Payment?
You’ll likely need to accept credit and debit card payments from customers. There are a number of options that range in complexity and expense.
PayPal
PayPal is a straightforward way to take payments online. The advantages are that creating a PayPal account is easy, it doesn’t require a credit check, and integration can be as simple as hardcoding a button on your page or as involved as full integration. Google Checkout offers a similar service (and a similarly low barrier to entry), as does Amazon (in the US) through Amazon Payments.
Using A Merchant Account
To accept card payments directly, rather than through services like PayPal, you will need an Internet Merchant Account. This enables you to take credit card payments and process the money to your bank account. If you have an existing merchant account for face-to-face or telephone sales, though, you will not be able to use it for online transactions. Internet transactions are riskier. So, to start trading online, you’ll need to contact your bank. The bank will require that you take payments securely, in most circumstances via a payment service provider (or PSP, sometimes called a payment gateway).
What you should definitely not do is store card details in order to enter them in an offline PDQ later. This would be against the terms of the merchant agreement. So, unless you have written permission from your bank saying you are allowed to do this, and you’re complying with the PCI DSS, just don’t.
The Payment Gateway
The purpose of the payment gateway is to take the card payment of your customer, validate the card number and amount and then pass the payment to your bank securely. You can interact with a payment gateway in two ways:
- Via a pay page. The user moves from your website to a secure page on the payment gateway server to enter their details.
- Via API integration. The user enters their card details on your website (on a page with a secure certificate installed, running SSL), and those details are then passed to the gateway. Your website acts as the intermediary; the user is not aware of the bank transaction happening, having seen it only via your website.
The advantage of pay page integration is that your website never touches the card details, so you are not liable for the customer’s security. The most significant disadvantage is that you lose some control over the payment process, because the final step requires gathering all the details to pass to the payment server. In addition, you are often unable to customize the payment screen, even if only to upload a logo.
Store owners are often concerned about this break in the user experience: they fear the user will bail before going to the payment page on WorldPay or another server. But transferring your user to a known banking website where they’ll enter their card details might actually give them confidence in the legitimacy of your website. When I deal with an unknown website (perhaps a small retailer) and it asks me to enter my card details, I immediately worry about how it will handle them. Does the website email my card details in clear text? Will the details be stored in a database somewhere by the website? Even if the page has a secure certificate and checks out, I still have no idea what happens to my details after I hit “Submit” on the form. If the final step of checking out takes me to a known PSP page, then I can be confident that my details are safe and the small website isn’t handling them at all. I trust WorldPay with my details far more than I trust Joe Blogg’s Widget Store.
Another useful argument for using a pay page is that, should there be any changes in card payment regulations, these will be handled by the PSP. For example, 3-D Secure (verified by Visa or MasterCard SecureCode) was instituted recently. It requires that users verify their payment on a page related to their bank before it can be authorized. If you had API integration, you would need to edit your code to ready it for 3-D Secure; whereas on payment page websites, those changes are done by the PSP.
These points have encouraged many website owners to reconsider their reluctance to use a pay page — most realize that being responsible for credit card details is more trouble than it’s worth.
Pay page integration should work with most off-the-shelf software. After payment is made, it typically sends back something that enables your website — which has a script running for this — to identify the user and the transaction and perform any post-purchase processing that may be needed (such as marking an order as “Paid” in the database or giving access to an electronic download).
The advantage of full API integration is that you control the payment process from beginning to end, including the look and feel of the payment pages. However, you are also responsible for the security of the user’s card details, and regulations require that you prove you are following best practices.
PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) is a set of 12 requirements that must by complied with by all businesses that accept credit and debit card payments. This doesn’t just cover online transactions; a street store that takes payments online must also comply with the PCI DSS for both their offline and online payment methods.
If you are just taking online payments via a pay page and do not take, process or store any card details at any time, then you can complete the shortened PCI DSS questionnaire (SAQ A) to confirm that your PSP is PCI DSS-compliant. If you use API integration, then you’ll be need to comply fully with the PCI DSS — even if you do not store the details — including by allowing quarterly security scans that check ongoing compliance. Explaining PCI DSS compliance in detail is beyond the scope of this article, but if you’re involved in a project that takes card details without a pay page, then you should acquaint yourself with it — or take on the services of someone who already knows it.
Storing Card Data
I would strongly advise any designer or developer against storing card data on their website server, even in encrypted form. Storing card data will, of course, require you to comply with the PCI DSS and to maintain a server and network capable of keeping this data safe. If you need the data of card holders for recurring billing, for example, some payment gateways offer data storage services.
If you are considering storing card data only for “one-click” ordering (as Amazon does), please be careful. Do you really want to be liable for your customer’s data? Are you willing to deal with the extra and ongoing expenses that maintaining compliance will require?
Multiple Currencies and Local Taxes
You’ll likely need to account for local taxes or VAT in Europe. Understanding exactly what taxes you need to collect can be difficult enough, but you also need to ensure that your system can process them correctly. For example, my company has a downloadable product, a mini CMS called Perch. Our company is registered in the UK, so we need to collect VAT from UK buyers. We also need to collect VAT from EU (European Union) buyers, unless they have a valid VAT number. If the buyer is outside the EU, then we don’t need to charge VAT. So, our system has to allow for validation of VAT numbers as well as for the correct calculation of price with and without VAT. If you find yourself in a similar situation, then the European VAT Number Validation API (written by Aral Balkan) will be helpful.
Collecting the VAT Number here triggers the VAT Number Validation process so that we can determine whether to charge VAT. (Large view)
Most stores take payment in a single currency. If you want to accept multi-currency payments — that is, allow visitors to select their regional currency, see pricing and make a payment in that currency — you will need to set the desired currencies in your merchant account. Another option is to get an up-to-date exchange rate and display prices in other currencies while accepting payment only in your local currency. You can either update these exchange rates manually or use data from an API to do automatic currency conversions. If the user will be paying in your currency and not theirs, then they will need to understand that the prices displayed are solely informational and that the actual price may differ slightly (owing to fluctuating exchange rates).
What About Delivery?
If you are selling physical items that need to be shipped, you’ll need to charge somehow for the shipping costs and perhaps arrange for order-tracking. Because you’re selling online, you may attract customers from other countries, so you’ll need to decide how to calculate shipping for different destinations. Otherwise, limit potential buyers to people in your country or a small group of countries.
Threadless explains to the user how shipping works and then presents shipping options based on the user’s mailing address. (Large view)
Typically, websites offer free shipping for orders of a certain price or higher. They also typically offer shipping with different carriers, such as by regular post or by priority courier (depending on when the user wants to receive the item). Consider these things when planning your website.
Digital Products
When customers buy a digital item (an e-book, music download or software) they expect to be able to download their item quickly after purchase. For digital products, delivery takes the form of a link or a page in their profile where the product can be downloaded (and a license code issued if required).
Your system will need to be able to secure products prior to download and provide an account — or at least an emailed link — through which the download can be accessed. When selling software, you may also need to generate a product code.
Reporting And Other Functionality
Your client will need to receive and process orders as they come in, and they might also need to mark items as shipped as they are processed. Some form of download to CSV would likely be helpful to allow a mail-merge of data onto address labels, as would the ability to import to an offline accounting system of payment information. Other questions to ask your client are:
- Do you need the system to be linked to any other systems (for example, a system running in a street shop or an accounting package with particular data requirements)?
- Do you need to be able to control stock through the website?
- How do you want to deal with orders that you can only partially fulfill?
- Will the website generate invoices or will this happen offline?
Most successful store owners will want to automate their accounting processes eventually in order to avoid duplicating data when calculating their year-end accounts. Many accounting systems have an API that allow you to send transactions from the store automatically to the accounting package.
Accounting systems with APIs, such as Xero, make it simpler to tie website orders to accounts. (Large view)
Finding Your Solution
With all the above questions answered (in addition to thinking about the design — i.e. the look and feel of the store itself), you are in a position to prepare a solution that suits your client’s needs. Your options are either to develop something yourself (or contract a developer to do so) or to select an off-the-shelf system that meets as many of your needs as possible either on its own or with modifications.
With e-commerce, you can always start small. Begin with a simple solution or a simple payment method, and then move on to more complex solutions as you start to get a return on your investment. Including many features right away is tempting, but your goal is to make money, not to spend it. Testing the water before spending a fortune is perfectly acceptable.
Keep It Simple
First, be sure of your actual needs. For example, if you are selling a single product, then you won’t need a shopping cart; all you’ll need is a way for customers to pay. At the most basic level, this could be a PayPal “Buy Now” button on an HTML page, or your own form that posts the data to a PSP pay page. You could test the waters with PayPal’s “Buy Now” buttons for just a few products, using PayPal as a simple shopping cart.
Online Solutions
If you need more than a few PayPal or Google Checkout buttons but would rather not invest time or money in installing an e-commerce solution, then hosted solutions are available. Selling online becomes more straightforward when someone else worries about the complexities of the cart.
Popular hosted products include Shopify and Foxy Cart. Both of these services allow you to create a store, hosted on their servers, for a monthly fee. Some hosted solutions target a particular market and are therefore more likely to have features that the market wants. A good example of this is Big Cartel, a shopping cart for artists.
The Big Cartel website. (Large view)
There are also specialist services that assist with the delivery of digital purchases such as e-books and software. Fetch is a hosted application that integrates with Shopify and other carts to deliver digital purchases.
You should be able to get up and running quickly with a hosted solution. But hosted solutions come with a few disadvantages: usually a monthly fee, limited customization, and the prospect that users will have to visit three websites to complete their purchase (your website, a hosted cart and a pay page). To keep things simple, though, it can be a great solution, especially in the early stages of a business.
Commercial and Open-Source Products
There is a huge range of off-the-shelf e-commerce products that you can download and install yourself, including plug-ins for CMS systems. When assessing these systems, check each one against your list of essential and ideal features. You don’t want to buy something that isn’t the best fit. Most software will have a demo website set up as a basic installation that you can play with to see what options are available. If you have a comprehensive list, it will be easier to see whether your needs are supported.
The Open Source CMS website has an e-commerce category that allows you to try out a number of open-source systems from one location, including the popular Magento and osCommerce applications.
With a store-bought system, consider whether creating templates or changing the look and feel are feasible. Some systems enforce their website design and thus compromise yours. You should also look at the mark-up generated by the system; will your pages still validate? How accessible and usable will the store be for visitors?
One problem with many popular existing systems is their reliance on JavaScript, both in administration and in the shopping experience. While JavaScript can greatly enhance the user experience, it should only be used as an enhancement. That is, your website should have basic functionality (e.g. purchasing and checking out) without JavaScript, even if the experience is less smooth. The popular Magento Cart requires that users enable JavaScript in order to add products to their cart; an article in the Magento wiki suggests that you display a message asking users to turn on JavaScript. Paul Boag recently wrote an article about Business Catalyst and its lack of support for users without JavaScript.
If you are tied to a particular payment method or PSP, make sure the product supports that method. Also, make sure the product allows you to comply with your local legal and tax requirements.
When assessing a product, find out what support is available. Open-source products might offer a community forum; check that the forum is active and the community helpful. For commercial products, find out what support you can expect after buying a license. Finally, check how frequently the product is upgraded. If the latest version is two years old, newer payment methods might not be supported.
With Trading Eye, you must purchase support credits in order to get product support (Large view)
A Note on Modifying Commercial Products
If you can’t find an off-the-shelf product that meets your needs, it can be very tempting to grab whatever nearly does and start hacking away, trying to force it to fit your requirements. I urge caution when doing this: by modifying the basic source code, you might make the product very difficult to upgrade — because upgrading to a new version could overwrite your changes. Keeping up with security upgrades is also important; a compromise in a widely used system can attack many websites.
Many open-source products have a plug-in architecture that allows supported modifications and additions that can be upgraded. If you decide to modify an existing product, look for one with a good plug-in system and a helpful community. You could even offer your plug-in back to the community when it is ready for those with similar needs.
Developing Your Own Solution
Sometimes the only way to get the features or create the user experience you want is to develop your own solution. In this case, the requirements list that you created earlier will help you develop a specification before starting work or hiring a developer to build the solution for you.
MySoti offers many color options and types and sizes of t-shirts. (Large view)
Custom e-commerce systems are prone to scope creep, because there are so many potential elements of functionality to develop, and clients tend to expect a clone of Amazon! By outlining exactly how shipping, special offers, categorization of offers and so on will work, you keep the client’s expectations and yours in line. A well-built system should be able to extend as time goes on. I encourage clients to develop only what they need to begin, rather than spend a fortune on bells and whistles “just in case.”
“Special offers” is a good example of this. You could develop a system that lets the client create many combinations of special offers, which would require a complex user interface and a lot of logic. But in most cases, the client would use such a system minimally. A lot of time and money would be saved by creating only what is needed, but building it in such a way that it can be modified later if desired.
In Conclusion
I hope this article has clarified some of the technical considerations of developing an e-commerce website. I enjoy e-commerce projects; they’re a great opportunity to help clients develop their businesses online, and it’s nice to see quantifiable results as people start making purchases. When you create a solid set of requirements based on real business needs and match them with great design and care for the user experience, you build a website that increases sales — and you enable another business to grow. That is a satisfying thing to do.
If you have experience developing for e-commerce and have some tips to share, or if you have favorite commercial products, drop a line or two in the comments section.
(al)
