#cerebro_code
fathom jettyBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1433439235733717113
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- cerebro_code, 1 hour ago, 79 messages
brisk knot
hi there, taking a look at this now
opal carbon
for each result I still need to make sub calls again to the API to fetch more info... seems like an impossible task for something that should be so trivial
I already hate Stripe's API... but you guys rock! Thanks!
brisk knot
so one potential idea would be to listen for checkout.session.completed events and get the time and products from the associated event data https://docs.stripe.com/payments/checkout/pricing-table#handle-fulfillment-with-the-stripe-api
you could then keep track of which were associated with particular customers on your backend. would save you some API calls
opal carbon
the documentation says that completed is not the same as paid
I quote: "complete The checkout session is complete. Payment processing may still be in progress"
brisk knot
that's true, for async payment methods like ach debit there's the checkout.session.async_payment_succeeded event https://docs.stripe.com/api/events/types?api-version=2025-10-29.preview&rds=1#event_types-checkout.session.async_payment_succeeded
opal carbon
the problem with webhooks is that I need to store all this information in my DB
since it's not only once that I need to fetch this information
this is everytime the user logs-in
brisk knot
gotcha. let me think a bit about an alternative that doesn't involve storing...
I see you already tried using the Search API with Payment Intents. have you tried it for Invoices? https://docs.stripe.com/search#query-fields-for-invoices
opal carbon
yes but sometimes not sure why... invoices are not generated
brisk knot
you could filter the results based on billing_reason of subscription_create to get the first invoice of each subscription https://docs.stripe.com/api/invoices/object?api-version=2025-10-29.preview&rds=1#invoice_object-billing_reason
that's interesting, do you have an example Subscription that didn't generate an Invoice?
opal carbon
ok so that's the issue, users can buy other things than subscriptions
one-off payments
before I had guest users too... now I'm making sure the session is always linked to an already existing customer (in Stripe)
brisk knot
hmm ok, then Payment Intent would be common denominator among those... I don't think there's any one-stop shop API endpoint that will meet your needs. if this is something that is dynamically kicked off by your customers, I think it'll be most efficient to track webhook events and store this on your backend, using customer as the key
opal carbon
ok thanks!
one last question, in the redirection url, is there a way to tell Stripe to add the connected account ID and the session ID? apparently, I need these values to retrieve information about the session
brisk knot
you can add the checkout session ID as a variable to the redirect url https://docs.stripe.com/payments/checkout/pricing-table#post-purchase-experience
what type of charges are you using for the connected account? Direct / Destination?
brisk knot
... interesting. so just removing {CHECKOUT_SESSION_ID} made that error go away?
opal carbon
....session_id={CHECKOUT_SESSION_ID} doesn't work
....session_id="{CHECKOUT_SESSION_ID}" works
back to the initial problem of this thread, do you know what happens if a webhook request fails (suppose our server was down)? is is retried later?
because if Stripe doesn't retry... then I still need to figure out all these API calls to get the information I need
brisk knot
yes, they are retried automatically. the behavior is described here https://docs.stripe.com/webhooks#behaviors