
Introduction To Online Payments - TL;DR: It's A Total Bitch - arjunlall
http://blog.meatinthesky.com/introduction-to-online-payments-tldr-its-a-to
======
there
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.

~~~
sachinag
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.

~~~
enjo
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:)

------
sachinag
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.

~~~
mschaecher
I think a follow up is a great idea

------
zefhous
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.

Thoughts?

*<http://www.braintreepaymentsolutions.com/pricing>

~~~
patio11
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.

~~~
ctd
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.

~~~
itgoon
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.

Anecdotal, I know.

------
bryanjohnson
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:

a) New to Payments - <http://bit.ly/cIY58t> b) Don't get duped. Use this
checklist - <http://bit.ly/dliMpH>

~~~
mahmud
Bryan,

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.

~~~
bryanjohnson
bryan.johnson@getbraintree.com

------
theBobMcCormick
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.

~~~
paulhart
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.

~~~
leftnode
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).

~~~
patio11
_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.)

~~~
pbz
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...

~~~
detst
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.

------
sunir
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.

[http://www.freshbooks.com/blog/2010/04/30/part-2-how-do-
paym...](http://www.freshbooks.com/blog/2010/04/30/part-2-how-do-payment-
gateways-work-and-how-to-choose-one/)

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.

~~~
bvi
How easy/painful would it be to switch from PayPal Standard to Authorize.Net
or PayPal Payflow Pro, if the situation arises?

~~~
sunir
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.

~~~
ovi256
>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.

------
mattmaroon
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.

------
mrshoe
Suddenly the App Store doesn't seem so bad.

~~~
ibejoeb
That's pretty poignant. We pay dearly for it, but the App Store and in-app
purchasing is about as easy as processing payments can get.

------
quicksilver03
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.

~~~
henrikschroder
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.)

If you're in Denmark for instance,

~~~
quicksilver03
Thanks for the pointers, I should have mentioned that I'm in France so it
looks like they're not available to me.

------
seanharper
There are two philosophies:

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.

------
bcl
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.

~~~
seanharper
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.

~~~
billswift
According to this site, [http://www.merchantaccountblog.com/1027/a-comparison-
of-3-al...](http://www.merchantaccountblog.com/1027/a-comparison-
of-3-alternative-payment-methods) , which was linked from the original
article, the Google and Amazon payment systems have the same fees as PayPal.

~~~
checkvantage
CheckVantage offers a cost effective solution for electronic checks.

------
jasonlbaptiste
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.

~~~
seanharper
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.

------
braindead_in
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?

ref: <http://news.ycombinator.com/item?id=1314560>

~~~
dan_manges
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.

------
ck2
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?

------
jasonlbaptiste
This is where I see a pretty huge opportunity for facebook. Tie credit card to
identity and offer a simple yet robust payment system.

~~~
randallsquared
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.

------
ahoyhere
If you want to get into online payments with a lot less text, and a checklist
of what you need, try my cheat sheet:

<http://jumpstartcc.com>

It even explains the different types of accounts, and how the whole shebang
works - incl. Ruby and JavaScript code samples.

------
houseabsolute
OK guys, since it's a bitch, let's bitch about it, which will no doubt have
the effect of attracting some bitchin' bitches.

