
How do you process credit cards? - pchristensen
http://www.37signals.com/svn/posts/753-ask-37signals-how-do-you-process-credit-cards
======
tptacek
This is a great 37s post, less about how a tiger manages to stalk its prey and
more about how a multicellular animal manages to drive its Krebs cycle.

Note that a really important code issue is buried in the comments here, with
DHH following up to clarify: you have to decide whether you want to store
credit cards, or enroll them with your payment processor gateway.

I have an opinion here, as one of the people the payment industry sends out to
punch unwitting developers in the kidneys: _don't store credit card numbers_.

It's not just that you have to follow "PCI guidance" (which changes at an
average rate of once every 18 months). It's that you become liable for PCI
auditing at some unknowable point in the future. PCI audits are not one of our
industry's great technical success stories; imagine an IRS audit where the
auditor had an upsell interest in making you fail, and you're getting close to
the mark.

~~~
jacquesm
Second that. I am fairly closely involved with a company that does just that
and the amount of rules and regulations borders on the draconian. The only
thing missing is armed marines in front of the server room access doors.

This is one of those instances where if your volume is < $1,000,000 per annum
you probably shouldn't even be thinking about doing your own acceptance of CC
data.

Just hand it off, pay a couple of % and get on with doing what you're good at.

~~~
robotron
Does the company you're involved with do PCI compliance auditing?

~~~
jacquesm
They are a VISA/MC authorized reseller working together with Paysquare in the
netherlands, I'm not going to name them because I would not want to recomend
any compay that I'm affiliated with, that's too much like advertising on a
site like this.

So, no, they don't do the audits themselves but they have been audited several
times over the last 8 years, and so far they have passed their audits with
flying colours.

The people running that business take it very seriously, they process about
150M$US annually and they have it set up so that every customer has their own
merchant account.

This is contrary to most IPSP's that multiplex a single (or several) merchant
account(s) across many merchants, which I personally believe is a recipe for
disaster. For more information on what can go wrong have a look at 'IBill' and
'DMR'.

This does mean that it is much more expensive to set up a customer but the
good news is that it actually is a lasting relationship instead of 'until we
get yanked'.

~~~
robotron
Understandable (avoiding the appearance of advertising). I actually need
auditing and was being lazy about shopping around.

tptacek, you're right about life being too short for that BUT in some cases an
entity really does need to ensure compliancy.

~~~
tptacek
Just don't get rolled. I can refer you to some reputable companies, if you'd
like.

------
axod
Seems like there's room for more startups in this area - paypal/google
checkout/etc.

I don't want to re-implement a billing system, I just want to tell some API
"This person should be paying X per month, let us know via some callback if
they don't."

With all this sudden hyping of charging for web based software, you'd think
there would be more choice out there.

~~~
villiros
PayPal's basic business account has subscription functionality. It does
exactly what you described: you send a customer to PayPal, indicating what
their billing cycle is and how much they should be charged. Once they payment
goes through, paypal notifies you (via IPN callback) that the subscription
should now be active. Once it expires (due to limits you have put in, or
because the customer cancels, or if their payments fail), paypal pings you and
you can update stuff on your side.

It's actually very easy to integrate, and provides a very good functionality
set. It even has trial periods and such.

I imagine Amazon's payments system can do similar things.

~~~
axod
Hmm ok, thanks for the info. I'll have to look into that.

------
ropiku
DHH on twitter: "We haven't stored CC numbers on our own for quite some time.
We're using Braintree Payment Solutions these days."
<http://twitter.com/d2h/status/1184653105>

~~~
dasil003
We recently made this exact switch from Authorize.net to Braintree.

Being less than a year old, we were able to take advantage of Authorize.net
CIM (Customer Information Manager) to store credit cards. It worked pretty
well, except for the API seems to lack some basic features. For instance, if
you happen to lose the id of a customer profile, there is no way to ever
recover or delete the profile. It will just remain inaccessible (and blocking
duplicates) forever. Additionally the API is bolted onto their old API, so you
have to check two fields for error responses, etc. Definitely a solid system,
but sort of rough around the edges.

Now as of this past December we decided that it was a priority to
internationalize billing for our app. We have partners in Europe and have even
received grant money there. Long story short, we needed to be able to bill
Europeans in Euros. As it turns out, quite a few gateways advertise billing in
foreign currencies, but the majority convert the currency internally and then
bill in dollars. Well you can imagine that if you're in Europe and you
purchase something for €5, but the gateway converts to dollars (at an
unfavorable rate) and then bills your account in USD (incurring a second
unfavorable rate), you're going to be pissed when you see a €7 charge on your
statement.

In our (admittedly rapid) research, for any kind of low to moderate volume of
transactions, Braintree is the only gateway that will actually process
multiple currencies directly. We made the switch, and processing payments in 3
currencies as of 24 hours ago. The Braintree API (standard POST) is dead
simple compared to Authorize.net (SOAP) and yet doesn't feel any less
powerful.

------
mhb
What Phil Greenspun has to say about processing credit cards:
<http://philip.greenspun.com/panda/ecommerce>

------
Hexstream
In the article they talk about how they initially wanted to charge a per-year
fee but eventually had to charge a per-month fee, but anyway the better
granularity was better for everyone in the end.

Now I'm thinking, what would it take to reduce the payment granularity to 2
weeks? 1 week? 1 day? 1 hour? 1 minute?

I mean, we already have compound interest, which calculates interest
continuously and precisely over time (I think). Why couldn't we have the same
for payments?

Now I know that "micro-payments" aren't a new idea and it must be a really
tough challenge but if someone has some knowledge of the different
difficulties I'd love to see them spelled out.

~~~
ja2ke
The smaller the granularity the more likely it is you'd need some sweeping
change at the top of the chain -- at the CC providers, banks, processors. Most
services charge you for every authorization request you initiate, let alone
successful or failed transactions, so you'd have to be charging a very high
rate for your service to be authing a card once a minute.

~~~
jonknee
Not only that, but that many authorization attempts would immediately trigger
fraud filters and the account would be locked.

------
braindead_in
What if the business is not setup in US? Do you need a bank account in US if
you want a merchant account?

~~~
laut
You don't need a US business and bank account to accept credit cards. That
would be a major hassle for all the businesses outside the US.

There are credit card gateways in other countries.

~~~
budu3
Does Authorize.net only work with US bank accounts or do you need to get a
local card gateway for the country in which your bank account is located?

------
debt
He doesn't mention a merchant service provider. Does this mean he deals only
with the bank?

~~~
tptacek
Aren't they getting that from Authorize.net?

~~~
aston
Authorize.net, basically just an API front for the real money handling, is
only available through 3rd-party resellers. My best guess is that 37s's bank
is one of those and is also providing the merchant account.

I know that you can just grab a merchant account and then find a reseller for
Authorize separately, but it just seems easier to take the package deal from
someone, and banks are safer than some random Authorize reseller on the web,
IMO.

