SaaS Subscription Billing, or How to avoid getting your n*ts in a vice | Hacker News Reader

SaaS Subscription Billing, or How to avoid getting your n*ts in a vice

peachshake.com

72 pointsbjonathan40 comments

From Braintree's site:

To try and help address this problem, we created a Credit Card Data Portability initiative (press release). It's an opt-in community of payment providers that agree to allow a merchant to port credit card and other associated information if the merchant ever decides to move to another provider.

http://www.braintreepaymentsolutions.com/blog/data-portabili...

I'm a huge fan of Chargify after talking to them a little, and they weren't taking any new Braintree customers. It had to do with Braintree API versions (v1 vs v2). I didn't want to wait, so I went with Authorize.net

Maybe Authorize over Braintree was a mistake, but switching to a different CC processor than Amazon was definitely the right move.

It's interesting that the author didn't mention a third option– you can build your own subscription management and dunning code, and then foist the high-risk credit card related stuff onto a third party. I'm not sure I'd necessarily suggest doing this over going with a provider like Chargify or Spreedly (both look like cool services), but that's what we've done at Onehub, and while it was painful, it's worked extremely well. We just store tokens and let our payment gateway, Braintree, deal with the actual card data and charging.

Additionally, if you are going to write any of your own billing code, I sure hope it's not buggy and poorly tested. If it is, you should probably test and debug it before unleashing it to your customers :)

I did mention that option, and basically said it was a bad idea. I think that most SaaS apps are better served by offloading as much as possible onto third parties. Just like I wouldn't encourage someone to write their own web server, I wouldn't encourage them to write a subscription billing service. It's a pain. Pay someone else to handle that and focus on your core competency, whatever that is.

Right, having written a billing system, I'd agree with you wholeheartedly. I just got the impression that the article conflated rolling your own billing system with actual handing of the payments and credit card storage. Perhaps I was mistaken.

I just finished building part of our billing system that signs up users for subscriptions. We're using metered billing and that part of our service doesn't report anything yet, but so far using chargify has been a great experience.

We don't need to hold CC stuff. We don't deal with dunning. We don't do anything except tell chargify how much our user has used and give them users credentials.

It seems to work very well.

To me, the most important drawback is the inability to defer charging. It honestly breaks my heart to want to tell someone "thank you for that, have a free month of service" and then to see that you can't do that because they already liked your service enough to support you.

I see a commenter mentioning PayPal reference transactions, I will give those a go and see if they are more flexible.

I agree, free subscription time is my favorite thing to give. I can sort of do it with Chargify. It basically works as a partial credit toward their next charge. It's not exactly the same as deferring a payment, but it pretty much works out the same.

Too bad I'm stuck with PayPal :/

With Amazon's SimplePay subscriptions, you can offer a free trial or a promotional period at the start of the subscription contrary to the what the author of the post says.

https://payments.amazon.com/sdui/sdui/business/asp/subscript...

Pretty sure you didn't read closely enough.

I'm speaking of deferring payments, not free-trial periods. The SimplePay free trials work fine. It's only after they convert to paying that things are fully locked in.

One thing I often see neglected from requirements is the need to generate invoices for every payment especially if you are selling to other businesses. They will need records for tax purposes particularly if your customers need to itemize sales tax.

PS I work at FreshBooks helping people use our API for billing

If you're concerned about credit card portability (as this blog author is), your only real options are Braintree's vault or Recurly. Chargify still stores the CC at the gateway level, so you have gateway lockin, which is no different than the PayPal/Amazon case the author bemoans.

Authorize.net also has a vault product.

Chargify still stores the CC at the gateway level, so you have gateway lockin

I don't understand this. Gateways that provide a vault for storing credit card information give you a way to get it out in order to process the transaction. So if you can get the information out, couldn't you just transition to a new gateway if necessary. Only sites like Paypal and Amazon really have lockin.

The way most vaulting services work is, you pass through credit card details, and they store in their vault. They then send you back a token to reference for future transactions. In most cases, you won't have the ability to pull back the full vault entry (specifically the credit card number) from them. This is the lock in that's being referred to here. Most gateways who won't let you export the cc data yourselves, or to another provider will cite PCI compliance issues, but it's all smoke and mirrors. They just don't want you to leave.

And to be 100% clear, Chargify is not a gateway or anything like that, so they don't do any storage - they're a SaaS provider that has built their app to offer recurring billing on top of a bunch of other gateway's APIs.

Bingo.

We decided to go with Authorize.net, and I'm afraid we're locked in again. I willingly and knowingly put my nuts in the vice this time. I asked the sales rep about getting the CC info back, and she cited PCI compliance as their reason for not giving it up.

Still, I decided to go with the big dog, and my hope is that any services like Chargify that we decided to use will also work with Authorize.

You can do exactly what you need with paypals reference transactions.

Also if you use their NVP api, and web payments pro then the user does not need to leave your site and you can take c/c details on your site and pass directly to paypal.

i.e You don't need to store their CC details you only need the reference transaction ID and you can re bill any amount you want.

You also don't have to worry about PCI compliance. I'll talk about this in more detail on today's techzing. http://techzinglive.com

It sounds like this is pretty close to what he was doing originally, but then you have to write your own code and screens to handle dunning (as stated in the article).

Chargify gives you a hosted payment page that you can brand with your own CSS so you never touch the CC at all. It works waaaay better than Amazon, and is not nearly as jarring.

If you don't like that, you can build your own page and pass off the CC details via the API, but I went with quick-and-easy Chargify hosted pages and have been very, very pleased.

Thank you for the very thoughtful write up about the reasons not to build billing and how Chargify has helped. The ownership of CC data is an important topic and many providers talk about the importance of this. Three things to consider

1) How often will you actually change gateways? I can tell that we have had the same gateway account for 7 years and processing millions of dollars a year and changed merchant accounts many times. The gateway industry is pretty much a commodity, very little price change, no difference between gateways so there is not much value in changing. There are reasons you might change merchant accounts as rates do change and volume can make a difference.

2) How to change. If you really do need to change gateways and keep in mind Authorize.net is not going out of business so that is not a consideration, think about the right way to do it. I would either slowly move accounts over as operations like CC updates happened or run multiple gateway accounts to diversify risk.

3) Where is the risk? The largest gateways are not going anywhere so your real risk with not doing billing on your own is the billing provider. And yes I am saying this and I am a co-founder at Chargify. Would you prefer to have your CC details held there or at a gateway where you can always access the token to make future charges? This gives you the ability to move billing providers compared with getting locked in.

At Chargify we take security very serious and have reviewed all of the different reasons around this topic and can tell you that today all CCs are stored at the gateway but in the future we will have an option that gives YOU the choice where to store this data and how.

Chargify seems to be on the right path. I do think they could use some work on their flexibility though.

Holding credit card data is always a bitch. Paypal website payments pro's API lets you issue coupons and discounts that are baked into the initial signup. However midcycle its tough to issue a discount.

They also have some bugs in their API with their callback urls etc.

My biggest bitch about paypal and subscriptions?

They have a documented event for the end of a subscription (EOT) THAT DOESN'T EVER GET SENT! We had some unpaying subscribers hanging around for a few weeks before we noticed the money coming in didn't match our active subscribers. So now we have a nice little cron job cleaning up expired subscriptions.

Don't get me started on the quality or lack thereof of Paypal and their systems.

Actually, Aria SubscriptionsPlus for PayPal lets you manage discounts, etc. with the customer service tools.

Glad you think Chargify is the right path, love to hear what flexibility you want that we cannot give.

@dh I haven't looked over the product in 3 months or so, but there was some issue at the time that we felt we could do better in our own code we layed on top of paypal api.

It's not widely adopted yet (and it's doubtful that it will ever be adopted by Auth / Paypal), but of significance to this discussion is http://www.portabilitystandard.org/.

If the provider you're looking at is a member, then you can at least be sure they get it.

Another option is Spreedly. They store the credit card information internally (they're DSS compliant), so that you can switch merchant accounts/gateways as needed. If you want to transfer out of Spreedly, they'll work with your new provider to get the CC data out to them (it has to be a secure exchange).

Very interesting, I'm making this desicion at the moment. Currently settling on Chargify, but it means changing banks and setting up a new merchant account which is hassel I could do without! Should save me some time on developing my own system though....

hm. how do customers feel about you changing the pricing without their input? I mean, it sounds like the guy is clear ahead of time, but if he thinks he will lose customers if he reminds the user that they are paying, uh, doesn't that mean that he is basically acknowledging that he is not providing a service the user values at full price? that he is just hoping they forget to cancel?

It's related to something I've struggled with; I mean, I make users take active action every bill... I don't support recurring billing, just 'cause I feel weird about just hoping you won't remember to cancel your account. And yeah, I'm probably loosing out on a lot of trailing months... but what do you think that does to customer goodwill?

I'm not saying I know the answers... however, my opinion would be that long term, you are better off providing enough value that the customer is willing to take active action to stay.

On the other hand, I've had several customers ask me for recurring billing, so it's quite possible that the convenience factor is the operative issue here, rather than the value provided by the service. It's possible that the service is worth the money, but not worth the hassle of positively acknowledging another bill.

how do customers feel about you changing the pricing without their input?

I would assume they feel the same way anyone who has ever had phone, cable, or internet service feels. Outside of a contract, prices go up over time. You send out an email 30 days in advance, tell them it's going to happen, and then do it. If they want to cancel and get a refund, ok, no big deal.

Virtually everyone is familier with recurring billing so I think offering it is entirely for the customer's convenience and in no way a bait and switch or any other kind of attempt to rip-off a customer.

>I would assume they feel the same way anyone who has ever had phone, cable, or internet service feels.

If I treated my customers as poorly as comcast does, I'd be out of business, and I say up front that you should only be my customer if you can tolerate poor service.

The point is that everyone is used to this pattern: free trial that will switch to paid subscription unless you cancel.

'everyone? Personally I associate those billing patterns with, uh, less than reputable businesses. Now, I may be very unusual, but we have at least one counterexample.

Edit: I sound like I'm calling you a fraudster, and that is not my intent. I really want to hear about the other side of this, in part because some of my customers have asked me to setup recurring billing that doesn't require action on their part.

As it is, most people who cancel do so right after I bill them. if I was just taking the money rather than sending the bill, then for the same thing to happen, they'd have to ask for a refund. Which, I seems kinda bad to me- I mean, negotiation is waste. However I could automatically gave a refund if they cancelled within X days of me charging them, that would solve the problem.

Anyhow, I really would like to know more about what you think of how 'normal' people think of it. It's not obvious to me.

doesn't that mean that he is basically acknowledging that he is not providing a service the user values at full price?

Well, the users seem to like the service, and they're willing to pay full price. That's good enough for me.

long term, you are better off providing enough value that the customer is willing to take active action to stay.

Good luck with that. I take the stance of provide something of value AND make it easy to pay. I guess you could say I want to have my cake and eat it too.

right, but my worry would be that if you increase your revenue a lot when you switch from sending a bill and waiting for them to give you money to taking money automatically until they ask you to stop, I would question how much of that increase was due to people forgetting to tell you to stop until after they've been billed.

As I said elsewhere, I think the problem could be solved, for a pre-paid service, by giving an automatic refund if the user cancels within X days of getting billed.

Google Checkout allows you to charge less than original subscription.

For startups looking for Subscription Billing, Aria Systems has two options. The first is our powerful & full featured Aria Billing Platform.

The second is Aria SubscriptionsPlus - this is Subscription Management on the PayPal platform. Unlimited customers, you can set up subscription / promotions / usage plans, the data is yours, and you can accept Credit Cards and PayPal. And yes, there is customer support. Pricing is free for the first 6 months, and after it's $40 plus any PayPal fees. More information: http://www.paypal.com/SubscriptionsPlus

How does Chargify deal with fraudulent orders?

Since you have to have your own merchant account, we (Chargify) do not have to deal with the fraud transactions but give you the tools you need like searching for the account to turn it off.

Reply on news.ycombinator.com