However, after an hour or so of emailing the store owner I got a very worried phone call. In short, the bulk price update to had caused all archived order invoices to become incorrect. Why – due to bad database design by the original developer, let me explain.

The web developer had stored the order as you would expect – an order header table, coupled with a order lines table (one record for each order item). All good so far. Where the previous web developer had fallen short is not storing the price at the time of the order, instead simply storing the product id within the order lines table and looking order details via the way of an INNER JOIN – bad move unfortunately. Obviously, in any sort of product price update (as above) all of his historical order information would become null and void. The latter was especially bad in this case, as the store owner pretty much used the list of store orders as base for financial and year end reporting, as the business was pretty small (no Sage then). Explaining the latter to a none technical client is even harder, believe me

To avoid such nightmares never, ever store such information in this manner – always store product details at the time of ordering. Storing products details at this stage will ensure that an order made in 2008 will be correct when viewed even 10 years later when prices will have been updated. So, in the order lines table, as an absolute minimum store the product name, price and any attributes that will affect price – meaning an INNER JOIN with the order header table is not required.

Depending upon your business rules and frequency by which your product information changes, you could also store the product at time of ording, within a product archive table – that stores basic product info. This way, there is the benefit of saving the description the customer saw at time of ordering.

What is descriobed above is basically bog standard when making any ecommerce solution, or even using something bigger like Opencart, but when it is not present, the amount of issues it causes is huge.

Luckily for me (and the store owner) I created a quick backup of the entire store’s database schema and data before making the bulk update, so was able to restore this for the time being. All I have to do now is amened the database design accordingly and alter the way the site stores order information.

So, never ever rely upon relational data, to view and store data that needs to be achived.

For example, let’s say the user can enter a specific coupon code during checkout. You would want to make sure the Paypal transaction has been successful before making the voucher as used, to do this you would need to know what code was entered during checkout. In the following simple example we’ll use the ‘custom’ field variable  – this is an optional field, whereby the the data is never presented to the shopper and can be 256 character long. Whatever is placed in this field before clicking your checkout button will be invisibly sent ot Paypal and posted back to your IPN script (assuming you have youre ‘rm’ or return method set to 2, or ‘POST’). The HTML for the hidden field is very simple:

<input type="hidden" name="custom" value="YOUR CUSTOM INFORMATION HERE">

Now, let’s say when you’re recording all the order information you weant to record the exact coupon code, delivery method id, the method by which the customer found your site (E.g. another id) and referrer id number. For convenience and for the sake of the example, I’ll assume you’ve done all the necessary processing to get your four pieces of information. The code to create our hidden field data is as follows:

/* ...logic to get below variables here! */

$shipping_method_id = '33';
$coupon_code = '45895';
$found_out_method = '9';
$referrer_id = '200';

$custom_info =
                       array(
			'shipping_method_id' => 33,
			'coupon_code'=> 45895 ,
			'found_out_method' => 20 ,
			'referrer_id' => 9
			);

/* Initiase field data and looping variable */
$field_data = NULL;
$i = 0;

/* Loop through info array to build data string */
foreach ($custom_info as $key => $field) {

	$field_data .= $field;
	$i++;

	if ( $i !== count($custom_info)) {
	      $field_data .= '-';
	}

}

/* create the hidden field
generated HTML is <input type="hidden" name="custom" value="33-45895-20-9"> */
echo '<input type="hidden" name="custom" value="'.$field_data.'">' . "\n";

Printing the value of $field data will give you the string ’33-45895-20-9′. This translates to shipping method id 33, coupon code 45895, found out id 20 and referrer id 9. The dash symbol has been used to delimit values for convenience, as we need to split this string up later on.

To process these variables in your IPN script (see the Paypal PHP sample script) you simply use PHP’s explode method to split the data into an array:

/* $_POST['custom'] contains the custom information we initially sent to Paypal */
$data = explode('-',$_POST['custom']);

/* Convert $data array into variables for further processing */
$shipping_method_id = $data[0];
$coupon_code = $data[1];
$found_out_method = $data[2];
$referrer_id = $data[3];

So you’ve now posted a string of custom information to Paypal and got this custom data back via IPN during the transaction processing. Now you have assigned each piece iof the array to a variable, you can easily continue to create your order header and save it to a database.