Stripe integration unanswered questions v2

A slightly related question I have been asking myself is "what information should I save in my own data store?". Ideally I want to store everything, because that makes querying all this information easier, this will however increase maintenance complexity. Currently I am only storing some basic information about the current subscription (such as start/end date and plan id), and a customer id.

Using this information I query all other information during runtime. At this moment the additional information I am querying is mostly about invoices, registered payment methods and other subscriptions.

Now back to the free plan. Initially I did not register anything with Stripe. Now however I have changed the method to directly sign the user up to a trial of a premium plan, instead of signing users up to a free plan, with the possibility to upgrade to premium with trial included. This has the benefit that users get to see the premium features without further action, instead of having the mental barrier to 'potentially' spend some money by signing up to a trial.

From a technical point of view I have implemented this by creating a subscription as soon as the user is being registered. Within the trial period I try to get the user to enter their payment information in order to convert the trial into a paid subscription. If I do not have their payment information by the end of the subscription I cancel it, and the users can continue using the product using the free plan. When an user signs up again after the trial has ended, I check whether the user has a cancelled subscription for the plan, in order to prevent the user from having another trial period. Information on the back-end is primarily updated by relying on web hooks, and based on this the API almost instantly reflect changes made within Stripe.

Within the front-end I load an object with user information which contains info about the current subscription, but also some information about the user's access rights.

If interested I can do a write up about the combination of GraphQL, user authorization, subscription status and role base access control (RBAC). Simply put, the API only returns the data the user has access to in order to prevent roundtrips for questions like 'do I have access to this resource?'.

I would love another one of these! I might collate all this information and put it somewhere useful for us indiehackers.

Thanks for the shout Andreas!

That is, "How to have a free member plan in your paid service?".
Short answer, you don't! In all my apps I consider a "free subscription" to be a user without a subscription. That is to say, they have registered an account, but have not subscribed, so they are , for lack of better words, "on a free plan".

Should you keep the stripe customer plan state on your database or request it directly from stripe?
I always keep the plans in the app. >When the plan is updated, it gets synced to stripe via an async background job. You really want to save the plans, and the plan id into your own app, because a typical flow involves a pricing page, and clicking on a plan to subscribe, and you'll typically send that plan id in the URL as a parma so that you can match it up server side when they actually subscribe.

Hope this helps! Happy to answer questions.

1. "How to have a free member plan in your paid service?".
   I agree - your application does not need to do anything with stripe regarding free users. Just let them access the app.

2. I think you are asking how your application will know if a user is paid or not so you can give them access to a specific service or specific page. Generally I put a enumerated column called "account_type" in the users table with the options: "free", "standard", "pro", or something like that. Then the application can just check the session data to determining which user is currently logged in, and if they are a paid user or not. This way you minimize the number of api/db calls.