

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

What do YC startups recommend?<p>PayPal?  Google Checkout?  Credit Card? (merchant account), Other?<p>Which provides the minimum hassles, delays, transaction fees, etc.?  Which do customers prefer?<p>Any positive or negative recommendations based on experience would be much appreciated.
======
ScottWhigham
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.

~~~
ruslan
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.

~~~
ScottWhigham
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.

------
jbr
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.

~~~
jwt
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.

~~~
jbr
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

------
aaroneous
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.

------
jwt
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.

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

~~~
ujjwalg
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.

------
oomkiller
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.

------
jbr
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).

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

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

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

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

------
codemechanic
[http://www.codelathe.com/blog/index.php/2009/06/14/a-brief-c...](http://www.codelathe.com/blog/index.php/2009/06/14/a-brief-
comparison-of-internet-payment-options/)

