7 min read

Shipping

Shipping is a very important aspect of an e-commerce system; without it customers will not accurately know the cost of their order. The only situation where we wouldn’t want to include shipping costs is where we always offer free shipping. However, in that situation, we could either add provisions to ignore shipping costs, or we could set all values to zero, and remove references to shipping costs from the user interface.

Shipping methods

The first requirement to calculate shipping costs is a shipping method. We may wish to offer a number of different shipping methods to our customers, such as standard shipping, next-day shipping, International shipping, and so on.

The system will require a default shipping method, so when the customer visits their basket, they see shipping costs calculated based off the default method. There should be a suitable drop-down list on the basket page containing the list of shipping methods; when this is changed, the costs in the basket should be updated to reflect the selected method.

We should store the following details for each shipping method:

  • An ID number
  • A name for the shipping method
  • If the shipping method is active or not, indicating if it should be selectable by customers
  • If the shipping method is the default method for the store
  • A default shipping cost, this would:
    • Be pre-populated in a suitable field when creating new products; however, when the product is created through the administration interface, we would store the shipping cost for the product with the product.
    • Automatically be assigned to existing products in a store when a new shipping method is created to a store that already contains products.

This could be suitably stored in our database as the following:

Field

Type

Description

ID

Integer, Primary Key, Auto Increment

ID number for the shipping method

Name

Varchar

The name of the shipping method

Active

Boolean

Indicates if the shipping method is active

Default_cost

Float

The default cost for products for this shipping method

This can be represented in the database using the following SQL:

CREATE TABLE `shipping_methods` (
`ID` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`name` VARCHAR( 50 ) NOT NULL ,
`active` BOOL NOT NULL ,
`is_default` BOOL NOT NULL ,
`default_cost` DOUBLE NOT NULL ,
INDEX ( `active` , `is_default` )
) ENGINE = INNODB COMMENT = 'Shipping methods';

Shipping costs

There are several different ways to calculate the costs of shipping products to customers:

  • We could associate a cost to each product for each shipping method we have in our store
  • We could associate costs for each shipping method to ranges of weights, and either charge the customer based on the weight-based shipping cost for each product combined, or based on the combined weight of the order
  • We could base the cost on the customer’s delivery address

The exact methods used, and the way they are used, depends on the exact nature of the store, as there are implications to these methods. If we were to use location-based shipping cost calculations, then the customer would not be aware of the total cost of their order until they entered their delivery address. There are a few ways this can be avoided: the system could assume a default delivery location and associated costs, and then update the customer’s delivery cost at a later stage. Alternatively, if we enabled delivery methods for different locations or countries, we could associate the appropriate costs to these methods, although this does of course rely on the customer selecting the correct shipping method for their order to be approved; appropriate notifications to the customer would be required to ensure they do select the correct ones.

For this article we will implement:

  • Weight-based shipping costs: Here the cost of shipping is based on the weight of the products.
  • Product-based shipping costs: Here the cost of shipping is set on a per product basis for each product in the customer’s basket.

We will also discuss location-based shipping costs, and look at how we may implement it. To account for international or long-distance shipping, we will use varying shipping methods; perhaps we could use:

  • Shipping within state X.
  • Shipping outside of state X.
  • International shipping. (This could be broken down per continent if we wanted, without imposing on the customer too much.)

Product-based shipping costs

Product-based shipping costs would simply require each product to have a shipping cost associated to it for each shipping method in the store. As discussed earlier, when a new method is added to an existing store, a default value will initially be used, so in theory the administrator only needs to alter products whose shipping costs shouldn’t be the default cost, and when creating new products, the relevant text box for the shipping cost for that method will have the default cost pre-populated.

To facilitate these costs, we need a new table in our database storing:

  • Product IDs
  • Shipping method IDs
  • Shipping costs

The following SQL represents this table in our database:

CREATE TABLE `shipping_costs_product` (
`shipping_id` int(11) NOT NULL, `product_id` int(11) NOT NULL,
`cost` float NOT NULL, PRIMARY KEY (`shipping_id`,`product_id`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;

Weight-based shipping costs

Depending on the store being operated from our framework, we may need to base shipping costs on the weights of products. If a particular courier for a particular shipping method charges based on weights, then there isn’t any point in creating costs for each product for that shipping method. Our framework can calculate the shipping costs based on the weight ranges and costs for the method, and the weight of the product.

Within our database we would need to store:

  • The shipping method in question
  • A lower bound for the product weight, so we know which cost to apply to a product
  • A cost associated for anything between this and the next weight bound

The table below illustrates these fields in our database:

Field

Type

Description

ID

Integer, primary key, Auto Increment

A unique reference for the weight range

Shipping_id

Integer

The shipping method the range applies to

Lower_weight

Float

For working out which products this weight range cost applies to

Cost

Float

The shipping cost for a product of this weight

The following SQL represents this table:

CREATE TABLE `shipping_costs_weight` (
`ID` int(11) NOT NULL auto_increment,
`shipping_id` int(11) NOT NULL,
`lower_weight` float NOT NULL,
`cost` float NOT NULL,
PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

To think about: Location-based shipping costs

One thing we should still think about is location-based shipping costs, and how we may implement this. There are two primary ways in which we can do this:

  • Assign shipping costs or cost surpluses/reductions to delivery addresses (either countries or states) and shipping methods
  • Calculate costs using third-party service APIs

These two methods have one issue, which is why we are not going to implement them—that is the costs are calculated later in the checkout process. We want our customers to be well informed and aware of all of their costs as early as possible.

As mentioned earlier, however, we could get round this by assuming a default delivery location and providing customers with a guideline shipping cost, which would be subject to change based on their delivery address. Alternatively, we could allow customers to select their delivery location region from a drop-down list on the main “shopping basket” page. This way they would know the costs right away.

Regional shipping costs

We could look at storing:

  • Shipping method IDs
  • Region types (states or countries)
  • Region values (an ID corresponding to a list of states or countries)
  • A priority (in some cases, we may need to only consider the state delivery costs, and not country costs; in others cases, it may be the other way around)
  • The associated costs changes (this could be a positive or negative value to be added to a product’s delivery cost, as calculated by the other shipping systems already)

By doing this, we can then combine the delivery address with the products and lookup a price alteration, which is applied to the product’s delivery cost, which has already been calculated. Ideally, we would use all the shipping cost calculation systems discussed, to make something as flexible as possible, based on the needs of a particular product, particular shipping method or courier, or of a particular store or business.

Third-party APIs

The most accurate method of charging delivery costs, encompassing weights and delivery addresses is via APIs provided by couriers themselves, such as UPS. The following web pages may be of reference:

Using such an API, means our shipping cost would be accurate, assuming our weight values were correct for our products, and we would not over or under charge customers for shipping costs. One additional consideration that third-party APIs may require would be dimensions of products, if their costs are also based on product sizes.


Subscribe to the weekly Packt Hub newsletter

* indicates required

LEAVE A REPLY

Please enter your comment!
Please enter your name here