Stripe + Redwood Integration package

Hi All! I’m building a Redwood/Stripe integration package. I’m currently researching what v1 should look like and was wondering whether I could pick the brains of those who have built Redwood apps with Stripe integration.

The main question here: What would you find valuable as part of the integration?

For example:

  • React component based API or vanilla javascript API?
  • Redirect to Stripe checkout page or building custom checkout form?
  • Any Stripe feature that you feel is a must for an MVP for you?
4 Likes

That’s great @chrisvdm! I’ve been thinking a lot about what a plugin framework would look like for RedwoodJS. I have a project I’m working on, and I want to abstract pieces of it for reuse in other projects. There’s an open issue on the topic (#388) that didn’t get much traction, mainly I think because the posters in that issue weren’t very clear about what exactly they wanted.

@freddydumont has an nprogress component for RedwoodJS that might give you some ideas. I like that it uses Emotion and Theme UI. I’ve seen other work that’s based on Tailwind, which hard-wires styling into an “all-or-none” pattern in the package. Emotion/Theme UI lets you override just the styling you want really easy through props in client code. The downside is it specs a component library (included in Theme UI) which is too opinionated for a framework to do.

One of the things I’ve wanted to recommend and write up reasons for doing so is to follow a naming convention like Gatsby does. It makes Gatsby-specific plugins really easy to find in the package registry. A general scheme would be something like redwood-plugin-stripe, and then if there’s plugins to your plugin redwood-stripe-[subplugin name].

It’d be nice to have the option to redirect to the Stripe checkout page or build a custom checkout form - maybe the latter through a supporting package, like a subplugin (e.g. have an extension API for doing so)?

An easy way to use Stripe’s sandbox testing environment would be a nice feature for me, especially if it picked up the dev environment to know to do so.

3 Likes

I love the idea of just dropping in a React component, but deciding how much of it can be customized (and that interface to the styling options) is tough. The Headless UI stuff from Tailwind has been pretty easy to customize and looks great right out of the box: https://headlessui.dev/ I like that you have access to regular HTML elements and className attributes and not some kind of invented data structure you need to fill out to change colors/fonts/margins.

We do have a bit of a style language developing with our scaffolds (and login/signup pages coming soon) so we could default to something with a similar style:

Of course, if you just drop in a link to a Checkout page then none of that matters! If you use Checkout for a subscription I’m not sure how you would update/cancel? Maybe they have a “modify your subscription” Checkout page to send a user to?

My most common use case is letting users sign up for a subscription: a page that shows the available plans/prices, lets them choose one, then a preference/settings page for letting them change/cancel their subscription later. So being able to pull the list of plans/prices would be great, but not required—I’ll only have a couple of plans and could start by hard-coding the price onto the page. But later on when it’s time to start testing different pricing levels it would be much more convenient to pull the data from Stripe itself. (But you could always use the stripe package directly and do whatever you want to pull data, I don’t know that Redwood even needs to do anything to make that more convenient…)

The most base requirement I can think of is to respond to Stripe webhooks!

3 Likes

@rob thanks for the link to Headless UI, that’s a really nice project. Is there anything in the utility CSS space (especially with Tailwind) for doing global theme templates, like Theme UI does?

The new version of Material UI (in beta now, v5) is moving to Emotion. I think that’ll get a lot closer to allowing interchangeable component libraries at some point since the props have defined meanings. React Admin uses Material UI (v4), and it also seems like a really good choice for an admin framework with Redwood right now. Being able to swap Material UI out for Theme UI or something else with little friction might be a real possibility with it in the future.

Thank you @rob and @WebstackBuilder for sharing. I really appreciate it.

So some observations (from this discussion and DMs) are:

  • The ability to work with webhooks might be the clincher. Stripe has a few million, but the subscription-related ones are a place to start.
  • The degree to which UI should be customisable is a question if using a React component based API.
  • (Mainly from DMs) There seems to be a desire for some type of database syncing with Stripe .e.g. Customer changes their subscription and us developers might want to update our database to reflect that.

If more people would like to jump in on this, I’d be keen to hear your thoughts!

If we could do all of what stripe-sync-engine does, that would be awesome :smiley:

stripe-sync-engine is a stand-alone app that uses Stripe’s webhooks to sync a few DB tables with Stripe’s data. But with RW we don’t need anything stand-alone, we can do it all with RW’s built-in support for webhooks. They use a separate db schema for the tables, but that only works with PG DBs, and we want to be more DB agnostic than that. And it also doesn’t work with Prisma, it only gives you access to the “public” schema.

1 Like