#Davste
obtuse star
leaden finch
client_reference_id - This field is used so that we can associated an internal user to a stripe customer, so that we can figure out.... who paid lol
I am sending the
client_reference_id: userId,
when creating a checkout session
I do get it back on checkout.session.completed, but not on charge.succeeded
My goals are:
- to figure out which user who paid at the end of a succesful checkout,
- how many days are in their subscription
- how much they paid
for both recurring subscriptions and also new customers
mental patrol
Yeah really recommend you use stripe customer id. That would get propagated to the charge object
Client reference id cannot
leaden finch
the callbacks are milliseconds within each other. This is risking a race condition
mental patrol
How? You would create the customer in stripe prior to even creating the checkout session. You would then pass that to the checkout session creation request and it would be attached to all associated objects (like charge)
leaden finch
I see.
So you recommend I create the customer in Stripe before creating the checkout session (ex; signup)? I think I read in the docs that user is auto-created on a new checkout session
Seems kinda wasteful tbh, as a lot of users would never end up making a checkout session, ever?
mental patrol
There's no harm really. If your concern is just cluttering the dashboard with unused customer objects, then that's fair i guess
There's also this param: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer_creation
Which you can set to always
leaden finch
Could you kindly glance over this to see if it sounds right then:
- On signup -> Create stripe customer, update our internal customer with your stripe customer ID
- On 'charge.succeeded' || ' 'invoice.payment_succeed' -> (For recurring subscriptions ) -> Extend user's internal subscription by N days
- 'payment_intent.payment_failed' -> Handle failures
mental patrol
Yeah that seems right