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).
SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
11–20 of 43 posts
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#12You 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
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#13You 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.…
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).
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#14Chargify 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.
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#15It'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.
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#16One 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
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#17It'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 :)
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#18hm. 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.
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#19To 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.
Re: SaaS Subscription Billing, or How to avoid getting your n*ts in a vice
#20hm. 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 st…
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.