Payola – A Rails engine for Stripe | Hacker News Reader

Payola – A Rails engine for Stripe

petekeen.net

104 pointszrail30 comments

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.

[1] http://github.com/andrewculver/koudoku

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).

This looks great--thank you!

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).

I look forward to when the gem will be updated with the possibility for subscriptions.

Was just about to say the same. Commenting here so I don't forget.

Can't speak to the code, but the name seems unforunate:

http://en.wikipedia.org/wiki/Payola

It's money related and customers are never going to see it so I thought it worked well. If people think it's offensive I'll think about changing it.

There's a food product named Soylent... So I wouldn't worry about it too much.

That's a poor choice of name, too.

It's not that the name is offensive. The definition of the word Payola, is not something you should want your product to be associated with.

Yeah, I know what the definition is. I just don't think it matters all that much.

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).

Thanks for making and releasing Payola!

I thought it was clever; it might have even been the reason I clicked the HN link.

And I kinda doubt there will be confusion over whether you put together a rails plugin to facilitate paying money for airtime of a band's song.

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.

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.

Awesome! I'm about a month away from adding Stripe into my app.

Thanks for the work on this.

This seems pretty great: like an open source Gumroad or Cargo service.

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.

He wrote the book on payments with stripe. Which also happens to be a high quality book and worthy of a purchase.

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.

Like many others, I've read Pete's book, and it's very good.

Does anyone know of something similar for Paypal?

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.

This would be nice because it's always a good idea to have a fallback payment processor.

Reply on news.ycombinator.com