What is the best credit card processing setup for startups?
24 comments
PayPal is good if you don't want the hassle of dealing with credit card numbers and the real meat of the credit card processing business because PayPal does it for you. All you have to worry about is giving a link to your customers to pay you via PayPal and you have the cash. The big disadvantage of PayPal is lack of control; they can hold your cash at anytime and big as they are it can be a while before you get it sorted out. Additionally you are very limited as far as how much you can customize the payment page. Now with the paypal api I think you have more control than when I used em.
Now lets talk about the real cc processing setup. It involves three parties: merchant, gateway, signing bank. Usually, when you signup with a merchant they will set you up with the bank they have a deal with so you can accept credit cards. The gateway is authorize.net. Authorize.net will be the interface between your customer's CC info and the bank that actually does the transaction.
Ideally for long-term you'd want to use a real merchant. But for starters, paypal should be a good option for you.
Now lets talk about the real cc processing setup. It involves three parties: merchant, gateway, signing bank. Usually, when you signup with a merchant they will set you up with the bank they have a deal with so you can accept credit cards. The gateway is authorize.net. Authorize.net will be the interface between your customer's CC info and the bank that actually does the transaction.
Ideally for long-term you'd want to use a real merchant. But for starters, paypal should be a good option for you.
PayPal accepts credit cards from a very limited number of countries. It is West-centric, in other words.
PayPal or Google Checkout are both good ways to start out with. But depending on the volume of transactions and the amount of control you want you may want to go with your own merchant account. They are not hard at all to set up. Talk to your current bank to see if they have an arm that deals with merchant accounts. Most banks that offer business accounts either have their own or partner with a third party to provide the services to customers. Note that you will need an SSL certificate if you go with a merchant account. Id recommend VeriSign ( they will also most likely end up being your Payment Gateway if you do decide to set up your own merchant account). Their SSL certificates are a bit pricy, but the most trusted name in the business. You want to make sure you get a low processing fee (percent of the transaction that the bank ends up taking shoot for under 2% and a low per transaction fee (shoot for 20 cents or lower hard to find). After a lot of shopping around, we ended up going with Bank of America. Best of luck!
Google checkout currently has a deal where all credit card processing is FREE for the rest of the year!
https://checkout.google.com/sell
https://checkout.google.com/sell
Don't forget to check the content policy,
http://checkout.google.com/seller/content_policies.html
Google's looks straight-forward, but sometimes providers have uncommon restrictions in there. eg, the "Travel packages and offers" wouldn't be immediately obvious.
http://checkout.google.com/seller/content_policies.html
Google's looks straight-forward, but sometimes providers have uncommon restrictions in there. eg, the "Travel packages and offers" wouldn't be immediately obvious.
Google Checkout and/or PayPal until you handle enough volume to justify the hassle of something else. Authorize.net makes you go through a reseller, and the resellers are less competent than a poorly trained chimp. It took me two months to get through the process:
"The merchant account provider needs to see your website."
"OK, here it is."
"No, they need to see the shopping cart."
"What!? We don't have merchant services yet. We're not going to put up a shopping cart that people can't order from!"
"They won't set it up until they see the shopping cart."
"OK, fine. Here's the link."
"They said they went to your site and didn't see a shopping cart."
"I sent you a link to the shopping cart. It isn't visible on the index page yet, because we can't take orders."
"Oh. It has to be the real website."
"Huh? It is the real website. I just haven't linked it from the front page...we already have users, I'm not going to confuse them with a shopping cart that doesn't work."
"It has to be a real website."
"You're kidding, right? Just send them to this link. I'm certain they'll be able to figure things out."
"OK. They said there is no terms of service or refund policy clearly linked from your front page."
"We don't sell anything yet. Why would we have those things on our front page? They're linked off of the store link I sent you." (This is the second time I've setup merchant services, and I knew they would need to see those things. It's not like they give a shit what they contain...they just insist they exist.)
"They have to be on the front page."
And so on. I won't bother to type in the exchange we had over the resellers first attempt to actually setup the username and password, or the fact that all payment information had to be faxed in. (Yes, you read that right. The reseller for Authorize.net that we went through would not accept payment online. And the form that was online was just a ruse...they made us fill out the exact same form again and fax it in.)
Next time I build a shopping cart, I'll spend that time writing a payment backend for a payment processor that isn't operated by the functionally retarded. Or maybe I'll just use Google Checkout instead, and let them worry about the banking industry monkeys.
"The merchant account provider needs to see your website."
"OK, here it is."
"No, they need to see the shopping cart."
"What!? We don't have merchant services yet. We're not going to put up a shopping cart that people can't order from!"
"They won't set it up until they see the shopping cart."
"OK, fine. Here's the link."
"They said they went to your site and didn't see a shopping cart."
"I sent you a link to the shopping cart. It isn't visible on the index page yet, because we can't take orders."
"Oh. It has to be the real website."
"Huh? It is the real website. I just haven't linked it from the front page...we already have users, I'm not going to confuse them with a shopping cart that doesn't work."
"It has to be a real website."
"You're kidding, right? Just send them to this link. I'm certain they'll be able to figure things out."
"OK. They said there is no terms of service or refund policy clearly linked from your front page."
"We don't sell anything yet. Why would we have those things on our front page? They're linked off of the store link I sent you." (This is the second time I've setup merchant services, and I knew they would need to see those things. It's not like they give a shit what they contain...they just insist they exist.)
"They have to be on the front page."
And so on. I won't bother to type in the exchange we had over the resellers first attempt to actually setup the username and password, or the fact that all payment information had to be faxed in. (Yes, you read that right. The reseller for Authorize.net that we went through would not accept payment online. And the form that was online was just a ruse...they made us fill out the exact same form again and fax it in.)
Next time I build a shopping cart, I'll spend that time writing a payment backend for a payment processor that isn't operated by the functionally retarded. Or maybe I'll just use Google Checkout instead, and let them worry about the banking industry monkeys.
You can't really complain about the fax. Getting a merchant account is a sensitive thing so I totally understand each time I have to fax my id with the application. Just part of the process.
PaySimple is another good one for Startups. They have a great API, can handle recurring billing, stores the CC info and are good about letting you take the data with you if you wanted to go to another service. Wufoo is probably going to move over to them from Authorize.net (which is also a decent service that just implemented recurring billing).
Costco has very cheap rates, not sure how good they are as far as integrating with web services. ~$50 a year for the Costco membership, then 1.99% + $0.27 per transaction plus a $20 minimum monthly charge.
http://www.novainfo.com/costco/index.asp
http://www.novainfo.com/costco/index.asp
Google Checkout has rates of 2% + $.2 per transaction with no extra/hidden fees.
The rates start in 2008. It's free 'till the end of the year.
If your startup is looking for an Asian market, you can try PayDollar. I used PayDollar at Fleur.hk http://fleur.hk/ , which is a WebObjects site I made for a flower shop.
They offer Paypal style redirection but the meat is their API which does not cost extra. The trick part is, you have to ask and you have to implement your own POST routines if you are not using Java. Wouldn't be hard if you are a STARTUP right?
Most Asian based cc gateway only needs CC number, name and expiration date for transaction, which is a "plus" to get you paid. You have to be careful about potential fraud though.
They offer Paypal style redirection but the meat is their API which does not cost extra. The trick part is, you have to ask and you have to implement your own POST routines if you are not using Java. Wouldn't be hard if you are a STARTUP right?
Most Asian based cc gateway only needs CC number, name and expiration date for transaction, which is a "plus" to get you paid. You have to be careful about potential fraud though.
I am using another Asia Payment Gateway comapny called <A href="http://www.paymentasia.com">PaymentAsia </A> and they have the 3D secure with Visa/ MasterCard. Is it good or not?
Paypal has a service called Website Payments Pro. I used it on a past venture and it was great. It was cheap to setup and maintain.
It is a transparent solution too, so you don't redirect users to the Paypal site unless they are paying by Paypal. Credit card payments are done from your site via a webservice.
It is a transparent solution too, so you don't redirect users to the Paypal site unless they are paying by Paypal. Credit card payments are done from your site via a webservice.
what do people recommend for handling subscriptions/automatic recurring billing that can change over time?
I decided to use RightCart. Its not a perfect solution, but its cheap and easy and I am going with it for now. I have disccussed it here before http://news.ycombinator.com/comments?id=8060
I have been researching this for a while, and have been mostly confused. The obvious answers I have seen are authorize.net or paypal's services. But what is the ideal setup for a new company with not too much money in the bank?
For my summer startup, I'm going with Google Checkout. My alternative was PayPal Payments Pro, but the documentation is horrible which makes integrating difficult.
Go with a merchant account if you're going to be doing any regular commerce/membership, but don't neglect paypal/google checkout as some people may prefer them.
I'm using authorize.net at the recommendation of board member/successful business owner.
PayPal can be great as well because it is so easy.
PayPal can be great as well because it is so easy.
Are there any limitations with Google Checkout? Such as accepting credit cards only in US? Heard a rumor about that...
authorize.net - its not that hard. I was actually surprised at how easy it was to set up. If you are doing a consumer site paypal looks sort of amateur - remember the people who are coming to your site don't necessarily need to kmow that its 2 guys in a spare bedroom.
When accepting credit cards you'll also need a SSL (Secure Socket Layer) or in other words a secure connection (https://). I think they will actually allow you to use their api without that but it's definitely a horrible idea. There are a few major providers of this service, and they range in price significantly. www.InstantSSL.com or "Comodo" as they call themselves, has a pretty decent mid range SSL encryption package for about $100 a year. Godaddy.com has one that's like 19.99 or something ridiculous. The issue with SSL providers is simple. You can bet that they are all perfectly secure. The issue is really in browser recognition. The worst thing ever for an online merchant is to loose credibility, and what's the fastest way to appear disreputable - ""this site may not be secure, internet explorer recommends that you leave it immediately" or what ever that error says. This happens when a browser doesn't recognize the security certificate. To be safe, go with a provider that you can guarantee is trusted by all the major browsers (even old versions).
Also - one last piece of advice. When subscribing for a SSL certificate make SURE to turn your domain anonymity off temporairly while you subscribe. Otherwise they'll put you through an endless "verification" process that involves multiple faxes and endless bureaucracy!!!