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

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.

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.

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 ;)

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/