1. How does accepting credit cards work?
This is going to take some explaining…
In a Nutshell
There are many different ways to configure an online e-commerce system, but the most common way is to utilize a payment gateway system. The main thing you need to know is that, while you could easily create an online payment form that collects credit card information and relays it through your website and to you, that approach would not provide the level of security that you need to offer customers in order to safely conduct business with them on the web. A payment gateway serves as an intermediary between your customers and your website, taking care of approving credit card transactions and capturing funds without interrupting the user experience unique to your website.
When users complete and submit payment forms on secure websites, the sensitive information they've included—specifically, their credit card type, number, CVC (card verification code) and expiration date—is encrypted (more on this later) and relayed to the payment gateway, which then approves (or denies) the transaction and captures the funds. This all happens in the blink of an eye, between when the user clicks "Submit" and then sees the screen confirming their purchase.
- A user fills out a payment form on your website and hits "Submit."
- Because the website is using SSL (secure socket layer)—its address should begin with https://—the user's browser will encrypt this information before passing it over to your website.
- Your website then passes over the encrypted order to their payment gateway.
- The payment gateway then passes the order details to your merchant account's payment processor.
- The user's credit card issuing bank then receives an authorization request from your merchant account's payment processor and will respond with a code either approving or declining the transaction, as well as indicating the reason for the decline (e.g. "the credit card number is invalid," "the credit card has expired," etc.).
- Your merchant account payment processor then relays this response to your payment gateway.
- The payment gateway receives the response and forwards it back to your website, which will process it and display the relevant message to the user (e.g. "Thank you for your purchase," or "Your purchase could not be completed…").
This entire process takes about two seconds.
You can configure your payment gateway to either accrue all transactions into a list which can be batch processed to capture funds and relay them to your bank, or you can instead have your payment gateway capture each payment at the time of the transaction. It's up to you. There are definitely pros and cons to each approach, which I'm happy to discuss in detail in the comments if you're interested.
[Update: Smashing Magazine has just published a helpful article explaining how to get started using the PayPal API.]
2. Instead of building something custom, are there third-party shopping cart tools I can use?
Absolutely, but, like any low-cost tool created for a wide audience, it might do most of what you need it to do pretty well, but struggle with the rest—if not leave it out entirely. For very simple online stores, a basic tool that can be inexpensively plugged-in might work just fine (check with your developer to make sure there are no technical barriers). But my experience has been that no two online stores are alike, especially when you get down to real detail. So, do look in to them, but also read on to get a better sense of the complexity of your ecommerce project.
3. Can I also let users pay with their PayPal account?
Definitely. This is easiest to enable if you are already using a PayPal product for your payment gateway. In fact, some PayPal gateways require that you offer PayPal as a payment option in addition to major credit cards. For the most part, Paypal's gateway solutions are easily configurable and there are many (maybe too many) different options to fit your needs.
4. Can I connect my online store directly to my existing merchant account?
Probably not. There are actually two issues to parse here:
The first has to do with your existing merchant account. Every business must have a merchant account, which is distinguished from a regular bank account by its ability to accept payments by credit and debit cards. But not all merchant accounts are configured for online commerce. You'll need to get in touch with your bank and verify that your account is qualified for internet transactions.
The second issue has to do with connecting an online store directly with your merchant account. In my answer to the first question, I explained how payment gateways work by acting as a secure intermediary between your website and your merchant account. These gateways protect you and your customers by offering a level of security that most merchants can't offer on their own—your customers from identity theft and other forms of credit card fraud, and you from liability in the event that your customers' credit card information is stolen.
Now, in some instances, the situation can be simplified depending upon the type of payment gateway you decide to use. For example, PayPal offers a particular gateway product called Website Payments Pro, which can be used as both a gateway and a merchant account. For those website owners hoping to pay less in transaction fees (both your gateway and your merchant account will charge you fees per transaction), PayPal's Website Payments Pro can be an attractive option as it can serve as a merchant account as well as a gateway, saving you from paying fees twice. However, there are other limitations to consider which might make this particular gateway less attractive, such as it's transaction limit/pricing scale as well as a lack of recurring payment modules. Another PayPal product, Payflow Pro, is a much more robust gateway solution, but does require a separate merchant account.
5. What else do I need to know about data security?
Earlier, I mentioned SSL. Every ecommerce website needs to have it's own SSL certificate, which validates the security of an HTTPS-based website. Without this certificate in place, users being directed to a secure server would likely be alerted by their browser that the URL cannot be trusted, and would have no way to be sure that their information is protected. SSL certificates require advance registration, a recurring fee, and a unique IP address. There are various types of certificates that offer advanced levels of security—you may have seen some of them in action, they will change the color of your browser bar—which come at a higher cost than standard certificates. Prices vary by the issuing provider, of course.
All online merchants also must be compliant with payment card industry data security standards (PCI compliant). But, PCI compliance is not itself a law. The way this works is that merchants that are not PCI compliant can be subject to fines levied against merchant account holding banks by credit card brands. In turn, the banks can pass those fines on to the merchants themselves. The fines can be anywhere from $5,000-$100,000 per month, which would be world-ending for most online retailers.
The PCI Security Standards Council maintains its own website, which is the best resource available for getting familiar with PCI compliance.
6. Will my online store automatically keep track of all my inventory?
That depends upon whether you are selling products in any other settings. For merchants doing business only through their websites, their content management systems should be the central control point for their inventory. But for larger-scale merchants—those selling products online that are also sold in stores, catalogs, and the like—the online store will only contain a portion of their overall inventory. In cases like these, we've configured websites to run routine database reconciliations with the other points of sale. For instance, a website might run a nightly script that imports product listings from a warehouse database and reconciles them with the inventory available online. This prevents the website—or any other point of sale—from selling a product that is out of stock.
7. Do I have to charge sales tax?
Back in 1992, a Supreme Court decision in the case of Quill Corp. v. North Dakota upheld the limitation of state sales tax requirements to only those vendors that maintain a physical presence (a store, business office, or warehouse) within that state. What this means is that an online store—what they classify as "remote sales"—run by a company that also has a physical store in the state of New Jersey must charge any online customer residing in New Jersey the state sales tax—7%, in case you were wondering. But, a customer residing in Massachusetts who orders the same product would be exempt from paying sales tax on it. That is, unless the online retailer also had a physical presence in Massachusetts. I know, it's all very confusing.
To make matters worse, this could change at some point in the future. In the 1992 Quill decision, the court specified that only the U.S. Congress has the authority to enact interstate taxes. Since then, 44 states, as well as the District of Columbia, have collaborated to produce the Streamlined Sales and Use Tax Agreement, which reorganizes and unifies sales tax laws and, as of 2010, was entered into legislation by 24 states. But only Congress can apply this new agreement to remote sales. As far as I know, there's no serious push to do this right now.
8. How do I make sure I'm charging enough for shipping?
And you thought sales tax was confusing? I'll be frank with you: Calculating shipping can be a major pain in the neck.
The first thing you need to do is decide which shipping methods (e.g. USPS, UPS, FedEx, etc.) you will offer to your customers. Each of these offer configurable calculation tools that your website can integrate with in order to automatically calculate shipping cost and time estimates for your customers when they are checking out.
In very simple situations—like stores that only offer one product—this could be pretty straightforward. But even with one product, things can get tricky very quickly, say if a customer orders 10 of them. Let's say you're selling a book on your website. You know your book weighs roughly 1 pound, so you're able to use the USPS API to offer various shipping methods (e.g. Media, Priority, etc.) and easily calculate the cost and provide an estimated delivery date. But multiplying that cost by 10 for a customer that buys 10 books may not be the best approach. After all, it's unlikely you're going to ship each book individually. One box with 10 tightly packed books may cost less than 10 individual parcels. Just something to consider when you're selecting the shipping methods you want to offer…
The same principle applies to stores that sell multiple products. While it's simple to calculate the shipping cost of one widget, it's more difficult to figure out the shipping cost for a customer that buys one widget, its accessory case, and a matching paperweight. The larger your inventory, the more combinations there could be. It won't take too many products to make the shipping possibilities very difficult to anticipate in advance. In this scenario, sometimes your best bet is to create a scale based upon various contingencies and build in some room for error. The alternative, only estimating shipping at the time of sale and then charging the final amount once the order has been fully processed and shipped, is not likely to make many customers happy.
It's not that a solid and mostly accurate shipping calculations system can't be built. One certainly can, but it requires the thorough and focused attention of everyone involved in a project and should be an early-stage conversation, not a last-minute detail.
9. How do discount codes work?
This is another one that is pretty much up to you. What's more important is that discounting methods are accounted for in advance.
Discount codes can work in a variety of different ways, depending upon how you plan to offer them to customers. For instance, an ecommerce system can be configured to take at least three different big-picture approaches to discount codes: Codes could (1) swap a discounted price in for the default price at checkout, (2) reduce the price by a percentage at checkout, or (3) deduct a set dollar amount from the total price at checkout. A discounting system could take any of these approaches, or even a mixture of them, depending upon what makes sense for the business. Other factors can also be built in, like routine automation of discount codes so that discounts can have date ranges and even recur on a scheduled basis. Codes could even get as specific as only applying to particular products, product "families," or even combinations of products. Really, there is no end to how complex discounting could be. Of course, the more complex the system is, the more expensive it will be to implement and the more difficult it will be to manage. But if you have the resources—in funding, time and personnel—then the sky's the limit. (Actually, it's not, but you get what I mean.)
10. Can I display different prices for the same product?
Sure. But let's first think about why you might do that.
I've worked with some companies that sell products wholesale to other businesses. In those cases, it made sense to build an ecommerce system that required their business partners to log in to the website before they could see prices or place orders. Once their partners logged in, their user accounts would display prices based upon a price list system that the website owners controlled. Based upon relationships that they'd built over decades, the sales managers could create lists that defined unique prices for products or families of products, and then associate those lists with individual buyer accounts or even groups of buyer accounts, depending upon what made sense to how they operate.
That kind of thing is possible, but it really only makes sense in a situation in which the customer is required to log in to the website in order to see prices. If some other mechanism controlled the display of prices—say geography, time of day, or something like that—it wouldn't be long before the "flexibility" of your prices created enmity between you and your customers. In other words, outside of a wholesale situation or something similar, it's probably a bad idea.
<--- Author Note: Ok, so I lied. There are more than ten things here. Hey, this stuff's complicated! --->
11. Can products be bundled together?
Yes. Though many ecommerce sites are very basic (i.e. a few discreet products) my experience has been that if a pre-existing business is expanding to the web, as opposed to beginning online, it is likely far more complex than that. Many websites have extensive inventory taxonomies, with products being organized into families—from which a customer is unlikely to buy different products—as well as having relationships with other products—like accessories, extension modules, and the like—that are very likely to be purchased by the same customer. In these scenarios, the relationship between the product structure and the website's content management system is critical. The CMS could be configured to enable the user to associate products in ways that alter prices, availability as well as promotions to other products and accessories that display on that product's detail page. Just like I recommended with discounting schemes, the product taxonomy, whether it already exists or needs to created from scratch or amended, needs to be fully planned before any programming takes place.
12. Is there a way to prevent customers from abandoning their shopping carts?
Prevent, no, not absolutely. But there are some things you can do to make it less likely. I'll review a few of them below, but first, I want to recommend against one method in particular: emailing the customer.
Some websites are built to collect email addresses from would-be customers early in the checkout process so that they can trigger an automatic email to that customer if they end up abandoning the cart before completing checkout. Seems like a good idea right? Maybe. I suppose if that customer was having technical difficulties or was confused, it might re-establish what would otherwise have been a successful sale. But if the customer abandoned the cart for other reasons—maybe they weren't ready to buy but wanted to see the final price, or maybe something just rubbed them the wrong way (like having to provide their email address first)—an automatic email isn't likely to do any good. Think about it this way: Let's say you just spent a half an hour browsing your local bookstore. After flipping through a few magazines and checking out that latest Dan Brown novel, you think to yourself, "I think I'll come back another time." As you're heading toward your car in the parking lot, a salesperson catches up to you and says, "Hey, I noticed that you were pretty interested in that issue of Cooks Illustrated and Lost Symbol in paperback. Are you sure you don't want to buy them today?" Right. You were thinking maybe you'd come back another time; now you're thinking maybe not.
But what about making it less likely that someone might abandon their cart for reasons other than that they're just not ready to buy? Here are a few things to think about:
- Preserve the customer's cart. Just because a customer abandons her cart doesn't mean you've lost the sale. In fact, plenty of studies have shown that many sales take longer than a day to convert. A perpetual shopping cart, driven by a lightweight cookie that saves the user's session—cart items and all—on your site, can be a service to a customer who needs a little more time to make a final buying decision.
- Don't require so much information from customers. Allowing guest checkout is one way to build trust with an increasingly skeptical customer population. A Forrester Research study showed that 23% of would-be customers will abandon their carts if asked to register before checking out.
- Keep the flow simple. If you can consolidate the various checkout steps to as few clicks and as few screens as possible, you're more likely to preserve the attention and reduce the frustration of customers.
- Offer help. I mentioned that the cart abandonment email functionality might be well received by a customer who had technical trouble or was confused during the checkout process. But why not pre-empt that by offering help before they ditch rather than after? Some websites will offer real-time chat tools that enable customers that need help to have instant message conversations with salespeople. There are all kinds of third-party solutions for this. The only caveat I would offer is that this kind of thing seems to make more sense for products that are highly technical, long-term, or on the more expensive end of things.
13. How much does it cost to set up an online store?
Well, I obviously can't speak for every developer out there, but I can say that for Newfangled, ecommerce will add at least $10k to a project's budget. But really, unless you're planning to use a strict plug-and-play third-party shopping cart, ecommerce is far too complicated to have a set price without knowing more specific details related to all the points on this list. If you need to get a better sense for how much to budget, get in touch with a developer you trust and start working through the details.
But wait, there's (probably) more!
You may be exhausted from reading through this list, but I'm sorry to say that it's by no means exhaustive. The amazing thing about ecommerce projects is that no two are exactly the same. That means that the scope of complexity for any given ecommerce site is pretty hard to nail down exactly without plenty of planning—which really means conversations; a web article on this topic can only go so far. That said, there is of course much more detail on every single point I've made here that you could dig into further. But I hope this serves as a solid primer for anyone anticipating doing an ecommerce project. If you have any questions, feel free to leave them in the comments (or email me) and I'll reply to them to the best of my ability.