Building a subscription service? See a cool way to plug in the subscription part... | Hacker News Reader

Building a subscription service? See a cool way to plug in the subscription part...

spreedly.com

68 pointspetenixey32 comments

The Terms of Service speak for themselves. .

Who in their right mind as a developer would integrate with a service that by its own admission cannot be considered secure, does not guarantee its service, can shut you off for any reason, has no liability if in doing so causes your business to fail, and can change its TOS as it sees fit and you agree to any change they might make in advance.

When Lawyers and Accountants start running your business, you might as well get the bankruptcy documents rolling.

Just a few of the idiotic terms are listed below. To see the complete list of reasons why you should not do business with these guys, go here:

https://spreedly.com/info/terms-of-service/

# Spreedly has the right to modify or terminate the Service at any time, without notice.

# Spreedly has the right to refuse service to anyone for any reason.

# You bear all risk for your use of the service.

# Spreedly does not warrant that the service will be available or reliable.

# Spreedly does not warrant that the service will provide accurate data.

# Spreedly does not warrant that the subscriptions that you offer through the Service will meet the expectations of your subscribers.

# Spreedly bears no liability for any losses of any kind that you may incur through the use of the Service.

#Besides credit card information (which is encrypted), no information that Spreedly stores is guaranteed to be secure.

But they do guarantee that they will bill you once a month and you get a full 2 weeks to audit that bill, and if its wrong and its 2 weeks and a day later, that's just tough luck.

Nice.......

Welcome to the state of TOS in the payment services industry. I agree, it's pretty yucky, but every single upstream provider that Spreedly uses (PayPal, Authorize.net, etc.) has similar terms that are as or even more non-committal. Because of that, and because we're not in a position (yet?) to buck the trend, we've stuck with the party line for now. Even Shopify (http://shopify.com), who is perhaps even more critical to the businesses on their platform, has basically the same set of terms.

Now, while legally there's not much we can do, on a practical level we're a support-centric organization that totally understands that our clients are building their businesses on us and that we have to be reliable. Our income is directly tied to our clients income, so we have all kinds of incentive to make sure that the service is always up and ready to collect payment. Also, because of the way Spreedly works, you can quickly build a layer of simple caching in to your application that will ensure that even if we were down for some reason your site would still be up and serving existing clients.

I hope this helps explain. I know it's not the most satisfactory answer ever, but it's an honest one based on where we (and the industry) are at this point.

Hey HN, just wanted ya'll to know that we're psyched about getting on the home page (the HN audience has a lot of overlap with our target market) and we'd love to answer any questions you have, either here, at http://getsatisfaction.com/spreedly, or via email (support@spreedly.com).

Spreedly is small, but we're feisty, and we're excited about helping a lot of hackers by taking care of the billing while they "build something people want". Thanks for checking us out!

I'm a happy Spreedly customer (I use them at www.neobudget.com). I'm a one-man shop. I developed my software in my free time and wanted to provide it to others at a small subscription fee. I know this sounds like a commercial, but I can't say enough good things about Spreedly. They made what I do possible. Otherwise, I would have to spend half my time worrying about payment processing. But now, I just integrated their API (in one evening after work), and I was good to go.

In my situation, it was well worth the cost to be relieved the burden of developing my own payment processing. Also, the cost is so low, I had nothing to lose by giving it a shot. If it didn't work, I was only out $19.

Those fees are on top of the cut that Authorize.net/PayPal/Protx take, right? So with Paypal Website Payments Pro for example the total cost would be $49/mo and 4-6% + $.30 per transaction.

Yup, that is correct. One nice thing, though, is that you have gateway portability, so you can do some hard negotiation with your gateway and/or merchant account once your volume grows to cut down on the fees. And, of course, as your volume grows, you'll be getting charged 1-2% for most transaction. 3% is only for the first 50 every month.

I don't get why a service that makes money on percentages also has the need to charge monthly access fees. This will slow growth significantly.

I'm no expert, but I'm guessing it's so they don't have a bunch of accounts with 2 or 3 transactions a month making them lose money.

Why would customers with 2 or 3 transactions a month lose them any money?

It'll probably slow growth in a good way. It's really a pretty low bar for anyone who's even half serious about doing recurring billing. It seems like a pretty good way to cap who you're providing support to, and it's a small enough monthly fee that people won't even think twice before paying it... assuming they're half serious, again.

It's a big bar if you just want to test out the service to see if it actually converts better than whatever solution you are currently using. Because anyone who is half serious will have other solutions he is already using.

You're in a position to test providers for conversion rates, but $19/mo is too much? That seems crazy to me.

$19 a month is less than I'm paying now with Cybersource.

Could be. We're OK with that, for now at least. Pricing is tricky and you have to start somewhere, and so far our current price point is working great for us.

It seems to be the difference between an enterprise product and a simpler product for single developers. Does anyone know how much Zuora charges, I can't see on the website?

Spreedly is $19/month + 1-3% depending on volume.

Zuora expects to make $1k/mo off their customers, although I think we could have used them for $500/mo. That's roughly $50k/mo worth of revenue through Spreedly.

its 500 month or 2% of revs. so whichever is more.

Is that something they finally tell you after you sign the NDA? Getting that information was like pulling teeth, and I didn't even have it until you posted it on Hacker news. :)

Funny, Zuora quoted us 2% with a $1,000/month minimum fee. Not realistic for a startup until you're already pretty well established IMO...

That fits what they told me pre-nda (at least, the $1k/mo minimum). They did hint that we could get a $500/mo minimum, but never really said much about it.

2% based on the Techcrunch post

http://www.techcrunch.com/2008/05/20/zuora-the-salesforce-fo...

"Naturally, Zuora has opted for a utility-like pricing model. The company will take 2% of all invoiced amounts, with that percentage increasing decreasing as payments get bigger and eventually getting capped completely for particularly expensive items."

I think the "Freemium" project on Github would also be a good alternative. It builds off of ActiveMerchant and focuses on a subscription model.

http://github.com/cainlevy/freemium/tree/master

Saasy is an open source alternative for Rails: http://github.com/maccman/saasy

Dumb question; How is this better than Paypal?

Spreedly is talking to multiple businesses currently using PayPal's recurring service that want to switch to Spreedly (and we're working with them to make that happen). In short, PayPal's recurring API is awful, especially as you want to do more complex things like, say, allow a subscriber to change their subscription term or plan. Also, have you seen PayPal's admin UI? It's awful for any sort of ongoing use, especially for subscriptions where you have an ongoing relationship with your customers.

In short, Spreedly grew out of using PayPal's recurring API on a client project and realizing that there had to be a better way.

For a bit of background on part of that project see http://talklikeaduck.denhaven2.com/2007/09/02/how-to-cure-th...

Is Spreedly PCI-DSS compliant or have plans to become compliant if it isn't?

One of the Spreedly cofounders is a PCI expert, and we're building the application with PCI compliance in mind. Security's a big deal for us, and for now we're focused on the practicalities of being secure rather than the (expensive, time-consuming) trappings of being certified as secure. We'll definitely get our gold sticker eventually, but not quite yet. In the meantime, we have a constant focus on security and spend regular time looking at the platform through that lens.

What's a "one-time subscription payment"? How does that differ from any other one-time payment for something? In other words, can this be used for generalized one-time non-recurring payments, as well as subscriptions?

By one-time subscription payment we mean a user paying for time-based access to a service where their subscription does not auto-renew. Weewar launched with this model on Spreedly and ran successfully on it for quite a while.

As to non-subscription payments, we don't support them in the general case, but we're currently in the process of adding support for adding one-time fees to a subscriber's subscription. So for instance if you charge for hosting and want to charge customers for bandwidth overage, you'll be able to do that soon.

how does it compare w/ zuora?

For one, they list prices. Zuora seems like they are going for a different kind of customer than Spreedly.

Reply on news.ycombinator.com