Live data from Hacker News

Ask HN: How are lean startups easily accepting CC payments?

news.ycombinator.com

21–30 of 125 posts

Re: Ask HN: How are lean startups easily accepting CC payments?

#21

If you want something simple without writing much code, go with PayPal. You'd expect some "horror stories" from a payment processor with 232 million accounts. Virtually all of them involve someone doing something that'd raise flags at any merchant account provider or bank, it's just that people think PayPal isn't a bank so they should be able to get away with anything. 10,000 horror stories still leaves 99.99% of use…

Authorize.net also offers a hosted option so that the merchant doesn't have to deal with the burden of PCI compliance. In other words, the merchant (you) never sees the credit card number.

http://developer.authorize.net/api/sim/

Re: Ask HN: How are lean startups easily accepting CC payments?

#22

If you want something simple without writing much code, go with PayPal. You'd expect some "horror stories" from a payment processor with 232 million accounts. Virtually all of them involve someone doing something that'd raise flags at any merchant account provider or bank, it's just that people think PayPal isn't a bank so they should be able to get away with anything. 10,000 horror stories still leaves 99.99% of use…

Here's my horror story, let me know if you can figure out where I raised a flag because I can't. I was using Website Payments Pro with Spreedly for over a year, when I applied for access to their Adaptive Payments APIs. After getting approved a few days later, all of my spreedly subscriptions started failing with the error that I had to include the CVV. You can't store CVVs so it was now impossible to process recurring subscriptions with WPP.

Multiple calls to PayPal were useless. They told me that when I applied for adaptive payments, they reviewed my entire account and decided to require that I always include CVVs. In over a year, I had almost no chargebacks so fraud shouldn't be the reason.

The next day I applied for Authorize.net and was accepted the following day. It's about about the same price as when I was with PayPal, but with none of the hassle.

In summary, if you want credit card based recurring subscriptions, PayPal is just as expensive, significantly more restrictive, has terribly designed APIs, a sandbox environment that doesn't work as often as it does, and is kind of like smoking next to a barrel of gun powder.

Re: Ask HN: How are lean startups easily accepting CC payments?

#23

Are any of the solutions out there comparable to BrainTree? It's easy to process CC's, even recurring, but it's a pain to do PCI compliance. If the CC info hits your server, you're in PCI scope. BrainTree has the browser send the info direct to them, then redirects with a token you can use to check information and perform charges. Anything else out there like that? That is, all the flexibility of being able to run ch…

I am no expert on this, but from what I gathered of previous discussions of this topic, is that if you are serving the form HTML, you need some form of PCI compliance, even though the CC never hits your server. This makes sense as any XSS attack would allow an attacker to lift the CC straight from the page.

Re: Ask HN: How are lean startups easily accepting CC payments?

#24

I'm using Paypal Pro payments + Recurly. Between the ease of opening an account and ease of integration it made the slightly higher charges well worth it. Recurly doesn't have drop in django integration, but I'll eventually clean up and open source the subscription/registration app I'm using.

I am doing something similar with Spreedly. There is a Django app for it, but the API code is pretty messy (what do you imagine get_info() does?) If anyone is interested, I can post my API wrapper to github.

Re: Ask HN: How are lean startups easily accepting CC payments?

#27

My personal strategy has been to start out with paypal because it's super easy to integrate, and then when you have enough sales, upgrade to something like braintree. That way you wait until proof of concept and revenue before you put down money on a better solution.

+1

PayPal is _absurdly_ easy to set up and start collecting money.

You do though, need to understand that Papal's main business advantage over banks is their automated fraud prevention/detection - if you do anything that might come close to triggering their automated systems, you need to watch out. In my experience, that's almost always been accepting payments significantly before shipping something that can be tracked. Pre orders often get accounts locked. Non physically shipped products (thing "digital downloads" - software, music, or ebooks) often get accounts locked.

If you're not doing that kind of thing, or if you're doing it and are prepared to put up with Paypal holding on to your money until they believe your customers are happy, then PayPal is a reasonable solution (we have a client who starts accepting pre-orders for e new edition of his book every October, and PayPal hang on to _all_ money put into his PayPal account until 3 or 4 weeks after the books start shipping in early January. This has been going on for 4 years now, exactly the same every year, but the client is perfectly happy with that situation, he's mainly accepting pre-orders as a way to more accurately guage how many copies to print in the first run, he doesn't need to have the money up front but it's a great way for him to know really firm minimum order numbers for the first print run. It's only when he gets drunk over Xmas/new year and starts ringing PayPal up and screaming "give me my fucking money!" at anyone who answers the phone that it's a drama, unfortunately _that's_ been going on for 4 years now too...

Tl;dr, use PayPal to start with. Never leave more money in the PayPal account than you're prepared to lose. Never leave that money in a bank account linked to PayPal either. Make sure you've got a backup payment method at least planned, that you can switch in sufficiently quickly that you don't go broke between when PayPal cuts off your money and the new payment system is in place (that means get your merchant account and Internet merchant ID applications in process _now_, not after you have a PayPal problem.)

Re: Ask HN: How are lean startups easily accepting CC payments?

#28
We went through this recently and decided that Braintree was a nice one stop shop. Great hand holding through the set up process and lots of api/library support out there.

You can always decide to put Chargify on top of that if you want. Bonus -- if you end up getting a merchant account with your existing bank you can swap that in later. (Though you probably will get a better rate w/ Braintree).

Re: Ask HN: How are lean startups easily accepting CC payments?

#29
post #21

If you want something simple without writing much code, go with PayPal. You'd expect some "horror stories" from a payment processor with 232 million accounts. Virtually all of them involve someone doing something that'd raise flags at any merchant account provider or bank, it's just that people think PayPal isn't a bank so they should be able to get away with anything. 10,000 horror stories still leaves 99.99% of use…

Authorize.net also offers a hosted option so that the merchant doesn't have to deal with the burden of PCI compliance. In other words, the merchant (you) never sees the credit card number. http://developer.authorize.net/api/sim/

As does E-xact:

http://www.e-xact.com/hosted-checkout/

Post reply on HN