5 ms·

If you are using Ruby on Rails, you can buy a base application with a whole bunch of best practices built in, including many payment systems. This will save yo

If you are using Ruby on Rails, you can buy a base application with a whole bunch of best practices built in, including many payment systems. This will save you much more time than the cost of the kit. Check out http://railskits.com/saas/ http://railskits.com/saas/ for the SaaS Rails Kit * Disclosure - I'm friends with Ben, the owner of RailsKits, and have done work for him in the past.

Terpaholic 13y ago
Unfortunately I'm using PHP, but thank you! I think I'll be going with Stripe for the payment management, now just working on account management (hashing/salting passwords etc) and associating that with the accounts. I've never done this before so it's really like building two projects at once: the software, and the account/payment management system.
- tomfakes 13y ago
  Find a good PHP bcrypt library and you'll be ahead of 90% of web sites with your password security. bcrypt is the current Rails best practice password hashing solution. Stripe is good, as you'll never see credit card numbers, so you'll have no security issues to deal with in that area
  - krapp 13y ago
    phpass? https://github.com/rchouinard/phpass https://github.com/rchouinard/phpass
tptacek 13y ago
I'm surprised that this is the first of these I've seen. This is actually a really good idea.
- jplewicke 13y ago
  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.

Terpaholic 13y ago

Unfortunately I'm using PHP, but thank you! I think I'll be going with Stripe for the payment management, now just working on account management (hashing/salting passwords etc) and associating that with the accounts. I've never done this before so it's really like building two projects at once: the software, and the account/payment management system.

tomfakes 13y ago
Find a good PHP bcrypt library and you'll be ahead of 90% of web sites with your password security. bcrypt is the current Rails best practice password hashing solution. Stripe is good, as you'll never see credit card numbers, so you'll have no security issues to deal with in that area
- krapp 13y ago
  phpass? https://github.com/rchouinard/phpass https://github.com/rchouinard/phpass

tptacek 13y ago

I'm surprised that this is the first of these I've seen. This is actually a really good idea.

jplewicke 13y ago
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.