What are the advantages of using a recurring payment provider e.g. Recurly et al when Stripe (or Paypal for that matter) allow such subscriptions to be set up?
The only thing I can see is that they might offer a nicer user interface - Stripe offers nothing, so I’d have to build one myself.
Prior to Stripe it actually made sense to use a recurring payment provider since most of the gateways had very awful, or non-existent, recurring billing services. Now with Stripe, and with the burgeoning marketplace that is forming around Stripe, I don’t think it’s as essential as it used to be.
I believe Chargify is starting to change its target market a bit away from API integration and more to providing a pre-built but customizable UI so non-devs can set up recurring billing. So maybe it makes sense if you fit into that category, but if you’re a developer then for the moment Stripe is probably your best solution.
Agreed with @aeden. You don’t need a recurring payment provider if you’re using Stripe.
On the other side, please let me know if you need to manage tax invoices after getting paid via Stripe. I built a solution to deal with that problem.
If I was starting from scratch I would use Recurely or Chargify or similar. Dealing with the Stripe API is a nightmare. It’s way more powerful than old school Authorize, but that lets you get into way more trouble. We’ve also encountered many bugs as well as confusing scenarios where we’re sending in something that would seem harmless but in fact does great damage like resetting customers back to trials, etc.
Using a service in front of Stripe also means it’ll be much easier to do other nice things. For example, try CC up front vs not (requires tons of work to change this if using your own code), accept invoices outside of your standard subscriptions for special cases, enterprise sales, etc, make it easier to move away from Stripe if they go south or get funky.
One downside of using a service like Chargify: Chargify subscriptions are not Stripe subscriptions, so services that rely on data from Stripe subscriptions to do interesting things (such as Bare Metrics) won’t work.
On the other hand, having Chargify in front of Stripe was a boon for us when it came time to migrate from Auth.net, since Chargify did the majority of the work relinking all customer profiles with Stripe profiles, so there are positives as well.
Your point is valid though - having a layer here does let you switch later assuming that layer provides the integration for you. The same could be said by making sure you have an internal API layer as well though when you design systems that communicate with the outside world.
Giving 1.25% of revenue to Recurly seems like a little much tough don’t you think?
Do the likes of Recurly/Chargify provide a skinnable UI that you can domain redirect to? Would be nice to avoid having to write any UI code.
Chargify is flat fee. Recurly does take a cut though. Hard to say if it’s worth it or not, but I know between missed revenue to do issues and dev time spent on fixing, modifying, changing, working around, etc that paying them 1% would be a lot less than it’s cost us so far.
Recurly is a fee per month AND a cut - $299 per month and 10c + 1.25% per transaction. The two together are hard to swallow! One or the other would be fine but both are too much.
Chargify does offer white-labeled UIs I believe.
one reason I looked into implementing https://www.chargebee.com/ (and probably will do), is because they handle the european VATMESS
I’ve been using Stripe for 2 years without problems, but I manage trials myself and only create a Stripe customer when they activate their subscription. Maybe that’s why I never ran into problems.