Congrats, Pete! You literally wrote the book on Stripe integrations and it's awesome seeing you embrace open source as a way of sharing your knowledge. I love how well thought through everything you've done is. I can't wait to see what you do with subscriptions!
As the author of the Koudoku gem[1] that Pete mentions, I'd encourage people familiar with it to keep a close eye on Payola as well. Given Pete's technical excellence, great implementation choices, and broad experience with different types of Stripe integrations (my primary interest has been SaaS products,) Payola could very well supersede Koudoku when he tackles the subscription side of things.
As a minor contributor to the Koudoku gem, I have to say that the structure and especially the test coverage of payola are amazing.
Well done, Pete! Looking forward to how you integrate subscriptions into this
Seems like this is a little bit cleaner than using stripe-ruby + stripe_event + checkout.js. I've never tried stripe-rails.
I get the idea behind making this code async. I've never experienced slowness with Stripe's API, but I'm sure it happens!
One of the pain points for me is keeping all of my Stripe data in sync with my AR models.
Would would be helpful for me would be a generator for a set of ActiveRecord models representing all the stripe data, and have all the webhooks populate those tables(and maybe rake tasks as well to initialize things).
Does anyone use ActiveMerchant? I looked at it several years ago and it seemed to be just a mess: scanty documentation, hard to install/set up, lots of bugs. So I've always gone with rolling my own payment code (usually Stripe, sometimes PayPal), and it'd be nice to stop that, one way or another. It seems like ActiveMerchant will be Payola's main competitor.
ActiveMerchant's entire purpose is about abstracting all the different payment gateways into one API. If you know for sure you're going to use Stripe, or if you want to use Stripe specific features (of which there are quite a lot worth using) ActiveMerchant is less valuable to you.
It's also worth noting that ActiveMerchant hails from a time long before Stripe or even Braintree, and so it supports gateways that are quite a bit more complex. (disclosure: I wrote the ActiveMerchant Stripe support).
Yes. Now that I look over the ActiveMerchant docs again, I have a few observations/questions:
- With AM, you have to accept the credit card details (even if you don't store them), and then send them on the the payment gateway. Even with AM's Stripe implementation, it's your Rails app sending the info to Stripe. There is no Javascript sending the details straight from the user's browser. (Or am I mistaken about that?) So you have a higher PCI burden than if you used Stripe in the normal way.
- AM doesn't provide any persistence, just an API to the payment gateway, so you would still have to roll you own tables/models for payment success/failure.
- I don't see support in AM for subscriptions.
Looking at AM again now, perhaps my previous comment was too harsh, although that's how I remember it when I checked it out long ago. Even now, I'm tempted to say that Payola's landing page already has better documentation than AM.
ActiveMerchant is just an abstraction layer around various gateways. It's goal was never to provide a full-stack solution, but to simply making working with numerous gateways easier because you have a common interface for working between all of them.
As for subscriptions, that's a feature that could be added but many of the Gateways that ActiveMerchant supports don't have subscriptions baked into them (compared to say Stripe).
You could of course have your application store the credit card information and manage the charges yourself using ActiveMerchant, but that opens a bunch of PCI compliance and such.
If you just need to accept money and aren't already bound to a specific merchant account, then plain ole Stripe or Payola are a better option.
The main thing preventing me from using stripe directly in my applications is that it does not calculate sales taxes. The added complexity to do so makes it complex to integrate.
That aside, thanks for the book, I am buying it as I am sure that the advice will be relevant for the payment platform I will use (hesitating betweek Chargify and Recurly right now).
Regardless of the name, this is a Rails engine for Stripe integrations put together by the guy who wrote the book on Stripe integrations for Rails. Definitely worth checking out.
In this case I don't think it matters because it's not offensive. Most people won't even make the connection to the other definition (I didn't know about it until now).
I actually thought about this too. The small subsection of people who will get the reference and be a Rails developer may chuckle, but I think for the most part it will go unnoticed and not really matter.
Love that this gem does things the right way, like including background jobs. As a Rails newbie trying to build billing, all the code/tutorials/gems I could find weren't nearly this high quality or robust.
So, is this only needed if you want to do asynchronous processing with Stripe? I vaguely recall integration with Stripe was really simple probably because it was synchronous.
A basic Stripe integration is pretty simple, but to do anything more advanced you end up writing a lot of boilerplate code. Payola (and the other projects mentioned in the post) attempt to simplify and eliminate the boilerplate that you'd otherwise have to write.
Right now things are Stripe-specific for expediency, but there's no reason why Payola couldn't be extended to multiple payment providers, as long as they provide the same basic capabilities.
As the author of the Koudoku gem[1] that Pete mentions, I'd encourage people familiar with it to keep a close eye on Payola as well. Given Pete's technical excellence, great implementation choices, and broad experience with different types of Stripe integrations (my primary interest has been SaaS products,) Payola could very well supersede Koudoku when he tackles the subscription side of things.
[1] http://github.com/andrewculver/koudoku