Recurly releases API V2, client libraries and multi-subscription
blog.recurly.comI wrote my own Python client for Recurly API v1 that I released a few days ago (http://pypi.python.org/pypi/recurlib) and asked them, last week, if I had their permission to release it publicly, not because I technically needed it but as a courtesy. I also asked them if they had any requests on what I should or should not name it; I thought it would only be polite to give them first dibs on the PyPi name. I also asked them if they had any requests on what license I should use. In the process, I reported a large number of bugs on the v1 API. They never answered any of my questions straight, they just said "we're releasing our own Python client". They never mentioned that releasing their own Python client was going to coincide with an updated API and that I was actively coding against a soon-to-be deprecated interface.
So thanks, Recurly. I spent a week writing a library to add value to your product without so much as a "good job" or a "that's cool", and when I extended every courtesy I could you basically said "fuck you" to me in every way possible.
We certainly appreciated the efforts you contributed to the v1 version of our API Python library. As we had mentioned to you in our support exchanges, we realized our old Python library was not up to our standards, and that we had been working on a new client library - because this is such a large project with many working pieces, we were keeping it slightly under wraps to allow for flexibility in the release cycle.
That being said, we know many merchants will opt to stay in v1 of our API for some time, and your client library will be very much appreciated.
well to be honest that client library was written to address the shortcomings of the previous Python library, which didn't support Recurly.js (arguably the best part of Recurly), but the new Python client library does and my library wasn't completely finished yet. Even though I have to move some code on my project over, it frees me from having to finish writing that client library, which is honestly about as interesting as waiting for paint to dry so you can watch it chip. It's don't exactly wake up in the morning and think "I wonder what kind of XML I'll get to parse today".
I'm annoyed that I did a bunch of throwaway work that could have been easily avoided, but the API updates are a significant improvement and they solve a bunch of problems for me that I was previously forced to solve myself (especially the new support for multiple subscriptions), so it all comes out in the wash.
wow that's messed up
But still no metered billing or check-receiving. These two features would really be a killer feature for Recurly/Cheddargetter/Chargify, as opposed to Zuora's $10k/month minimum fees.
Metered billing can be accomplished through the Recurly API: http://docs.recurly.com/subscription-plans/metered-billing
How is recurly relevant any more, given Stripe and Samurai?
well first off they have many customers, I'm one of them, that use and love their product.
Second, anyone with an established merchant account that would like to add a recurring payments front to it is in the market for recurly and not as much stripe.
Not sure about Samurai, but Stripe is an aggregator of payments which can lead to problems down the line because credit card companies don't like to deal with aggregators because when issues arise with customers, the onus is on the credit card companies. Example: a Amex customer tells amex 'I never paid company X money'. Amex looks and doesn't see any payment to company X but a payment from Stripe which aggregated payments from Company X. This creates problems which typically yield in Amex refunding the customer but taking the hit because they can't prove it to the aggregator. It makes it very hard to resolve the issue and as a result credit card companies start playing hard ball with aggregators. Note: I'm a huge fan of Stripe and what they're doing. All the power to them.
Established merchant accounts are expensive.
Why pay those merchant account fees, and on top of that, pay another set of fees to be able to do recurring billing?
To be absolutely sure it will work.
Recurring billing is a whole separate issue. I've rolled my own before and realized how much of a pain it can become. Using recurly allows all non devs on my team to handle all the subscription and recurring problems without me having to build anything.
Stripe and Samurai don't work?
Recurring is built-in to both of those platforms, and the fee structure is far less.
I don't know why you're willing to put up with the credit card processing status-quo.
What do recurly use to generate their docs?