#notdpr-charge-email
proud mango
harsh minnow
notdpr-charge-email
@mossy escarp the receipt_email property on the Charge reflects the email address where an email receipt was sent if any if you forced it as a parameter in the API. The billing_details[email] corresponds to the email address collected with their payment method details if any.
So it's less about the fallback and more about understanding your own integration, what you do/set/use and then reading back that part
mossy escarp
In this case, it's a stripe-user outside our company... they're using Stripe Checkout, and oauth-ing stripe with our app... so we can get their webhooks and record purchase info in our platform... so how they do their charges/checkout/subscription isn't under our control as far as I know...
so it seems reasonable to be able to handle the email address coming in no matter how
harsh minnow
Sure but in that case, if they use Checkout you should listen for checkout.session.completed instead and read https://stripe.com/docs/api/checkout/sessions/object#checkout_session_object-customer_details-email instead
mossy escarp
ok, for the Checkout case, given that we'll see both events (charge.succeeded and checkout.session.completed), is there a way to tell in the charge.completed event that it's for a Checkout and thus ignore it (so we don't duplicate things). I know they'll share the payment intent ID, but that isn't enough to know we should ignore the charge.succeeded on its own.
harsh minnow
No there isn't, there's no link to "what created it" unless you track both.
Ultimately, if all your customers are doing Subscriptions and what you want is their customer's email you should look at the associated email property on Customer
Unfortunately there are many ways to integrate our products and it depends a lot how people do things
mossy escarp
Understood. In this case the event data customer is null... I'm not as familiar with Checkout as regular Stripe billing (where we always have customer)... is it "normal" for Checkout customer to be null?
btw, We have both single charges and subscriptions coming in
harsh minnow
Checkout won't create a Customer by default for one-time payments so yes it's expected
It seems that in your case, if you don't control the integration of your connected accounts you do kind of have to have multiple fallbacks in place depending on what they do
mossy escarp
Agreed. Thank you so much, it's been a big help!
harsh minnow
Of course! Any other questions I can answer? The server is quiet for once (hopefully I don't jinx myself) so happy to look into other things if it can be helpful!
mossy escarp
I think that's it. Enjoy the silence 🤞