Live data from Hacker News

Recurly releases API V2, client libraries and multi-subscription

blog.recurly.com

11–13 of 13 posts

Re: Recurly releases API V2, client libraries and multi-subscription

#11
post #7

Earlier quoted context omitted.

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 aggregato…

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.

Re: Recurly releases API V2, client libraries and multi-subscription

#12

Earlier quoted context omitted.

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.

Re: Recurly releases API V2, client libraries and multi-subscription

#13
post #5

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 as…

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

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.

Post reply on HN