Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

mcprogramming's avatar

Stripe and User table order of attributes

I think it wouldnt matter but just to be safe, I am making a user table that will have quite a few columns that I need to add (i may end up refactoring to another table if possible later, not the stripe columns obviously) and I will be bringing in Stripe which will add 7 more columns to users table as you know. I want to build up the site first and once satisfied,then bring in stripe. At that point the users table will be (hopefully manageably) dense. So is their any advantage, or more importantly, disadvantage to adding stripe towards end of project and its columns to users table as the last few attributes? My intuition says no but I want some perspective from some more professional developers than me. Thanks!

0 likes
7 replies
MikeHopley's avatar

I will be bringing in Stripe which will add 7 more columns to users table as you know.

Does it really? What columns?

I'm using Stripe for subscriptions. Here are all the columns in my user table:

  • id
  • email
  • password
  • remember_token
  • created_at
  • updated_at
mcprogramming's avatar

Yea it adds the columns to your users table. Did you make a custom table?

MikeHopley's avatar

"Custom table"? As opposed to what? It's my users table.

Are you using Cashier? You know that Cashier !== Stripe, right?

Anyway, you can do it however you want -- but you are not required to add any extra columns to your user table. I would recommend keeping your database fairly normalised, rather than just making a massive user table.

mcprogramming's avatar

By custom table I meant do you have a different table specifically for stripe, im assuming that uses the user_id as a foreign key. Every documentation Ive come across shows the stripe columns being added to users table and yes i want to keep my users table normalised. I just was looking for some suggestions. Ill see if having a different table with the stripe related columns works better for me.

jekinney's avatar

If you utilize the auth() facade I would strongly suggest keeping the user table lean and mean with just the required columns needed for basic user stuff. Otherwise your retrieving the whole row and data every time you call auth()->user(). Also no pre planning docs? That helps create your schema for you and keeps you focused on the tasks and features

MikeHopley's avatar

By custom table I meant do you have a different table specifically for stripe, im assuming that uses the user_id as a foreign key.

Okay, now I understand. No, I don't have a table for Stripe. Stripe is a just a service that I use; it has no place in my core business logic.

I do have tables for payments and subscriptions. These are business objects. I also have tables like vendor (which contains vendor names, e.g. 'Stripe'), vendor_subscriptions (which contains the subscription reference from Stripe, or another payment provider), and so on.

In my previous (nasty!) schema, I had tables like paypal_subscription_info, which contained a column for every damn item of data Paypal sent me. That wasn't very smart. I learned the hard way.

Every documentation Ive come across shows the stripe columns being added to users table

Okay. This isn't what I've seen. It's up to you.

Please or to participate in this conversation.