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.
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 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. Sigue leyendo