Building a custom ecommerce Website

SHOULD YOU SCRATCH BUILD YOUR NEXT custom ecommerce website PROJECT USING NODE.JS?


Lee Anderson
Monday, January 8 2018

Custom ecommerce websites are big business. With a lot of Wordpress and Magento developers charging in excess of £20,000, there's a huge amount of money can be made installing pre-made code and plugins. If you've ever installed Wordpress, maybe downloaded a cool looking template, you'll know that it's pretty straight forward. Simple to get going, well supported by the community and it can make you and your clients a lot of money. So why would you even consider building your next e-commerce project from scratch? 

After creating and maintaining 3 production commerce websites using NodeJS, I know a few things you should consider before starting, and a few steps to complete if you decide to go ahead and build your own.


SO WHAT'S THE PLAN


Here's how it's gonna go down

1. Should you build custom, or go with off-the-shelf

Is a custom E-commerce website right for your project? What are some questions you should be asking yourself first


2. Plan Your Pages and how you're going to make them

You need a plan for your pages, so here's a few pointers to get you started. You also need to thing about how you're going to generate the content


3. Choosing a Database and Product Schema

The right database can provide speed and functionality that reaches beyond the competition


4. How Customers Buy Stuff

What's the point of all this if customers can't buy anything? We'll go over the process from start to finish


5. Tieing it All together

Let's make this thing live and get some customers!


6. Last Things to Consider

A few add-on ideas to really make your project stand out and increase usability. Some of these ideas can even save your clients money


SHOULD YOU BUILD YOUR OWN custom eCOMMERCE WEBSITE FROM SCRATCH, USING NODEJS, OR ANY OTHER STACK?

I'm gonna start off by saying yes. Everything should be considered when starting a new project. Falling back on a CMS you're familiar with could result in a subpar experience for both you, and your client. Not everybody wants to work with Wordpress and Cube Cart and whilst there's a lot that do - there's definitely companies out there that require something more custom.


If a customer comes to you with a request for something new and different, do you turn to what you know and advise them that it's more secure and robust to use off-the-shelf code, or do you dive in head first and work with them to give them what they need? Maybe they would like something to add on to their existing website, maybe they just want some way for people to quickly buy something off their site rather than a full blown Amazon behemoth. Maybe they're after something so specific, that pre-written packages don't cut the mustard.


There's actually no straight answers here. It's definitely a judgment call based on the customers requirements, skill level and how much you can afford to invest into the project at the time. However, I can recommend at least considering the notion of branching out. How else will the internet move forward? How else will you learn new skills? Are we going to be stuck with a handful of content management systems for the foreseeable future? 


A quick Google shows there's also a number of NodeJS custom commerce website packages too. So there are quite a number of different options available for you to move forward, rather than starting from scratch. This guide will at least give you an idea of how everything should work, but maybe it will light a spark in someone, and show that's it's actually not that difficult to write your own.


But Isn't it a massive task to write one from scratch?

The basic functionality of an ecommerce website is to create an order once payment has been confirmed. That's it. It doesn't matter how that's done, as long as the right information is there so the company can fulfil the orders, and the customers get what they pay for. Sounds simple enough? That's because it is. There's no magical, mystic process needed - just a way for customers to tell the company what they want, where they want it and that they've paid for it. custom ecommerce website basics

So whilst the basic underlying functionality is quite simple, the idea of building a site for a company to run their business on can be quite scary. I'll admit that. There's a lot riding on it for sure, but there's no reason why it has to be more complicated than making a list, paying for it, and creating an order. If you've ever written your own CMS or blog script - it's really no more different than that. It's easier than you might think.


And yes, the project may take longer than you initially estimate - but isn't that true of most projects? There maybe a longer testing phase needed to make sure the checkout process works, but again, it's really no different than other sites you've worked on.


IS A CUSTOM ECOMMERCE webSITE LESS SECURE?

Easy question. No it isn't. Why would it be? The actual basic concepts behind an e-commerce site are very simple, and with third party payment gateways like PayPal, Braintree and services like Barclays EPDQ - pretty much all of the financial security issues can be handed off to companies people trust, and are familiar with. Gone are the days of having to store customer payment details securely, costly PCI DSS qualification and EV SSL certification. As long as a customer can't edit the product information - i.e. standard website security - it'll be fine.


A website that you create yourself will have flaws and bugs, but the chances of someone knowing about them are slim. Nobody's going to start a forum listing exploits for the one or two sites that you create. With well known CMSs, there's a large number of these forums, listing all kinds of vulnerabilities. With a custom site, you can pretty much bypass this issue completely. Also if you keep your code simple, any issues can be quickly rectified with little fuss. A strong testing plan is obviously recommended, as with any production project, so you can go live with confidence, but I'll talk about this more nearer the end.


What if something goes wrong? 

I know this question quite personally. I've pondered on it many times. Dealing with someone else's company and making sure they're not subject to bugs and hacks which could ultimately result in lost revenue is no small matter. What if you introduce a bug which means the orders are lost? What if someone manages to create an order without paying? What if the cart total isn't calculated right? What about delivery charges?!


These questions are things you should be asking yourself. It's quite daunting at first and I think I still ask myself things like this even now - I'd be worried if I didn't. But if you write them down, and plan for them from the beginning, your project will be better in the long run. Plan first, then code. 


ok I think I'm ready, LET'S BEGIN

So you've considered all your options. You've come to the decision that it's best to move forward with a custom e-commerce website, and you're confident with your skills that you can tackle it. I don't claim to be a Javascript genius and I know my code can be simplistic at times, but I do know that I can do it. I'm confident that I can work out any problems without getting in over my head. So unless you're reading this to learn a new skill - for a production site I'd recommend having experience with your chosen stack with at least one other project. Don't learn Node.JS by creating an e-commerce website - there's plenty of easier starter projects to teach you the basics.


Additionally, this isn't a copy/paste guide. I'm going to assume you know enough about coding to get going yourself. Hopefully this should widen the appeal of this article to more than just NodeJS, as there's not many guides like this around. I know because I've looked.


So let's get going...


first step.

plan what you need


Here are some essential pages to get you started building your own custom ecommerce website

1. Editable Homepage

In it's simplest form, the home page should tell potential customers what to expect from the site and a very obvious above the fold call to action. Include company branding and lots of pictures - people are drawn to images first, text later. A more advanced home page will include featured products, promotions and customer reviews. A fully editable home page is very useful for promoting the products featured on the site and keeps it all feeling fresh and new.


2. Product List

This page lists products from a certain category or from search results. It should display a grid or list of sortable products, that is fully s100. Potentially over 50% of the traffic will be from mobile devices, so it's essential that your product list looks great across all devices.


3. Product View

The product view page is where customers will find more information about a product, view images in a gallery and add the item to the cart. The information should be incremental, going from bullet points to more in depth details and descriptions. People want to know they're looking at the right thing before reading more.


4. Cart, Checkout and Payment

The checkout pages on an ecommerce site are extremely important. The customer needs to be clear on what's happening, where they are and what they can expect. There's nothing more off putting than a mass of unexpected forms to fill out. The checkout process should be clear, quick and simple. Include a progress line so people know where they are and a breakdown of what they're paying for to build trust


5. Order list page

Finally the orders need to be listed on a page, so the company can process them. This can be something they print off, or manage on the site itself. Something that is usable by the company is the important thing here.

custom ecommerce website flow

How should you construct these pages?

One steep learning curve with ecommerce websites is SEO. Even if you've done SEO for a blog, or content rich website you still may face challenges you've not come across before. Writing content for a blog is fairly straight forward, it's easy to make it unique and offer something different to your competition, but with an ecommerce website, there's a good chance you'll be selling the same products as other, more established brands. You'll want hundreds, if not thousands of products listed on your site - which makes unique content a daunting task, and generic, pre-written description text more likely.


In spite of this, you can give yourself a boost over the competition - your custom site can be fast. The majority of your competition will using a bloated CMS site, written in PHP and served by Apache. Even if it's a custom CMS, an established site will most likely be using a MySQL backend. It's slow, old and too expensive for the larger sites to even consider upgrading.


Starting from scratch gives you the freedom to use whatever backend database you like. Lightning quick databases like MongoDB and ArangoDB spring to mind. Tie these together with a lightning fast NodeJS service, proxied behind Nginx, and you'll be on your way to a faster front end experience. On average customers give a website 3 seconds to respond before trying something else, a fact that Google is very aware of. Giving yourself a speed boost may help with your page rankings later on. 


Using your awesome skills as a front end dev will help here too. As you're not using Magento, you have full control and freedom over the code on the pages. Don't include unnecessary links to javascript files, keep your code light, images small and process as much as you can server side. Frameworks like Angular and React are pushing the web forward, but until SPA's have proven SEO benefits, it's still recommended to generate simple HTML code on the server, and send it to the browser. 


This is extremely important for the Product List page. It might sound like a good idea to have a product list with instant searches and filtering, but when it comes to ecommerce and SEO, if search engines can't get the information from your SPA, you will lose out on that much needed link juice. Whilst sitemaps and menus help, there's nothing crawlers like more than to parse information from the page and follow the links. A well presented pure HTML Product List will do just that, and your products will be indexed before you know it. This may not be an issue in every case, and hopefully SEO on javascript heavy pages will improve, but this has been my experience of it so far.


Making a wise choice with how you generate your pages at this stage, will give you major benefits. Templeting languages such as EJS and Jade are great examples of how to loop through database results on the server, and present the client with simple static code. I've seen first hand the benefits of this over an Angular front end - going from page 30 to page 2 just by changing to simpler code. What benefit is a funky front end if no-one sees it?


So use a quick back end database to store your product information, a quick server-side rendering framework and Nginx to serve any static content. This will give your custom ecommerce site an upper hand over traditional CMS websites.


Make every page fully s100

With Google moving to a mobile first ethos, it's imperative that every page on your site is s100. It needs to look great on any device it's viewed on, with a consistent experience all the way through from the home page to the checkout. It's not good enough to just give basic functionality to mobile users. In most cases, they will be the majority of your traffic, so a bad mobile experience could cut your sales in half, if not more.


Your product grid is the first thing to tackle with this. Generally a 2 cell per row grid is good for portrait devices, like phones, 3 cell grid for tablets and up to 5 for desktop. Having the option to display products in a list is always a nice option - however the only real reason for doing this, is to get more products in the viewport. If your list view only displays 6 items with loads of horizontal white space, there's little point in having the option over displaying 5 grid items over the 2 rows the customer will be able to see.


Use inline-block grids for best browser compatibility and s100ness. CSS Grid is looking more and more like the best option, however it's good to be mindful of your target audience and what browsers they're using. Using a fancy CSS Grid on a site that sells mobility scooters might cause problems if the older audience is using an outdated version of IE for example. But selling trainers to a younger audience might offer a little more flexibility, as the majority will be using the latest tech. Things like this will get better as time goes on, but the point remains - don't prioritise fancy code over compatibility. When it comes to ecommerce, the simpler everything is, the better.


Choosing the right frameworks and tools is an important part of planning your ecommerce website. It needs to be fast, lightweight and simple to give you an advantage over the clunky competition


SEO on ecommerce websites can be a little tricky, even if you're familiar with SEO already


Using canonical links on your Product List pages helps stop content duplication which can be a major problem when filtering and sorting

choosing the right database and product schema


A custom ecommerce website must be simple to use. Not everyone working in retail has a degree in computer science

Take advantage of modern database tech

Your custom ecommerce site doesn't have to be limited to what people are used to. You've chosen to go custom for a reason - take advantage of speed, new features and better functionality to overtake the competition. There's no reason to go custom if you're just going to replicate an existing way of doing things.


Use Excel to manage and import

A quick way to get started. Using a spreadsheet is something a lot of people are familiar with. It's easy to update, compare data, and using formula is a great way to calculate prices. Things like profit margin and tax can all be worked out on the sheet, rather than on the site itself. A spreadsheet can normally be easily created, either from scratch, or from an export of an existing database. They're easy to import and also create an instant offline backup.


Create custom back office toolS

This is generally the best way to add and maintain products on an ecommerce website, however it can be fairly time consuming. Depending on the customer and size of the project it maybe beneficial however, and produces a more polished final product. Maintenance and ongoing support needs to be considered also.


Future proof your product data

Include fields like MPN, Gtin and EAN numbers to future proof your data and make it easier to lookup product details. They can even be used to lookup product information from APIs and help with SEO. Use Google Merchant field requirements as a template.


Choosing the right database

I have briefly mentioned MongoDB and ArangoDB. If you're not familiar with either of these, I suggest reading up on them. NoSQL and document based databases are, in my opinion, the future of the web. They integrate well with Javascript driven websites, they're fast and easy to work with, however you need to look at your requirements and make sure they're going to work well and scale in the future. Using the newest, fastest tech isn't always going to be the right option.


ArangoDB is my personal favourite. It may not be everyone's first choice - maybe you've never even heard of it, but exploring new tech should be part of your planning. Remember, we're using the custom nature of this project to our advantage - so even using Neo4J's graphing ability might be handy for some. You have the freedom to research and select the right back end system, and then exploit it's features to your advantage. Don't fall back on SQL just because that's what you're used to - there are other options out there. ArangoDB's query language AQL makes it easy to transfer skills from a well learned stack, into something that's new. It provides a lot of the same functionality as SQL, it's ACID complaint and works well with relational data. This isn't an article about Arango however, so I'll leave it up to you to research further.


Obviously, SQL and more established DB's like Postgres may still be the best option. Their proven scalability could be more beneficial if your project needs to expand, or if the website needs something more familiar so it can be better supported. However not every e-commerce site will have the standard product/category schema. An e-commerce site is a way of taking orders online, not necessarily the digital replication of a physical store. A major reason for going custom is because the normal way of doing things doesn't quite work. So explore every option - if what you're used to is the best fit - great! But maybe there's a better way of doing things.


As mentioned above, the functionality of the database can save you time. ArangoDB has a fully featured UI to add, manage and maintain the data. This could be used instead of writing back office tools, which won't be suitable for every use case granted - but we're thinking custom here. We're straying from the norm on purpose.


custom ecommerce website arango


The type of database you choose won't have any impact on financial security either, so don't worry about it being a liability - most of this is handled by the payment gateways. It does have to be consistent, ACID compliant wherever possible, and secure enough that the general public can't change the data however, so keep these things in mind when choosing.


Product SCHEMA

Once your database is up and running, you need to start adding products. There are services available to provide this data for you, if you don't already have it. Companies like Semantics3 and Diffbot offer API's to obtain product descriptions, images and other data. Very useful if you don't have the information or the time to add it yourself. It does cost however, so an ongoing subscription may have to be factored into the price.


As with one project I worked on, these APIs didn't provide enough precise detail that was needed for the website to work. We had to rely on manually copying details from the manufacturers website, to populate the data. If this is relevant for your project, you need to use a tool which makes this process simple. It may mean writing a scraper to parse the information directly off a list of URLs - however we found Excel to be perfect for the job. It provided an offline backup of our data without any additional effort, and writing a CSV parser in Node was simple enough. Meaning the spreadsheets could be quickly imported into the database, updating and adding multiple products in one go. This may seem like a flaky solution compared to writing a full suit of back office tools, but it works very well with the right processes and can be more accessible to retail employees who aren't familiar with custom software.


If you're starting from scratch however, you may need the following fields to be included in your product data. You can start by looking at their field requirements for Google Shopping. Not only will it give you a good starting point, it'll make it easier to integrate with Google Shopping in the future.

This is by no means an exhaustive list, but some fields to consider are:

  • ID
  • Title
  • Category
  • Short Description
  • Long Description
  • Bullet Points
  • Images (recommend 4 images, with compressed variants if possible)
  • Keywords
  • Stock Level
  • Manufacturer Name
  • Product Code (SKU or local stock code)
  • Manufacturer Code (MPN, EAN or Gtin)
  • Dimensions
  • Weight
  • Cost Price
  • Profit Margin
  • Tax
  • Total Cost
  • Delivery Cost
Completing each of these fields for every item is worth it in the long run. You can always add more later, but as a default list, I think this is a good place to start.


If you're not familiar with NoSQL and document based JSON databases, now is a great time to investigate. There's loads of options out there, so use the freedom of your custom site to bring in new functionality and lightning speed

Check the Google Shopping field requirements to base your product schema on

Don't forget about stock levels and have the ability to change them once an order has been placed

So How do customers actually buy stuff?


An Ecommerce site without a checkout process is like shop with no registers. Who wants that?

1. Add an Item to the Cart

The customer clicks the button, and only the item ID is passed to the server. The server then checks the price on the database, calculates the cart total, and adds the item into the cart. The cart is usually a session variable, held only on the server.


2. GOto The Cart

This page manages the cart variable, so the customer can see what they're paying for and how much it will be. The ability to remove and add multiples of an item is useful here


3. Complete The Checkout

To ship the item to the customer, you'll need their name and address. Depending on your payment gateway, the billing and shipping details might need to be the same so form validation is important at this point. Phone numbers and emails are handy too


4. Select Payment method

Display a list of payment gateways like, PayPal, Credit/Debit card, finance and cryptocurrency. The more options you give, the more likely someone will buy. Once they click on a gateway, they will be redirected away from your site to complete the payment authorisation. Generally no money changes hands at this point.


5. Success Confirmation

Once they are redirected back to the site, your server may need to capture the payment and take the money. If this is successful you need to create an order in the database, using the cart and checkout data - and tell the customer the items are on their way. This page is normally the cart page, but without the ability to add/remove the items.

Once the order has been placed, the cart session variable should be cleared and the stock levels updated for each item purchased.


Adding an item to the cart

This step is important for many obvious reasons, however there's a few things you can do to make adding items to the cart simple and secure. But first, why do we need this step? I think we've all become so accustomed to adding items to a shopping cart online, that it may seem obvious, but if you think about it - what is actually happening here?


The goal is to create a list. A list of items that the customer would like, which will eventually be added to an order that can be processed. Any way of creating this list can be used - it doesn't need to be a green 'Add to Cart' button if your project allows for something different. The customer just needs a simple way to create their list, and move on to pay for it. Again, I'm thinking custom here. We're free to do something new and exciting, what's the use in recreating something we can download for free?


Clearly there's a benefit to having some sort of consistency and having peoples expectations work for you. I'm just reiterating the fact that one of the reasons you chose to go custom, is for the freedom it provides. So if you can, go wild. Let's move forward into the future and create something better than the competition. Saying all that... I'm going to go back to the boring old 'Add to Cart' button and how it should work, just so I can better explain the example.


So when someone clicks on the button what should it do?


It needs to send the item ID to the server, which stores it somewhere. Sending all the product data from the browser to the server isn't a good idea. You're opening up the opportunity for someone to alter the price of the product, and add it into the cart. However this can be easily avoided by simply sending just the item ID or SKU to the server when the button is clicked. The server can then lookup the item on the database, and add the information to the cart. This way the most up to date price and stock information can be used, rather than relying on hackable data coming from the browser. Never trust the client. Always validate on the server before moving on.


So once you have the correct data for the first item, you can use it to create the cart. You'll most likely want to push the product name, image and price, to an array stored as a session object. You can include other fields, but these will do for now. This creates the first half of the order that you'll create at the end of this process.


So what should the cart OBJECt look like?

It actually doesn't matter too much. The item added by the customer can be pushed to an array, and everything else we need can be stored alongside it. Something simple like this would do to begin with:

cart {

    items:[], // push item data to this array

    billing:{}, // billing address from checkout page

    shipping:{}, // shipping address from checkout page

    sub_total:0,

    tax:0,

    delivery_cost:0,

    delivery_method:'', // log additional data that may be useful

    total:0

}

You may want to think about adding tracking in here too. Things like the external referral page, client IP address, HTML headers or even timestamps are really useful for security screening customers and site performance reports. Google analytics is great in so many ways, but sometimes you may find you need a little more specific detail.


Vouchers are also a large part of e-commerce sites, and should be stored in the cart. If you are adding vouchers, you need to think about how many can be used at once, and the actions they will perform on the cart when someone uses one. Things like 10% off the total, buy one get one free and free delivery are all common promotions that companies like to use, which manipulate different parts of the data stored in the cart. Additionally this may involve a back office tool so the company can manage the vouchers as and when they need them. 


Cart Calculation

Once an item has been added to the cart, a calculation is needed to create the sub_total, tax, delivery, total values, including any vouchers that have been used. This function should be an asynchronous loop which goes through every item in the cart, getting the price, name and stock level from the database, and calculating the totals. It's imperative to only rely on the item ID here as well, and always get the most up to date information from the database directly. Don't rely on any existing data in the cart that's subject to change - it might be out dated. So get the item data from the database when it's added to the cart AND when you're calculating the totals.


For NodeJS, I can recommend using the Async module to loop through the items to query the database. Any kind of asynchronous code will work here however, so if you prefer using function calls or even promises, I'm sure it'll do the same job. Synchronous loops, like standard For Loops can be inconsistent, especially when performing database calls and you may find that it doesn't calculate everything properly. Asynchronous loops will ensure that the next item is processed only when the current query has been completed. We need consistency and robustness here.


Calculation as a function

I can highly recommend building the cart calculation as a function, so you can call it at any time - not just when someone adds a new item. The benefits of this can be extremely useful, and it also mitigates any issues if an item's price has been changed.


One helpful feature of any e-commerce site is to store the cart so it's available the next time the customer uses the site. It makes their life easier and they're more likely to return to your site if they know the items will still be there. This can be done by dumping the cart into the users login data, or even a simple session variable. Either way, the customer will be adding items to the cart, leaving the site and coming back at a later date. During this time, one of the item's price may change or an item may go out of stock - so if they come back and checkout, the website stands a chance of losing money, or not being able to complete the order. 


To bypass this issue, the cart calculation function can also be called when a customer logs in with an old cart, updating all the prices and stock information. It's useful in other situations too, but the idea is to break out the cart calculation function, so you can use it whenever you need to. It's not good enough to only calculate the cart totals once, when an item is added. It needs to be more robust than that.


The Cart Page

This is a fairly simple page, where the contents of the cart object can be viewed and changed if needed. It also serves as a hook to entice people to complete the purchase. Most customers will add items they like to the cart to see how much the total and/or delivery charges will be. Some may be undecided as to whether they're going to purchase from your site, or from another. This page can be used to convince people you're the one to go with - so dangle carrots, show customer reviews, prove to them that they should buy from you.


But in it's simplest - output the cart object to a list on the page, and give the customer a way to add, remove and empty the items. If you can, make the cart page update without refreshing - so when something is removed, the item disappears from the list and updates the cart object on the server, without a reload. Simple thing, but it improves the user experience quite a bit.


Another function of the cart page is to verify how much everything costs. Ensure that your cart calculation discussed previously, is accurate. Any wrong tax or delivery values are going to force the customer elsewhere - there's no room for error here. It should also promote the payment methods that the site accepts, so people know how they can pay for it, and you might want to include a small section with promotional items too. This is also the start of the checkout, so some outline of the whole checkout process is also strongly recommended. If people see that it's just a few simple steps, they're more likely to buy.


Once they're happy with everything, they can move on to the checkout.


The Checkout Page

Once the customer has added everything they want to the cart, and everybody's confident that the prices have been calculated correctly, the next step is to get the billing and shipping information plus any other data needed to fulfil the order. This forms the second part of the order that you'll create at the end of this process.


The checkout page can be a page on it's own, or even underneath the cart. A simple 'scroll down' makes the whole process more streamlined. However you decide to lay it out, the customer needs to be informed of where they are, where they've been and where they're going to go. It's very off putting to be presented with endless forms asking for all kinds of information when you don't know why it's there. 


Everything about the checkout page should be clear and defined - not only will this build confidence, it will allow the customer to give you the information you need. There's always going to be errors with the data supplied by customers, and a complicated checkout process only increases the risk of these errors. Keep it simple, keep it short, but get all the information you need.


Additionally, guest checkout, Paypal express checkout and social media logins can help here. If a customer logs into your site, you can store their checkout information for the next time they buy something. This is great for customer retention - but how annoying is it when you have to register for a website before buying something? Personally I hate it. There's no real need for it either unless you're storing credit card information - but with third party gateways you can simplify the whole process just by allowing guest checkouts. Remember, if you can get all the information you need to fulfil an order during the checkout process, why would someone need to log in? There could be other reasons why you'd want them to sign up, but coming from the view of a customer, I'd just like to buy something and move on.


Social media logins are simple to integrate using the NodeJS Passport module, and can be used to get all the information needed to complete the checkout form. A few clicks and everything could be filled out - score! Paypal express checkout is also similar. The customer logs into Paypal, and all their information can be passed to your server - without needing to complete the checkout page.


However you go about it, once all the information has been attained, the customer can pay.


The Payment Process and Payment Gateways

The payment options are just a simple list of links that redirect the customer to the payment gateway of their choice. Different payment gateways have different ways of working, but it normally works a little like this:


custom ecommerce website payment


Once the customer reaches the payment page, your server may need to contact the payment gateway to setup a payment, and get a redirection URL. This URL can then be used to create a link on the page. The customer clicks the link, and is redirected to the payment gateway where they authorise the transaction. In most cases, no money is transferred at this point, however this may differ depending on who you use. In most cases the redirection is used to get the customer's authorisation for you to take the money.


Once the customer authorises the payment and has been redirected back to your site (normally redirected back to the cart page, or something similar to summarise the order) you need to capture the funds. This completes the payment process and the money will be transferred. To do this, your server will contact the gateway one last time and it should get a 'success' response to indicate that the payment has gone through, and we're good to move on.


Finally creating an order

If everything's ok, you're good to go ahead and dump all the cart data into an order, which can be picked, processed and shipped. It's also a good idea to empty the cart at this point.


All the orders should be displayed on a back office orders page - doesn't need to be fancy, just something that allows the company to pick and ship the orders to the right place. This may involve some sort of printing, so if you haven't already, take a look at setting up a print style sheet. The orders may also include some sort status, so they can be moved to different departments, or just different stages of the fulfilment process. This page is very specific to the company the website is for, so I won't go into too much detail - but remember we're making something custom here, so make it fit into their way of working. They'll be more appreciative of that, than you telling them they'll need to change their processes.

Never send price information when adding to the card. Send the item ID to the server and look up the item details from the database. This ensures that the cart is populated with accurate data, and more importantly, the right price


Create a cart calculation function so it can be called anytime. Calculating the total only when a new product is added can cause major problems


Ensure the checkout process is clear, simple and doesn't ask for unnecessary information. Keep the customer informed about where they are, where they've been and where they're going at all stages

Going Live in 3... 2... 1


We've got this far, now let's tie it all together

1. Products have been added and the Database is stable

You've loaded up the database with products and the data can be queried without the whole thing falling over. The product data is complete and consistent across all products, or products in a certain category.


2. Products are shown correctly on the website

All products are shown in a fully s100 grid, that works on the majority of browsers and the page is generated within 3 seconds. Filtering and sorting options are also available.


3. Customers can view the products

The product view page gives the customer all the information they need to buy the item. Including delivery expectation, payment methods etc. There's a nice gallery for them to get a good look at the item.


4. Add any Legal pages

Customers have legal rights when purchasing things online. Now is the best time to research any existing returns procedures, or even seeking legal advise to create one.


6. Customers can buy the products

They can add to the cart, view/change the cart, add their billing and shipping details and finally pay. This checkout process needs to be extensively tested before going live.


7. The company can process the orders

There's no point in having an e-commerce website if the orders can't be processed. Work with the client, and integrate this step into any existing procedures they might have.




Returns and T&Cs Pages

So as well as the initial pages outlined at the start of this article, you may need a few pages with legal jargon. Customers have legal rights when purchasing items online, and these should be made visible to them. A Returns page protects the customer from problems that may arise. Things like what will happen if an item is faulty, or if the wrong item is shipped out are important to address. The right procedures and information will install trust in the company, and people are more likely to buy.


Terms and Conditions for using the website are important to protect the company. These outline how the website should be used, when a purchase may be cancelled and a what will be done in fraudulent situations. Legal advise is highly recommended for both of these pages. There are generic templates that can be used, but it's extremely important to make sure that these pages are accurate for your project. Legal battles are not something that should arise from a badly worded website.


Extensive Testing

It goes without saying that everything should be tested before going live. The checkout and payment process should be completely free of any bugs most importantly. Here's a checklist of some of the things you should consider:

  • Complete full end to end testing of the checkout process, for each payment gateway. Most gateways have some sort of testing environment where you can pay for an order without any money changing hands. An item should be added to the cart, checkout completed, test payment made and order created. Do it many, many times with different browsers, operating systems and end users.
  • Every category of product or product variation should be tested, from adding to the cart all the way to a successful test payment. If your products have different fields, you need to be sure that missing or incorrect data isn't going to affect the payment process
  • Payment gateways have required fields - ensure EVERY SINGLE product has the correct data for these fields. Things like missing SKU's or descriptions can stop the items being paid for and will result in lost custom
  • Ensure the orders are created every time. A slight typo in your code when the customer returns from the payment gateway may result in the customer paying for an order, but one is never created. Think about how you can mitigate this problem, and ensure that every order is created successfully. This may be creating the order before the customer has paid for it, or some other kind of validation.
  • If the website has different domains, or subdomains do they all work with the payment gateways? It's highly recommended to redirect ALL traffic to 1 domain as soon as the customer gets to the homepage. Generally you can only specify 1 return url on a payment gateway and having a customer return to the site on a different subdomain, may affect cookies or session variables, which WILL result in lost data, and the payment process failing.
  • Does the customer get a confirmation email once the order has been placed? Are they aware of their order ID? Customers WILL ring the company to chase if they don't get this information. It's simple enough to give it to them - don't create unnecessary work by being vague. The more information you can provide to them on the website and via email, the better.
  • Backup the product data and the orders. Think about automating an offsite backup function. Offloading to Dropbox, or another server is a good way to do this.

lAST FEW THINGS TO CONSIDER


Well done if you've got this far! Here's a few other things you may wish to consider

STATIC PAGES

As content is still king for SEO, having the ability to create static pages is highly recommended. This may be a simple blog tagged on in someway, or even hand written HTML - either way, having the ability to do promotional, support and information pages only adds to the credibility of your site. This also ties in with the editable home page mentioned at the start.


Image compression

Having a handy imagemagick bash script available to compress images as they're uploaded, or in a batch is also very useful. You can run it manually, or call it whenever you like, but as you'll likely have a stupid number of images to manage, it helps to automate the task. Not only does it create consistent images, it's far quicker than using Photoshop, or an online service. Also having multiple versions of the same image in different sizes is recommended too. Show a thumbnail in any list views, larger pics on the products pages etc. 


Custom Automations

As you've written the website yourself, you'll instantly know how to add on to it. Daily repetitive tasks can be easily automated. Things like clearing down old orders, or even scraping products from a distributor feed to automatically manage stock on the site are possible. It really does open up a lot more opportunities than installing a pre-made CMS.


Mail Server

Using NodeJS and Sendmail, or even something like Exim is also worth considering. It's not easy maintaining an email server, but there are benefits for things like promotions and newsletters, as most third party email hosts won't allow mass mailing.


Social Media Integrations

Have your fancy new e-commerce server automatically tweet new products, or write Facebook posts on featured products. Quite simple to achieve, but it's almost like automatic marketing


I think we're done

This is a very high level guide to building the basics of a commerce website. There maybe more to your project than I've written here, but hopefully it lays down the basic information needed to start planning, or giving a little more insight into how these things work. You will face bugs. It will take longer than you think. You may even scrap it all and install Cube Cart without turning back - but hopefully you'll have learned a few new things along the way. I know I have. 


We've been through the pages you'll need and how to create them. Database choices and how to take advantage of the custom nature of your website. How customers can actually buy things, and generate orders, plus a few little things to keep in mind whilst testing. It's by no means an exhaustive list, but it's definitely the stepping stone to get your project off the ground.    

Thanks for reading my guide on building a custom e-commerce website. If there's anything that I've missed, or anything you'd like to see on here, please feel free to contact me.

Home
About Me
Packages and Pricing
Contact Me
All Site Content
moc.ytilaerdemrofer@eel  
leeanderson.web.design  
l33103