#kevin_reactnative-meta
dense boltBOT
👋 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/1401939189682933852
📝 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.
- kevin_code, 5 hours ago, 11 messages
- kevin_code, 4 days ago, 25 messages
- kevin_code, 4 days ago, 28 messages
solemn forge
👋 happy to help
hmmm good question, I'm not sure you can, I'd have to check for you to be honest
I'm suspecting something in relation to https://docs.stripe.com/api/payment_methods/object#payment_method_object-customer
but what are you trying to actually achieve?
ebon haven
Currently, when we book on the product I work with:
- If we pay with an existing credit card, we create the booking for the customer with the existing credit card via back-end directly without validating anything on Stripe
- If we pay via payment intent or setup intent, we validate it via Stripe before creating the booking
I want to migrate from CardElement to PaymentElement and wants to have the same behaviour 🙂
solemn forge
via back-end directly without validating anything on Stripe
what do you mean by that?
off_session: true
like an MIT transaction
ebon haven
What we do is that we pass the selected payment method ID to the back-end if we pay with an existing credit card without doing stripe.confirmCardSetup or stripe.createPaymentMethod
What do you mean by off_session: true ?
solemn forge
What we do is that we pass the selected payment method ID to the back-end if we ...
Ok I see what you mean
solemn forge
What do you mean by `off_session: true` ?
ebon haven
But on front-end side, how can I know that the selected payment method is an existing one?
For example in React Native, we have this payment method result: https://stripe.dev/stripe-react-native/api-reference/interfaces/PaymentMethod.Result.html from confirmHandler but we do not have something like offSession or something like this 🤔
solemn forge
you have the selectedPaymentMethod which is the equivalent of the PaymentMethod Result
ebon haven
What do you mean?
solemn forge
const {error, selectedPaymentMethod} = await elements.submit();
ebon haven
Ah yes but I don't understand how to differentiate an existing payment method and a new one 🤔
solemn forge
I think the new one won't have the customer ID
ebon haven
Oh okay, you're sure of that? Because looking at the React Native Stripe API, the result of PaymentMethod: https://stripe.dev/stripe-react-native/api-reference/interfaces/PaymentMethod.Result.html
I can see the type of customerId , it's customerId: string;, it's not customerId?: string or customerId: string | null
solemn forge
can you please try to log the selectedPaymentMethod in both cases and see the difference?
ebon haven
Oh the thing is that I'm preparing the work so that product team know if it's a hard project before we prioritise this project or not so I can't log anything, all my threads are purely theorical 😭
finite elk
@ebon haven sadly it's hard to debug with a meta question here. I recommend taking a few hours to integrate the product end to end here
kevin_reactnative-meta
ebon haven
<@1269928366182629378> sadly it's hard to debug with a meta question here. I rec...
Okay might try this 🙏
You lost me there, I asked how to differentiate an existing payment method from a new one when submitting elements or in confirmHandler in React native
What's the connection between this and prices / taxes?
finite elk
Ah sorry I mixed up my threads, my bad
ebon haven
Ah NP 😂
I haven't tested yet but on React.js, selectedPaymentMethod only returns a string it seems, it's not the result of payment method like in React Native 😅
I have checked with these libs versions
"@stripe/react-stripe-js": "~3.9.0",
"@stripe/stripe-js": "~7.8.0",
finite elk
sadly our web and mobile SDKs have different interfaces. Something I keep fighting against internally but alas 🙁
ebon haven
Hahahaha NP so on web SDK it's not possible to distinguish if a user selects an existing payment method or a new one? 🙁
finite elk
what exact doc are you following end to end so I can grasp what you are asking?
finite elk
where is selectedPaymentMethod coming from on that doc? (for web)
ebon haven
In your doc, you only show this const {error: submitError} = await elements.submit(); but when I check the signature of submit I see the previous screenshot I showed you
finite elk
gotcha, never heard of this sadly. Best approach is really to test this end to end versus guessing from the type signature
ebon haven
Oh okay thanks, so you don't know how to do the difference between old and new payment method in confirmHandler signature too? https://docs.stripe.com/payments/mobile/accept-payment?platform=react-native&type=payment#confirm-the-payment-details
Otherwise yup I'll check this during implementation ^^
finite elk
Not sure, those things are much easier to understand while running the code with logs.
ebon haven
Okay thanks anyway, will see that with product team 😄