How Backend Code Describes an Ecommerce Business

The rules and policies of an ecommerce business are reflected in its backend code. Offering free shipping for minimum purchase amounts, as in this example from Adagio Teas, must be written into the code.

In “How Backend Web Applications Power Ecommerce Sites,” my article last month, I addressed web applications and explained how they can dynamically generate pages for your ecommerce store, eliminating having to hand code thousands of pages.

There’s another feature to backend code that’s just as important: business logic.

‘Business Logic’ for Web Applications

Web applications — such as an ecommerce platform — contain business logic, which is just development jargon for programming code that describes the business, its rules, and its processes.

Inside of an application there is code that lets the application run. There’s code that manages data. And there’s code that tells the application what do it with that data. That third item contains the business logic.

What follows are a three examples of business logic for an ecommerce store. These are by no means the only types of business logic — each application and each company will have different business logic.

Example: Free Shipping Limit

Many stores have coupons or discounts for free shipping. This is a simple form of business logic.

1. If an order contains products totaling over $100;
2. Then set the shipping rate to $0;
3. Otherwise, charge $6.95 shipping.

This example of business logic is simple. It’s triggered based on what’s happening in the web application. The customer either does or does not have enough in her cart to get the free shipping.

As a business changes, the free-shipping logic can change. For example, maybe the new policy is to require $150 per order for the free shipping offer. Or, it could be even more complex, such as a $150 minimum purchase and delivery to one of five U.S. states using UPS only.

Example: Cash Payments for Local Customers

An ecommerce merchant recently told me an interesting piece of logic for his business, which sells and ships products nationwide. But for local customers, the business does things differently. During checkout, local customers can choose to pay for the order on delivery and bypass the online payment system entirely.

The business logic for this would be:

1. If a customer is located in these specific zip codes;
2. Then show him an additional payment option called “Pay on Delivery”;
3. If he selects that option, don’t take payment information online;
4. And include the details about his amount due on the order for the delivery driver.

In this case, the standard procedure is to function as a typical ecommerce company, taking online payments and shipping orders. But there is an exception, where local customers can skip paying online and pay in person instead.

This example demonstrates how business logic can vary based on external conditions, such as delivery location.

Example: Automatic Reordering

Another type of business logic is automated processes. For example, a store might have its web application set so when the inventory level of a product dips below 20 units, a new order is automatically placed with the supplier.

The business logic looks like this:

1. If a product has fewer than 20 units in inventory;
2. Then create a new purchase order for 150 units;
3. And send that purchase order to the supplier.

The triggering event in this feature is the inventory level. Nothing happens until the inventory drops below the defined threshold (20), which then creates the cascade of events.

This type of business logic can be difficult to code because of its complexity. But since it is automating manual processes, it can save much time and labor expense. Once the correct thresholds are determined for every product, the application can automatically reorder inventory.

Every Ecommerce Store Has Business Logic

All ecommerce stores, even the most basic ones, have business logic.

Some business logic is universal: how shopping carts work, what an order is, and the types of customer data to collect. These are the minimum set of features to be an ecommerce store.

To these universal features one can add custom configuration details. Sometimes these options must be developed, from scratch. Other times the configuration comes from adding modules to the application, or even turning on (or off) different settings in an administration panel. But the point is that business logic will vary, based on the ecommerce store.

Finally there’s another layer of custom logic, where the entire web application is customized to a business. This could be in the form of an entirely custom-coded platform or a customized open source application. Or the business logic could be achieved through third party apps and vendors that integrate with a merchant’s application.

The More Custom, the More Expensive

Business logic follows from the rules and strategy of a company. The more complex the company, the more complex the business logic.

For web developers, the creation and development of an ecommerce store’s business logic occupies most of the development time, and therefore costs the merchant the most money. Even then, over time the business will likely change, requiring the logic to change, too.