Introduction To Online Payments - TL;DR: It's A Total Bitch
blog.meatinthesky.com
blog.meatinthesky.com
i needed a credit card processor for corduroy (plug: http://corduroysite.com/) to process monthly subscription charges. i filled out a form (i think, it was 2 years ago) on braintree's website (http://www.braintreepaymentsolutions.com/), they emailed me back some info, i filled out and faxed over their forms about my business and already-established checking account, they created my american express/discover/visa/mastercard merchant accounts for me, and i used activemerchant (http://www.activemerchant.org/) to talk to their gateway via my rails app. according to my email archive, i received the signup forms from them on april 14th and they emailed to confirm my first charge through their gateway on april 22nd.
i wrote some simple code to use activemerchant to process the monthly subscriptions from a cron job that submits a charge to braintree using the customer's vault id (the only thing stored locally, braintree actually stores the credit card and address information) and the subscription monies are deposited into my bank account the next day.
i get a monthly statement from braintree in addition to instant email receipts. i've had to change my bank account and address information once, which involved contacting braintree and american express/discover/visa/mastercard and was relatively painless.
i'm not sure what is so difficult that services like recurly are trying to make easier, but if the problem is lots of different points of contact, i'm not sure that another middleman is the answer. braintree stores and charges the credit cards, the credit card companies deposit the money into my local bank account. simple.
Most web apps are too small to worry about these issues.
(Full disclosure. I work at FreshBooks and I'm actually the product manager of recurring and subscription billing.)
There are a number of reasons why it can be that complicated - doesn't always have to be, but I think you are the exception rather than the rule.
First, most people just don't have a basic understanding of how it all works. The idea that a merchant account isn't a bank account at all is non-obvious to everyone I've walked through payments hell with. Recurring billing, in particular, is a huge pain in the ass, especially with upgrades and downgrades that users do as they try to optimize their freemium subscriptions. (There wouldn't be at least four companies doing just this if it wasn't a total PITA.) If you're not built in Ruby, and you can't use ActiveMerchant, you really have to evaluate the documentation for each of the various gateways - and good luck finding out the names of all of them - before you can even begin. AmEx, in particular, is a whole 'nother circle of hell, although OnePoint solves a lot of these issues (but, of course, for a price).
Honest to God, I'm going to try to learn Ruby this summer purely because ActiveMerchant exists. My existing startup is coded in PHP with a dash of Perl and Python, but online billing is so complex and so tedious that I'm learning a language that's not useful to my existing startup because payments are so hellacious.
I've done some work with various authorize.net resellers in the past with similar results. Really, understanding the magic that is interchange rates is the most difficult piece of the whole equation:)
When I first started getting into subscription based services about 2 years ago, googling "recurring billing rails" brought me ActiveMerchant, a few Payment gateways, and some blog entries about getting a merchant account which is all you need. I was on my merry way.
Try that same query now and it's full of noise. You get rants from various people and you get companies peddling their services. While I agree that new services are helpful and are an essential part of the eco-system it's becoming really intimidating for newcomers because it's so hard to get the bare minimum truths one needs to know.
Sure, there are many payment gateways to choose from (Auth.net, TrustCommerce and Braintree are great with ActiveMerchant, btw). Sure it's a lot to thinking and worry about. We're talking about taking money out of other people's pockets here - there should be at least a little bit of effort right?
If you're intimidated by recurring billing issues - get over it, it's really as easy as there makes it out to be, especially when you're just getting started. There's time to fill in the details (like coupon codes, special offers, prorating, etc) after launch. For now, I'd suggest ActiveMerchant + Gateway + cron job and worry about getting customers instead of worrying about your middlemen.
Braintree seems to simplify the work by a lot. On the other hand, use another provider, and PREPARE TO SUFFER!
I wrote about our pains w/ Auth.net in specific (and cc processing in general) here: http://letsfreckle.com/blog/2008/12/ecommerce-stuff/
* Personal guarantee. Most merchant account providers require a personal guarantee. I signed one for Dawdle.com, but I never would again, even if it costs me more.
* Recurring billing. There are a number of startups focused here, including Recurly, Chargify, Spreedly, and CheddarGetter.
* PCI compliance. The physical access tenet makes it technically impossible to be compliant if you're using any cloud hosting provider for e-commerce; in reality, almost no one is PCI compliant.
* Gateways. There are a bunch. ActiveMerchant (Ruby gem open sourced by the good folks at Shopify) can do basic handshakes with most. There isn't an AM equivalent for Python, PHP, or other common languages that I know of.
* Processors. First Data ostensibly processes 75% of credit cards in the U.S. This is a more academic topic than the others, but it's terribly interesting if you want to understand why online payments are the clusterfuck they are.
* Chargebacks. You'll almost never win one.
* AVS and CVV. They protect you, but goddamn, are they expensive to process. AVS can sometimes cost you a dime (or more!) every time you check a card - and it rarely works on non-U.S. addresses (and American Express often fucks up apartment addresses even within the U.S.).
* Vaults versus reference transactions. Reference transactions are an elegant way to handle credit card data, but they lock you into the gateway. Vaults give you portability, but those providers are always more expensive than the ref tranx folks.Braintree claims that their pricing is very competitive. I don't doubt that it is, but being in business with them for a single year costs a minimum of $1659* (supposing you need recurring billing). That's a lot for someone who wants to get started charging for a small web app.
I've been really discouraged to get started because I know that as soon as I do I'll be paying high monthly fees that I'm not sure I'll be able to cover.
Thoughts?
After you've got a better handle on your market, have traction, and have passionate paying customers singing your praises, switch to a subscription billing provider and grandfather in the old users at free for life.
This assumes that you have nearly zero marginal cost per account, or a growth curve which can absorb the early adopters as a cost of doing business.
Otherwise, this seems like a good strategy for testing the waters with a new product.
Anecdotal, I know.
The entire online industry and everyone who takes credit has to hand over %3 to credit card processors, who take money from both sides of the transaction.
It just sucks, that's all I'm saying. I wish there was a better way...
Every merchant I visit is giving me 2% off with Visa and a bank in the middle to make sure of it.
1) There is much more than meets the eye when choosing a merchant account provider, and not all are created equal (it's very true that few understand online payments). We will be first to say that providing merchant account services to online merchants is very challenging for a host of reasons. Because it's so complex and because there are so many moving parts, no one is immune to mistakes, misunderstandings, complex situations and difficult situations. With that said, the importance of choosing the right provider cannot be overstated. Merchants need to find a company they can trust because when stuff happens (i.e. account closure, reserves) you need someone in your corner that can help navigate. In our experience, merchants are most likely to make mistakes when solely focused on price.
2) I'm very pleased to see you call out data portability. We were the first in the industry to start raising the alarm bells about providers holding stored credit card data hostage. It's a huge issue with very serious implications. To address this problem, we created the Credit Card Data Portability Standard and invited all providers to participate (http://bit.ly/a0i86v).
We've been blogging about the industry for years now trying to help educate merchants. Here is are two resources to contribute to yours:
a) New to Payments - http://bit.ly/cIY58t b) Don't get duped. Use this checklist - http://bit.ly/dliMpH
Can you add an email to your profile, or shoot me one?
Really, it's good to have a human being reachable. I was at your site all morning, comparing you to Zuora, and this couldn't have come a better time.
[1] http://www.braintreepaymentsolutions.com/blog/data-portabili...
[2] http://www.braintreepaymentsolutions.com/services/new-to-pay...
[3] http://www.braintreepaymentsolutions.com/blog/dont-get-duped...
I know that for my own online shopping, I'm much more likely to purchase from a site that uses Google Checkout or Amazon payments than on that wants me to enter my CC information onto their own page. I figure Amazon already has my CC info anyway, and Google is more likely to have sophisticated security measures than joe-random ecommerce site.
I'm working on a business-oriented startup that requires credit card transactions, and part of my desire to have payments on my own site is because of the signal it sends out that you have your stuff together.
You tech people keep forgetting that reading a URL bar requires superpowers. I guaranteed you, having suffered many customer support incidents because of this: many people cannot tell the difference between getting redirected to Google/Paypal and the site they were originally on. (For that matter, a huge portion of my customers don't understand that I am not Yahoo or Internet Explorer.)
You may feel different about it but the average person doesn't.
Given that PayPal has more established accounts than Checkout or AMZN, my assumption is that those services would get even less.
I understand business' distaste for co-branded UI; it can be a jarring experience for users and it often feels unprofessional.
That's one reason.
Second, anyone who's ever been screwed by PayPal or Google Checkouts (they stole my money without warning) is going to be wary of it.
The most salient post is Part II, which helps people choose their gateways.
http://www.freshbooks.com/blog/2010/04/30/part-2-how-do-paym...
Speaking as someone who frequently has to call into the payment gateways' customer support on behalf of our customers who have hit a brick wall, personally, I like to keep life easy. I recommend PayPal Standard if you're doing less than $2000-$5000 a month in transactions, and then Authorize.net or PayPal Payflow Pro.
The other gateways are more complex since you cannot migrate the credit cards, and if you have recurring profiles managed on the gateway, you will have a harder time moving as you'll have to convince your customers to punch in their credit card again.
Give them a free month, or 5 free GB, or what have you.
The rate is a little high at our scale, but it's not quite to where it would be worth the developer man hours of switching yet, and I hear they'll give you a lower than published rate if you have enough volume and ask nicely.
If you're in Denmark I can recommend http://epay.dk as a provider, their SSL relay solution + some AJAX allows you to make really nice payment interfaces that are completely branded and integrated, without the hassle of PCI compliance for your site.
(As processor we use http://pbs.dk, because, well, there's noone else really.)
If you're in Denmark for instance,
1. Hire one provider, an expert, to handle everything for you - the merchant account, your billing logic (ex. recurring billing) and the payment gateway.
2. Get the best in breed for each layer in the stack. The Chargify/Recurly/Cheddargetter set is working to be the best in class at handling billing logic. For most online services the billing logic is quite complicated (and gets increasingly complicated over time) and something that the majority of merchant account providers / gateways are not historically good at handling.
Therefore, if you have an abnormally large average transactions size OR get paid mostly by other businesses, with their business cards OR have an abnormally large share of amex transactions, paypal will be more appealing from a cost perspective than it otherwise would be.
At TransFS.com we include them in the auction results because the answer of how paypal compares in price is actually different depending on your situation.
- Could we put together some type of invoicing system/coalition that lets users sign-up then pay by check? ie- you signup for a paid web service such as 37 signals/freshbooks/etc. Agree to pay by check. If payment isn't received within 15 days, the account is suspended. As a user, I'm pretty sure I wouldn't screw around with paying you since my data is important and continued access to the service. Businesses write checks all the time, especially for software purchases and services. This would pretty much eliminate the need for processing fees and all this crud. I don't know enough about ACH-debiting, but I believe there is no charge to do this. ie- you can do recurring payments on the bank account after one check is sent in.
Once again, this is only a suggestion for SaaS/business related apps.
As smartphones become ubiquitous, maybe we can go back to the cypherpunk idea of everyone having a public key.
It even explains the different types of accounts, and how the whole shebang works - incl. Ruby and JavaScript code samples.