I've spent some time researching the various approaches to accepting credit cards online. I haven't been impressed with the level of information I've found online about this topic. Few companies offering these services provide really good information online, and I also didn't find very much impartial information (reviews, tutorials, etc).
So, I thought I'd summarize what I found so far, in case it is of interest to anyone else. And, if you've had experience with anything I mention below, please contact me and let me know about it (weblog@karlnelson.net). Especially if I've said something incorrect!
First, here are the constraints I'm working under:
All of this is to say that your mileage may vary, and your circumstances may dictate different approaches than what I'm taking.
So, there are basically three approaches to accepting credit cards online.
The first, and more traditional approach, is to use a separate "merchant account" and "gateway processor". The user remains on your website throughout the entire transaction, and your server talks to the credit card servers to make the transaction. (I'm radically over-simplifying this. Authorize.net actually has a very nice diagram of the entire process.)
The two big processors seem to be Authorize.net and VeriSign . I wasn't able to find pricing for Authorize.net, but VeriSign's service costs $59.95/month (flat rate), with a $249.00 setup fee. A third one I ran across is NetBilling, which runs 1.5% + $0.15 for each purchase or a flat rate per transaction.
As for technology integration, Authorize.net looks fairly easy to interface with, especially given the Ruby Payment GEM. VeriSign's looks more challenging, possibly because they don't have much technical data on their website. Rather, they're assuming you're going to use one of the dozens of shopping cart applications that have integrated their system.
The merchant account is just a bank account set up to work with the processor. The processors seem to have banks they're set up to work with, and there seem to be hundreds of options.
The second method is the "all-in-one" approach. Like the first approach, the user stays on your website the entire time.
PayPal, in its Website Payments Pro service, is one provider of this method. One advantage is that it doesn't require a merchant account (the money goes into a PayPal account, and you would then transfer it to you bank account). As for fees, there is a $20/mo. charge, then 2.9% + $0.30 on each order. No setup fees. They have what looks to be a nice web service (SOAP) that shouldn't be hard to integrate into any system. I think PayPal has done a really nice job of providing lots of information, including a full user manual, in a clear and upfront way. Many of the other sites I've seen don't give you squat unless you give up your contact information.
But, there are a couple of little downsides to PayPal. First, you are required to allow users to pay via the PayPal website in addition to allowing them to enter their credit card info on your website (I'll talk more about this in the third section). And, they have some rules about when and where you can ask for certain information (like billing address). I don't think these are insurmountable, but they are issues. And, they do somewhat break the illusion that everything is happening at one site.
The third option is to use what I'll call a "pass-off" service. In other words, instead of keeping the customer on the your website throughout the entire process, when it comes time for them to enter payment information, they'll be directed to a third-party website. Once the payment info is entered, they'll land back at the your site. The advantage is that this is *very* easy to set up. No web service integration, no forms to build; just a little HTML that passes the user off to the third-party site. The disadvantage is that you lose some control over the user experience. It is really obvious that everything isn't happening in one place (although some services allow a level of customization so the third-party site could look like your site).
PayPal started out life as a provider offering this type of service, and, as I mentioned above, this option is still a part of their "Website Payment Pro" service. Going with the PayPal "standard" service would run 2.9% + $0.30 on each order, but without the monthly fee of the "pro" service.
Another service that looks similar is 2Checkout. They want $0.45 + 5.5% of each order, plus a $49 setup fee. I'm not sure what the advantage over PayPal is.
So, did I miss anything? Any suggestions? Experiences? Write me!
Posted by Karl
March 30, 2006 02:36 PM