Suggested database architecture for my first SaaS with Stripe?

Hi, if you're still interested in this, here is how we are handling the Stripe data at NLP Cloud: https://juliensalinas.com/en/storing-stripe-payment-data-database/
Basically, we store everything in local DB as a PostgreSQL JSONB field as soon as we make a request or receive a webhook.

Doing this you have the best of both worlds:

• Speed (since you are reading local data instead of remote data)
• Ease of development (you don't have to think to much about which Stripe data you are going to save)
• You're safe in case of disaster on the Stripe side
• You data is always up to date

Hope it helps

Just stumbled onto this thread as I am at the same decision point wiht my product.

I think I'm going to start off with just storing the Stripe customer ID on the user, with a subscription object that holds the subscription ID, status, expiry date.

I'll extend the expiry each time I get a successful payment event from Stripe.

Not sure if anyone will see this, but thoughts?

Hello! What did you end up doing? Do you have any feedback on your choice? I'm currently reflecting on this exact subject regarding our SaaS and cannot wrap my head around the best option between:

• Dedicated table to keep track of subscriptions (at first, feels a bit like double accounting)
• Hitting Stripe API for any billing related info (at first, feels slow/resource intensive)
  Any feedback could probably help. Thanks in advance :)

I wouldn't recommend hitting Stripe's API to fetch billing information as-needed. For example, if you wanted to check if the current user has a subscription, that will add latency if you hit Stripe's API every time you needed to know that. It's very simple to keep local billing data in sync with Stripe's system using webhooks, e.g. customer.updated, customer.source.created, customer.subscription.created, etc.

I have a billing table that looks something like this:

billings {
  string customer_id
  string subscription_id
  string subscription_status
  datetime subscription_period_start
  datetime subscription_period_end
  datetime card_expiry
  string card_brand
  string card_last4
  datetime created_at
  datetime updated_at
}

That's all the information I've ever needed to know.

For our billing pages, we just pull in the history from Stripe. If you can get away with it, a single source of truth is best.

~25,000 Stripe users later and I don't regret it. We've had to create a FakeCharge and a ShopifyCharge in our main DB (Postgres) to fudge it a little for alternate billing. Hopefully you never need to do that. When getting user.charges (Rails ActiveRecord syntax here), it just grabs data from those two tables plus Stripe then sorts them all by date.

When creating charges/users in Stripe, I suggest storing some metadata like User id so you can figure out what happened if a user is deleted/updated.