TL;DR indeed. it doesn't have to be that complicated.
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.
Billing can get complicated if your customers are other businesses and need proper invoices and account statements for tax purposes, not to mention managing coupons, refunds, expired credit cards, credit card failures, account suspension rules, etc. which apply to all classes of customers.
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.)
Ha, looks like Bryan owes you a beer for this ringing endorsement. :)
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.
Well, he may be the exception but it lines up with my experience (also Braintree). I think I've spent a grand total of 1 day on our billing system. We do threshold billing, monthly subscription, and one time payments. We use the Braintree vault and everything just sort of works.
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.
Last I checked, Braintree doesn't want most startups - their site says they didn't want anyone under a threshhold of $LARGENUM per month. I recall it being quite high for a non-existing service - like $20k to $50k.
Braintree seems to simplify the work by a lot. On the other hand, use another provider, and PREPARE TO SUFFER!
We (Braintree) now work with companies of all sizes, including a lot of startups, and have no volume requirements. In the past we did have volume requirements. We were a smaller company then and were trying to balance maintaining a high quality of service when working with more leads than we could handle. We'll be blogging about this in greater detail.
Wow, top story on HN. Thanks, folks! I wanted to call out a number of things I glossed over to see if it's worth doing a follow up or seventeen:
* 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.
What frustrates me is that it's just so expensive to get started... I know that it's "just the cost of doing business" but it really bothers me that you have to give away ≈%3 of your revenue to get paid.
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.
Use Paypal & E-junkie for your first few months and sell folks lifetime subscriptions to your service. $5 a month for e-junkie (not strictly necessary but it will save you a few hours of integration work), ~3% for Paypal.
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.
My only concern about this would be selling lifetime subscriptions for an embryonic service. What if it fails? This may be built into the terms, but it could also sour customers on your future offerings (or hurt your personal brand).
Otherwise, this seems like a good strategy for testing the waters with a new product.
My own view on "lifetime" anything is that I'm taking a gamble on whose lifetime is longer, and consider that when choosing that option. Ultimately, the amount I pay comes down to how long I think the company/product will last.
You're right to a degree, but don't you wish there was another way?
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...
Sachin - the online payments industry is indeed very complex. I'm impressed that you both took the time to write this up and did such a nice job. I would add a few things. (Disclosure: I'm with Braintree)
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:
I'm not sure why so many of these guides seem to operate under the assumption that having the transaction happen on someone else's server (ie, traditional Paypal, Google Checkout, Amazon Payments, etc.) is a bad thing. I would think it'd be a good thing. Google and Amazon in particular are well known and trusted brand names that most customers likely already do some amount of business with.
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.
That's true from a rational perspective, but people aren't rational. They have expectations of a nice, consistent experience that doesn't bounce them from one service to another.
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.
Honestly to me it sends the opposite signal. Like I said, I see your site and think "what the f* is this joker gonna do with my CC info?". I see Google Checkout or Amazon and thing "big established company who already has my CC info anyway!".
Precisely it. Everyone knows anyone can throw up a Paypal link, but to have the transaction go through on your site makes it feel more official. Sure, it's not completely rational, but people sometimes like it better (alternatively, some people will only pay through Paypal, but unfortunately I can't sell my merchandise through Paypal/Google/Amazon).
to have the transaction go through on your site makes it feel more official
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.)
I agree with noticing the URL change, but what's a lot more noticeable is when the look of your site changes. They're used to your site's look and feel. When you direct them to a different site, even if it sort of looks like the original site, it's a big speed bump in the flow. Makes you stop and think (hey, what's going on?!) and question if you're in the right place (did I click the wrong button?!). You may even get suspicious and leave. You'd probably feel the same if at a supermarket when it's time to take out the card and pay, within seconds the building changes, the cashier is no longer there, the door you came through is gone, the lightning is different, the people who surrounded you disappeared; only the colors sort of look the same...
In my experience, some level of similarity (colors) is all that really matters. People have no problem accepting that the shopping cart and check out experience might be a little different.
You may feel different about it but the average person doesn't.
This is true. But it precludes you from doing two-click checkouts on the second transaction (wink wink) and real users really don't have a problem whipping out their credit cards on a new site.
Offsite checkout has a bad reputation for decreasing conversion rate. It would be interesting to have a really scientific a/b test, but the results will also differ between different customer bases.
If your customers pay with PayPal, and it's a subscription, they cannot cancel their subscription from within your app. They will have to log into PayPal and do it directly there.
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.
If you want another perspective on this, we have to answer these kinds of questions a trillion times a week at FreshBooks. We're posting a guide to help people get through it.
The most salient post is Part II, which helps people choose their gateways.
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.
Moving from PayPal Standard to anything is pretty easy since for most people it's a very simple payment service.
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.
We use PayPal Payments Pro. We do pretty solid volume with them, and have never had any holdbacks, or any problems at all. Our fraud is very low (if you steal a credit card, you aren't going to waste it on virtual coins in a Facebook game, you're going to buy things you can sell on eBay) which may be why.
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.
I'd like to know if someone has pointers to a similar writeup but focussed on Europe rather than US. AFAIK neither Google Checkout nor Amazon Payments are available in Europe, but I'd love to be proven wrong.
You can't do a EU-wide guide easily, because you will need a merchant account at a bank in your country (and you typically can't use one from another country), and you will need a processor that can work with that bank (which will typically be a processor from the same country) and finally a provider that can work with that processor, again, mostly country-bound.
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.)
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.
Just use PayPal. I've been using them for years with zero problems. Their fees work out to be about the same as I'd pay for a merchant account, but without all the development hassle. There is also a new player on the block, http://www.gunpal.com, which I'm looking to add as an option just on principle -- they don't discriminate based on what you are selling or buying like PayPal does.
Paypal has a pretty high per-item fee of 0.30 / transaction and a reasonably low (and fixed!!) percentage fee of 2.2%-2.9%.
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.
is there some new innovative way around this problem specifically for SaaS/ web apps that charge businesses? (Ecommerce, consumer purchases, and virtual currencies are different beasts).
- 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.
Why not just do an ACH transaction? ACH is problematic because it is not very secure, but for subscription software can be a good solution since there is no cost of goods.
What about the requirement that any code that touches CC payments has to be PCI compliant? Doesn't these leave only PayPal and Auth.NET as the only option for smaller players?
If you use an API like Braintree's Transparent Redirect ( http://bit.ly/d5wD4P ) you can host the payment form on your site without touching any credit card data. That way you won't have to deal with the drawbacks of redirecting your customers to a third party hosted page. Disclosure: I work for Braintree.
Good article but could the site owner check their logic with using light grey text on a pure white background. The lack of contrast is killing my eyes... anyone else?
The fact that I'm constantly getting friend requests from facebook accounts which are pretty transparently not real people does not reassure me about the idea of facebook doing identity verification with consequences.
As smartphones become ubiquitous, maybe we can go back to the cypherpunk idea of everyone having a public key.
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.