Cost breakdown for Stripe, Braintree, Chargify, Recurly and Saasy(expletiveinserted.com)
expletiveinserted.com
Cost breakdown for Stripe, Braintree, Chargify, Recurly and Saasy
http://expletiveinserted.com/2011/10/02/stripes-new-online-payments-service-wheres-the-catch/
56 comments
I've been reading PayPal horror stories since I-don't-remember-when. I only recently started bookmarking them under their very own tag in pinboard so that when they get brought up again I can bring a few examples to bear:
Upgrading to PayPal's "virtual terminal" triggers a "rolling reserve" hold on this person's transactions; thread contains numerous other firsthand PayPal complaints: http://www.reddit.com/r/reddit.com/comments/l4q2y/please_hel...
Indie game devs bootstrapping development for a new game get their PayPal account locked down for 180 days after accepting preorders: http://www.pcgamer.com/2011/11/07/xenonauts-dumps-paypal-for...
HN's own jacquesm learns his PayPal lesson the hard way: http://www.jacquesmattheij.com/PayPal+robbed+my+bank+account
PayPal shuts down Regretsy's charity efforts: http://www.regretsy.com/2011/12/05/cats-1-kids-0/
PayPal destroys an antique violin (and robs the seller of $2500 in the process) out of simple ignorance: http://www.regretsy.com/2012/01/03/from-the-mailbag-27/
PayPal can't seem to figure out what features they do and don't offer: http://christianowens.com/post/15771850658/my-recent-experie...
That's only the stuff I've read recently. So, seriously, I'm happy for you that PayPal is working great so far. Awesome! But, people aren't avoiding PayPal because it's "not cool", they're avoiding PayPal because they've paid attention to its numerous institutional problems and they'd like to do business instead with a company that at least tries to be decent.
Sneering at people making such a measured decision is also "not cool".
Upgrading to PayPal's "virtual terminal" triggers a "rolling reserve" hold on this person's transactions; thread contains numerous other firsthand PayPal complaints: http://www.reddit.com/r/reddit.com/comments/l4q2y/please_hel...
Indie game devs bootstrapping development for a new game get their PayPal account locked down for 180 days after accepting preorders: http://www.pcgamer.com/2011/11/07/xenonauts-dumps-paypal-for...
HN's own jacquesm learns his PayPal lesson the hard way: http://www.jacquesmattheij.com/PayPal+robbed+my+bank+account
PayPal shuts down Regretsy's charity efforts: http://www.regretsy.com/2011/12/05/cats-1-kids-0/
PayPal destroys an antique violin (and robs the seller of $2500 in the process) out of simple ignorance: http://www.regretsy.com/2012/01/03/from-the-mailbag-27/
PayPal can't seem to figure out what features they do and don't offer: http://christianowens.com/post/15771850658/my-recent-experie...
That's only the stuff I've read recently. So, seriously, I'm happy for you that PayPal is working great so far. Awesome! But, people aren't avoiding PayPal because it's "not cool", they're avoiding PayPal because they've paid attention to its numerous institutional problems and they'd like to do business instead with a company that at least tries to be decent.
Sneering at people making such a measured decision is also "not cool".
Speaking from the startup's side, I feel a lot of startup hate for Paypal comes from these horror stories. But in reality any low cost service will have bad customer support (Gmail customer support anyone?).
Also, take into account the fact that Paypal has millions of users, so even a 1:million horror story rate will explode into thousands, whereas for these new startups, I doubt they even have a million customers.
Yes, their customer support is stubborn, paranoid, and OCD. They might even sneer at you, but learning to work with them may be one of the best paying skills to have if you're processing volume.
Also, I give paypal credit for taking almost everyone under their wings. Half the people using paypal couldn't get a merchant account with any real reputable bank. They have paranoid security because their standards are so low.
And of course on the other side, if you're willing to give up a percent or two for being treated kind and by the "right people" then of course these startups will probably suit your need better.
Also, take into account the fact that Paypal has millions of users, so even a 1:million horror story rate will explode into thousands, whereas for these new startups, I doubt they even have a million customers.
Yes, their customer support is stubborn, paranoid, and OCD. They might even sneer at you, but learning to work with them may be one of the best paying skills to have if you're processing volume.
Also, I give paypal credit for taking almost everyone under their wings. Half the people using paypal couldn't get a merchant account with any real reputable bank. They have paranoid security because their standards are so low.
And of course on the other side, if you're willing to give up a percent or two for being treated kind and by the "right people" then of course these startups will probably suit your need better.
Using PayPal is basically a crap shoot for recurring virtual services. As one poster on Hacker News said, if you aren't putting physical items in boxes and shipping to customers homes, you aren't in PayPal's target market.
I have to disagree with that. I think the vast majority of businesses, even those selling services, have no problems working with PayPal. Services and virtual goods are as baked into their service as physical ones -- anywhere you describe a payment, in sending, accepting or disputing one, 'service' is an option in the dropdown. Their buyer protection policies and seller protection policies explicitly call out what portions apply and don't apply to virtual goods. Not shipping a tangible item does not automatically put you in a bad position with disputes or chargebacks -- I win virtually all of them.
I consume a lot of other SaaS products, and the majority of them accept PayPal alongside credit cards. I run several "recurring virtual services", and have done so for many many years, and have hundreds of subscribers paying with PayPal. My PayPal account is 11 years old now and some of my PayPal subscribers have been around more than half that long.
When PayPal's customer service fails it tends to fail spectacularly, but all evidence points to these failures being exceptionally rare given the size of their user base.
http://i.imgur.com/z1fTG.png
I consume a lot of other SaaS products, and the majority of them accept PayPal alongside credit cards. I run several "recurring virtual services", and have done so for many many years, and have hundreds of subscribers paying with PayPal. My PayPal account is 11 years old now and some of my PayPal subscribers have been around more than half that long.
When PayPal's customer service fails it tends to fail spectacularly, but all evidence points to these failures being exceptionally rare given the size of their user base.
http://i.imgur.com/z1fTG.png
Nothing to do with "not cool". It's their customer service.
I'd love to use PayPal price wise, but I just don't trust them. I feel like at any time they can freeze my funds, have final decisions made by very low ranking support staff (with no ability to escalate) and lack of accountability (sure, I can go to FSA, but how much company time will that cost me? They should govern themselves fairly first).
Just search for the recent "Paypal Regretsy" and "PayPal violin" and tell me you trust them with your business. [edit] oh, and this one http://christianowens.com/post/15771850658/my-recent-experie...
I'd love to use PayPal price wise, but I just don't trust them. I feel like at any time they can freeze my funds, have final decisions made by very low ranking support staff (with no ability to escalate) and lack of accountability (sure, I can go to FSA, but how much company time will that cost me? They should govern themselves fairly first).
Just search for the recent "Paypal Regretsy" and "PayPal violin" and tell me you trust them with your business. [edit] oh, and this one http://christianowens.com/post/15771850658/my-recent-experie...
>at any time they can freeze my funds
That's true of any service though. Just because they haven't yet doesn't mean they couldn't in future.
I think payment processors must have very similar mean-transactions-between-failure and the smaller operators aren't yet handling the scale of transactions where you'd start to see failures.
That's true of any service though. Just because they haven't yet doesn't mean they couldn't in future.
I think payment processors must have very similar mean-transactions-between-failure and the smaller operators aren't yet handling the scale of transactions where you'd start to see failures.
I trust them with my business. So do millions of other businesses -- more than all the other companies in this thread combined. So do major YC companies like Weebly and Carwoo.
Well, the Paypal cost line starts low but then has a sudden spike to infinity when Paypal cancels your account, steals all your money, and refuses to speak to you about it.
It's been a long time since calculus but I think the area under the curve when the curve goes to infinity is also infinity. So Paypal's cost is actually a bit steep.
It's been a long time since calculus but I think the area under the curve when the curve goes to infinity is also infinity. So Paypal's cost is actually a bit steep.
Show me a way to accept credit cards without the risk of that happening. Please. Don't come back with Google Checkout, Amazon Simple Pay, 2Checkout, WorldPay, or any real merchant account provider -- because you'll find in their terms and their customer stories that they do the same thing. You think PayPal won't talk about it? At least they have a phone number you can call! Try getting one from Google.
I've had a merchant account do it to me personally -- cancel my account and hold thousands of dollars of my sales for 6 months while I had to fill those orders without any revenue. This is how the payment industry works, not how PayPal works.
I've had a merchant account do it to me personally -- cancel my account and hold thousands of dollars of my sales for 6 months while I had to fill those orders without any revenue. This is how the payment industry works, not how PayPal works.
I've got no idea why you're being downvoted - perhaps your last paragraph is a little harsh. But you're right, it's odd not to see mention of PayPal. It works, it's inexpensive, and for non-US businesses it's one of the few available options.
He's probably being downvoted by people who have extensive experience in dealing with PayPal. Dealing with PayPal's rather frequent API outages can be hell for businesses and developers. If you have a small enough business that you don't need to use the API, then go for it, but otherwise, you might just wind up scraping the PayPal site pages when there's an outage.
We're looking into PayPal, but I try to avoid systems that put strict limits on what I can do with my customers. Things like refunds, deferred charges, adjusting price up and down, etc. I can do all that easily with Chargify, but I'm not so sure about PayPal.
I talk more about it here: http://peachshake.com/2010/06/15/saas-subscription-billing-o...
I talk more about it here: http://peachshake.com/2010/06/15/saas-subscription-billing-o...
[deleted]
Missing from this analysis is which options are available outside the US. I've tried to quicky figure this out for each provider, please correct me if I'm wrong:
- Braintree: only if doing 3 million+/year.
- Chargify: in theory yes, if you can find a merchant provider that accepts you with reasonable terms, which isn't easy.
- Recurly: "Recurly supports SagePay and PayPal in the U.K. and Ireland, as well as Wirecard throughout the broader European Union."
- Saasy: Yes.
- Strip: Not yet.
I think there's a huge market of non-US startups that would love to find a Stripe equivalent that they could use. Much easier to compete than going head-to-head with the US crowd, whose customers are spoiled for choice.
That's what Shuttleworth in effect did - fulfilled a demand outside the US for a service that US companies couldn't legally fulfil. Got him into space. Not bad.
That's what Shuttleworth in effect did - fulfilled a demand outside the US for a service that US companies couldn't legally fulfil. Got him into space. Not bad.
Which is precisely why I chose saasy for my web app, being based in the uk. Same goes for tropo vs twillio, until twillio lainched uk sms yesterday.
And how has your experience been with Sassy?
I've just checked their page, featurewise they look like very interesting, but their pricing is far from being cheap:
"Pricing is 5.9% plus $.95 or 8.9% flat per order, whichever you prefer. The minimum order fee is $.75 per order."
EDIT: according to http://saasy.com/matrix.php it includes also the merchant fees, unfortunately in their comparison Stripe is not cited
EDIT: according to http://saasy.com/matrix.php it includes also the merchant fees, unfortunately in their comparison Stripe is not cited
That sounds like how 2Checkout approach it. They are a reseller of your products/services, and you must state so on your sales page. It's also the reason 2Checkout give that they don't allow 'vendors' to customize their checkout pages.
I'd also mention 2Checkout.com which offers recurring subscriptions with an API. I use them from Ireland, it just about works, but they lack innovation.
> Where’s the Catch?
Anyone care to comment? I can think of some potential ones, but have no first-hand experience with them, so I'll withhold comment.
However, my biggest fear is derived from self-awareness. I run a startup and, no matter how good I think our code is, we fuck stuff up. Plenty. Oddly, in this sector, I trust an older company full of idiots more than a brand new startup full of brilliant hackers, if for no other reason than the idiots have already made their mistakes and are now just not gonna fuck with it. If they made it a few years, ironed out the kinks and then just they leave it alone, it's less likely to break :-P
Anyone care to comment? I can think of some potential ones, but have no first-hand experience with them, so I'll withhold comment.
However, my biggest fear is derived from self-awareness. I run a startup and, no matter how good I think our code is, we fuck stuff up. Plenty. Oddly, in this sector, I trust an older company full of idiots more than a brand new startup full of brilliant hackers, if for no other reason than the idiots have already made their mistakes and are now just not gonna fuck with it. If they made it a few years, ironed out the kinks and then just they leave it alone, it's less likely to break :-P
The biggest one is Stripe does little beyond actually charging a card. If you're a business, you likely need to provide your customers with receipts via email at the very least, and ideally have a portal for them to look up their payment history. You probably don't want to bother with Dunning emails, either. If you go with Stripe, be prepared to implement all this yourself.
I can't speak fully for the others, but I have used Chargify and Recurly. Chargify finally has statements. Recurly has a large emphasis on making sure your customers are retained -- so much so that they added their own payment gateway to help make sure that's the case.
So, Stripe may be a low cost option on a per transaction basis, I just wouldn't brush aside the development costs that some of the other providers save you. In the end, Stripe may still be worth it for you -- it is for us. But that's the catch.
I can't speak fully for the others, but I have used Chargify and Recurly. Chargify finally has statements. Recurly has a large emphasis on making sure your customers are retained -- so much so that they added their own payment gateway to help make sure that's the case.
So, Stripe may be a low cost option on a per transaction basis, I just wouldn't brush aside the development costs that some of the other providers save you. In the end, Stripe may still be worth it for you -- it is for us. But that's the catch.
> I run a startup and, no matter how good I think our code is, we fuck stuff up. Plenty.
What makes you think that's unique to a startup?
What makes you think that's unique to a startup?
Nothing. I never made that claim.
I said "If they made it a few years, ironed out the kinks and then just they leave it alone, it's less likely to break". I have the same concerns about all new software from any provider. The same concerns applied to Google Checkout and Amazon Payments when they were new.
I just happen to run a startup & have, as expected, observed this fact about software engineering.
However, given the smaller teams and conflicting demands on attention for a startup, the problems may be more pronounced. Furthermore, billing is an industry filled with high degrees of both incidental AND inherent complexity. Navigating that complexity requires institutional knowledge that must be built over time.
I said "If they made it a few years, ironed out the kinks and then just they leave it alone, it's less likely to break". I have the same concerns about all new software from any provider. The same concerns applied to Google Checkout and Amazon Payments when they were new.
I just happen to run a startup & have, as expected, observed this fact about software engineering.
However, given the smaller teams and conflicting demands on attention for a startup, the problems may be more pronounced. Furthermore, billing is an industry filled with high degrees of both incidental AND inherent complexity. Navigating that complexity requires institutional knowledge that must be built over time.
Stripe's simplicity blows me away. Payments is one of those things I always hated dealing with--you could never provide a decent user experience for a reasonable cost.
Stripe's solution is exactly what I want, so much so it's baffling that nobody had ever done it their way. And since I'm not planning on doing $50M+ revenue anytime soon, they're cheap too :)
Stripe's solution is exactly what I want, so much so it's baffling that nobody had ever done it their way. And since I'm not planning on doing $50M+ revenue anytime soon, they're cheap too :)
I agree, from a customer's point of view Stripe is a godsend. However, I wonder if that level of simplicity is sustainable for them going forward. The reason other payment providers have paperwork and approval processes is because of liability and the reality that there are unscrupulous merchants out there. Is Stripe assuming an increased liability because of the ease at which anybody can just sign up?
I was somewhat surprised that when signing up I was not asked to agree to any terms, and there wasn't even a link to any on the signup form. When I did find them after signing up I see they require you to comply with PCIDSS, but by neither asking me to agree to this nor pushing it in their documentation at all, it's unlikely their users are going to actually do so. How many Stripe users are paying SecurityMetrics or ControlScan for their quarterly compliance scans? How many have even filled out the self-assessment questionnaire?
So then comes the problem -- Stripe is encouraging developers, regardless of experience with security or payment systems, to set up direct credit card payment forms on their website (to be processed by Stripe's javascript). Lots of these servers probably have outdated services, CMS's and other packages with gaping security holes -- any of which would allow someone to hijack the form to silently send customers' credit card data somewhere else.
In the end, who is Visa going to be able to get its half million dollar fine for a data breach by a site not in compliance with PCIDSS from? The merchant it has signed contracts with (Stripe via their underwriting banks) or the lone developers that have no funds to meet the security requirements, let alone pay fines on the resulting losses?
I think Stripe's pitch deck would be an interesting thing to see.
So then comes the problem -- Stripe is encouraging developers, regardless of experience with security or payment systems, to set up direct credit card payment forms on their website (to be processed by Stripe's javascript). Lots of these servers probably have outdated services, CMS's and other packages with gaping security holes -- any of which would allow someone to hijack the form to silently send customers' credit card data somewhere else.
In the end, who is Visa going to be able to get its half million dollar fine for a data breach by a site not in compliance with PCIDSS from? The merchant it has signed contracts with (Stripe via their underwriting banks) or the lone developers that have no funds to meet the security requirements, let alone pay fines on the resulting losses?
I think Stripe's pitch deck would be an interesting thing to see.
What are the PCI-DSS compliance requirements when you're using Stripe?
Everything except the parts about storing payment data. In a nutshell:
- Install and maintain a firewall
- Lock down system users, groups, passwords and default settings of your services
- Use encryption
- Use and update anti-virus software
- Restrict access to your systems and have auditable logs of all access to your systems, physical and digital
- Have unique identifiers for all people with access to your systems, so that those audits are meaningful
- Log and monitor all network access to your systems
- Have, distribute, and regularly test your physical, network and information security policies
- Fill out a self-assessment questionnaire attesting you meet all these requirements
- Have your server scanned by a 3rd party compliance company every 3 months
To pass the compliance scans, you will have to maintain all services on your servers at the latest versions or provide evidence that you have applied patches covering all known security flaws, among other things. The scans are not cheap and have to be made by a provider approved by PCI. SecurityMetrics charges $699 per year to do them quarterly.
By signing up with Stripe you are agreeing that you're taking care of this already.
> You agree that at all times you shall be compliant with the Payment Card Industry Data Security Standards (PCI-DSS) and the Payment Application Data Security Standards (PA-DSS), as applicable. You agree to promptly provide us with documentation evidencing your compliance with PCI DSS and/or PA DSS if requested by us. You also agree that you will use only PCI compliant service providers in connection with the storage, or transmission of Card Data defined as a cardholder’s account number, expiration date, and CVV2. You must not store CVV2 data at any time. Information on the PCI DSS can be found on the PCI Council’s website. It is your responsibility to comply with these standards.
https://stripe.com/terms
It's also important to realize that you can't meet all the requirements on shared or cloud hosting -- except Amazon EC2, which is AFAIK the only PCIDSS approved cloud. You really need your own server to be in compliance.
- Install and maintain a firewall
- Lock down system users, groups, passwords and default settings of your services
- Use encryption
- Use and update anti-virus software
- Restrict access to your systems and have auditable logs of all access to your systems, physical and digital
- Have unique identifiers for all people with access to your systems, so that those audits are meaningful
- Log and monitor all network access to your systems
- Have, distribute, and regularly test your physical, network and information security policies
- Fill out a self-assessment questionnaire attesting you meet all these requirements
- Have your server scanned by a 3rd party compliance company every 3 months
To pass the compliance scans, you will have to maintain all services on your servers at the latest versions or provide evidence that you have applied patches covering all known security flaws, among other things. The scans are not cheap and have to be made by a provider approved by PCI. SecurityMetrics charges $699 per year to do them quarterly.
By signing up with Stripe you are agreeing that you're taking care of this already.
> You agree that at all times you shall be compliant with the Payment Card Industry Data Security Standards (PCI-DSS) and the Payment Application Data Security Standards (PA-DSS), as applicable. You agree to promptly provide us with documentation evidencing your compliance with PCI DSS and/or PA DSS if requested by us. You also agree that you will use only PCI compliant service providers in connection with the storage, or transmission of Card Data defined as a cardholder’s account number, expiration date, and CVV2. You must not store CVV2 data at any time. Information on the PCI DSS can be found on the PCI Council’s website. It is your responsibility to comply with these standards.
https://stripe.com/terms
It's also important to realize that you can't meet all the requirements on shared or cloud hosting -- except Amazon EC2, which is AFAIK the only PCIDSS approved cloud. You really need your own server to be in compliance.
Correct me if I'm wrong, but I thought the whole point of Stripe's JS setup, Braintree's transparent redirect, etc. was that it takes your server out of scope of PCI compliance. Basically my server doesn't "store, transmit, or process" any credit card information (the customer's browser sends it straight to the processor), so it's not within the scope of PCI compliance. The author even hinted towards this in their post.
What Stripe does is a gray area, but something you can be pretty sure the PCI Council will eventually clarify so that these things are clearly covered. They may or may not be now.
Why will it be? Because whether the form submits to your server or to someone else's server is irrelevant. If you have not secured your own server, then someone can redirect the target of that form, or inject their own Stripe-style code to silently send the form contents offsite the same way Stripe does it. And nobody will be able to track down the source of that breach because the site owner is probably not complying with the access control and logging requirements either.
Do you really want people that can barely configure WordPress responsible for the security of your credit card number online? That's the effect of not putting this practice under the scope of PCIDSS. That's probably why the banks underwriting Stripe told them to put the requirement that all their users comply with PCIDSS into their terms of service.
If you want to be outside the scope of PCIDSS, then don't host payment forms. Either redirect to a hosted page, or embed an iframe. Either way, being on a different domain means your own security practices can't compromise the payment data.
Why will it be? Because whether the form submits to your server or to someone else's server is irrelevant. If you have not secured your own server, then someone can redirect the target of that form, or inject their own Stripe-style code to silently send the form contents offsite the same way Stripe does it. And nobody will be able to track down the source of that breach because the site owner is probably not complying with the access control and logging requirements either.
Do you really want people that can barely configure WordPress responsible for the security of your credit card number online? That's the effect of not putting this practice under the scope of PCIDSS. That's probably why the banks underwriting Stripe told them to put the requirement that all their users comply with PCIDSS into their terms of service.
If you want to be outside the scope of PCIDSS, then don't host payment forms. Either redirect to a hosted page, or embed an iframe. Either way, being on a different domain means your own security practices can't compromise the payment data.
I asked stripe about all this in their campfire chatroom last night, and I was hoping they would chime in on this thread, but let me pass along some of what they said.
Their response was similar to what the grandparent articulated: that by using Stripe.js, you're avoiding the storage requirements and thus don't have to do anything extra for PCI. However, you can also interact with their API without stripe.js, which is where you would need PCIDSS and thus the language in the terms.
Now, all that aside, I think you bring up a great point about the gray area and the risk that a security breach would cause. One major difference is that with Stripe.js, a security breach would not put at risk all cards used in the PAST, the way storing them yourself would.
Their response was similar to what the grandparent articulated: that by using Stripe.js, you're avoiding the storage requirements and thus don't have to do anything extra for PCI. However, you can also interact with their API without stripe.js, which is where you would need PCIDSS and thus the language in the terms.
Now, all that aside, I think you bring up a great point about the gray area and the risk that a security breach would cause. One major difference is that with Stripe.js, a security breach would not put at risk all cards used in the PAST, the way storing them yourself would.
Does an iframe really buy any security?
A malicious entity who seizes control of your page rendering could replace the javascript, sure. They could also replace the iframe loading code. I don't see why one would be any more or less of a risk than the other.
A full browser redirect will at least show a valid certificate in the URL bar and alert (savvy) users to shenanigans... assuming the user understands that "Stripe, Inc" is a legitimate payment service. Which they almost certainly don't, so the attacker just needs a (free, easy-to-obtain) certificate for any domain that looks plausible.
The underlying problem is that the trust model for credit card processing is fundamentally broken. There really aren't any rules - at least related to the technology for rendering a "type in your cc #" form - that can fix this.
A malicious entity who seizes control of your page rendering could replace the javascript, sure. They could also replace the iframe loading code. I don't see why one would be any more or less of a risk than the other.
A full browser redirect will at least show a valid certificate in the URL bar and alert (savvy) users to shenanigans... assuming the user understands that "Stripe, Inc" is a legitimate payment service. Which they almost certainly don't, so the attacker just needs a (free, easy-to-obtain) certificate for any domain that looks plausible.
The underlying problem is that the trust model for credit card processing is fundamentally broken. There really aren't any rules - at least related to the technology for rendering a "type in your cc #" form - that can fix this.
Thanks, I didn't understand that before. I'm looking for a hosted service to avoid as many of those things as possible!
Why not include Samurai (http://samurai.feefighters.com)? Seems like it would be cheaper than the other ones and the api docs look breezy like stripes. It's only 2.3% + 30cents. Also look at Spreedly for recurring.
I am in the process of integrating Recurly into my existing business, and I have to say, those graphs misleading regarding Recurly.
The Recurly gateway is already included with the normal Recurly costs.
Zero out the gateway numbers in the calculator there and you will see the difference. http://expletiveinserted.com/recurring-payment-cost-calculat...
Granted, Stripe avoids the paperwork and business requirements for getting a merchant account. However, I already had most of those requirements ticked (you need them anyways if you intend to operate aboveboard), and I want all the subscription management features Recurly provides.
Further, the Recurly gateway includes credit card portability (Braintree is the only other company I know of that supports this). http://www.portabilitystandard.org/
EDIT: Removed incorrect merchant account fees.
The Recurly gateway is already included with the normal Recurly costs.
Zero out the gateway numbers in the calculator there and you will see the difference. http://expletiveinserted.com/recurring-payment-cost-calculat...
Granted, Stripe avoids the paperwork and business requirements for getting a merchant account. However, I already had most of those requirements ticked (you need them anyways if you intend to operate aboveboard), and I want all the subscription management features Recurly provides.
Further, the Recurly gateway includes credit card portability (Braintree is the only other company I know of that supports this). http://www.portabilitystandard.org/
EDIT: Removed incorrect merchant account fees.
We looked at Recurly too... You are wrong that you can just zero out the gateway numbers in the calculators. Recurly charges 1.25% + 10 cents (http://recurly.com/pricing). 1.25% is a CRAPLOAD. Using a merchant account from FeeFighters would for us end up costing something like 2.1% + 20cents for the merchant account but then we'd have to pay an additional 1.25% + 10cents to Recurly, making it a total of 3.35% + 30 cents, far more than Stripe. Plus there's a $69 minimum fee, which sucks when you are starting out
Chargify (http://chargify.com) or Spreedly (http://spreedly.com) + Samurai (http://samurai.feefighters.com) is going to be significantly cheaper in our case (we expect to ramp to $30k/sales/mo). I'll pretty-up and share the google spreadsheet I used shortly. Stripe is still the best option if you have low transaction size and low volume (I think it was <$6k/mo). Other than that it was either chargify+samurai or spreedly+samurai (depending on the number of transactions because of chargify's tricky pricing)
Chargify (http://chargify.com) or Spreedly (http://spreedly.com) + Samurai (http://samurai.feefighters.com) is going to be significantly cheaper in our case (we expect to ramp to $30k/sales/mo). I'll pretty-up and share the google spreadsheet I used shortly. Stripe is still the best option if you have low transaction size and low volume (I think it was <$6k/mo). Other than that it was either chargify+samurai or spreedly+samurai (depending on the number of transactions because of chargify's tricky pricing)
The Recurly costs are inherent in the calculation being made there. The Gateway costs were being added on top.
Portability is very important and often overlooked. Braintree created the Credit Card Data Portability Standard a couple years back, and I think there are may be a few additional companies supporting it now. http://www.braintreepayments.com/blog/data-portability
OP here. That was the Recurly pricing at the time. I have updated now to their latest pricing, and if you use their gateway they are indeed the lowest cost option of that bunch.
Also, Stripe claims to support data portability.
Also, Stripe claims to support data portability.
> a good merchant account will have rates under $0.20/transaction
That's impossible. Visa and MasterCard's interchange rates are 1.15% - 2.7% + $0.10 per transaction, that's the floor at which a merchant account could start its pricing.
That's impossible. Visa and MasterCard's interchange rates are 1.15% - 2.7% + $0.10 per transaction, that's the floor at which a merchant account could start its pricing.
Sorry, you are right, I was only quoting the merchant account rates on top of the interchange.
The 1.94%/transaction on that page is competitive. With that and my other numbers, the Recurly are still competitive with Stripe.
The 1.94%/transaction on that page is competitive. With that and my other numbers, the Recurly are still competitive with Stripe.
Would love to see the same thing for monthly billing, but with completely variable monthly payments.
Most (all?) of these companies support that.
Most of the services mentioned in the article can add "charges" to each months accounting for things like usage based systems. Of course if you're payments are completely variable, you'll have a hard time calculating with any service that charges a percentage for each transaction.
As a gentle aside: the graphs in this post are pretty nice, but I can't tell what's what in them because the colors are evil. I'm one of a large number of colorblind men (http://robsheldon.com/colorblind/).
The main reason for the nature of credit-card fees (fixed+percentage) is to manage the fraud.
Stripe's simplicity of access means that it is going to be completely destroyed by fraud. The reason for the effort in getting merchant accounts is that if you take the money and run, the organization that gave you the merchant account is responsible for the chargebacks, up to 6 months later.
6 months is a long time. It's not feasible for most businesses to wait that long to get their money. Hence the percentage charge to cover the risk of fraud. If you think that a 2% charge means that 1 in 50 of every transactions is fraudulent already, imagine what a skilled fraudster will do.
Stripe's simplicity of access means that it is going to be completely destroyed by fraud. The reason for the effort in getting merchant accounts is that if you take the money and run, the organization that gave you the merchant account is responsible for the chargebacks, up to 6 months later.
6 months is a long time. It's not feasible for most businesses to wait that long to get their money. Hence the percentage charge to cover the risk of fraud. If you think that a 2% charge means that 1 in 50 of every transactions is fraudulent already, imagine what a skilled fraudster will do.
Would like to see the banking industry disrupted even more in 2012+, such as by Dwolla, which was covered in the mainstream media yesterday in this good 2-minute CNN video clip: http://goo.gl/ISZ9C (Note: I've got nothing to do with Dwolla, just supporter of disruptive companies like them.)
What's disruptive about Dwolla? PayPal has always let you fund payments by bank transfer and person-to-person payments are free to send and receive. As far as I can tell reading their site, they are PayPal without 90% of the features but a better mobile app, and the only benefit for merchants is the introductory $0.25 pricing. If ACH-funded person-to-person payments are going to disrupt the banking industry, why didn't it 12 years ago when PayPal started doing it?
In addition, Paypal is currently making $$$ on ACH payments that they charge their full fees for. They can flip a switch and change those back to free or $0.25 and kill any Dwolla advantages.
How complicated is it to use https://www.dwolla.com/ for recursive payments?
It seems to be cheaper than all the other options. .25 cents per transaction, no matter the volume.
It seems to be cheaper than all the other options. .25 cents per transaction, no matter the volume.
Dwolla doesn't let you accept credit cards.
In addition to the simple "Pay with PayPal" button scenario where you get all the simple subscriptions-as-a-service features built in (automatically handling failed payments and retries and notifying you of subscriptions, payments, cancellations, expiration of services, etc)... they'll also power your normal credit card payment forms on-site, and do token-based recurring billing (authorize payment once, charge the customer a variable amount whenever you need).
That startups discount PayPal entirely because it's "not cool" and you can't chat with the founder at 4AM about your implementation is astounding to me. All of these other services are very expensive, less fully featured, and none of them come with 240 million pre-registered users and brand trust. Any reasonable decision maker should be at least considering them an option.