
  Online Subscription Billing Is A Pain. Recurly Wants To Alleviate It.  - transburgh
http://www.techcrunch.com/2009/11/17/online-subscription-billing-is-a-pain-recurly-wants-to-alleviate-it/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29&utm_content=Google+Reader
======
mrkurt
I encourage anyone who needs something like this to check out Spreedly
(www.spreedly.com). We use them for the Ars Premier subscriptions and they're
fantastic, don't kill us with fees, and have a really nice API.

3% of transactions on top of the credit card fees is pretty nuts.

~~~
bluebird
Chargify changres nothing for the first 50 clients and then I think it is a
flat fee if I am not mistaken. That can be cheaper than Spreedly. Recurly
seems to be doing something similar.

What does make a difference is that Spreedly is not PCI compliant. Both
Chargify and Recurly are PCI compliant.

~~~
nreece
Chargify only supports Authorize.net, whereas Spreedly and Recurly support a
few more options.

I think Spreedly has by-far the most reasonable and economical pricing
structure for lean startups.

~~~
dangrossman
I've been evaluating all of these companies and I agree, Spreedly is the most
startup-friendly. Not only in pricing, but they also have the broadest gateway
support.

Unfortunately their admission that they may not be PCI compliant is a legal
issue... if you read that, and pass cardholder information to them, you could
be in breach of your merchant agreement and have no way to really know.

Spreedly also seems to be a side project that isn't getting the developer time
it needs considering the sensitivity of what the product is. They have threads
in their support area where they promised features a year ago and still
haven't delivered.

------
akronim
It sounds like they're targeting startups, but if you're a startup you're
adding quite a bit of risk by depending on another startup (in beta) for
something so critical as your cashflow. It's easy to imagine scenarios where
they go bust at a critical time and take you out too.

~~~
mrkurt
We are part of a pretty risk averse large corporation, and this really isn't
all that much of a consideration for us (for reference, we use another small
recurring billing startup). We generally think the startup can do a better job
of handling these things than we can. We also get ridiculously good service
that we wouldn't be getting from a large, established company trying to shunt
us through a useless enterprise sales process.

So in summary, you're kinda right, but I think it's worth the relatively
minimal risk.

~~~
akronim
Yes, but as a large corp, you have the momentum to survive if you can't bill
for a month, but it might be fatal for a startup.

------
jacquesm
Fair warning: get your own merchant account, never ever use a service that
does not use segregated merchant accounts.

All you are doing is to allow other people to reduce their chargeback rates by
diluting their volume with your charges and sooner or later they'll go down
and leave you swimming.

It will take you a bit longer to get approval and you will have to pay a fee
but at least you will be building a business that will last.

All you need to do recurring is an IPSP.

~~~
johnrob
What is an IPSP?

~~~
jacquesm
Internet Payment Service Provider

A company that registers your merchant account with a company such as
paysquare, they will take care of scrubbing and fraud control (for a nominal
fee per charge) and will deposit your money in your bank account, usually on a
weekly basis.

I should probably do a post on how all the items in an e-commerce transaction
go together.

~~~
adriand
I've got a contract for a web project right now where, if possible, I'd really
like to integrate some fairly sophisticated e-commerce. The two big
challenges:

1) The project deals with separate businesses that all have their own bank
accounts. The money from transactions processed by the app has to be deposited
into the bank accounts that belong to individual businesses. I believe this
means that PCI requirements are substantially more onerous for an app like
this because my client is classed as a payment service provider, rather than
just a user.

2) The app must also be able to process card-present transactions, both
credit- and debit-card based. Customers of the businesses (who are the
customers of my client) that use the app will often be present to swipe their
cards for their payments to be processed.

Are you aware of any services or technologies that would make this easier? So
far I think my preference may be for partnership with a vendor who is already
PCI-certified and has the pin pads for card-present transactions, whose
software has a good API that I can interact with via this web application.

I'll be building this in Rails. I've got lots of experience with traditional
e-commerce models, and I'm comfortable with the technical aspects of dealing
with multiple bank accounts, but the certification requirements appear to be
the major obstacle so far (costing approx $100k, according to my research, for
hiring an independent security assessor and working with them to achieve
compliance).

------
apowell
The API (<http://support.recurly.com/faqs/api/accounts>) looks very similar to
the Authorize.net API, so I'm not sure that this service simplifies the
integration all that much. Also, it isn't clear to me whether the accounts are
stored in Recurly, or whether they are stored within the payment gateway.

Overall, I can't say that I agree with the premise -- I haven't found online
subscription billing to be very painful. However, if I can be convinced that
this service adds value without creating third-party risk, I'd be interested.

~~~
dangrossman
Recurly stores the payment information themselves, not through the gateway. I
e-mailed them previously to ask about this. Theoretically this would mean that
you can switch payment gateways and your subscriptions will continue to rebill
automatically on the new gateway. It also means that if the company were to go
out of business or you were to leave, they could potentially give you your
customers' billing information to take elsewhere.

------
eo3x0
Unless I am mistaken, this is also what Chargify is trying to solve. When I
built my first app, I thought about spinning off the billing layer into a
separate service, but then realized that established companies like Auth.net
have all of the real leverage. We'll see how this plays out in the long run,
but I have a feeling that these types of services are in for a bumpy ride as
their customer base is probably the least stable of them all (start ups).

~~~
kapitti
Chargify, CheddarGetter, Spreedly, Zuora, Aria Systems and now Recurly. Seems
the space will get crowded quickly.

------
nathanwdavis
For a very young startup, the pricing structure is much better than
competitors. If my revenue is really small, 3% of total rev is better than $39
plus a smaller percentage of sales.

~~~
apowell
The pricing is in addition to what you pay for your merchant account and
gateway.

------
jazzychad
I have seen several of these recurring billing services posted lately, but no
one has mentioned BillingCircle. <http://www.billingcircle.com/> I use it for
my startup and love it to death. Great API, ok-ish pricing, and the reporting
dashboard is insane (in a good way).

~~~
dangrossman
Expensive, though.

