#zaq_unexpected
vale agateBOT
đ 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/1229534809454411776
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
fringe warrenBOT
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.
- zaq_best-practices, 5 days ago, 6 messages
- zaq_error, 5 days ago, 13 messages
versed bridge
this is all for the same app, but just slightly further along in the developrment process
steel violet
Hi there! Can you clarify which test account you're using?
versed bridge
the one associated with my email. do you need that email address?
(just for now until we get all the kinks worked out and then will set up for client)
steel violet
Ah, sorry. I meant which test bank account are you selecting in the PaymentElement
versed bridge
debit not authorized 3335, account closed 1113, failure 1116, insufficient funds 2227, along with the ones I expected to work: high balance 4321, success 6789
steel violet
Ah, I see
So adding these will succeed but if you try to create a payment for one of these accounts, the payment will ultimately fail
versed bridge
thats my concern
I'm not sure why all of those different test accounts exist if they return the same result. unless somehow I'm causing this behavior?? but it seems like this is all from the stripe PaymentElement's internal behavior
steel violet
No, I don't think you're doing anything wrong. The key here is that those test accounts will fail (due to debit not authorized, insufficient funds, etc.) when a payment is taken. You're still simulating a successful connection, which is why the SetupIntent confirmation succeeds