In the day and age of “the cloud”, everything seems to be making its way to the browser, and commerce is no exception. More and more companies are making their products and services available online, resulting in many options for us developers. When creating a Drupal site, people can often forget to consider all their site’s requirements and simply choose the most popular e-commerce options. While this may work, poor planning can also cost a company. Let’s look at a few of these examples and how they perform for the many different use cases you can throw at them.
Product Catalogs
The obvious classic example is a site that sells products. If this is you, then you probably want a few nice looking pages listing the products along with some images, some options, maybe reviews, stuff like that. Because this is such a popular problem and has been that way since the 90s, you’ll find that there are many many different solutions for it.
This is also one of the simplest solutions, because all purchases are manual and one-time. If the user’s credit card fails, then just deny the order and tell them that. There is no immediate impact (up-sale and marketing notwithstanding) if the user cancels the account 2 weeks before the next billing period. As a result, this is one of the easiest types of e-commerce to set up.
However, there are complications stemming from the fact that you’re probably shipping actual physical products as opposed to a service or a download, which means you need to worry about things like shipping and returns.
Recurring billing
Maybe you’re selling a service that auto-deducts from your users’ accounts every month. Or maybe your website requires members to pay to get access to premium features. Those two revenue schemes describe a huge pool of businesses, including many of the new stream of SaaS (software as a service) providers.
These systems tend to be a little more complicated than one-time manual ordering. Concerns like credit card expiration, credit card updates, subscription-level changes, free months, refunds, discounts, cancellation policies, and security (storing credit card numbers is a dangerous practice) all suddenly become much larger.
Donations
Many sites, such as charities/nonprofits, accept payments but not in exchange for any goods or services. Because of this, all of the bulk that comes with traditional e-commerce solutions would be unnecessary and only complicate things, and all that’s really needed is a form to let the user enter credit card information and donation amount.
Many others
Those are only three common examples, and don’t even come close to all the reasons business might want or need to accept payments, or things they must consider when doing so. An e-commerce site is often as unique as the business model it follows. For example, any of the following might also apply:
- Product relationships/suggestions (upselling)
- Customized/Personalized products
- Ticketing and unique code generation (for use on different sites/services)
- Discounts, Coupons, and Gift Cards
- Tax calculations and exemptions
- Multiple currency and multilingual support
- Fulfillment and inventory management
- Notifications (both administrative and customer)
- Reporting
- One-step checkout
- Multiple payment methods
- Data Migration (from an existing store or database)
- Integration with non-commerce services (e.g. marketing data collection, newsletters, sharing purchase information on a social network)
The army of e-commerce solutions
The blessing and the curse of this problem is that there are so many different solutions. You can build an e-commerce site completely from scratch (although best security practices would be your biggest time consumer). You can build it in Drupal using Ubercart or Commerce or the Payment API. You can use an e-commerce-tailored CMS like Magento. You can use a hosted service like Shopify. You can host your main site separately and link to an external store like eBay or Amazon... and that’s only a few of the more popular e-commerce solutions!
So how do you choose? It all starts with doing your research. You have a specific set of needs and you want the solution that matches those needs as closely as possible, and the only way to find this is by doing research. Read features lists, try out demos, and ask the opinions of friends who know about this stuff. We can’t tell you what to use, but we can give some pointers about which solutions fits which problems well.
Before talking specifics, in general terms choosing something with a large community tends to be a good decision because communities bring along help, tutorials, sample code, 3rd party modules/plugins and themes, testing, and security auditing, which all come together to provide a huge productivity boost for you.
Using Drupal
Drupal is a popular and well suited solution for the majority of these problems, but it itself presents you with a few options. The three big boys are currently Commerce, Ubercart, and the Payment API. These platforms are constantly evolving, so anything missing from this list could be there tomorrow... and more importantly, YOU could be the one that helps add that functionality!
Ubercart is a feature-packed e-commerce platform, which overtook the Drupal “e-commerce” module during the early days of Drupal 6. Ubercart has a very strong community following, which is the main reason you can do so much with it out-of-the-box. It is most appealing to people that need to focus more on configuration options. There are some deeper concerns regarding how product variations work, however.
The Drupal Commerce module is an evolution of Ubercart for Drupal 7 that’s built to be much more flexible, lightweight, and more “Drupal-ish”, meaning it uses more Drupal core features like fieldable entities as opposed to home-baked solutions. As a result of this, it tends to provide more flexibility and easier modification than Ubercart at the price of getting less out of the box and doing more setup yourself. If you’re after a generic quick-and-easy product catalog then Ubercart might be better suited, but if your needs are a little more unique then Commerce is probably the way to go.
The Payment API, in opposition to both Commerce and Ubercart, is extremely lightweight and only provides some core functionality for accepting payments that you’d need to extend to do anything useful. It tends to be better suited for problems that are either too simple to require Ubercart or Commerce or so unique that Ubercart and Commerce wouldn’t be of much help. For example, a simple paid subscription to a site could be cleanly built using the Payment API without all the bulk that Commerce of Ubercart bring along.
CMS’s built for e-commerce
There are also a small army of CMS’s built specifically for people who need e-commerce sites, such as Magento, LemonStand, and Zen Cart. As you’d imagine, these systems tend to be pretty good at getting you started with product catalogs since that’s exactly what they’re built for. Magento is the most popular, and it’s a robust solution with a ton of features and an easy-to-work-with API.
If you’re after a site that specifically only handles sales and doesn’t require any other features, then this can be a good solution that can get you running quickly. However, it’s important to remember that while it might seem like you’ll never need more than a product catalog on your site, your needs might change in a couple years, and as soon as you want to add a blog or a photo gallery or some videos or an API then you’re probably going to wish you had gone a different route.
Hosted services
SaaS (software as a service) is on the up and up as of late, and e-commerce services are no exception. Hosted solutions like Shopify are increasing in popularity, largely due to the incredible ease of use. There’s no development or setup, you just create an account, add your products, and you have a fully working product catalog.
If the benefit here is in ease of use and setup, then the downsides are a lack of control and extensibility. If you want to add a feature to a Drupal site built on Commerce, you just add it (with a 3rd party module or some custom code), but if you want to add a feature to your hosted e-commerce site, you’re probably completely out of luck. As is the case with CMS’s built for e-commerce, this is probably not a very good long term plan unless you can somehow be absolutely sure that your needs won’t change.
Going custom
If no existing solutions come close to matching your needs (and this is extremely rare but of course happens), then you’re free to build your system from scratch and not use any pre-existing solutions.
However, if this seems like your best option, then beware that the lack of any sort of community is a huge negative here. You’re stuck doing everything yourself which means no help and no 3rd party code among other things. As a result of all of this, you’ll obviously be paying more for a custom built solution since it takes so much more work.
Also, perhaps it’s worth considering extending an existing solution rather than starting from nothing. Drupal for example is extraordinarily flexible and can accommodate just about whatever your specific site requires, and it’s likely that even if you have to do a lot of custom development on top of Drupal, you’re still going to save time over not using Drupal at all, because things like the AJAX framework, many 3rd party modules, the user/permissions/roles and login system, and fieldable entities tend to apply to many different types of apps, even if features like nodes and blocks don’t make as much sense for you.
In conclusion
As is the case with all things development-related, there are a lot of options here, and the best one just depends on your specific needs and desires. Do your research, ask around, try things out, and plan ahead, and building an e-commerce site doesn’t have to be a pain.