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:
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.
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!
@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:
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 
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.
Thank you @Tobbe, I’ve seen a few projects that do the whole Stripe DB syncing rather well. It’s good to have another reference.
I have a question: For those that have used Stripe, how often have you used the setup checkout session mode?
I’m in the process of building out a subscription site for field service work. It has 3 tiers with add-on products in scheduled(recurring) and upfront annual payments. I’m going to use Redwood for the admin and routing utility but need a front end for user registration, account and subscription management. Vercel has a pretty sweet starter for Next that has some nifty CLI utilities for setup: GitHub - vercel/nextjs-subscription-payments: Clone, deploy, and fully customize a SaaS subscription application with Next.js.. Something like this for Redwood would be the cats meow.
@justinkuntz is anything in your project related to Stripe (or you did not reach that stage yet - this is really a rhetorical question 
)? As you likely know, Stripe just released a beta for Stripe Apps, as different from using Stripe CLI. I believe that your app Next.js Subscription Payments Starter, using the Stripe CLI approach is this correct?
Do you have an opinion about which of these two approaches would you take if starting today. I would also appreciate a comment from @chrisvdm (she is running this project, having limited time on her tasklist), so I am trying to help by establishing best path forward.
My last question is this: in your app, do you use any stripe “components” that have their own UI, like Stripe checkout which simplifies your work, but disables you from invoking only Stripe API, rendering all of your UX yourself?
Hey @adriatic, I’m jumping all over the place with Stripe integration so bear with me. I haven’t really looked into the Stripe Apps release but it looks pretty cool for integrations for metrics and services.
For the current project use case, the system will collect user information and subscribe them to monthly, quarterly, or bi-monthly plans (pay on interval or annual). An added complexity is the graduated pricing per each product (say $29.99 for the first and $10.99 for each quantity after that). The collected customer data will be used in a customer management portal for business procedures and the customer will receive service information in a customer dashboard.
To test Stripe options, we were added to the Stripe Pricing Table Embed beta which is pretty slick. They don’t support graduated pricing yet but will in the coming months. The Stripe Checkout and Pricing Table approach could work but we are needing more control over the signup process and collection of customer data.
This is why the Nextjs starter was appealing for customer marketing and sign-up. It uses Supabase (Postgres) to sync Stripe (CLI) with 5 tables: customers, prices, products, subscriptions, and users. With the captured data, the app can present the user with an interface protected by login that displays their subscription plan. If they click to change it, the user is directed to the Stripe Checkout integration (vs using Elements). It just doesn’t incorporate the more complex pricing models like graduated pricing nor the collection of customer data before checkout.
So…to answer some questions 
- Starting today (or a couple of weeks ago), I’m building the capturing of customer data in Redwood. Long term, we want heavy control over the user experience within the app (likely Stripe Elements) to provide a more seamless experience. In the near term, we are likely going to simplify the pricing model and use some Stripe Checkout tooling as we need to get up and running soon.
Disclaimer: I work more in Product and Design and get myself in plenty of trouble with code. That is to say, when it comes to really technical questions, I run for the woods 
Hello @WebstackBuilder 
I am trying to help @chrisvdm (project lead of this rw-stripe integration package) so, I am having a favor to ask. Please check my today’s questions for @justinkuntz and respond to this discussions. My key issue is the one of approach to RedwoodJS-Stripe integration:
The simplest one is described in article gatsby-source-stripe where Gatsby created a Stripe plugin, that support fetching the stripe data via Stripe API. The consequence is that our RW app, integrated with Stripe this way has to create the complete UX.
The next level of integration is via stripe cli. Unsure how much this approach makes the integration saves time adds to better UX?
The third approach is via Stripe Apps, just started beta
Which of these three would you advise us to take?
Thanks @justinkuntz for very valuable opinions (as you know,I did not ask about any code related questions) You being in design mode, I would care about your preference between two extremes:
The simplest one is described in article gatsby-source-stripe where Gatsby created a Stripe plugin, that support fetching the stripe data via Stripe API. The consequence is that our RW app, integrated with Stripe this way has to create the complete UX.
The next level of integration is via stripe cli. Unsure how much this approach makes the integration saves time adds to better UX?
As a designer, what you think your customers ask for (approach 1 is a simple integration with Stripe, but you would have to code for all user experience (UX) - a non trivial task for your developers.
[quote=“chrisvdm, post:8, topic:2226”]
setup checkout
[/quote] @dom
@dom strong text
Chris would this quote help ?
What’s the difference between Stripe and Stripe checkout?
You may be wondering what the difference is between Stripe and Stripe Checkout. While our “regular” Stripe Payments integration allows users to enter credit card payment information directly on your form, Stripe Checkout seamlessly redirects users to the Stripe website to process payment.Jul 26, 2021
Please note that this answer is over a year old - and that there are new options I posted in my questions to @WebstackBuilder
@adriatic I promise not to run for the woods…I was slightly exaggerating 
I have some clarifying questions.
In #1 the plugin pulls data from Stripe to be ingested by Gatsby at build time. It still uses the Stripe Checkout but I assume a developer could replace that with Stripe Elements to control the final checkout experience as well as the customer dashboard(s)? Would the Redwood approach store the data independently like the Nextjs example that uses Supabase?
For #2, I’m not 100% what that build would look like? It seems like the Stripe CLI could be used in #1 for development. In the Nextjs example, I used the CLI to query Stripe data in an attempt to adjust the fixtures and types files. Would this approach be primarily tooling through the CLI to set up the webhooks between Stripe and Redwood resulting in an API to be then integrated into the Web directory? I suppose the benefit would be a Redwood API that then could be used in several other directories?
Apologies if my questions are rudimentary…please feel free to ignore answers if this doesn’t contribute to a roadmap that @chrisvdm is working on.
So to answer the designer question. Most of my clients want a lot of control over the user experience. That is primarily because they work in the subscription and membership arena with a lot of “hooks” and custom customer messaging (both UI and email). I also have a tendency to want control over the entire user experience. That said, it always comes down to budget which usually stomps full control. Most developers I work with want to use as much of the Stripe tooling as possible to eliminate the need to add more test files.
Most developers I work with want to use as much of the Stripe tooling as possible to eliminate the need to add more test files.
The ability to integrate Stripe with any app in the way to use Stripe not only as the source of data (the approach Gatsby uses) but also to have Stripe components also render as much of data as possible is the key for our decision (yet to be approved by @chrisvdm, @rob and @dom). I am engaging you in this discussion not to make a decision for us, but rather to share your preferences given your longer experience with Stripe.
In order to explain the your app rendering versus stripe elements rendering let me show this image, below
If you only use Stripe API (a techniques used by stripe years ago (see payment API blog article, your application would have to render (draw all bits) shown on the large green rectangle on the screenshot above.
In other words Stripe learned a lot from its early customers who did not like to do all that work. So the today’s trend is moving away from just supplying the data and keeps adding more and more visual components.
Making sense?
In the meantime I established contact with Paul Asjes - Stripe Developer Advocate, who was assigned to be a part of this project. I was not sure whether he has access to this discussion, so I send him my questions via email. I will post my questions and his response, shortly.
Hi @adriatic,
I’m interested in this feature and would like to help by sharing my experience and maybe in future helping with more research and even coding.
About a year ago I worked on a startup that needed Stripe integration.
One of the things that hasn’t been mentioned yet in the discussion here is the ability to intergrate the Stripe subscripion status into the authorization of an app.
For example, we had a requirement to disable all app functionality when the subscription was expired in Stripe with the exception of login/logout and navigation to the billing management screen.
We didn’t use any “stripe-to-db” sync tools so our solution ended up requiring a lot of effort on the coding side. From memory we used a webhook to update our CustomerSubscription table in our database. This would then be checked during authorization to determine if an account had a valid active subscription.
We also didn’t have much experience within the team of Stripe so the interactions between the product owner, designer and developers were not ideal. The product owner wanted to get a fully branded experience for payment while also wanting to manage the effort and time of development. I think the reason for this was that it was a very important part of aquiring paid customers of the product.
But on the other hand we did not end up adding support for Apple Pay or Google Pay which is an in-built feature when using the Stripe hosted checkout. So in that sense it may have detracted from the UX of the upsell from the free plan.
Unfortunately I moved on before the product ever launched so I can’t give any more details around how it went.
However I do think that having the Stripe hosted checkout and subscription management should at least be an option for Redwood as it allows for low-maintenance adoption of future improvements and features that Stripe adds.
Maybe having both the Stripe hosted and fully branded as options that can be chosen from when setting up Stripe with Redwood makes sense.
In regards to the syncing of data from Stripe to Redwood I think that should be treated as a separate decision to how the customer experience is built.
Whether or not Stripe hosting UI or Stripe Elements are used should not have an significant impact on the decision on what to use for syncing data to and from Stripe and Redwoods database.
One last note, we also had a requirement for a free trial which we setup in Stripe as a product with $0 price. This seemed to work fine and allowed a user to transition to and from the paid products.
Hello, @jonparker thanks for your very informative post. Please see my comments below:
I’m interested in this feature and would like to help by sharing my experience and maybe in future helping with more research and even coding.
About a year ago I worked on a startup that needed Stripe integration.
I am sure that all contributors to this project will be happy to see this - @chrisvdm in particular.
One of the things that hasn’t been mentioned yet in the discussion here is the ability to intergrate the Stripe subscripion status into the authorization of an app.
Stripe is advancing very fast, so the so this issue seems not be an issue 
any more. Probably the best use case for the initial deployment is the Redwood’s own shop site which was at the moment created without Stripe (note - this is just my opinion)
We didn’t use any “stripe-to-db” sync tools so our solution ended up requiring a lot of effort on the coding side. From memory we used a webhook to update our
CustomerSubscriptiontable in our database. This would then be checked during authorization to determine if an account had a valid active subscription.
Stripe’s “visual elements” hosted in Stripe cloud seem to be the natural approach now. It’s just a guess, but I do not expect to have to deal with our own database
We also didn’t have much experience within the team of Stripe so the interactions between the product owner, designer and developers were not ideal.
Our current situation is quite opposite - we have a prominent Stripe’s developers advocate on our team (lead by @chrisvdm as you likely realized) and my own experience with Stripe’s support time is better than with any other vendor ever.
At this point it is pretty obvious that this discussion thread has created a significant interest in the RW community (based on the number of views). Here is a brief summary of my own actions, trying to learn enough about Stripe to be able to offer the quality help to @chrisvdm (help that this project deserves).
The existing code (GitHub - redwoodjs/example-store-stripe: Redwood Example Store with Stripe Checkout Integration) relies on a previous version(s) of stripe, so rather than trying to massage the app at https://superstore-redwood-stripe.netlify.app/ to work with the latest Stripe, I am planning to create that same app from scratch using several existing new ports by Gatsby, Vue and Next.
In the course of last week I established a connection with Stripe Developer’s advocate Paul Asjes, several Stripe support engineers and several RedwoodJS customers (software developers) willing to help this project.
As I may have taken more time than I was supposed to take, I would to ask @chrisvdm to assess whether we can continue pursuing my plan based on my investigation of Stripe, i.e.
Note: I expect that @chrisvdm approves this plan before getting to run it. At the moment there is at least one RedwoodJS customer contributor - @realStandal with existing Stripe experience who accepts to work on this (slightly modified) project
