Ask HN: how do you process payments?
29 comments
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...
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.
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.
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?
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?
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/
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/
Auth.net is what we use at servee to setup subscription services.
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.
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 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.
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.
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.
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.
Great advice but... so? What do you use?
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).
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).
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...
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 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.
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.
That's good to hear that the recurring billing is as pleasant experience. I pretty much assumed as much, given how smooth Auth.net is for single transactions.
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.
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.
[deleted]
Spreedly looks like an interesting alternative for outsourcing the hassle of subscription payments: http://spreedly.com/
Not used them myself yet.
Not used them myself yet.
Does anyone here on HN have experience with spreedly?
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.
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.
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.
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.
"The other nice thing about Amazon is they let payers use their amazon payment accounts."
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.
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.
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...
Check out their DevPay service. It's intended use is reselling Amazon Web Services with a markup, but you can also use it to do a simple recurring monthly fee. It's dead simple to set up compared to every other ecommerce system I've looked at, including Amazon SimplePay.
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.
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.
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)?
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)?
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!
Sounds like your app is exactly in the target zone for FPS - I just wish they hadn't neglected the more conventional use cases!
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).
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).
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.
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.
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.
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.
Braintree does it. We're taking EUR and GBP in addition to USD. The API is also far far simpler than any of the SOAP crap the last generation of market leaders foisted upon us.
But the problem of braintree is that it only works with us merchant accounts so for people like the parent who is in Australia or me whose company is in HK it doesn't work...
I found that finding good payment gateways is very easy for a us company but rather hard when you're in other countries
I found that finding good payment gateways is very easy for a us company but rather hard when you're in other countries
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.
+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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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
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.
It has a lot of the work done for you, so you just plug it in and go.
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...
It's described as being in closed beta, but Amazon's friendly representative gave me access minutes after I emailed them.
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.
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 [email protected]
or feel free to check out our site at www.ipapplications.com.
Cheers.
Paul
Cheers.
Paul
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.
For some reason Braintree has gotten a lot of hype but offers nothing any better than the most lowly auth.net reseller.
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.
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.
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.
TrustCommerce.com is very fast (<2 sec.) and developer-friendly, and they run on open source systems if that's important to you.
http://www.ccavenue.com/ for Indian customers
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.
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.
I use paypal subscription thing atm, it seems to do the job ok.
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!