How do you process credit cards?(37signals.com)
37signals.com
How do you process credit cards?
http://www.37signals.com/svn/posts/753-ask-37signals-how-do-you-process-credit-cards
7 comments
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.
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.
Third that. I used to work at a company that processed a high volume of payments. It's a pretty big pain to be PCI compliant, from restricting access to any server that handles payment information, to managing who can access what information. Like the parent said, unless you're doing multi-million dollar business, it's probably not worth it to handle this on your own.
Does the company you're involved with do PCI compliance auditing?
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'.
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'.
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, you're right about life being too short for that BUT in some cases an entity really does need to ensure compliancy.
Just don't get rolled. I can refer you to some reputable companies, if you'd like.
(You weren't asking me, but I may have implied it earlier --- we definitely don't do PCI certification work; life's too short to waste on a bunch of checklists.)
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.
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.
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.
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.
Hmm ok, thanks for the info. I'll have to look into that.
Spreedly seems like a potential option as well.
WorldPay do this.
PayPal's PayFlowPro can do basically that. No callbacks, you have to poll them.
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
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.
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.
What Phil Greenspun has to say about processing credit cards:
http://philip.greenspun.com/panda/ecommerce
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.
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.
The main difficulties are the high per-transaction fees and the reasonably large percentage revenue cuts all of the concerned parties take from you. The more you charge, the larger the percent of your revenue you keep.
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.
Not only that, but that many authorization attempts would immediately trigger fraud filters and the account would be locked.
probably because of those fixed processing fees that you get charged...plus you'd have the stuff show up more than once on the credit card statement
What if the business is not setup in US? Do you need a bank account in US if you want a merchant account?
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.
There are credit card gateways in other countries.
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?
He doesn't mention a merchant service provider. Does this mean he deals only with the bank?
[deleted]
Aren't they getting that from Authorize.net?
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.
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.
No. There's a misconception that money is immediately deposited into your merchant account once a transaction is authorized and captured.
In fact, there's a middle man called the merchant service provider which holds your funds and deposits them to your merchant account. They are contracted out by your bank.
A transaction is sent through Authorize.net to the msp then through to the customer's bank.
In fact, there's a middle man called the merchant service provider which holds your funds and deposits them to your merchant account. They are contracted out by your bank.
A transaction is sent through Authorize.net to the msp then through to the customer's bank.
Didn't they mention Chase?
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.