Archive for October, 2006

The Wikipedia Project

Monday, October 30th, 2006

As vast as Wikipedia is it is far from complete. One thing I found lacking was the overall contributions for merchant services related topics. It seems that those of us in the merchant services industry are either to lazy to contribute or just not savvy enough to provide Wikipedia with good content. We’ve identified a few solid contributors, to whom we tip our caps to, but overall this category is just under-represented.

So, Merchant Account Services has decided to make the Wikipedia Project our project. Our goals are simple:

  1. Identify merchant services related topics
  2. Categorize them
  3. Contribute new content and improve existing topics
  4. Create new articles for topics not yet represented

To get things started we have created a Merchant Services category. So far we have four articles listed: Authorize.net, Chargeback, Merchant Account, and Payment Gateway. I am sure there are more that can be added to it.

And we do not want to do this alone. Anyone who understands how Wikipedia works and would like to contribute is more then welcome to do so. We have started a new forum to keep track of our progress. Feel free to let us know what you’re working on.

Technorati Tags: , , , , ,

Visa, MasterCard … Discover Card?

Thursday, October 19th, 2006

Currently, if your business wanted to accept all four major credit cards you would go to a company that set up Visa and MasterCard together for you and then also help you set up a Discover Card account and an American Express account. Essentially you would have established three relationships. Although Visa and MasterCard are two separate companies the way they operate allows processing banks to wrap them up into one package with the same rate structures. The result of this is that you will be very hard pressed to find a merchant that accepts Visa but not MasterCard and vise versa.

What you won’t be hard pressed to find is a merchant that accept Visa and MasterCard but doesn’t accept Discover Card. This is because of Discover Card’s low level of usage relative to Visa and MasterCard. Most merchants work under the assumption, and rightly so, that anyone with a Discover Card also has a Visa or MasterCard. So why bother dealing with another company with extra rates and fees when you can just have one relationship that takes care of your needs?

To combat this problem Discover is moving to a new business model. Starting in November Discover Card will allow the same processing banks that establish merchant accounts for Visa and MasterCard to include Discover Card. The processing bank will be able to set their own rates just like they do with Visa and MasterCard (currently Discover Card has a set fee program which means every merchant has the same rate structure to work from). This means that when you establish a new merchant account, you can get one quote that will cover three major credit cards. You also only have one relationship to manage and one monthly statement. It also means there is potential for Discover Card rates to be more attractive then they were in the past as now competition can cause the pricing to go down.

This new program will start in November with First Data and this will expand as other processors have already signed up and more are on the way. This should increase Discover Card’s reach dramatically. Maybe in the not-too-distant future Discover Card will be as synonymous as Visa and MasterCard?

Technorati Tags: , , , ,

When to use an SSL Certificate

Monday, October 9th, 2006

A common question from merchants entering the world of online credit card processing is when should an SSL certificate be used on a website. SSL allows websites to encrypt sensitive data when in transit to and from a user’s web browser. This prevents hackers and other nefarious characters from stealing sensitive data being sent during an online transaction.

Based on that basic description of what an SSL certificate does it would seem to make sense that a merchant should simply make their entire website encrypted. That way they can be sure every page that needs to be encrypted is. At a glance that would seem to be a logical solution. After all, if every page is encrypted then it is safe to assume that every page that needs to be encrypted is.

But upon further scrutiny important flaws can be found in this solution:

  1. SSL requires the server to do more work
  2. Every time an encrypted page is requested by a web browser the server must first process the encryption portion of the request before sending the web page to the browser. This requires server resources to do. Encryption must be done every time an encrypted page is requested. If your site has simultaneous users this will increase the burden on the server even more.

  3. SSL is not search engine friendly
  4. Naturally every ecommerce website would like to be in the search engines as they can provide a lot of free traffic for a website. However, search engines cannot read pages encrypted by SSL. This prevents them from finding and reading the pages in your website and thus they cannot add your pages to the index. If you are not in their index, you simply cannot be found by searchers.

So what is the proper way to use SSL to secure a transaction? As explained above, SSL is used to encrypt sensitive data. For an ecommerce website, this would mean encrypting the information your customer submits to you during their transaction. This includes their personal information (name, address, etc.) and credit card information. Some websites collect this information on one page; some collect in on multiple pages. However you choose to implement your checkout every page that transmits your customer’s data needs to be encrypted. Your order confirmation page should be encrypted as well if you print out your customer’s personal information on it.

By only encrypting these few pages we are avoid both pitfalls of using SSL. Since only a few pages are encrypted, and these are only used by the small percentage of your site’s visitors that checkout, we relieve the server of the burden of encrypting the other pages. Plus we do not have to worry about the search engines as they do not need to index your order form or order confirmation page (as it won’t even exist until after checkout anyway).

Technorati Tags: , ,

Contributing to Wikipedia Again

Sunday, October 1st, 2006

Just like we did for Merchant Accounts, we’ve contributed to Wikipedia once again. Wikipedia now features an article for Authorize.net.

It was surprising that an article did not exist for them prior to this entry but while trying to create this article it became apparent why. We first submitted this article a few days ago and was writing a blog post about it when it got marked for “quick deletion”. They cited too much of the information matched the content on the Authorize.net website. That’s a fair enough reason to delete it so it was rewritten to not include any content from the Authorize.net website. It didn’t make a difference. Whomever deleted the article didn’t bother to check to see if the content was corrected (in Wikipedia you can provide notes for an article so editors can collaborate and discuss an article. The notes for this article clearly explained what happened but apparently the editor whom deleted the article didn’t read it or didn’t care).

Well, you can’t let one lazy person ruin it for everyone so we resubmitted the article with original content. It got marked for “quick deletion” again. This time it was cited as not showing that Authorize.net was a worthy enough company to warrant an article about it. So we did some research and found that if you can provide enough evidence, usually through media reports, then the listing can stay. So we added media reports showing the importance of Authorize.net (and we added a note of course). Didn’t matter. The editor deleted it instantly.

Fortunately we’re persistent here and were going to allow a couple of lazy editors to ruin a good thing. So, armed with more experience, we wrote the Authorize.net listing to include the media reports. It has been published and now the powers that be at Wikipedia seem to be happy with our submission. Naturally we’re going to keep an eye on it to make sure they don’t delete it from under our feet but if they haven’t marked it for deletion yet I feel pretty good about our chances.

In the future it would be good to have a time line of the company’s history listed. They have one on the Authorize.net website but we can’t use it as it copyrighted material. One day maybe we can go through their press releases and news stories to make our own time line.