#mike_error
regal groveBOT
👋 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/1377203260003323977
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
karmic glacier
yes
slow lintel
if that's the case here's the doc that explains how you should proceed https://docs.stripe.com/connect/direct-charges-multiple-accounts#clone-payment-method
karmic glacier
well, brief review of the doc speaking of "cloning the payment" but this is not our case. each connected account act as vendor (receiving payment throught our platform) but also as a customer (created in our stripe account). Each customer should have its own pm so we don't clone anything. I understand the error that on stripe we created the pm X and assigned it to cust A but in our app (database) we (somehow 🤷♂️) assigned X to cust B due to restart the browser and some background process has not been killed successfully? Does it make sense?
slow lintel
no not really
but I think what you need to look into is accounts v2 https://docs.stripe.com/connect/accounts-v2/api
where the account can act as a customer and a connected account at the same time
karmic glacier
Well, I've spent with Stripe 3 years already and I believe I know fundamentals (so I'm not rookie but advanced stripe integrator). We have done comprehensive integration with Stripe already. I only experienced edge-case error and want to understand possible sources of it. Let's leave the connected-accounts for now as maybe it's not the problem.
Let's start over - we have b2b platform. each account in the platform is a stripe customer by design (created in our stripe account) so they can buy and pay (each of them have pm created and saved in our system). I was testing creation of multiple customers and each would buy same product on the platform. I've used the same 4242...4242 card to create new payment_method. with the 4th customer purchase the form with Stripe Payment Element stuck as well as the whole browser. I had to close the window, reopen it and tried to finish the purchase with the same card and got the error.
slow lintel
Well, I've spent with Stripe 3 years already and I believe I know fundamentals (so I'm not rookie but advanced stripe integrator).
I didn't imply anything of that sort
slow lintel
Let's start over - we have b2b platform. each account in the platform is a stripe customer by design (created in our stripe account) so they can buy and pay (each of them have pm created and saved in our system).
I was just giving you a rundown of a new feature that we have that could help you move from that model to a newer and more sustainable one
I only experienced edge-case error and want to understand possible sources of it.
sure let's do that
karmic glacier
that sounds good and i will definitely read all the articles
slow lintel
would you mind sharing the request ID that failed?
karmic glacier
that is the problem - I did not log the requests at that time as I did not expect any issue of this sort. later I was unsucessfull with reproducing the issue
I only have the pm and cus ids
btw - I am solution architect and backend lead. I am not involved in FE implementation and this is (partially) linked to FE due to Payment Element used IMHO
slow lintel
yes but you can look the request ID up in your dashboard's logs
karmic glacier
I asked my FE colleague to watch this conversation and in case of front-end related question he'll answer that instead
regal groveBOT
karmic glacier
yes but you can look the request ID up in your dashboard's logs
req_gELvkVKPxRqEXe
btw - the filter works on cus id but not on pm id... 🤔
slow lintel
in this request the customer is cus_SOBk5G0LU0hWSX
which makes the PM attached to that customer
instead of the customer you shared
karmic glacier
yeah, I've found it as well. I understand WHAT happened but still trying to figure out WHY and HOW to avoid it next time
maybe our FE somehow "remembers" previous pm id due to Stripe Payment Element unresponsiveness and re-use it for another customer... 🤔
sonic anchor
Hi, taking over as my teammate needs to step away.
On that request my teammate shared, https://dashboard.stripe.com/test/logs/req_xc4fjnvAGaVcCB you passed rhe customer ID from your backend code.
That is coming from your code
If that is not intended, you need to debug your code to ensure that you're passing the 'correct' customer id
karmic glacier
do you "see" at your end any irregularities with the elements? I mean can you (or us) somehow figure out what happened with the element form? it's a kind of black-box for us. right @sand falcon ?
sonic anchor
That code is coming from your backend code when you create the PaymentIntent
I do not know what 'irregularities with the elements' means here.
You should start logging these objects and audit your code
sand falcon
Hey, I'm the FE developer mentioned.
Just to provide more context to what "probably" happened on the Stripe Payment Elements side. I can only guess since I wasn't there at the time of the error and we can't seem to replicate it.
The first problem with frozen browser started after the submit on the form inside which the Payment Elemented was mounted. The only thing happening there that could potentially froze the browser is a confirmPayment method that we call on a loaded Stripe object instance.
Since the window was closed and reopen afterwards and the purchase was reestablished with a new customer, the custmer id (client secret) changed as well since we take it dirrectly from the order made before that. But for some reason, my guess is that even thought new payment was being made with a new customer, the pm from the previous failed attempt was somehow preserved and mismatch happened.
karmic glacier
You should start logging these objects and audit your code
be assured that if the problem is on the backend side we will find it and fix it
the most problematic moment here is the impossibility to reproduce it
sonic anchor
Why would you do 'we take it dirrectly from the order made before that' this?
You control what client_secret you pass on your code. When you create the PaymentIntent on your end, you need to pass the customer you want to charge: https://dashboard.stripe.com/test/logs/req_xc4fjnvAGaVcCB. Your code determined what that customer id is.
What does your checkout flow look like currently?
karmic glacier
I have to leave now. @sand falcon would take over
sand falcon
Checkout flow is roughly like this (we use Vue 3):
- Create an internal order (to our db)
- Select appropriate payment method and confirm
- After this confirm we create the payment intent for the appropriate customer (my coleague can speak more in detail to this since its happening on the backend side)
- Save the clientSecret from payment intent in url query in case a of missing card, move to a embeded Stripe Payment Element
- There we loadStripe with a public key, create the element instance with the client secret and mount it.
elements.value = stripe.value!.elements({ { theme: 'stripe', clientSecret }); const paymentElement = elements.value!.create( 'payment', { layout: 'tabs' }, ); paymentElement.mount('#payment-element'); - Then we check status of payment intent by retrieving it with provided client secret, incase a mistake was made somewhere:
const { paymentIntent } = await stripe.value!.retrievePaymentIntent( clientSecret, ); switch (paymentIntent.status) { ...do something } - After the form is filled and confirmed, we build a return url and run confirmPayment where we pass the elements from Stripe object instance and the return url. (in case of an error, display message)
const { error } = await stripe.value!.confirmPayment({ elements: elements.value!, confirmParams: { return_url, }, });
sonic anchor
What does step 2 mean exactly?
sand falcon
That's just a part of our app where customer selects if they actually want to pay by card using stripe or manage their transactions themselves with bank transfers and such. Not relevant to this discussion really. The only time the rest happens is if they choose to pay via Stripe and don't select (or don't have) an existing card.
sonic anchor
In that case, at step 3 is where things are not behaving as expected and you're passing the wrong customer id here
sand falcon
It's definitely possible. We'll look into it.
Just to make sure, there is no possibility that the payment method was somehow preserved for two different transactions if the embeded components crashed? I'm not that well oriented in the inner workings of payment methods so excuse me if that sounds weird.
sonic anchor
I can't confirm this without being able to reproduce this. From the information we have thus far, it looks like your code is passing the customer id on the backend and that is why you get the error as the payment method belongs to another customer
It would not have any relation to the front end at this time
sand falcon
I'm looking into the creation of payment intent and reading the documentation on a param setup_future_usage that's set to 'off_session'. It says "Indicates that you intend to make future payments with this PaymentIntent's payment method.". But it says it attaches the method to customer so if we send the wrong customer id, it would not be there if I'm not mistaken.
karmic glacier
I can't confirm this without being able to reproduce this. From the information ...
Just to add a bit of context: we have run thousands of testing runs without this error. This is for the first time and it was when the form stuck. Of course it does not mean the problem could not be on our side.
sonic anchor
What does 'But it says it attaches the method to customer so if we send the wrong customer id, it would not be there if I'm not mistaken.' mean exactly? Can you reword this please?
sand falcon
Just reading the docs for that param.
"Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes."
If the two checkout sessions in question have two different customer ids, the payment method saved on PaymentIntent's Customer would have to be different or not there at all.
slow lintel
taking over for my colleague as they need to step away. Let me catch up on what I've missed from the conversation.
it seems that the issue in your flow is that you don't assign a customer to a user but rather create a new customer each time
I suggest mapping each of your users to a Stripe customer object
and using that ID create any PI for that user
slow lintel
If the two checkout sessions in question have two different customer ids, the pa...
I'm not sure what do you mean by that
a PM can only be attached to one customer
it's a 1 to many/1 to [0-1] relationship between customers and PMs
sand falcon
I suggest mapping each of your users to a Stripe customer object
I think we are already doing that but my colleague has to confirm that @kind gust
slow lintel
in that case how did you get the PM ID?
sand falcon
it's a 1 to many/1 to [0-1] relationship between customers and PMs
I understand. I probably misunderstood how that works.
slow lintel
it's a 1 to many/1 to [0-1] relationship between customers and PMs
meaning that a customer can have multiple PMs but a PM can only be attached to at most 1 customer
sand falcon
Yes. That's why we get the error in question.
colleague who implemented most of the stripe integration with payment intent and method is looking into it and and will respond asap
Okey, we might have found the problem. In this version, we are creating a new stripe customer for each checkout session, even thought the implementation is mostly ready for stripe_customer per workspace.
Thank you for pointing out the possible issue
slow lintel
sure thing