It really depends on what data you need to store do your app. Stripe is just an aide to taking money. Generally, when you make a payment with Stripe, you will get a unique ID for each customer. This helps for repeat billing etc.

You might want to consider an orders table, or an invoices table. All that relate to a user. We would need more idea about your app in order to help with the DB structure.

In general, a user may have many orders, so keep any order data out of users. You can just store the stripe ID on the user. Orders would have users id.

Hi! Ty.

I have one main table where user inputs email, password and customer type. After that they get email with a registration link to complete registration. I have three types of users and three types of tables for each type of user. So when they get a registration link they insert data in one of the tables (depending on the type of user). Login is via main table with email and password. Payment should be immediately when entering data in the first table (before sending an email with your registration link). Users can choose between monthly or annual subscription. Ty for help.

I have some experience with Stripe (which I love) and I concur with T2theC in his recommendation that your users table(s) store the Stripe customer_id.

From your description, it sounds like you have a "master" user table which stores email, password and customer type. The rest of each user's data is stored in one of the other three "user type" tables. If the user type tables simply contain metadata, the the master user table should contain the Stripe customer_id column, in my opinion.

Then, you can always retrieve the data you need from Stripe as the user interacts with your app.

Can you tell me how to input customer_id into "master" table?