#zishaansunderji-terminal-payments
1 messages · Page 1 of 1 (latest)
Hi there! Awesome thanks!!
I checked our logs and we got a failure response from the reader at 9:50:02 - and then the next transaction started - but both transactions were successful
This response was from the kotlin sdk to our tablets (obviously the reader and in Stripe it went through)
These do look like two distinct payments, though the information for them looks identical (except for the Customer ID, but it looks like a new Customer was created for each of them).
Is your integration designed to try to create a new payment if it receives an error when processing a payment?
So we create a new customer id everytime we process a transaction because at a bar we just get a surge of cards
And every payment is unique
but yesterday I found another issue where a transaction went through but had a timeout issue so we had to re-check the payment intent to see if it went through after a buffer
could you look into any errors we got from the earlier payment?
the exact issue was a READER_COMMUNICATION_ERROR which isn't a surprise because our business' internet isn't the best
this might be similar
Based on what I'm seeing on the Payment Intent, everything went smoothly. Can you share the ID or serial number of the reader so I can look at this from a different angle?
yuppp for sure!
oh shoot our logger doesn't capture that
i can get the series of transactions and the tablet that was used - but i don't know which reader they used because they periodically change it
I'm looking to see if the reader used is logged on our side, but I haven't been able to locate that yet.
gotcha!
so this payment intent pi_3LNS2QFk5BSitd8b1dkl0KYD responded back an error as you can see from the Sentry screenshot - any chance you can see what that might be?
I'm seeing two post requests for that intent, one to create it and one to confirm, and both of them were successful and returned a 200.
hmm
that's weird
so i checked the logs and there wasn't a button tap
so those two transactions happened automatically
and our workflow does have a modal when the card gets declined or any other err (besides err code 16 - which is payment cancelled) to try the transaction again
hmm and I rechecked we only update the UI (as a side effect) once when it goes from card inserted to processing when we get that from the reader
quick question for you, do you when the first transaction ended - that error from our logs happened at 9:50:02 pm Eastern
did the transaction finish before or after that?
I'm seeing that we received the request to confirm pi_3LNS2QFk5BSitd8b1dkl0KYD at 1:49:57 AM UTC (9:49:57 EDT), and that request had an end-to-end duration of about 3.5 seconds, so it seems like it would have fully completed before 9:50:02.
Okay sick! Let me check what our transactions look like
oh okay - so my bad - there was a second touch event which means the bartender did press pay twice after the first one failed with some error
the error is weird though - if you see the payment go through - before reporting an error i could check stripe to see if it was successful
and to confirm the transaction was successful before we saw the error right? so 1:49:57 AM UTC the request to confirm goes through and at 1:50:00 AM UTC the confirm is successful which is 2 milliseconds before we said something went wrong
That would be about 2 seconds before the error in your logs (+/- a second for rounding)
yupp for clarity the bartender made the second touch event at 1:50:55 AM UTC
okay so i'll re-check Stripe to see if the transaction succeeded and if it did then i'll not log the error so that we don't charge a customer twice
awesome!! thanks a ton dude!
this was super helpful!!
Happy to help!
also adhoc question - if you're not sure that's totally fair haha - but the reader we use is the BBPOS Wisepos E and it is loud
i tried lowering the volume and it doesn't help haha
any chance I could programmatically switch off the sound lol
Haha, it can be noisy, you're talking about the ding noises that it makes when reading cards?
I don't think that's currently something that can be controlled programmatically, but am booting up my reader to double check.
(waiting for it to update, impatiently)
haha you're good
i do have to head to the office for a meeting - so is it cool if i look back this thread in 30 ish mins?
Sure, I'm pretty sure this isn't currently possible, but will leave a message here if I find out otherwise.
hahaha oh well - guess i'm giving out complimentary earplugs lol
thanks for your help today!!
i'll find out in 30 mins if there's something i can do anything lol
I've confirmed what you're reporting about the volume buttons, but am not finding any way to control the volume for those readers. I'm capturing this idea as feedback for our product teams to consider adding 1) the ability for the volume buttons to influence the volume and/or 2) a way to control this programmatically.