Ecommerce Applications

When I started working on it, the eTools eStore application was a hastily built shopping cart and check out system, quickly written, few configuration options, and riddled with site-specific logic and hacks. On and off over the course of a year I rewrote the code, converting it from a loose collection of functions held in a library file to a fully object oriented application, capable of being customized on a site-by-site basis without editing the shared code, integration with Authorize.Net and Shopatron, support for UPS and FedEx shipping, the ability to define coupons and gift cards, customizable shipping options (flat rate, various tiered options), and order management and report generation. The store administration is written using HTML, Javascript, JQuery, and AJAX, while the back end uses PHP, MySQL, XML and SOAP.

Estore Administration – When I inherited the eStore code from the previous developer, the administration was little more than a list of orders and a CSV export routine. Store configuration was done by editing the database tables manually. In the months since I have improved the interface dramatically: adding pagination, filtering, searching, and categorization to the order history interface; expanded the reporting abilities; added support for Authorize.Net and Shopatron payment gateways; added an interface for defining several methods of shipping including tiered shipping costs by order quantity, order subtotal, and predefined rates for shipping methods, as well as support for USPS priority shipping, UPS shipping rate referral, and FedEx shipping rate referral; an ability to temporarily change product prices without having to edit the product records (to facilitate sales and specials); and a system for defining, managing, and applying coupons. These improvements, aside from imparting a more professional look and feel, gave our clients much greater control and flexibility with their store configurations, removed the need for the development team to make site-specific modifications to the shared store code, and allowed for future expansion of the store functionality without adversely affecting the stability of the core store code.

Authorize.Net – All in all implementing an Authorize.Net interface is a fairly straight-forward process: once the required data is formatted, a simple cURL routine is all that is needed to send the data to Authorize.Net and retrieve the corresponding response. Writing a working gateway interface proved to be the easiest part of implementing proper Authorize.Net capabilities. I soon realized there was a problem: if a user left the checkout page before the response from Authorize.Net was received, the order could not be finalized because there was no way to know whether or not the user’s credit card was approved. Without the response from Authorize.Net, confirmation emails could not be sent, orders could not be finalized, and reports were inaccurate because orders that showed as settled in Authorize.Net’s merchant interface might show as incomplete in the store reports. The solution to the problem was to send the Authorize.Net processing and order finalization routines into their own process so that, even if the user left the checkout page before the response was received, the response could still be received by the server and the transactions finalized properly. Much of the legacy store code had been written to access a session variable directly in order to identify the order. When the transaction processes were separated into their own process the session variables were lost, which introduced another set of obstacles to what otherwise would have been a fairly straight-forward solution. Much of the legacy code needed to be rewritten to not require the session variables. This actually proved to be a great opportunity to modernize the store code.

UPS, FedEx Rate Request – Of the three major shipping APIs (UPS, FedEx, USPS), UPS’s API was by far the easiest to implement. Their documentation is well-written, uncomplicated, and their XML format simple and clean. Best of all their example code worked and made a very good base from which to create a shipping class. FexEx’s API was not so friendly, their documentation confusing and contradictory, and their sample code did not work at all. My first attempts at writing a FedEx shipping class had to be scrapped until FedEx eventually fixed their API. The UPS shipping class uses XML and cURL. The FedEx shipping class uses SOAP, XML, WSDL, and cURL. Because the XML formats for the APIs are so wildly different, an abstraction layer had to be written so they could be used with a single set of data coming out of the store code.