pay VS PigCI Rails App

I believe he was talking about the gem called "pay", see https://github.com/pay-rails/pay

Pay for Ruby on Rails: Pay , a payments engine for Ruby on Rails, has made it easier to build custom webhooks.

Rails: Open-source maintainer @excid3 has released version 4.0 of Pay Rails with built-in support for Stripe Tax, metered billing, multiple subscription items, and pausing subscriptions. In addition, @JeffMorhous covers how to sell a one-time purchase in Rails with Stripe.

In the Pay gem, we model all these tables and sync from Stripe using webhooks so that your local copy is always up-to-date and fast.

Again, you don't technically need to store anything in your database. However, I recommend storing at least the string ID of the Stripe Customer (which looks like cus_abc123) in your database. You can store this directly on the users or teams table, or create a separate table for storing Stripe Customer IDs and their relation to PaymentMethods and Subscriptions. Maintaining a separate table offers a bit more flexibility later if you decide to change from supporting single users to teams. It also separates concerns. Have a look at the open source pay-rails database schema or the cashier-stripe migrations for inspiration for modeling your database. If you’d like more suggestions about how to model your database to work well with SaaS, let me know on Twitter: @cjav_dev.

I'd suggest checking out the pay gem. It won't do everything for you, but it'll get you part of the way.

Pay gem

So true! When I made a GitHub App I took the same approach of having a private app to build with & listening to Webhooks via Ngrok :) Then when writing tests I just stubbed out the GitHub API responses.