This week I’m on vacation in Vancouver but 76labs is still forging ahead on our secret project. My task this week is to evaluate and compare options for handling payments.

But first, before I jump in, I have a small confession to make. In my delirious excitement last week, I may have claimed that this new product we’re developing is “going to turn the music industry upside down”. While I did acknowledge in that same post — in the next sentence, in fact — that this was a tall claim, I feel a bit like John Lennon after his “bigger than Jesus” remark… minus the backlash, of course. Some colleagues of mine provided me with some sage advice following that hyperrific outburst so all future posts about this product will probably make slightly more modest claims about which industries it may or may not turn upside down.

Alright, got that off my back. Let’s return to our regularly scheduled posting…

At the core of our new project is a subscription model where our customers collect recurring fees from their customers. It’s akin to a consignment shop in some ways. He/she who wields the credit card is buying something from one of our customers. However, the payment is made to us and then we reimburse our customer with their share of the transaction money. Perhaps that sounds complicated, but it’s really not that important at the moment. The bottom line is that we need to accept payments online with credit cards.

In the interest of getting a beta version finished as quickly as possible we’ve decided to steer clear of setting up our own merchant account to process the cards ourselves. Why? Well, on top of not wanting to re-invent the wheel when we don’t have to, it makes sense when we’re starting from a stationary position. Setting up a merchant account is an expensive process and if we can start out using something that’s essentially free, then it probably makes better business sense to focus on squeezing a few more features into the product than building a custom solution for accepting payments.

Once we’d arrived at that conclusion we had a few options to look at:

1. Amazon’s Flexible Payment Service – came out in beta last week and, like Amazon’s other web services, is geared heavily towards developers. This means that it doesn’t work “out of the box” so to speak and would require a lot of work to integrate it into an existing product. Unfortunately for us, it doesn’t really matter because it’s not available to non-U.S. merchants yet anyways.
2. Google Checkout – it’s been out for a year and is free (as in, no transaction fees) for the remainder of 2007. It’s rather basic, which makes setup easy but the lack of customization makes it a bit of a drag. Once again, it’s not important because it’s only available to U.S. and U.K. merchants. Score: unusable options 2, Canada 0.
3. PayPal Standard – the vanilla fudge option. It’s lean but it certainly does the trick: simple to integrate, a trusted brand in the payment industry, and customers don’t need PayPal accounts anymore. What’s the catch? Well, during the checkout process customers get bounced to PayPal’s site to enter their credit card info and then back to your site when they’re done. While it is possible to “skin” the PayPal page to match your own site, it’s still obviously a PayPal page and probably a little jarring to your users’ experience as they navigate through the checkout process. But hey, it’s a free service so it’s hard to complain. If only PayPal offered a paid service that allowed you to really skin their page so that the payment process was completely seamless…
4. PayPal Pro answers the call. For $20/month you get a turnkey solution that allows customers to stay on your site from start to finish for a totally seamless experience. PayPal Pro basically fixes everything wrong with PayPal standard, and then some. Seem too good to be true? It is, if you’re in Canada. This service is only available to U.S. and U.K. merchants for now.

Until PayPal pro makes its way to Canada, the clear winner for us is PayPal standard. Well, technically it’s the winner because it’s the only option. As Homer once said, “the two sweetest words in the English language: ‘de fault’”. It’s not perfect, but it’s the quickest and easiest way for us to process credit cards.

I didn’t really get into the nitty gritty of comparing per-transaction fees. They’re all pretty competitive in that respect – ranging from roughly 2 to 3% per transaction depending on who you go with and what kind of volume you’re doing.

That’s a real quick and dirty analysis of what’s available (for free or nearly free) to Canadian merchants. Something I didn’t mention above but did weigh heavily on our decision (well, before we recognized how geographically handicapped we were) was scalability. At some point it’s going to become more economical for us to migrate to a merchant account and process the cards ourselves. With bigger volume also comes the need for more infrastructure to handle the volume. Adding in an order-management tool or developing something ourselves would be a lot easier with a merchant account.

When we get to that point we want to make the transition minimum muss’n'fuss. Apart from Amazon, pretty much every option would adapt well to the merchant account model (we’d basically just be filling in the gap in the process occupied by PayPal or Google). Unfortunately Amazon’s solution would require us to do a lot of custom work (well, a lot more than zero which is basically what it would be with PayPal or Google) to communicate with their APIs to integrate it into the purchasing process. That’d be work that we’d pretty much have to toss in the trash if we transitioned to a merchant account.

What’s next? Next week we take the development team’s user-flow diagrams, architecture and wireframes and start on designing the interface for the front end (and back end). Pressure’s on the design team ;)