Credit card slamming is the practice of trying hundreds or thousands of card numbers and security code combinations to find the few in the batch that will actually work. I have discussed credit card slamming here and over at the ZenCart forums several times in the past.

The code snippet below can be used in modules/checkout_process.php to automatically log a user out after a set number (6 in the below snippet) of payment attempts.

Place in between this code near the top of the file:

I found six attempts to work well on the sites I implemented on. You do not want to adversely impact normal users but you do want to make it harder on abusers so that they just go away.

BE WARNED

Improper use of this code could prevent anyone from checking out. The two things that will save you when trying this out are:

1. MAKE A BACKUP
2. FULLY TEST BEFORE CALLING IT COMPLETE

Feedback from users prompted me to add an extra column to the report display… the master category. The master_category_id is listed in the products table and is generally the category the product was originally created in (unless changed later). The report won’t show every category a product is listed in if the product has been linked to multiple categories.

Download ZenCart Inventory Report

Thanks to Ron for the donation to help out with these feature additions.

I have a major client whose Authorize.net gateway account gets hit sometimes hundreds of times a day with charge attempts. Most are posted by an automated script from IPs coming out of Indonesia or Eastern Europe in an attempt to find a valid credit card number and security code. Fortunately, it hasn’t cost the client any money directly yet. Out of the thousands of attempts in the last few months only a couple of charges actually captured funds from the stolen card information. All of these were promptly cancelled after review.

In discussions with this client, we came up with the following options. They are listed in order of ease to implement and least impact on legitimate customers.

1. Require only a billing address and plainly state all orders are only shipped to billing address
2. Require card billing address and shipping address to be in same country or deny the order before going to authorize
3. Require all international orders to be Paypal so they can’t automate the whole process (or maybe allow orders from countries with low fraud percentage to use a credit card directly and all others Paypal)
4. Automatically log user out after X failed attempts
5. Automatically block the IP address after X failed attempts for a time period between a few hours to a day or two
6. Match customer’s IP address to billing / shipping country before going to authorize

My thinking is the better methods would include ways of slowing down the requests so that automated script kiddie tools would constantly fail while legitimate users that are just having problems would not be completely prevented from checking out. I also think a more robust system would utilize several layers of protection (same as a multi-layered approach to server security is better in the long run than putting all of your eggs in the single proverbial basket).

Over the course of the next few weeks I will implement some of these options and dream up more if necessary. Stay tuned for updates.

Should your site be experiencing similar issues, contact me to discuss options.

Note

Maxmind supplies a free IP to country database in CSV format along with their commercial IP database products.

Thanks to Ron for posting a bug back on the Zencart forums about my Zencart Inventory Report

Fixed… download… enjoy.

In ZenCart versions immediately prior to 1.3.6 using many of the public side manufacturers functions may produce this error:

The error is caused by a missing database column that was added in the official 1.3.6 release. If upgrade is not immediately possible the following SQL snippet will correct the problem in most cases:

If you are using other product types, some additional UPDATE statements will be required for your new product types.

I found this solution after some searching on the ZenCart forums.

The “killingest” assumptions businesses make revolve around how their customers buy. Suppose you and 99 other people go into an electronics store and purchase the exact same item. That’s 100 sales. But you can probably guess those 100 sales didn’t unfold in the exact same way. No properly-trained sales person would ever use the exact same language or structure the sale the exact same way for every single customer. And yet, ecommerce sites routinely assume one product page is going to meet the needs of all customers interested in that product. Talk about your huge assumptions!

Source: GrokDotCom

How flexible are your sales processes?

Here’s a simple admin report for ZenCart that will generate an inventory report with per product totals and a report total. The report may be paginated or generated over the whole catalog.

The report was created by modifying the ZenCart default Products Viewed report. It was created from the ZenCart v1.2x source but has been installed on v1.3x versions. This is the first release, so any problems please comment below.

In future updates, I would like to allow for CSV export as well as reporting by category.

To install, simply unzip and upload to your main ZenCart install directory.

ZenCart Inventory Report

View all releaseas

One of my client’s ZenCart installs was loading the server down so much to generate sales reports with the Sales Report v1 contribution that the public side was noticeably less responsive for the couple of minutes it took to build the report. The site has been running for over three years and contains 9k orders, so there is a lot of data to weed through even for a weekly report. A quick look at the slow query log listed the following query as the culprit:

Running this query through EXPLAIN shows 20978 rows examined. In this case, thats 20978 rows per day included in the sales report.

The main problem with this query is the ORDER BY clause which cannot utilize an exisiting index. Adding the following index:

limits the rows examined for each query to 68 (results).

This simple change allows the sales report to load in seconds as opposed to minutes with no noticeable lag on the public side.

The create table SQL for the current version of ZenCart (v1.3.5) contains the following index in orders_products_attributes:

This index is used in the query in question. In my tests it was only slightly slower than the single column index above. EXPLAIN showed about 270 rows examined with the two column index on my dataset while the single column index only examined 68 rows.

The ZenCart admin does not allow searching for products by the products_id field. This is the field assigned internally to each product as it is entered by ZenCart itself.

Using the Paypal Session Viewer (updated v2 here) to debug recent Paypal issues for a client, only shows the products_id ordered without any additional product information. To make it easy to find the product in the ZenCart admin from only the products_id make the following hack in admin/includes/modules/category_product_listing.php around line #191:

Before:

After:

You can see the:

added near the bottom of the snippet.

I recently migrated a customer’s ZenCart site to a hosting account with Godaddy.com. The project went smoothly except for the Authorize.net gateway. Trying to process orders, the site timed out on the final order process page.

Godaddy’s support site, some googling and debugging led to this working code to be added to the cURL routine in authorizenet_aim.php.

Links:

• http://www.zen-cart.com/forum/showthread.php?t=39438
• http://help.godaddy.com/article.php?article_id=288&topic_id=&&