

Recurly releases API V2, client libraries and multi-subscription - raerae7133
http://blog.recurly.com/2011/10/api-v2-and-multi-subscriptions/

======
zemo
I 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.

~~~
raerae7133
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.

~~~
zemo
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.

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

~~~
raerae7133
Metered billing can be accomplished through the Recurly API:
<http://docs.recurly.com/subscription-plans/metered-billing>

------
create_account
How is recurly relevant any more, given Stripe and Samurai?

~~~
ScotterC
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.

~~~
create_account
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?

~~~
ScotterC
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.

~~~
create_account
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.

------
robbiehudson
What do recurly use to generate their docs?

