Ask HN: how do you process payments?
I'm starting to research payment processing systems for my startup, and was hoping to get some feedback from some HN readers who have had some experience with some online merchant service providers.
Which payment processing provider do you use? And how would you describe the quality of your service?
Google, Yahoo, and PayPal all provide this service, and they all charge similar fees. How do they stack up against each other?
Also, the ability to charge for recurring payments (subscriptions) is important to me.
Thanks!
50 comments
[ 3.8 ms ] story [ 109 ms ] thread1. PayPal subscriptions are an under-documented mess. I was hoping to get a trial going with their subscription quickie form builder but couldn't figure out how to get return data. I'm sure this is possible, but it all seemed more like it was setup for magazine subscriptions than for online subscriptions.
2. Zuora is a company that keeps getting mentioned on TechCrunch and had given me the impression it was subscriptions done right, where right is simple API and simple setup. On investigation, they're only open for private beta and they seem more like a "solution" provider where you're going to have to talk to a salesperson to get anywhere.
3. If you mention Zuora on twitter you will be contacted by a company called Aria Systems. In order to see their API they will say they "need a signed NDA as our API's are mature proven and we guard them like the family jewels."
4. Spreedly seems a little bare bones but is the only company out of that bunch that seems to share my sensibilities.
I would love to hear an authoritative answer. If you were building a subscription based service like Basecamp, what would you use to start?
PayPalTech has a nice script generator that outputs a simple PHP script that gets data from PayPal's API after a purchase/subscription is processed, I'm a terrible coder and I was able to get all the data I needed pretty easily.
https://www.paypaltech.com/PDTGen/
Hardly convenient if you don't already have an account. The layers of sign-up added to the process creates too many hoops to make users jump through.
It's almost like a loophole, finding something so dead simple that doesn't require you to run SSL at your end. If only they could roll that interface out to their other payment products.
Their web site is a bit confusing.. as a consumer, it seems that they offer me P2P micropayment services. As a developer, it seems like they just offer me the ability to bill people.
What if I want to write an application that wraps around their P2P services? (Like an "Email Money" application)?
Sounds like your app is exactly in the target zone for FPS - I just wish they hadn't neglected the more conventional use cases!
I'm using them from the EU. ShareIt is based in Germany and Plimus in California, and still Plimus is cheaper.
These are one-time payments only, so no idea how they work with subscriptions. I'd expect them to work fine if they provide the service, they are very professional.
Consider the trade offs between better user experience if the payment process is on your site vs. not having to deal with PCI compliance with a hosted solution.
I don't think you can get away from PayPal, their market share is just too big to ignore. Amazon Payments sounds like a good second choice, but it depends on your customer base.
I don't currently accept automated payments through them, though they do have a recurring payment functionality built in. I haven't used Auth.net's recurring payment system.
Before they implemented that, when I was building a service that relied on automatic recurring payments, I built a script that managed it (as the amount could vary from month to month depending on the selected features), and ran it on a cronjob.
It was quite secure as the processing server itself was firewalled from the internet (no way of accepting incoming connections, and operated from my home, away from the data center). Furthermore the data was all stored encrypted in the database (but it didn't survive on the public servers longer than 5 seconds or so). Whenever it processed the payments, it would pipe the output to a file and then to the printer for the hard copy records, resulting in daily printouts of the service.
Unfortunately, my service never went live, but the homegrown recurring payment system ran flawlessly for months (until it was decommissioned, that is).
Paypal also does that, but we chose Authorize.net mainly because Paypal is not completely behind-the-scenes in the process (I don't remember exactly, but I think PayPal forces you to redirect the user to a PayPal page). Also, Authorize.net is cheaper in the long-run.
The downside of Authorize.net is the account set-up, which is a bit cumbersome. A provider will contact you and you need to describe them how you are going to use the account, etc... Also, I think you need to open a merchant account. It's not painful per se, but you should expect at least a week to get the whole thing up-and-running.
On the upside, Authorize.net gives you access to their test environment in the meantime, so you can do the integration while you wait for your account...
PayPal also does not require that you setup a merchant account. All you need is a bank account. It's $30/mo for Web Site Payments Pro. If you provide them with a URL that shows what you're selling that's all they need. Otherwise you have to fax them a brochure or similar, to show that you're doing something legitimate.
Honestly, I'm quite pleased with using Auth.net and would indeed recommend it, moreso in hearing that their recurring billing is a simple process.
If you don't need access to the funds for a few days I would recommend using Braintree for recurring billing. But if you want the funds in your Paypal account immediately Paypal's Payflow Pro is a decent option.
http://www.braintreepaymentsolutions.com/
http://aws.amazon.com/fps/
previous HN thread http://news.ycombinator.com/item?id=432284
http://www.google.com/support/forum/p/checkout-merchants/lab...
In addition to the rate hike which now puts them in the same fee range as Paypal, Google Checkout is missing basic functionality.
True story: you can't download your complete transaction history. You can download one day of transactions at a time, but if you want something to give to your accountant at the end of the year, you've got to download 365 .csv files and combine them yourself.
We used paypal's payflow pro on our latest project. PayPal is TERRIBLE for development. For auth.net, you just put the account in test mode, send it some transactions, and get the appropriate responses. For PayPal, you have to have a sandbox account, and users in the sandbox, and this and that and blah. What it ends up meaning is that it's HARD TO SHOW YOUR CUSTOMER THAT PAYMENT IS WORKING. They have to have a sandbox account, and manage all of that stuff. Or you just conference call and screenshare, right?
Now, it turns out PayPal's not TERRIBLE, but I'll never use it again. WAY more hassle on that project than any of my others (I do ~10 ecom-enabled apps in a given year).
They are the biggest, most popular, and probably most trusted; but if you're going on technical merits alone, Paypal is one of the worst.
They are a pain to work with, they delay payments by a month, and they're expensive but they do multi-currency. This is important for me in Australia, because it means a customer in the US can buy in US dollars, and their credit card is billed in US dollars, with exactly that amount (no mysterious currency fluctuations). Same for Euros.
Their take is about 4.5% (better than PayPal etc when you take into account its hidden currency conversion spread).
Every so often I look around for an alternative for my situation ("there must be something better than this"), but so far they're the best in this.
I found that finding good payment gateways is very easy for a us company but rather hard when you're in other countries
Not used them myself yet.
For recurring billing, we use a Rails-based billing framework called Freemium (http://github.com/cainlevy/freemium/tree/master), and have been very happy with it. It integrates with Braintree flawlessly. Also, its primary developer is a freelancer (http://cainlevy.com/) who is available for hire, if you're looking for someone to help you get set up. We hired him, and couldn't be happier with his work.
One thing to keep in mind when you're looking for a payment processor is this: How transparent are they with their costs? Do they complicate their fee structure with hidden costs? Credit card billing can be a really complex beast, and having a partner who's interested in helping you make sense of it is very valuable. That's what we found in Braintree. I'm sure there are others that are good, but I'm glad I haven't had to look for them, and that I've been able to just focus on building my business.
I think a lot of these companies that typically target larger businesses are more willing to cater to startups these days to drum up new business.
I'd like to have the payment process a bit more integrated with my web site, but many of those solutions seem to require PCI compliance, and that looks rather involved.
For some reason Braintree has gotten a lot of hype but offers nothing any better than the most lowly auth.net reseller.
https://payments-sandbox.amazon.com/sdui/sdui/business?sn=pa...
It's described as being in closed beta, but Amazon's friendly representative gave me access minutes after I emailed them.
1. Think beyond taking people's money. Consider all of the use cases (credits, refunds, upgrades, downgrades, partner commissions, activation etc.). This way you can create a great customer experience, reduce cost of acquisition and maybe more importantly reduce the cost of owning a customer.
2. caveat emptor with payment processors and payment methods. Make sure you understand things like processor fees, reserves, chargeback fees, chargeback disputes and window for chargebacks. Also, please please please treat processors and payment methods separately...almost like different layers in your application. The timing of fund settlement is critical...it may be worth it to pay a little extra in fees for faster cash.
3. Scale. Volume and velocity of transactions. Some pay methods and merchant account providers only offer a best effort service. Think deeply about your projections, response times of each step in the process vs. your needs. Ask for latency SLA's if you think you'll spike volume at launch or PR etc.
4. Security. Think about security from a process perspective and don't rely solely on your processor's PCI compliance. Compliance needs to be END TO END!
I hope this was helpful.