
Cost breakdown for Stripe, Braintree, Chargify, Recurly and Saasy - ajessup
http://expletiveinserted.com/2011/10/02/stripes-new-online-payments-service-wheres-the-catch/
======
dangrossman
If you added PayPal to these charts it'd be well below all of the lines at all
of the price points. It'd start at around 3% and drop to 2.2% very early in
the graph. Plus, for most startups, not accepting PayPal is going to cost you
customers. Especially non-US customers.

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.

~~~
ed209
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...](http://christianowens.com/post/15771850658/my-recent-experience-
with-paypal-customer-service)

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

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

Although it makes sense to start in the US market, it's getting to the point
where all most alternatives are US-centric, and there's a big world of us out
here that would also love better payment gateways!

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

~~~
mise
And how has your experience been with Sassy?

~~~
Ecio78
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

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

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

~~~
ceejayoz
> 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?

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

------
cloudwalking
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 :)

~~~
thematt
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?

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

~~~
nilsbunger
What are the PCI-DSS compliance requirements when you're using Stripe?

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

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

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

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

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

------
GICodeWarrior
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...](http://expletiveinserted.com/recurring-payment-cost-calculator/)

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.

~~~
torontos
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)

~~~
GICodeWarrior
The Recurly costs are inherent in the calculation being made there. The
Gateway costs were being added on top.

------
jpdoctor
Would love to see the same thing for monthly billing, but with completely
variable monthly payments.

~~~
dangrossman
Most (all?) of these companies support that.

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

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

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

~~~
dangrossman
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?

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

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

~~~
dangrossman
Dwolla doesn't let you accept credit cards.

