Giving the right response - AVS and declined card messages

When you integrate a website with a payment gateway, you have to decide what to show your customer when a transaction is declined, or if their card received an AVS or CVV mismatch response. As simple as this may sound, doing it wrong can drastically impact a customer's desire to change their information and try again.

In the past, I have supported giving a visitor a single response for any decline, AVS mismatch, error or otherwise because it eliminated one of the lesser-known types of online fraud. Card testing is not something that should be overlooked, because it can have severe consequences that many business owners are not aware of.

After some long-term observation, I think that there is a better way to handle card testing while increasing the chances of a prospect becoming a customer. Depending on how your customers react to their transaction not going through as planned, it's possible to lose a measurable amount of sales by not displaying the correct message.

1.) The first step is blocking the IP's that card testing often comes from. In almost every situation I can think of, blocking IP addresses is ineffective at best, but in this one, it works fairly well. I've analyzed a lot of card testing attempts on many websites over the past five years, and nearly every one of them has come from an address that falls in one of these IP addresses.

2.) The next step is to develop an error message for different responses that you get from your payment gateway. These should be broad, but specific enough for your customer to understand what they need to do to correct the situation. Too broad and your customer doesn't know what they need to do. Too detailed and the card testing thing may become an issue again.

Example:

General decline: We're sorry but your credit card was declined. Please use an alternative credit card and try submitting again. If you experience further problems, please call us at 555-555-5555 to complete your transaction over the phone.

AVS mismatch, error, unavailable: We're sorry but it appears that the billing address that you entered does not match the billing address registered with your card. Please verify that the billing address and zip code you entered are the ones registered with your card issuer and try again. If you experience further problems, please call us at 555-555-5555 to complete your transaction over the phone.

AVS tips:
I do not recommend full street address matching with AVS. Your customer's don't need to know exactly what you match with regards to AVS. While the system works in theory, it is prone to errors, and more often than not street address errors are something other that the person entering the wrong street address. The zip code should most definitely be matched, but only the first 5 digits should be required. Very few people know the second 4 digits of their zip code.

Card Verification (CVV2, CVC, CVV, etc…) Tips:
Card code verification should be processed on every transaction. It costs nothing extra, and not using it is a poor practice at the expense of you and your customers. However, actually requiring a positive card code match is something that many would debate. Personally, I would require it on the website, validate that a card code is entered, process it, but don't decline on a card code mismatch. It's best to flag transactions for further review if a card code mismatch occurs. Card codes get worn off, the system often returns errors or not-available responses, and the number of declines is usually more than an acceptable or actual amount.

With either AVS or CVV, if you sell products that carry a high risk of fraud and chargebacks, have high dollar sales, or you have had problems in the past with fraud, then I would definitely require a positive match in both areas. This would include any custom products, electronics, and high dollar merchandise (>$1000), etc. Also, your processor may require a positive card code match for online transactions, and you should definitely abide in this case.

Finally:
You should always be on the lookout for card testing if you decide to show different responses for declines and errors. Blocking those IP addresses will do nothing if the person doing the testing is not in one of those ranges. If it ever becomes a problem, the numerous fraud prevention options that payment gateways have are designed to curb card testing. Whatever the case, action needs to be taken quickly to minimize the negative effects that can come from card testing.

2 comments November 2nd, 2007

How to accept credit cards on your website

I absolutely hate writing this post, because it is so generic, broad and over-done. But, I was searching on Google today to see what was out there, and as usual there are very few objective sources that are worth reading on the topic. Apart from that, I don't have a guide on this site, and seeing as how this is a merchant account blog, it sort of fits the genre. Without any further rambling…

Accepting credit cards on a website is absolutely necessary for the success of any online sales efforts. While there are several other available payment methods for websites, credit cards surpass every other one because of their wide use and convenience.

There are two types of companies that can enable a website to accept credit cards. The first is a 3rd party processor, and the second is a merchant service provider (called an MSP, or ISO). The primary differences between 3rd party processors and MSPs are the way a website integrates with their service, the liability that the website owner has over the transactions that they process, and the price that a they will pay for the ability to accept credit cards. 3rd party processors include companies like Paypal, Google Checkout, 2checkout.com, CCnow, Clickbank, and many more.

The difference between MSP's and 3rd party processors:

MSP's

• The business apply's for a merchant account directly with a MSP.
• Business is personally liable for everything that they process.
• Customer's credit card statements have the business name on them.
• Use with a Payment Gateway (Seamless integration available).
• Some fixed monthly fees in addition to processing costs.
• Possible setup fee.
• Possible long term contract requirement.

3rd Party Processors

• Business processes under the name of the 3rd party processor.
• Customer's credit card statement has 3rd party processors name on it.
• Any dispute is made through the 3rd party processor and not the processing bank.
• Business and customer have limited protection from being ripped off.
• Must use 3rd party processors checkout system (Paypal has one exception).
• No fixed monthly fees.
• Some have setup fees.
• Most have high processing costs (Paypal and Google Checkout don't).
• No contracts.
• Business is partially liable for the transactions that they process.

Which should a business use?

Assuming that you are based in the US, this depends mainly on how much business you do, the type of products you sell, how you want to integrate payments into your website, and whether you sell on eBay or not.

For businesses in the US, Paypal is pretty much going to be the lowest cost method of accepting payments that you will find. As much as I personally hate to admit it, it will be very hard to find a company that can beat the cost of paypal. However, paypal has many negative attributes which often make it a poor solution for serious ecommerce websites.

Personally, I think paypal makes an excellent supplementary payment method, as there is a fair number of online shoppers that prefer to use it.

• How much you business you do:Merchant accounts have fixed monthly fees associated with them. If you are only processing a few dollars a day, it is simply a waste of money to use a merchant account. 3rd party processors don't have fixed monthly fees, and will be a more cost-effective solution for low volume businesses or an individual. If you do a lot of business, then a merchant account will give you better control over the funds that you process, and how your payment method integrates into your website. Many people consider the threshold of switching from a 3rd party processor to a MSP at about $1000 per month in processing. Personally, I would switch to a merchant account at about $500 per month, so that I could provider a cleaner experience for my customers. But either way, these aren't huge volumes of processing before a merchant account may be warranted.
• The type of products you sell:Many product types are considered high risk. High risk refers to products or services that carry an increased risk of being charged back, or being obtained by or sold to fraudulent buyers. A few examples of high risk businesses include anything adult related, travel related, online pharmacy, and download-able products. Online in general is much higher risk than retail. On a personal note, I think that most online businesses will experience some sort of fraud in their online ventures. Neither 3rd party processors or MSP's like providing services to high risk businesses. In these cases a business will have to contact everyone to find a company that can provide service to them. In some cases they may have to process through an offshore merchant account provider.
• How you want to integrate payments into your website: If you want a completely seamless system where your customer never leaves your website, then you are going to need a merchant account and a payment gateway. Payment gateways generally have two integration methods, but I only recommend using an API method of integration. 3rd party processors require your customers to fill out their information on a website owned by the 3rd party processor. A seamless integration method is considered by many to be fundamental in providing a smooth and efficient shopping experience. Paypal does provide a system called payments pro, which is a step in the seamless direction, but it is difficult to integrate into a website, and still creates some usability barriers. If you look on any major ecommerce website, you will find that they are all using a seamless integration with their payment processing method. 3rd party processors may be an alternative payment method, but they are rarely the primary method for a serious company.
• Do you sell on eBay? If you sell on eBay, you should accept Paypal. Paypal integrates seamlessly with the eBay checkout system, and the majority of eBay users expect to be able to use Paypal to complete their purchase. Merchant accounts are difficult to integrate with eBay and must always rely on multiple independent systems for them to work smoothly and automatically. Businesses that sell a lot on eBay will probably look into one of these checkout management systems at some point, but Paypal is the perfect solution for the majority of smaller eBay businesses.

Now that you have your processing method:

I am making the assumption that you already have a shopping cart in place on your website. This can either be a custom designed system, or can be a pre-made cart system like oscommerce, zen cart, and many of the other popular carts.

If you went the merchant account direction, you will also need a payment gateway. It is easiest to get a payment gateway from the same company you are getting a merchant account through. If you already know what payment gateway you want, make sure that the merchant account provider can set this up for you. If you don't know what payment gateway you want, Authorize.net is always a safe bet. There are many payment gateways available, with the most common being Authorize.net, and Verisign. You will want to use a payment gateway that has an API (Application Programming Interface) method of integration. The API is what allows your website to transparently integrate with the payment gateway.

Requirements to process on your website:

1. A SSL (Secure Socket Layer) Certificate (needed if you use a payment gateway API).
2. A shopping cart system (This can be custom made or you can use ready made shopping cart software).
3. Integration of your payment gateway or 3rd party checkout system.
4. Merchant account providers also have a list of requirements to setup an ecommerce merchant account. I recommend making sure that as many as possible are met before applying for a merchant account.

Depending on whether you have a custom designed or a generic shopping cart system, it can be as easy as pressing a button, or as hard as writing a complex integration script, to integrate your website with the payment gateway. Most shopping carts that are widely used will have a module or plug-in to integrate with most of the popular payment gateways. Custom carts will need a custom payment module, which should be coded by the person who designed the cart or another competent programmer. Here is a guide on how to integrate Authorize.net with a website using php5. Also, if you are interested in purchasing a Authorize.net integration script, authnetscripts.com has scripts for PHP, ASP, PERL, and Cold Fusion. I have used their scripts myself and highly recommend them. The price of one of these scripts is far less than hiring a programmer to write one for you. Integration tutorials for most payment gateways are available in just about every programming language, but again these should be programmed by a professional. If you need to hire someone to do the integration for you, I recommend services like getafreelancer.com and rentacoder.com. Make sure to pick a service provider with positive feedback, and make price a secondary factor. Here is a brief guide on how to use freelance marketplaces.

If you do use a payment gateway, make sure you are not storing credit card numbers or other sensitive information unless you know exactly what you are doing, how to properly encrypt the data that is being stored, your server is PCI compliant, and your website does not have security vulnerabilities.

Once you're integrated:

Once your website is integrated with your payment gateway or 3rd party processor, you are ready to start accepting payments. This whole process is not really as complicated as it seems, and should be takes in steps to prevent problems.

Quick Overview:

Merchant Account / Payment Gateway Flow -is the order of setting things up that I recommend for the least amount of potential problems.

1. Setup Website
2. Setup Merchant Account and Payment Gateway
3. Purchase and Install SSL Certificate
4. Integrate Website with Payment Gateway
5. Test Integration, and Run A Real Transaction
6. Go Live!

3rd Party Processor Integration - requires less structured planning, but some ordering will make a difference.

1. Setup 3rd Party Processor Account
2. Setup Website
3. Integrate Website with 3rd Party Processor
4. Test and Run A Real Transaction
5. Go Live!

For a better comparison of merchant account and 3rd party processors checkout the Merchant Account Comparison.

Hopefully this whole process goes smoothly for you. Once everything is complete, you can focus on the marketing and promotion of your ecommerce business. As always, feel free to contact me if you have a question, or you need some direction on what to do.

Best of luck to you…

1 comment February 7th, 2007

Case study - Need Paypal merchants for participation

I am looking for website owners that currently accept 'paypal only' for a case study comparing paypal acceptance to credit card acceptance through a merchant account, on a website.

I need a total of five, US based businesses that only accept paypal, and have $1,000 - $5,000 in non-ebay monthly processing, and are willing to add credit card acceptance to their accepted payment methods.

The Case Study:
I would like to see how much a website can increase their sales when they start to accept credit cards, and I would like to know the sales difference between Paypal and a merchant account on an average website. I have seen a ton of theories and speculation on this subject but I have never seen any hard facts, so I am going to get a better understanding myself. This study will be conducted to determine how much a website's sales increase by adding a credit card acceptance if they already accept paypal, and will determine the sales difference between Paypal and a merchant account if both are offered to shoppers.

What you get out of this if you choose to take part in this study:

• A free merchant account for two months (You pay nothing)
• Authorize.net, also free for two months
• A godaddy SSL (if needed, one year)

The reason that the Paypal acceptance is required, is that I need to start with businesses that already have an expected amount of sales so that there is a baseline for this comparison. Also, you can keep paypal as an accepted method of payment on your website. This isn't a replacement test.

Requirements to participate:

• US based business / website
• Must have use general website tracking / analytic software
• Must be selling tangible goods (I may try non-tangible / service oriented at a later time)
• Must be eligible for a US based merchant account
• Must have $1,000 - $5,000 in non-ebay processing per month
• If you sell more than $5,000 per month and would like to participate, I will cover fees from the first $5,000 in sales.
• Must be willing to integrate authorize.net into your website using the AIM / API method
• Must be willing to allow result statistics to be published once the case study is complete (Nothing overly specific about your business will be published)

At the end of the two months you can either take over paying for the merchant account and authorize.net, or you can close the merchant account down, your choice. There will be no fees or repercussions if you decide to close the account, nor will there be any pressure to keep the account open.

Once complete, I will publish the results here on this blog, on my business website and possibly a few other publications. You will receive credit for the case study and a link to your website (if you want).

The results will compare total sales before having the merchant account, to total sales after having the merchant account, and will compare Paypal orders to Merchant Account orders with both being offered as a payment method. The results will also take total traffic into consideration so that we can eliminate any additional sales due to traffic increases.

I'm still working out the formal details, but if you are interested in participating or have any questions please contact me.

The study will take place after the holiday season, probably starting in mid-January.

1 comment December 20th, 2006

Where do data losses actually occur?

Most businesses that accept credit cards online have become more aware of Payment Card Industry (PCI) security regulations like CISP, and SDP. What I find to be an interesting figure is that very little data loss actually occurs with online businesses.

Roughly 65% of all data security breaches occur at restaurants, the next largest group retail stores claim about 12%, and the remaining percentage is split between every other type of business out there including online. The simple truth is that with all the scrutiny over online businesses, card companies have failed to see the actual problem. It is retail businesses where employees and even customers often have direct access to sensitive data. Online businesses, even with poor security would require someone very knowledgeable in networking and computers to compromise their data. Any average Joe could obtain a credit card skimmer and use it at the restaurant where they work.

What this concludes is that somewhere along the line, card companies ignored where data breaches actually occur, and just decided to target all online businesses. Now everyone has to jump through hoops when for many there is absolutely no risk of a security breach because the information just isn't there to steal.

Security is extremely important for all businesses, and protecting cardholders information is every business's responsibility. Don't store sensitive data if you don't have to, and if you do, make absolutely sure you know how to encrypt and store it properly.

Also, if you use any custom made POS software system, you may want to check with the programmer that the system is not storing track data. If it is and you get caught, you can get up to a $100,000 per month fine until it is fixed. That is just a fine for storing the track data, not for an actual data breach which could be significantly higher.

Add comment November 28th, 2006

Accepting payments on eBay

Ebay has become one of the largest marketplaces for selling in the world. Actually getting money from an eBay auction can be as hard as selling something.

Here's a quick overview of the different methods of payment you can consider for your eBay auctions.

Paypal:
Paypal is by far the easiest and most tightly integrated method of accepting payments on eBay. Paypal is automatically tied into the eBay checkout system, and Paypal is widely used by buyers. There is however a percentage of buyers and sellers that have bad experiences with Paypal, and wont use it. For this reason it is always best to provide at least one supplemental payment method for selling on eBay. But, buyers normally want to use Paypal to pay for auctions and from a sellers perspective it is wise to accept Paypal, even if you have had a negative experience with them. As crazy as this may sound, Paypal auctions almost always sell for much higher than an auctions where Paypal is not accepted. Even an automated credit card acceptance system does not offer a suitable replacement for the wide use of Paypal.

Credit cards:
Credit cards can be tricky to accept on eBay auctions, but are the second most desired method of payment next to Paypal. Depending on how many products you sell, manually accepting orders over the phone from eBay sales can be the perfect solution or simple impossible. There are a variety of pre-made systems that can integrate eBay with your payment gateway and merchant account, but these systems often add unnecessary extra fees to the already high cut that eBay takes. If you run a successful online business, I recommend hiring a programmer to develop an eBay checkout system for your auctions through your existing payment gateway. This creates a much more usable system, and eBay orders can be better integrated with website orders for inventory, customer service, and tracking.

Personal checks:
In my opinion, personal checks are the worst method of payment for eBay auctions that work well enough to consider. Checks are slow, they must clear a bank account, they are prone to bouncing and being lost in the mail, and they create a very poor user experience. With the exception of a few rare occasions, checks are not a convenient, timely, or cost effective method of payments for eBay. The money you save by not using Paypal or accepting credit cards, is most definitely more than offset by the lack of bids you get on your auctions. Nearly every bad experience I have had on eBay was a result of having to send or received a check.

Money orders & cashiers checks:
Money orders and cashiers checks are safe and effective methods of getting paid on eBay. But, they are slow as they have to be mailed by the buyer and deposited into a bank account before the auction item can be shipped. They are best used with high dollar auctions where it is essential that the seller is protected from any buyer fraud or frivolous chargebacks and disputes, and time is not of the utmost importance. For high dollar items, I recommend getting an initial deposit via Paypal or credit card, and accepting the balance by cashiers check. I would consider a high dollar item anything of about $2000 and up.

Cash:
I would not even consider sending or requesting cash through the mail. If you sell locally and are comfortable with meeting your customers, than cash can be a great method of getting paid for your auctions. For most of us, cash is rarely if ever a viable option. For those that do meet their customers, I would highly recommend taking appropriate precautions to protect yourself. If you do not have a business address, I recommend meeting your customers in a public place, not at your residence. Most likely you will never have a problem with a buyer, but it's simply not worth the risk to you or your family.

Western Union:
Western union is not an acceptable method of payment for eBay. It is commonly associated with fraud, and a very high chance of someone getting burned exists with western union. I do not recommend using western union for auction payments at all. eBay also warns against it. Just don't do it.

Other 3rd party checkout systems:
There are several other common checkout systems that can be used for accepting payments on eBay. Personally, I find most of these systems to offer a poor experience for a customer, but they are still used often enough to mention. Andale, Bidpay, Vendio, and USAepay are some of the commonly used checkout systems for eBay auctions. These systems have a hosted checkout process for your auction winners. They also help manage your existing auctions, shipping, and have a variety or reporting tools that help you keep track of all of your eBay affairs. All of these services have fees associated with different levels of their services, but they can help sellers that have a large quantity of items to manage.

Using a payment method that your 'buyers' want to use is vital to getting the most out of your eBay auctions. It is important to provide at least two options for payment from your customers, and make it as easy as possible for your customers to pay. One of the largest contributors to a low quantity of bids on auctions is not accepting the payment method that buyers want to use.

Add comment November 27th, 2006

Integrate a website with Authorize.net

The merchant account services blog, just came out with a guide on integrating a website with Authorize.net.

The guide is written for websites using PHP 5, Curl, and SSL to connect a website to authorize.net using the API method (Known as AIM with Authorize.net).

PHP 5 is required for this particular script. There are several PHP 5+ functions that will make the script completely incompatible with PHP 4. Unfortunately a good percentage of servers are still using PHP 4. Apart from that, it looks like this guide should be all that a developer needs to successfully integrate authorize.net into a shopping cart system.

I really like the feature where the script automatically retries a transaction 3 times if there is an error. This can be common with payment gateways, and it's definitely not good to return an error or declined message if you absolutely don't have to. The script also validates the card number using a simple version of the LUHN algorithm to verify the card number against a check-sum, in addition to performing basic card number and expiration date checks.

When it's all said and done the script will return an approved, error or declined message for your customer's transaction, and you can send them to whatever page or message on your website that you want.

This script is complete, but I don't think that a new programmer should change anything they don't understand, because they have the potential to open security holes if their programming gets broken. This is especially important since this script will transfer sensitive information across web servers.

There are a variety of free and paid scripts out there, but this one is written by a competent group of individuals that have extensive knowledge of payment processing, web development, and web security, so I highly recommend it.

Check it out:
Integrate the Authorize.net Payment Gateway with PHP

Add comment November 21st, 2006

Required Actions for PCI Compliance

If you accept credit card online, this chart is for you. This chart is a simple breakdown of the PCI data compliance levels and requirements. If you accept transactions online, you fall into one of these levels. This chart explains what the requirements are to be in a specific category, and what a merchant must do to remain compliant.

The yearly cost for a level 2, 3 or 4 merchant is around $150, while the yearly cost for a level 1 merchant is more than $30,000. Because of this, it is extremely important not to ever have a data compromise. I personally recommend not storing any sensitive data online, at all, and if it is stored offline, access should be highly restricted and the data should be encrypted. Track data should never be stored anywhere, under any circumstance.

If you have a data compromise and card holder data is stolen, you should expect upwards of $100,000 in fines, arbitration fees, and regulations in addition to the additional cost of level 1 PCI certification.

Related Posts:
Scan Alert PCI / CISP
A Guide to Small Business Security, Free PDF Download…
CISP, SDP, PCI Compliance required for every business…

1 comment October 25th, 2006

A list of payment gateways

I just compiled a list of commonly used payment gateways.

I added my recommendation and a quick price comparison for the more popular payment gateways. Check it out, and let me know if I missed any major gateways.

3 comments October 4th, 2006

Google Checkout vs. Everything else…

Google recently released their payment systems called Google checkout. Google checkout is a fairly easy to use merchant account alternative for businesses and individuals. Google checkout offers very low fees for use, and can be completely free, if a business advertises using Google AdWords. For every $10 a business spends in AdWords advertising, they get $1 free in processing fees.

Google Checkout Implementation:
Despite what Google would like everyone to think, Google checkout is not easy for websites to implement. With the exception of a few very simple and limited uses, it is not easy to get Google checkout into an existing website, especially if the website is using a custom shopping cart system. The Google checkout API is an XML based system and is not something that most beginning programmers could easily tackle. Google does provide a handful of good scripts, but even with these, integrating Google checkout can be a daunting task. The integration scripts can be obtained by signing up for an account with the Google sandbox.

The current requirements to be eligible for the Google checkout program are a US bank account. Google is planning on making Google checkout available to more countries, but for the time being US is the only country allowed. This single fact is probably one of the biggest reasons that Google checkout isn't more popular.

The benefits of Google checkout:
The biggest benefit right now that I see with Google checkout is for AdWords advertisers. AdWords advertisers get to display a small next to their AdWords listings. This small image could definitely help distinguish a particular AdWords ad from the others, creating a high click through rate. Since most web users have no idea what Google checkout is, this could be taken as an unfair advertising advantage to Google Checkout customers.

The use of Google checkout on a consumer level is very limited. It is slowing growing in usage, but at this time is not a widely adopted payment method. Expect the number of consumers using Google checkout to grow over time, but unless Google really makes it beneficial for consumers, it is unlikely that Google checkout will ever compete with Paypal or Credit Cards.

I am a firm believer in making the online shopping experience as easy as possible for website shoppers and this includes making all popular payment methods available to website visitors.

The negatives of Google checkout:
The biggest complaint that I have, apart from the difficult integration, is that Google requires website's using Google checkout to display Google checkout buttons all over the website. There are also a ton of regulations that are simple unnecessary.

Display a Google Checkout button immediately beside, above, or below every existing checkout button or link on your website.

Lets be honest here. Google is really turning off the desire to use Google checkout by forcing Google checkout users to place large Google buttons all over a website. It's also against policy to host the Google checkout images yourself, and it is against policy to alter the images (including resizing) in any way.

Google needs to have some consideration for website owners wanting to maintain the integrity of the look of their websites. Not many respectable websites want to have Google checkout buttons all over the place. Obviously Google doesn't care about this, because they just want more users at this time. Another deterrent to putting Google checkout on your site.

The other major problem with Google checkout, is that it is not an accepted or allowed payment method with eBay. This means that it is against eBay policy to pay or offer to accept Google checkout on an eBay auction, and doing so can result in getting suspended, or banned. Any Google checkout purchase made on an eBay auction, immediately removes all eBay buyer and seller protection. If you get ripped off as a buyer or seller, there is no recourse.

Overview:
If you are an AdWords customer, and you sell products, then Google checkout is a good system. You can get that little next to all your AdWords listings, and this is bound to help your AdWords click rate.

As for businesses just looking to accept Google checkout from their customers, my vote goes for hold off. There are simply not many people wanting to pay with Google checkout. The amount of purchases from Google checkout customers isn't going to be worth the trouble to integrate it into your website, and wont be worth clogging up your website with a bunch of ugly Google checkout buttons designed to circumvent your existing checkout process. Anyone that uses Google checkout also has a credit card, and most likely has a paypal account. If you're going to add another payment option for your customers, go with paypal. Wait until Google gets some people using it, wait for them to relax on their rules, and wait for it to be allowed on eBay.

The Google Checkout Blog has some good information about the Google checkout program, but expect it to be extremely biased as it is a Google blog.

Related Posts:
Google Checkout Sign-up Open
Google Payments, Update

4 comments October 2nd, 2006

Magazines for small business owners

I like reading small business magazines. I have a few favorites that I always read, and there are others that are good, but are just not as interesting to me.

Small business magazines can provide some good ideas for business owners, and usually give some good insight to upcoming products, services, and anything of interest to business owners, and entrepreneurs. They can be a good place to advertise, but you can also lose a lot of money buying big ads in these publications.

My Favorites:
Entrepreneur Magazine
Fast Company
Ecommerce Times

General Business Related:
Entrepreneur Magazine
Fast Company
Business 2.0
Fortune
Fortune Small Business
Business Week
Inc Magazine
Red Herring

Ecommerce and Online Related:
Practical Ecommerce (Online and Print)
Internet Week
Cio.com
Ecommerce Times (Online)
eWeek.com
Line56
.NET Magazine (UK Based)

Payment Processing Related:
The Green Sheet
Transaction World

Most of these magazines offer a lot of great content on their websites and you don't need a subscription for it.

Let me know if I'm missing any good ones.

2 comments September 7th, 2006