#mike_docs
lunar spireBOT
👋 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/1224698412642078721
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
restive urchinBOT
acoustic remnant
I know. That is not my problem. My question is how to avoid situation when somebody would click on "pay" button in our app (we create checkout session) and during the payment process somebody else do the same. We have workspaces where authorized users can pay the same order but we obviously don't want the same order to be paid twice
I've been thinking of saving the checkout_session_id to the order and "redirect" the paying user to the same session - the first successful payer wins
boreal tulip
acoustic remnant
I don't understand how this would solve my problem. please explain it with more details. we don't want to delay the capture - we want to capture the billingCode (uid stored in metadata) only once.
boreal tulip
this is about a limited stock right?
acoustic remnant
nope - the platform is for digital products only
boreal tulip
I'm not sure I understand the use case then
how would 2 people be paying for the same thing then?
acoustic remnant
the use case is - somebody creates the order in a workspace where multiple users can pay it. We want to allow to pay it only once. Two managers can (theoretically) list the order, click to pay it, stripe checkout form will open and both do the same simultaneously
I know it's an edge case but we must avoid it
boreal tulip
that's why manual capture can help
basically you would start by authorizing the Payment Method
but when you get the checkout.sessions.completed event you would check whether the order was paid or not before capturing
so when the first checkout session is completed the first event is fired and you check that the order is still not paid, so you capture the amount
and you update your db
when the second checkout session is completed the order is paid and you wouldn't have to capture the second time
acoustic remnant
it adds another layer of complexity which is not necessary IMHO. I try to rephrase the question: if the only payer open the checkout session (we create it via API first of course) and close it (in the browser) can he return to the existing session with the UI?
so continue with the previously created session?
if yes we can redirect any attempts to pay to the same session and the first payer will win. does it make any sense?
dark pine
Hi there 👋 I'm jumping in as my teammate needed to step away. Please bear with me a moment while I catch up here.
Yeah, you should be able to reuse an existing session as long as it isn't complete. Are you running into errors or odd behaviors in your testing when you try to do so?
acoustic remnant
no, we don't - I am just not sure how to do it. We I create the session I am redirected to the form automatically, right? How can I do this with existing one? I am backend (not frontend) developer so maybe I am missing something. If this is strictly managed by FE - I can ask my FE colleagues to manage it however I supposed it can be launch by the backend as when creating new session.
any link to docs explaining this scenario would be useful
dark pine
It's hard for me to give advice on how to do that redirect without understanding how you're handling it currently. It won't be automatic as it's a backend request that creates the Session and provides you with the URL, then somehow your flow returns that to your frontend to be used.
The general idea there is that you'd either recall the URL you already generated and saved somewhere for the Session or retrieve the Session again to get its URL, and then return that to your frontend to be used.
This the endpoint and functions used for retrieving a session if you need those:
https://docs.stripe.com/api/checkout/sessions/retrieve
acoustic remnant
you're right - I am checking the code and we do redirect to the url ourselves. so it should be ok. give me second I'll share the idea in diagram to explain the flow
Please check the flow. Does it make sense?
https://shorturl.at/zGJPV
dark pine
Loaded on the second try. That seems reasonable, is it behaving the way you're hoping in your testing?
acoustic remnant
not finished yet - I am working on the issue for development and wanted to be sure we're on the supported flow. I fixed minor error on the flow:
https://shorturl.at/kHJ04
after more than 2 years with stripe integration development and I still don't understand why we cannot create payment_intent before creating the checkout_session and assign the pi to the cs... 🤷♂️ it would make life so much easier.
dark pine
If you'd like to leave more context on how you envision that working, I can share that feedback with our teams. What you're describing is the way our Payment Element integration worked primarily (create a Payment Intent, then use that to render a UI to collect payment), before we released a deferred intents flow for that because the incomplete Payment Intents would litter the dashboard views.
acoustic remnant
well, generally we have orders and payments as almost everybody 😅. Once the customer creates the order we would like to create the payment_intent and save its id to the order. next any authorized user can pay the order, we would create the checkout_session with the payment_intent binding. Once the session is confirmed no other session can pay the same payment_intent. Accessing the same checkout_session is (as described before) is also possible however it has more limitations as we need to switch between on_session and off_session checkouts based on new and existing payment_methods. To our understanding by using reverse engineering of english language 🙂 payment_intent is what I want to pay (the order) which is always known before we start the payment session. based on legal processes I am obliged to pay the order right after it is placed. Next I can choose how to pay it - let's say we have only card options: new card = onsite checkout session or existing card = off-session. Both linked to the same payment_intent. Once the pi is fully paid remaining session have cannot be used anymore and they will expire automatically after predefined period.
checkout_session produces charges which we save as payments in our app
acoustic remnant
After some thinking the scenario I described before has one weak point - I can create (and save) checkout_session_id to the Order but if the user decides to pay the very same Order with existing card I have to create new checkout_session (off-site, confirmed) and the previous checkout_session can still be confirmed - so there will be two payments for the same payment_intent 😱 can you suggest how to fix it?
dark pine
Checkout Sessions don't really work for off-session payments, as they're designed to be used by the customer and are therefore by nature on-session. So I'm not too sure I understand what you're trying to accomplish.
Do you want to explore using our Payment Element on our own page, instead of using our Checkout Sessions, so you can create an Intent upfront the way you want?
If it's just the lingering Checkout Session that's the concern, we have an endpoint that lets you forcibly expire those:
https://docs.stripe.com/api/checkout/sessions/expire
acoustic remnant
I am aware of expire endpoint. Well, my issue is how we designed the flow in the past (suggested by stripe staff btw). We have on-site checkout_session (with human interface) and payment_intent (off-session, confirmed) for payments with existing cards. Everything is driven by API - you can choose from the list of existing cards saved in your profile or use new card request (we use fingerprints not to create card duplicities of course). Once two users choose to pay - let's say first one with with new card (opens the form) meanwhile the second one pay with existing card. We receive webhook and close the order. Meanwhile the new card payer continues with the checkout session and confirm it. We receive the webhook of the payment but the order has been already closed. That is why we would like to have the payment_intent (order) created first and then start the attempts to pay it...
dark pine
Yup, that's understandable. Having a flow where multiple people can pay for the same thing sounds like a flow that would be prone to race-condition concerns.
In the scenario you described, if you expire the Checkout Session while the customer entering new payment method details is in the form filling it out, does that block them from completing the payment?
acoustic remnant
yes, it does; however, there are still time edges between confirming the session and expiring it after successfully confirming the payment_intent. also two concurrent payment_intents (user1+card1 and user2+card2) can be done together. I am rethinking it from one direction and vice-versa, and I simply don't see a bulletproof secure solution. The only reasonable solution (from my point of view) is to create payment intent and pay it afterwards, so once the pi is fully paid, it cannot be paid again. You mentioned Payment Elements (though it is an embedded checkout session on our frontend pages? 🤷♂️). I am not a front-end developer, but I don't see how this would solve the concurrency payment issue... I am desperate (and thus very motivated) to find the right solution... 🙏
dark pine
Nope, not an embedded Checkout Session, those create the intents up front as you've pointed out.
This is an example flow that uses the Payment Element:
https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=elements
The reason I brought it up, is because I'm pretty sure it would let you use a single intent per order as you're describing.
You can create a Payment Intent:
- and use it with the Payment Element if you need to collect new payment method details
- or use it to process an off-session payment using an existing Payment Method by specifying
off_session: truewhen making the confirmation call. - using a single intent should block the other flow once one flow completes the payment, though you may need to catch the related error messages and surface a message that is more relevant to your situation to your customers.
acoustic remnant
maybe that's what we MUST do. let us to analyse it first
dark pine
I'll be needing to close this thread soon if there aren't any more questions right now, but wanted to check if anything else had come up while you were reviewing those docs before closing it?
acoustic remnant
feel free to close it and I'll create new thread once know the elements better and potentially meet some issue. hopefully not 🙏
dark pine
Sounds good! Best of luck with your project, hope you have a great day 👋