5701 Lonetree Blvd.
Rocklin, CA 95765
|
(916) 920-4730 |
Zen cart is a common choice for startup e-commerce sites; unfortunately, once a start-up has a successful e-commerce business, Zen cart brings a great deal of headaches: security risks, performance penalties, and no integration with external fulfillment, warehouse management, supply-chain, CRM etc. Read how we converted a large Zen install into using our custom e-commerce solution.
A Zen Cart based e-commerce customer came to us with a few issues. They had a customized zen cart that prohibited them from upgrading to new versions of Zen cart. So they were routinely seeing attempts to break in to their system on their site logs. On top of the constant attacks, they also had a major performance issue with the site. Whenever they sent out an email campaign to announce sales and offers to their customers, the response from the email campaign will slow down the site to a crawl.
They had to switch to a segmented list using a time delay concept just to keep their site online. This creating marketing complications with coupons and time-sensitive offers. When we audited the site, we discovered various attack packages laid throughout the site as nest-eggs for future attacks. So the customer finally authorized us to replace it and create custom solution that worked seamlessly with their back-office operations.
We routinely migrate customers from Zen cart to a scalable, custom e-commerce solution which provides: security, flexibility and back-office integration with warehouse, fulfillment, supply-chain, forecasting, and CRM applications.
Once Zen cart was out of the way, the e-commerce site went through a complete security audit for PCI DSS compliance and passed after tuning a few small unrelated tools that customer had custom built. The site’s performance was enhanced significantly due to the use of multi-tier caching strategy and the customer immediately created a version 2.0 plan to extend the functionality beyond what we created.
They told us that the successful departure from Zen cart has opened up their idea department again and now they are free to extend their site with new tools and marketing add-ons that were just put on hold due to the security and performance issues with Zen cart. We were glad to see that everyone involved were on the same page and a peaceful life was ahead of us.
Migrating entry-level Zen Cart e-commerce systems to secure, high-performance and expandable custom e-commerce solution with back-office integration is our primary expertise, which we acquired over the last decade of Web development.
We designed the new database for performance and at the same time developed the data archiving strategy that included a MySQL merge engine based table design. This design allows us to automatically isolate read/write traffic such a way that the database actually appears brand-new every archive cycle. This meant the the database operates really efficiently and appears “trimmed” every archive cycle.
We also developed a complete data migration strategy to survive exist Zen cart customers, their order history and products into the new database by writing an incremental migration tool. This tool was run multiple times throughout the iterative development cycles and also run once at the very end to sync up the final remaining data from the then live Zen cart system.
We applied a series of caching technique to speed up the PHP 5 applications that made up the custom e-commerce solution.
To speed up PHP itself we used a commercial op-code caching technique. Typically, when PHP runs an application it compiles the PHP script into an internal byte code. By caching the byte code itself, we eliminate the need for PHP to recompile the same script file again for subsequent requests.
To speed up database access, we used prepared statements which compiles the queries and avoids subsequent query syntax checking and compilation phase and thus speeds up the query run-time. In addition to prepared statements, we deployed a combination of InnoDB, memory, merge tables for frequently accessed data to gain higher performance. We tuned MySQL to run optimally using calculated bufferpool, heap, threads and other related settings.
To avoid database I/O for infrequently changed data such as configuration, product pricing, etc. we deployed an array of memcache servers across all the Web server nodes.
Our customer have thousands of products and therefore the catalog included tens of thousands of images and lots of video clips. We wanted to serve these static contents faster while serving PHP apps also at blazing speed. So we divided up the static content delivery by using a reverse proxy using lighthttpd and let Apache handle the PHP apps.
In a typical e-commerce, the card holder data along with the transaction data is sent to the payment gateway for a approval/denial response. But our analysis shows that our customer would benefit if they created customer profiles for each of their customers on Cybersource end. This way returning customer, which was a great percentage of the entire customer base, would benefit from using same card but without any risk associated on the customer end as the card data will be stored on Cybersource servers. Since VISA itself owns Cybersource, it is likely to have ton more security than most other options.
Since our customer has a high moral code unlike many of the e-tailers, they wanted us to authorize funds for the original order for each customer and then when their back-office confirmed that the order was shipped as expected, they wanted us to do a delayed capture of the funds. Of course, if the back-office system discovered that one or more items are back-ordered and cannot be shipped, they wanted us to inform the customer immediately via email and capture less funds to reflect partial order and capture rest of the funds when the back-order was completed.
We deployed industry-standard PCI compliance monitoring system to ensure that the entire e-commerce system remains under strict PCI compliance. An ever increasing battery of penetration checks are performed routinely to ensure PCI compliance.
We explored customer’s back-office operations and realized that they were using a warehouse management system that had a Java based middle-ware that can communicate with third-party systems using XML documents.
So we developed a batch processing back-end that communicated with the middle-ware in the warehouse using XML documents. Each Web customer was created on their warehouse system and assigned an internal customer ID, this ID was passed on to the Web platform to reference in future communication with the back-office system.
We also sent orders in batch so that our customer had no need to manually enter the order into their warehouse any more. In fact, we handled both invoice status, inventory updates all from the back-office system to the Web via XML. This reduced many duplication of work as Web platform was updated automated from the warehouse back-end.