pay VS stripe

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

Capacitor-stripe v4.2.0: The latest release of Capacitor-stripe introduces native support for Stripe Identity.

Capacitor Stripe plugin released v4.1.2 last month, supporting the card scan API for Android users.

Capacitor, a community-built plugin for Stripe, has added support for Apple Pay and Google Pay. Redwood.js developers are working on a proof of concept integration between Redwood and Stripe Checkout. Try out the project and file issues and PRs if interested in providing feedback or contributing.