It's been around for a few years, and I'd definitely recommend it. It's very comforting when you find yourself saying "Wait, what if I need to do refunds or dunning emails? Oh, that's already handled." I've saved many hours of development time by starting with it as a base, and would recommend it to anyone writing Rails-based SAAS.
It has a few wrinkles though, mainly from being actively developed in 2008, with mainly bugfixes and Rails 3 support coming since then. The main ones I'd highlight that tripped me up:
- Expects payment gateway authentication credentials to be stored in a YAML file in source control instead of loaded from the environment.
- A number of the controller actions trigger immediate email sending, which can cause customer-visible 500 errors if the email sending fails and is a less reliable way of making sure the email gets sent.
- Use Stripe API v1 instead of the current v2.
- A lot of the customer email templates are kind of boilerplate-y and would not win the Patrick McKenzie stamp of copywriting approval. I believe they're loaded in from the gem rather than from the app.
My main piece of advice would be to vendor the entire gem right off the bat -- you're likely going to be tweaking several different parts of it, and there's almost no active development that you'd have to incorporate.
Comments
I'm surprised that this is the first of these I've seen. This is actually a really good idea.
It's been around for a few years, and I'd definitely recommend it. It's very comforting when you find yourself saying "Wait, what if I need to do refunds or dunning emails? Oh, that's already handled." I've saved many hours of development time by starting with it as a base, and would recommend it to anyone writing Rails-based SAAS.
It has a few wrinkles though, mainly from being actively developed in 2008, with mainly bugfixes and Rails 3 support coming since then. The main ones I'd highlight that tripped me up:
- Expects payment gateway authentication credentials to be stored in a YAML file in source control instead of loaded from the environment.
- A number of the controller actions trigger immediate email sending, which can cause customer-visible 500 errors if the email sending fails and is a less reliable way of making sure the email gets sent.
- Use Stripe API v1 instead of the current v2.
- A lot of the customer email templates are kind of boilerplate-y and would not win the Patrick McKenzie stamp of copywriting approval. I believe they're loaded in from the gem rather than from the app.
My main piece of advice would be to vendor the entire gem right off the bat -- you're likely going to be tweaking several different parts of it, and there's almost no active development that you'd have to incorporate.