Recurly releases API V2, client libraries and multi-subscription
blog.recurly.com
Recurly releases API V2, client libraries and multi-subscription
1–10 of 13 posts
Re: Recurly releases API V2, client libraries and multi-subscription
#2But 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.
Re: Recurly releases API V2, client libraries and multi-subscription
#3But 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
Re: Recurly releases API V2, client libraries and multi-subscription
#4What do recurly use to generate their docs?
Re: Recurly releases API V2, client libraries and multi-subscription
#5I 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.
Re: Recurly releases API V2, client libraries and multi-subscription
#6How is recurly relevant any more, given Stripe and Samurai?
Re: Recurly releases API V2, client libraries and multi-subscription
#7How 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.
Re: Recurly releases API V2, client libraries and multi-subscription
#8I 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…
wow that's messed up
Re: Recurly releases API V2, client libraries and multi-subscription
#9How 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 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?
Re: Recurly releases API V2, client libraries and multi-subscription
#10I 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.
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.