#gecko-session-questions
polar tendon
ok, thx for answering 🙂
first...if I understand correctly, when I create a session, and await it....when the return comes back and I get a session object, it will include the successful/unsuccessful transaction result. yes?
drowsy palm
I recommend reading https://stripe.com/docs/payments/checkout/fulfill-orders which covers this in more details. But overall your code should look at the Session after redirect and check its status/payment_status
polar tendon
so there are cases where payment concludes "immediately" and the return of the session will result in payment-status...and other cases where it is not resolved, and a hook for later catching is needed.
my point is, that I create the session, it has success/cancel redirects, and then I isue a result.redirect
drowsy palm
it depends on the payment method types you access
polar tendon
i'm focused on an "immediate" payment for this discussion
ignore the deferred /webhook scenarios
so after the redirect(303, url), then I can inspect the session?
drowsy palm
yes
drowsy palm
not it's not a promise, it's a full page redirect and the person could stay hours on the page before paying
it's just a normal web redirect to your success_url
and then there, you should already know who is the customer (using cookies and such) and you can check the state of their session
polar tendon
right, so the session itself that's created in page 1, and redirects to page 2 for success and page 3 for cancel....the inspection of the result, isn't in the page 1, but it's a page 2/3 where I could do this....
or I can skip this inspection entirely in page 2/3, and just have webhook method to look for checkout.completion events?
drowsy palm
you can do both options, they are all detailed on the doc I linked. Which one to use depends on your overall integration/goals
polar tendon
so I scanned through that page, and it goes over the webhooks
as I understand it, the deferred payments problem can only be solved with listening for webhook events
but the 'immediate' payments could be handled in the redirect page...
so I'm trying to understand the benefits of doing both cases...why not just webhook only? is there a delay or something else? I'm trying to figure out what's the right fulfillment method, so sorry for the dumb questions.
drowsy palm
https://stripe.com/docs/payments/checkout/custom-success-page also covers the success page
webhook handling means it's all async. Most business want a "success page" after a succesful payment
polar tendon
what does "integration goals" mean?
drowsy palm
hmmm it means what do you want to do? Like that's a business decision
polar tendon
webhook handling means it's all async. Most business want a "success page" after...
this last link is answering a bunch....thx
drowsy palm
yeah sorry I think we split the docs and it's a bit less clear now
polar tendon
if I understand corectly, I can do most things with the success page, and that's great. the webhook catches all delayed payments, right?
drowsy palm
it used to offer multiple "fulfillment options" before
Mostly, webhooks are important for cases where the customer never hits the success page (for example they close the tab too fast)
so you always want webhook to ensure you don't miss any transaction
But overall if it were me I'd handle the redirect, look at the session and if it succeeded say "hey it's succeeded". And if you build Netflix, you just give video access now for example
polar tendon
but I'll need to deal with transaction ID's so that I don't have duplications, since the webhook will send all payments, right?
drowsy palm
yes
polar tendon
ok thx much
drowsy palm
sure!
polar tendon
const session = await stripe.checkout.sessions.create({
success_url: "http://yoursite.com/order/success",
success_url: "http://yoursite.com/order/success?session_id={CHECKOUT_SESSION_ID}",```is there any issues with having something on the success redirect, besides this session ID? (other params)
drowsy palm
no that works but know that people can change it and pretend to be someone else
polar tendon
the doc says to do this exactly (I'm assuming it's talking about only this param syntax)
the man/middle you're talking about?
the authentication can come from inside the redirect side, where the verification it's coming from stripe can be done...yes?
or this is a comment more about my other params and their vulnerability?
drowsy palm
the latter
if you add xxxxx&customer_id=ABCD then I can replace this myself before the redirect to pretend to be someone else
polar tendon
so I've got that stuff in metadata, and shouldn't need to put it on the URL
i'll pull it in the redirect after fetching session-id based object and authenticating it's coming from stripe. do I have the idea right?