#gt-gareth_code
1 messages · Page 1 of 1 (latest)
👋 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/1448791932640694363
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
So you're describing the situation where a user enters a card that "looks" like a real card number and passes our client-side validation, correct?
Is your question why don't we update the element with the Stripe error after the call to create a confirmation token?
Yes. And that's right. If the call to create a confirmation token fails because there's an invalid card, then I'd expect you to update your user-facing UI to tell the user as much.
Could you share a specific failing request? (req_123) In my own app, if I use, for example, a testmode decline card, the call to /v1/confirmation_tokens succeeds and then when I try to use that confirmation token to confirm a PaymentIntent, then you get a failure.
But I think you're saying that the call to create a confirmation is token - presumably because we have more robust checks on the backend to make sure it is a real card number before reaching out to the networks
Or if you just give me your account id I should be able to find it
Sorry for the delay, here's an example request to create a confirmation token req_KEABpe3bO8cFZn
By the way, that request was from my testing w/ a test CC.
Here's a request where this happened in the wild: req_5HLlmpNiCkzj7I
Interestingly, if I try using a live card in test mode we don't fail the confirmation token creation request 🫠
ah yes, that really bit us here
Ok, I don't think that there's any way you could affect this behavior in your integration. I think it is unlikely to be a bug, but it also doesn't perfectly mirror behavior of the Payment Element in other contexts. For example, if I confirm a PaymentIntent in the Payment Element and use a decline card, we'll display the error from the clientside confirmPayment call directly on the Payment Element
So what I can do is file some product feedback around this, though I unfortunately won't be able to promise whether we'll adopt it.
Thanks, i would appreciate that.