Stripe implementation: Create customer object for all new users, or only subscribers?
When a new user signs up, you can create their associated stripe customer ID or wait until they start a trial.
What do you do and why?
In the past, I have tried both. When I created a stripe customer ID with every new user, it seemed like it made the stripe dashboard messy.
There were events for people who had not started a trial or subscribed to the SaaS. I found this was confusing and made it less obvious who had payment info saved and was closer to or previously had a subscription.
So I changed my last SaaS to only create customers if they started a trial. Even if they cancel, they keep their customer ID. But every single new user did not automatically get a Stripe ID.
Today, it definitely seems like Stripe wants you to create as many customers as possible. Which makes sense given the way the stripe customer portal is trying to share authentication across all sites that use it.
But I don't see how creating a customer up front benefits anyone but Stripe in their data collection and metrics toward whatever liquidity event they see in the future.
Curious about your thoughts on this.
I do remember reading that Stripe recommends you to create a stripe customer id for all customers who are logged in, that means, freemium,, trial & ofcourse paid. You wouldn't need to create stripe ids for anonymous customers, now that wouldn't make sense.
All the other ways, freemium , trial do have the potential of one day attaching their credit card, and it's easier now since you already have their stripe id, one less api call to make.
I agree the dashboard can get messy with all those free users, but thats why you have services like paywell, chartmogul, baremetrics etc, that sift through the data. Im sure you can also filter it in Stripe dashboard too by subscriptions. As for stripe and the data they own, well thats another story.
Stripe & YC are the google of SaaS, nothing we can do about it now.
I agree it doesn't make sense to make Stripe IDs for anon users. But I'm not sure I buy the one less API call to make being a selling point.
One reason is once the
cus_xyz123is made, I would want to store and manage that data or have to look it up based on some potentially out of date email address.There are some privacy tradeoffs. It isn't really Stripe's business to know how many unconverted users I have, or have the email addresses of these folks.
One argument against putting them all in is that if I have only a portion of my users in Stripe, I'm not going to start relying on that service to store other mission critical data about users in general. I suspect Stripe wants you to put user data in. You'll never leave!
As for those other systems, they shouldn't be needed to make sense of stripe's customer dashboard. Stripe should offer those visualizations.
I have used those other systems, paywell, etc. for due diligence to sell a SaaS. But just like Stripe every time you spill massive volumes of user data into these systems they can leverage it in ways that benefit them.
I agree that Stripe is sort of acting like Google in its hunger for data and attempt to get at the center of user keys or even user accounts overall. It is as though the company is angling to be the federated login of payments to cards. Except I don't really want that.
I pay stripe a commission on payment fees, that should be enough. What I sense is that the company is putting in hooks to make it harder to select another payment provider.
Agree 100%.
Had I thought about this at great lengths, I may have decided to to only store my paid customers/trial on stripes platform, instead I was focussing my efforts on GTM and marketing.
In my case all my customers will be trial customers, and if they dont convert , do I delete their data from stripe? what happens if they reactivate, or sign up later on?
Lots of things to think about; who remains the single source of truth, stripe or your own database. You could use your database as a source of truth, but it doesn't have updated Realtime subscriber data, your webhooks may fail, your db may fail to log..
I've spend many hours talking to the extremely nice people on Stripe through their online chat, what I found is that depending on who you talk to they all have varying opinions as to how you should store your data. The great thing is that you make that decision. I choose the happy path which is store all customer data with them which is email address, first name, last name, stripe id, and my internal user id, all other particulars are stored by our saas database.
Right or wrong who knows, but great discussion.
Just was facing this issue as well. Initially only on-demand data was sent to Stripe, users who have started a trail. Now due to code logic change I need to create customer just before he starts a trial. This skews the data since people may accidentally visit the billing page without huge intentions to start a trial / buy.
Will try switching to model where a customer is created on signup. Stripe has great dashboard and having all data means I can trust the numbers.
I only create a stripe customer once someone goes to the payment portal (freemium model). If someone registered and quit the app after 2 days, I don't think I really want data for them inside of the Stripe dashboard.
This is a question I've wondered about too. Personally, I create a Stripe customer for every verified account. I find this makes billing logic less error-prone going forward.
For me personally, I don't even create a specific customer data in Stripe.
My paying customers signup for a subscription and the only thing a send to Stripe is their email, which I prefill in the Checkout page with my own data from my internal database.
(and that is for Stripe to automatically send them invoices and reminders)
All my customer data is managed by me and stored in my database, which is the single source of truth.
I only need Stripe to charge the subscriptions payments and that is for what I use them.
I'm not sure it's the best way, but I create Stripe customers for all signed-up people who visited the billing page. That way, they expressed some (at least minimal) intent to convert to paying.