Stripe + Redwood Integration package

Get Help and Help Others
4

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

5

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!

6

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.

3 Likes
7

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.

8

I have a question: For those that have used Stripe, how often have you used the setup checkout session mode?

9

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.

1 Like
10

@justinkuntz is anything in your project related to Stripe (or you did not reach that stage yet - this is really a rhetorical question :wink: )? 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?

11

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 :slight_smile: - 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 :rofl:

12

Hello @WebstackBuilder :smile:

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:

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

  2. The next level of integration is via stripe cli. Unsure how much this approach makes the integration saves time adds to better UX?

  3. The third approach is via Stripe Apps, just started beta

Which of these three would you advise us to take?

13

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:

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

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

14

[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

15

@adriatic I promise not to run for the woods…I was slightly exaggerating :lying_face:

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.

16

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

image
image2220×1036 415 KB

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?

17

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.

18

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.

1 Like
19

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 :grinning: 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 CustomerSubscription table 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.

1 Like
20

June 7 summary

Hello @chrisvdm and @thedavid

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.

  1. Create a new parallel version of https://superstore-redwood-stripe.netlify.app/, so we can be sure that all needed new Stripe functionality is being engages in the fashion Redwood team expects
  2. Create a set of issues, further processed by Paul Asjes from Stripe for final verification by @thedavid and others participating folks from Redwood team

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

21

Back to the original post by @chrisvdm (copy justinkuntz and WebstackBuilder)

I entered the group of fine people by responding to @chrisvdm ask for help her project - and while trying to collect all information needed for help, I created the perception that I am taking over her project with a lot more ambitious goals. That is not what I want to do, and I am writing this to make it perfectly clear.

Effective immediately I am switching to address these issues. @WebstackBuilder @justinkuntz your posts were not in vain as I plan to build on top of this project once it is done.

2 Likes
22

Hi @chrisvdm,

I have been checking out your integration package. Great stuff!. Are there plans to continue developing this? I have a project coming up that needs one of the payments so my choice is to start from scratch or use what you have made so far (and contribute back as opportunities arise)

What’s your advice?

Thanks

23

Hi Shannon,

Thanks for checking out the package.

Yeah, there are definitely plans to keep developing this and contributions are always welcome. Right now I’m preparing for v1 release sometime this month or early next month.

I’m also super keen to hear how others find using the package. If anything pops up you can create a ticket or PR and I’ll try responding asap.

1 Like