lunaru | weblog | thoughts

If you’ve ever thought that starting a company online and charging people money for your great software is easy, you’re seriously underestimating the pains of the current e-commerce state.

Consider this: You’ve got a great web-based software app. You think you’re going to be the next 37signals. You build out your application to perfection, skipping all that trivial stuff about charging for the software for the latter stages of the development cycle. You think you can push out all that payment processing mumbo-jumbo until the end.

Well, you are in serious trouble.

The problem isn’t even bottlenecked at a grandiose level - like lacking a great business idea to reel in the money. The pain is all in the details like setting up an online payment processing system.

I understand that trying to process credit cards should be a heavier process than setting up a lemonade stand, but the current state of the art is absolutely ridiculous. This is because the current players in the market are either 1) pigeon-holing all e-commerce transactions into simple, but totally uninteresting processes, or 2) completely ill-equipped to handle online commerce.

In corner number one, you’ve got players like PayPal, with whom you can easily set up a check-out form with PayPal express. Given that this is just about as brain-dead as e-commerce can get, you’d think that it’s as easy as filling in your name, getting a URL, and link your form to that URL. No. You’ve got to wade through a million pages of marketing rhetoric to get to any real documentation. And the end result is often so simple, that it doesn’t break the mold. If you’re doing anything remotely interesting, like a web-based software app, you’re not going to get much mileage here. Move along.

In the other corner, you’ve got big bank institutions offering online merchant solutions. Big trouble. Don’t even bother. From personal experience, I walked in and talked to no fewer than 3 representatives from your big names like Bank of America and Wells Fargo and got nothing but empty stares. “You want to do what?” “Wait, are you shipping anything?” “Do you need a terminal?” “You want a merchant account? We’ve got a nice merchant services package…” If you want to actually do credit card processing, you’re on your own when you talk to these big boys. They’re still living in a world where people walk into shops, swipe their credit cards in a terminal, and physically transact. Trust me, they’ve got good reasons to keep their focus (and employee training) in the physical space.

However, that leaves us web guys stuck out of luck. If you do your research correctly, you probably know that online payment processing comes in 3 pieces. First, at the layer closest to your application or system is the payment processing logic to initiate transactions and authorizations. There are plenty of great ways to roll this logic, my favorite being ActiveMerchant, a great gem for Ruby on Rails. This is the area closest to developers and I promise you will spend more time shopping for a solution than implementing it. You’re mostly in the care of savvy professionals here.

The next level, and one step removed from your application, is the Payment Gateway. See Authorize.net or TrustCommerce or Braintree. These guys provide an API for your application logic to talk to banks and do the actual transaction. Payment gateways are generally good people - they understand web commerce, since that’s their bread and butter. They can hold your hands a bit and even offer sandboxes and other developer friendly options to make sure your app is behaving properly. ActiveMerchant will generally abstract away gateway differences for you, so this step is solid, though it could use some improvements.

Another step removed, and the final step is your merchant account. Your merchant account is the part of all of this that actually touches the banks. This is where the Visa or Mastercard magic happens. This is also where you’ll pull your hair out trying to figure out why the support folks are speaking in alien languages.

For the most part, people who provide merchant accounts and the people who work for them do not understand what you are doing. They don’t understand web applications, they don’t understand why you’re doing what you’re doing and why you chose to do things a certain way. They don’t understand APIs, IP addresses, servers, Ruby on Rails, HTTP, SSL, or anything like that. They understand forms, paperwork, support tickets, legal documents, and all that bureaucratic burden.

I’m not kidding when I say that it took me over a *month* to finally get a merchant account properly integrated with my payment gateway. I won’t say who the two parties were, but let me say that no fewer than 10 bulky and sometimes unnecessary forms where sent back-and-forth in a span of 3 weeks with the rest of the time wasted in some weird support limbo.

For developers like me, who prefer to focus on the elegance, simplicity, and unerring logic of clean code, the frustration and archaic nature of filling out PDFs and DOCs just seemed like a step back in the wrong direction.

The problem arises from the many layers that it takes to build an e-commerce solution. There are too many middle-men and too many ways to lose empathy along the way. There is no way a support person at a bank can understand how web applications tick - they’re not trained for that.

So my question is - can there be a hero to arise from all this mess and deliver to us a better way?