Ask HN: Recommended way to receive customer payments when just starting up? | Hacker News Reader

Ask HN: Recommended way to receive customer payments when just starting up?

10 pointsdxjones18 comments

What do YC startups recommend?

PayPal? Google Checkout? Credit Card? (merchant account), Other?

Which provides the minimum hassles, delays, transaction fees, etc.? Which do customers prefer?

Any positive or negative recommendations based on experience would be much appreciated.

When I started http://www.learnitfirst.com/ originally, we only accepted PayPal. I did it this way because getting a merchant account seemed like a big deal+hassle (at the time). After we integrated PayPal, we added Google Checkout which was a collosal waste of time. We now accept credit cards directly.

I'd say that my customers 10:1 prefer to pay by credit card. If I didn't offer credit cards as an option, I figure I would have 20-40% fewer sales. That being said, get up and running first and foremost - that's what I think. You can always add credit cards. I think PayPal, for my customers, is an important option. Since it was the easiest of all to implement, I'd say start with it.

Thanks: PayPal first. Credit Cards second.

What made Google Checkout a collosal waste of time? Do customers choose not to use it? Or is it a hassle to deal with on your end?

We signed up for Google Checkout the first day we could. The integration was actually very easy but the problem was, for every five real transactions, we received one chargeback. That was incredibly high considering that, in 4+ years, we've only had a handful for PayPal.

Could you please drop a few words on how you fight credit card frauds and chargebacks ? This is the real and the only problem with CC processing we faced. We could not handle it, so our merchant account was blocked six months after we started due to high ratio of frauds. So now we accept through Paypal and Google Checkout only. Everyone who is going to start accepting credit cards directly must pay a thorough attention to CC fraud problem and there is no any ultimate solution for it.

Chargebacks through PayPal are almost non-existent. I think that in four years we've probably had a handful literally. Chargebacks through Google Checkout were so bad that we dropped them.

We went with Authorize.net as the gateway and another company for our merchant account. A lot of chargebacks can be handled by setting up your risk controls up-front correctly. Should the postal code be required to match? Should the card verification code be required? Those types of things have more to do with it than anything IMO.

It matters a whole lot what sort of payments you need to take. Is your payment model a sale (one-time transaction) or recurring billing?

If you're going to take credit cards and/or do recurring billing:

I've built two recurring billing payment systems (braintree and paypal express checkout) and maintained a third (paypal payflow pro gateway) and am most impressed with braintree's api thus far. http://braintreepaymentsolutions.com/ My braintree-based system hasn't gone live yet, so I can't say anything about long-term service, but their api was far more sane than the other two. That said, when we added express checkout to the payflow pro gateway, purchase rates increased substantially.

There are monthly minimums with braintree and a good bit of paperwork, but being able to directly take credit cards might add some degree of "seriousness" in the consumer's eyes.

If you're rolling on rails, you might want to check out http://railskits.com/saas/ (although I have no personal experience with them) and http://www.activemerchant.org/ (a payment library extracted from shopify).

If you're just doing one-time sales, you have a lot more options and the accounting is a heck of a lot easier.

Do you know what the monthly minimum for Braintree processing was? The last quote I got from them was $200/month if you're processing under $1mm/year. I've also heard of a couple recent cases in which it was negotiated down to $100 though.

I do think it's $200/mo, but as far as we've been able to tell, it's perfectly legitimate to run our own $200 transaction and pay the processor fee (a few bucks a month on $200). We've only had our merchant account for ~1 month, though, so I'll be able to tell you more at the end of the month

You can seamlessly accept credit cards and use PayPal as your backend processor. To your customer, it looks like you jumped through all of the hoops of a merchant account, but you're really just interacting w/ PayPal's API.

They also provide a virtual terminal so you can accept credit card payments via phone//fax.

I think they call it website payments pro and it costs ~$30/mo depending on volume.

PayPal is by far the most cost-effective way (in terms of % rates) to get up and running - compared to the time and costs involved in setting up a merchant account/payment processor.

As Aaroneous mentioned- Paypal Website Payments Pro allows you to process paypal payments and credit card charges invisibly in the background (there is no redirect to Paypal).

The processing fees/cost economics of establishing a merchant account/processor definitely make sense however once you're processing several $k/month.

In my startup (http://industrialinterface.com), we started by manually creating invoices in Paypal and emailing them out. That got lukewarm response.

I'm the lead dev, so I buckled down and figured out the merchant stuff. There can be 1-2 weeks worth of delays in getting your merchant account, but our admin guy said it was pretty straightforward. Took me about a day or 2 to figure out the response codes and to program the cc processing.

In short, take the jump and just process your own CCs (assuming that you have the legal structure in place so that you can get a merchant account. If not, use the Paypal API). Took about 2 days of learning and coding to figure out cc processing (and the Authorize.net interface ain't the greatest).

Fees are all about the same, so unless your margins are under a percent, don't worry about the fees. And if your margins are that low, rethink your business model ;)

we are a startup and we are going with paypal for now. We will move on to authorize.net after a couple of months and then to merchant account.

I would work on a relationship with a bank, and get a merchant account. There are many providers that offer low enough rates for a startup. One that I heard of was Merchant Plus. Just get someone that supports authorize.net and you can't go wrong. This might take a little time, so I would recommend using Paypal AND Amazon payments WHILE you're getting this setup, since they seem to be easier to implement. I WOULD NOT however start with these initially, and not put any effort into a merchant account. You WILL need a merchant account eventually (if you're successful), so you need to already be working on it.

Another note if you're doing recurring billing: Check with your payment provider if you can get your customer payment data out ever. At my previous startup, we were locked into PayPal because they wouldn't release the consumer CC#s and it's never good for business to have to ask your customers to input their payment info a second time (attrition is inevitable). This time, we did a bit more research and our two top payment services (braintree and trustcommerce) both allowed full data portability (with a fee).

i don't like paypal much, so i'd probably use amazon's FPS

http://aws.amazon.com/fps/

Can you give more details about why you would recommend Amazon FPS over PayPal?

almost purely reputation. i know people who have gotten specifically screwed by paypal. frozen accounts, sized assets. have yet to hear that about amazon.

http://www.codelathe.com/blog/index.php/2009/06/14/a-brief-c...

Reply on news.ycombinator.com