Online Subscription Billing Is A Pain. Recurly Wants To Alleviate It. | Hacker News Reader

Online Subscription Billing Is A Pain. Recurly Wants To Alleviate It.

techcrunch.com

21 pointstransburgh23 comments

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.

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.

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.

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.

Spreedly updated their pricing recently: http://blog.spreedly.com/2009/11/12/improved-spreedly-pricin...

Oh, yes. The 3% was in reference to Recurly.

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.

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.

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.

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.

What is an IPSP?

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.

That would be a very helpful post! For some of us the whole ecommerce side is unknown and a bit scary.

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

You need your own merchant account to use Recurly or any of their competitors. They are not doing the processing for you. You have to provide them your payment gateway credentials, and they make the API calls to charge customers using your own gateway (and your own merchant account). They're only handling the technical side, none of your money ever touches theirs.

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.

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.

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

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

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.

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

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

Expensive, though.

Reply on news.ycombinator.com