
Ask HN: how do you process payments? - lee
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.<p>Which payment processing provider do you use?  And how would you describe the quality of your service?<p>Google, Yahoo, and PayPal all provide this service, and they all charge similar fees.  How do they stack up against each other?<p>Also, the ability to charge for recurring payments (subscriptions) is important to me.<p>Thanks!
======
reidman
Google Checkout has no customer service, not for merchants at least. No phone
number, no email address, just a knowledge base and a forum where GC merchants
vent their frustration by making threats and typing in all caps:

[http://www.google.com/support/forum/p/checkout-
merchants/lab...](http://www.google.com/support/forum/p/checkout-
merchants/label?lid=12de2eed05d80c5b&hl=en)

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.

------
tonystubblebine
I'm in the same boat, here's a little bit of research regarding subscriptions:

1\. 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?

~~~
il
PayPal's API was actually pretty easy to implement for my subscription
service.

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/>

------
charliepark
We use Braintree (<http://www.braintreepaymentsolutions.com/>), and I've never
had a better experience with a service provider. They're consummately
professional, know their product and category inside and out, and are eager to
educate people on the ins and outs of credit card processing. I had heard at
one point that they had a higher rate for services billing less than $1MM a
year, but I've since heard that that doesn't apply to SaaS companies that are
using Rails (I'm not sure what the definitive answer is on this; I know they
were the best price we could find, and I looked extensively).

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.

------
figured
<http://www.zuora.com/>

<http://www.braintreepaymentsolutions.com/>

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

previous HN thread <http://news.ycombinator.com/item?id=432284>

------
jng
I use Plimus (<http://www.plimus.com>) for ViEmu and Codekana sales
(<http://www.viemu.com> and <http://www.codekana.com>). It's very good, and
the price is good, too. I used to use share-it (<http://www.shareit.com/>) for
a few years, but they were more expensive and less informative.

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.

------
edsull
Hey...my name is Ed and I'm the founder of Aria Systems (www.ariasystems.com)
which we started based on my experience building a very large subscription
based service (2.5 Million users). I'd encourage you to think about a few
things when creating a subscription based service:

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.

~~~
tphyahoo
Great advice but... so? What do you use?

------
chops
I use Authorize.net and am quite pleased with it, though, admittedly, I've
never used any other service.

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

~~~
felipe
We are using Authorize.net's recurring billing service, and we are very happy
with it. Mostly because we don't need to worry about the security issues you
mentioned (encrypting, secondary processing server, etc...). Authorize.net
stores the c/c info and takes care of it.

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

~~~
staunch
PayPal with Web Site Payments Pro can be completely behind the scenes. You
create a recurring payments profile, that has a profile id, you use that to
reference it in the future (to cancel it for example).

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.

------
madmotive
Spreedly looks like an interesting alternative for outsourcing the hassle of
subscription payments: <http://spreedly.com/>

Not used them myself yet.

~~~
raghus
Does anyone here on HN have experience with spreedly?

~~~
ivey
I know one of the founders, and hold him in pretty high esteem. I haven't
personally used Spreedly, but I know they make good stuff. They're also very
accessible, and are hackers. If you have questions, just ping them and you'll
get a real answer.

------
chaosmachine
Choose more than one. It's important to have redundancy when it comes to
getting paid. Ask anyone who's had their PayPal account suspended for
arbitrary reasons.

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.

------
lakeeffect
Amazon payments for cost efficiency. We thought considered using pay pal but
it was more expensive. The other nice thing about Amazon is they let payers
use their amazon payment accounts.

~~~
justinsb
Amazon payments seems very bad for repeated billings, particularly variable
repeated billing. They seem to be really pushing their P2P payments, so if
that's what you're doing then great, otherwise I would think twice...

~~~
eob
Does Amazon payments allows 3rd party developers to hook into the P2P-style
payments?

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

~~~
justinsb
You can definitely facilitate a P2P transaction - they have 3 entities in each
transaction - the sending account, the receiving account and the calling
account. All 3 can be different.

Sounds like your app is exactly in the target zone for FPS - I just wish they
hadn't neglected the more conventional use cases!

------
knewter
Authorize.net is great for customer service, I've never once needed to talk to
them and had to wait more than 5 minutes (granted, on-site text support, but
it's useful and they're efficient).

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

~~~
zain
I'll second this. Paypal is a _huge_ hassle to develop for. Their sandbox goes
down very regularly, and it's one of the most annoying things, because you
don't know if it is a bug with your code or if it is Paypal.

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.

------
10ren
Worldpay.com

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.

~~~
inovica
Hi there. We use Worldpay. Just a note - they ARE flexible on their rates
after you have been with them a while. We reduced ours to 3.3% with just one
phone call, so it might be worth you giving that a go

~~~
10ren
Thanks for that.

------
ScottWhigham
I use PayPal, Google, and Authorize.net currently. We are dumping Google in a
few weeks - 1+ years of "1 in 5" chargebacks and poor (non-existent?) customer
service. PayPal is best of breed but we do not use them as our primary payment
handler; it's an option presented to customers upon checkout though.

~~~
jonah
+1 for Authorize.net. Paypal's Website Payments Pro is good too.

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.

------
fastspring
Be sure to evaluate FastSpring.com as well.

Before you go with PayPal, you may want to read up on some of the issues
people have been having with PayPal:
<http://www.fastspring.com/blog/2008/...nt-processing/>

Also, this post explains the difference in a full service e-commerce solution
and a basic payment service like PayPal and the others:
<http://www.fastspring.com/blog/2009/...ng-e-commerce/>

Keep in mind that one of the ways customers can pay when using a full service
solution is via PayPal, but customers have numerous alternative payment
methods available as well. Some vendors won't need the features of a full
service solution, while for others it makes a huge difference in their bottom
line.

\- Dan

------
teuobk
On a related note, could anybody comment on their experience getting PCI
compliance?

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.

~~~
dhyasama
There are several levels of PCI compliance. At PowerPay we spend thousands of
dollars becoming compliant and staying that way. For most merchants, the
requirements are far less onerous. The biggest tip I can give is don't store
card numbers. Ever. Just pass the info along to your payment gateway and
forget it. Let them deal with the compliance and risk. Take my advice for what
it cost and speak with your sales agent for the exact guidelines you need to
follow.

------
dhyasama
I work at PowerPay which is a payment processor. Unless the person or
organization you sign up with is a registered ISO than you are actually doing
business with a company such as PowerPay. Visa and Mastercard require the ISO
to be clearly stated on the merchant account application. Most of the time
merchants go through sales agents who are working for or with a registered
ISO. Just an FYI, as the industry can be a bit sketchy. I've been at PowerPay
for a few years and for what it's worth I've always been impressed with how we
do business.

------
plusbryan
Cybersource is an oft-overlooked option I'd recommend considering. We were
going to go with the defacto AuthNet, but ended up choosing Cybersource for
the added features (better recurring payments, international currency support)
and the fact they gave us a pretty sweet deal (same price as Authorize.Net,
which is their lower-priced option).

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.

------
garethr
Paypal is good and pretty feature rich, but it's not the most straightforward
thing to work with. It's not really that the API is under-documented, more
that it can involve lots of back and forth and your code needs to deal with
lots of cases. The advantage is ease of use. In terms of time to implement and
wide spread user awareness it's a good starting point to get the money coming
in - with more options provided as time permits.

------
vaksel
I like cdgcommerce, they have reasonable rates and very good reputation. They
also give good support. You can find a whole bunch of reviews on
webhostingtalk

------
stympy
I'll plug myself here... :) If you are using Rails, take a look at
<http://railskits.com/saas/> \-- a great starting point for your Rails apps to
not only do the recurring billing (with Auth.net, Braintree, etc.) but also do
account management, upgrades/downgrades, etc.

It has a lot of the work done for you, so you just plug it in and go.

------
mjtokelly
Amazon Simple Pay Subscription has worked out very well for me. Startlingly
easy site integration.

[https://payments-
sandbox.amazon.com/sdui/sdui/business?sn=pa...](https://payments-
sandbox.amazon.com/sdui/sdui/business?sn=paynow/subscription)

It's described as being in closed beta, but Amazon's friendly representative
gave me access minutes after I emailed them.

------
Bill_N_Payments
I actually work for a software firm that created a billing and payments
application specifically for recurring and subscription services. Feel free to
send me an e-mail and I can answer any questions for you or provide some
information for you. My e-mail addy is pcain@ipapplications.con or feel free
to check out our site at www.ipapplications.com.

Cheers.

Paul

------
grandalf
We use authorize.net ... authorize.net provides remotely stored credit cards
(you just store a token). This is available through pretty much all auth.net
resellers.

For some reason Braintree has gotten a lot of hype but offers nothing any
better than the most lowly auth.net reseller.

------
goodkarma
We use Payflow Pro Recurring Billing (PayPal).

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.

------
izak30
I got a local merchant account (huntington national bank), which is flexible,
and I get a choice of gateways (we chose authorize.net). Great service at both
the merchant account and gateway level, also pretty good rates.

------
rbiffl
TrustCommerce.com is very fast (<2 sec.) and developer-friendly, and they run
on open source systems if that's important to you.

------
known
<http://www.ccavenue.com/> for Indian customers

------
ehaus
I agree with pretty much everything said here. Just for full disclosure - I
work for Zuora, one of the companies listed above.

All the above methods have pros and cons. I would echo the sentiment above to
look at payment processors and payment methods as separate entities. I would
also echo the sentiment about Google Checkout. With its now higher rates, less
customer support and higher fraud rates, there are fewer reasons to choose it
over others.

When choosing a payment processor, be sure to take into account your business
needs, not just who is cheaper. For example, some payment processors work
better in different geographic regions (or if not better, have different
commission rates). So make sure to look at where your sales are coming from.
If the the vast majority of your sales are (or will be) in North America, then
you can probably just compare prices. If you sell to Asia or Europe/EMEA, make
sure to see if the commissions are different in those areas. If you do a
significant amount of transactions in multiple geographic regions, it may be
worth the cost to support more than one payment processor (ie, use PayPal in
North America, someone else for Asia because they offer a lower rate, etc)

While commission/rate is probably the biggest driver in choosing a payment
processor, be sure to take into account a few other things:

* Ease of integration - how much work does it take to integrate with a payment processor. Moreover, if you are using a pre-built shopping cart, see if they have integration with a payment processor (most support Authorize.net, Paypal, and Google Checkout, with some even adding mobile payment processors as well). * Customer service - this isn't just if you can call someone. Most will rely on self service - be sure to vet their self service portals as well. * Fraud/chargeback - (especially in gaming and social networks). How much emphasis this is given really depends on your business. If you are selling physical goods, not usually a huge concern. If you are selling digital or virtual goods (usually consumable goods, as opposed to service), it can become a bigger problem.

For handling recurring fees/subscriptions, it also depends on your business
needs. If you are looking for a simple recurring flat fee on a monthly basis,
and will only have one fee per customer, many providers can help here. I know
that Paypal can support this today, and from this thread it seems that
Authorize.net and Braintree can handle it well, too. If you are already
considering one of them as your payment processor, then that may just suit
your needs. Google just released a subscription product as well, but that is
brand new, and I have no experience with it (or know of anyone who has used
it). So I cannot offer too much commentary there. From what I have seen (and
also mentioned elsewhere in this thread), Google Checkout does suffer from
higher fraud rate. I've known other companies to drop support for this reason.

Subscriptions can get complex quickly, but if your needs aren't likely to grow
beyond a single product with a simple monthly charge, then I would look into
Paypal/Authorize.net. However, if you are looking for more complex features
like offering multiple rate plans for a single product (ie, offer different
payment plans - like $9/month vs $99/year), offer usage based pricing (similar
to a pay-as-you-go cell phone plan), offer multiple products/rate plans to a
given subscription, offer ability to change from one plan to another, etc,
then using a subscription processor is the way to go (e.g., Zuora, Vindicia,
Aria, eVapt). I could give the whole spiel on Zuora, but I'll save that for a
different forum. Hope that helps.

------
axod
I use paypal subscription thing atm, it seems to do the job ok.

