We arrive now at the first page the customer sees after leaving the credit card company. This salesorder.php page presents a summary of the approved order (or a "sorry" message on a disapproved order) that the customer can print for reference. Also, since the order has been finalized, a new order number is issued in case the customer wishes to continue shopping.
The main division of the page begins with the page heading and capture of the Approval query string passed from the ordercapture.php page. If the order approval is "True," then begins the process of displaying the order information.
A Connection Object is created for link to the eCommerce.mdb database and an SQL statement is used for retrieving information from the OrderHeader and OrderDetail tables. These sets of records are matched against the order number, which still remains in the $_SESSION[OrderNo] global variable. All information is available, then, for recreating the order, beginning with the billing information extracted from the OrderHeader table.
The small section of code following the opening of the OrderHeader table is noteworthy:
This script checks for an EOF condition on the recordset, meaning that a match is not found for the OrderNo. How can this happen and why check? Well, it can happen if the customer uses the browser's "Back" button to return to the previous page (the confirmation page of the credit card company) and then clicks forward again.
When the present page is loaded the first time to present the sales order, the final section of script re-issues a new order number for the customer (see below). So, if the customer backs up a page and then comes forward again, the order number re-sent by the credit card company won't match the current order number and a script error will be generated. This section of code, then, avoids that problem by redirecting the customer to the home.asp page if no match is found. You can't keep people from using the browser's back button, but you can trap any problems that occur when they move forward.
The script then continues with producing the sales order by displaying the billing information and purchase details.
The formatting of this sales order is similar to that used for the shopping cart display. The script loops through the records extracted from the OrderDetail table, producing a row for each record. As before, each $ItemAmount is calculated, the OrderTotal is accumulated, and the $OrderShipping is computed on the $OrderTotal.
(Again, here is a case where we might think about storing the shipping charge in the OrderHeader record rather than calculating it when the order is produced. At some later date when this order is recreated there will likely be a change in the percentage charge and the order total will be different from what it is today. We won't deal with that issue here.)
Resetting the Order Number
Now, an important part of the processing. This customer's order is finalized, over with, finished, kaput. Therefore, we need to reassign a new OrderNo value in case the customer wishes to continue shopping. It they did so without a new number, then we would end up with duplicate order numbers and create all kinds of havoc in trying to keep customer orders separate. The final processing step on this page, then, is to assign a new number using the same routine we did when the person first arrived at the site and was assigned a random number home.php file.
Everything has come full circle. At this point the former customer is a new customer and can begin the shopping experience from the start.
This pretty much ends discussion about the basic mechanisms for maintaining an on-line eCommerce site. There are, of course, many of features and functionalities that can be added. We'll look at one more--the automatic issuance of e-mail confirmations of orders--on the next page.