#tobewisebeforeiamold_unexpected
tall lightBOT
👋 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/1429954973986328636
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
silk carbon
unreal cairn
Do you have an example PI I can look at?
silk carbon
Sure do! That one above is the one I used to get that screen shot: pi_3SIuu8FXc3zoUgUu1OYDcHXQ
unreal cairn
My bad! Looked right past it!
silk carbon
No worries!
The long and short of things are that if we get an error we don't update our DB to show the thing as "paid" for credit cards, as credit cards are instantly approved - for more immediate user UX as opposed to waiting for the webhook - but if we get confirmed and errors then our DB doesn't match Stripe's state.
tall lightBOT
eager dragon
👋 stepping in as mossy needs to step away.
So there were 3 separate confirmation requests for that PaymentIntent, two got blocked for incorrect_zip and then the third succeeded.
Can you tell me what was unexpected here?
silk carbon
It looked to me like in that code above - the const res = await stripe.confirmPayment... code - that we got res.error and the payment intent was confirmed. This is because in res.error is nothing we call our API and update the status in the DB to be "paid", but that call never went out.
eager dragon
Right so the customer likely attempted 3 times so that code ran 3 times
silk carbon
I'm not well versed in debugging via the Stripe developer tools. can you tell me if the three attempts to confirm each used different cards?
eager dragon
Ah you are saying you expected your database to be updated each time the confirmation ran but you never saw any updates for the declines here, correct?
To debug you can view the PaymentIntent in your Dashboard: https://dashboard.stripe.com/acct_1DLcKyFXc3zoUgUu/payments/pi_3SIuu8FXc3zoUgUu1OYDcHXQ then scroll the bottom and click "Inspect more logs in Workbench"
silk carbon
Correct. Each confirm should call our API...if there are no errrors
silk carbon
The errors in the Stripe developer tools are many because if we don't update our DB then the customer doesn't see their payment as being made and they try to pay again and again and again...and are thankfully blocked from doing so because we try and update the confirmed PI. But I'll see if I can trace the payment methods in there.
My understanding is that they used the same bard, got blocked twice, and on the third try maybe Radar let them through or something, but still showed an error in the front-end
eager dragon
The customer used 3 different postal codes in the 3 attempts here.
You can see that in the POST body for the confirmation requests which you can see by looking at the logs in Workbench
silk carbon
Ah, so they used the same card (I see the same last-4 on the first two errors and then the success) and just kept trying different postal codes!
eager dragon
Yep
silk carbon
Is there a test card we can use in local development that can simulate this: does an initial rejection and then we can enter something to succeed, using the same card number? The "blocked for postal code" test cards all seem to always block
eager dragon
Not really unless you toggle that rule off or you could set a custom Radar rule that blocks based on metadata or a value or something like that.
Actually yeah you should be able to just do a custom rule around postal code
So like block if postal code = '11111'
silk carbon
Interesting...does radar work in "test" environments? How might we go about recreating this locally?
eager dragon
And then you could use that and then change the value to simulate
Yes it works in test mode
silk carbon
Sweet! I have the stripe dashboard open - how might I navigate to those rules? I tried going to https://dashboard.stripe.com/acct_abc123/test/settings/radar but I didn't see how I might create a rule there. Maybe I don't have permissions?
eager dragon
You don't see a Rules option at the top?
silk carbon
I get a "Rules" section with a toggle, but clicking the Toggle doesn't seem to change anything...
silk carbon
OK, when I manually typed in https://dashboard.stripe.com/acct_1JsJtWDYgrK1cJzV/test/radar/rules (for my development environment) it showed up in the "shortcuts" section, but I don't see it in the sidenav otherwise. For the other developer I work with, should I just recommend they type in the URL manually? That's fine for now...hopefully I'll remember that in a few months if we need to test again 🤞
eager dragon
You should also just be able to search Radar in the search box at the top
Or you can give them the URL, yes.
silk carbon
Great, thank you! I'm off to see if I can reproduce this locally!
eager dragon
Sounds good!