#cristiancalara
summer dragon
Hi there 👋 can you share an example of the screen that you were expecting the readers to progress to? Are you seeing that behave as you're expecting in test mode?
tiny hazel
Hey, so the terminal should show the "Tap to pay" screen. Similar to the one above (ignore the tip thing)
It does work properly in test mode, yes
summer dragon
Gotcha, can you share the ID of the related Payment Intents from livemode where you did not see that displayed?
tiny hazel
Yes, one example is pi_3Oc8RtFEOo2q91401WUybGg5
(the client then mistakenly deleted the reader connection instead of just canceling the pending action https://share.zight.com/7KunLBNW - not sure if it's useful but basically that reader id that was used for the payment intent above is no longer present)
Another example is pi_3OcaHyFEOo2q91401HKd6oHa (in which the same reader id still exists)
summer dragon
Hm, it doesn't look like tipping was overridden in the processing request. Trying to think through what could have suppressed that.
Is the behavior consistent? Or intermittent, in that somtimes you do see the tipping screen?
tiny hazel
Sorry, my bad with the screenshot. That image is something I just took from google images as it takes a while for me to connect my test terminal back on.
The screen for the clients is left at the default gif screen. And what would be expected is that the screen turns into the screen that allows customers to tap or insert their card.
summer dragon
So you aren't even getting to point of the terminal prompting for a card to be provided?
tiny hazel
Correct
summer dragon
Alright, so this is way before tipping then.
tiny hazel
so they are not getting to this screen
summer dragon
Gotcha, my question about consistency remains. I'm trying to understand whether it's consistent behavior and we're looking for an integration issue, or it's intermittent and we're looking for an environmental or settings issue.
tiny hazel
It's intermittent. So it only happens say like twice a week on average.
While it's intermittent so it could be a environmental or settings issue - it feels too often to be that? We've already went through the standard troubleshooting for updating the software and restart
summer dragon
How often is too often?
You mentioned it is only happening for specific accounts as well?
gloomy shaleBOT
tiny hazel
In the past 11 days it happened 11 times for 6 terminals (obv. we can't assume that all the cancel actions were due to the same issue, but I think most of them are due this)
summer dragon
Which ones do you know are associated with an occurrence of the reported behavior?
tiny hazel
pi_3Oc8RtFEOo2q91401WUybGg5 and pi_3OcaHyFEOo2q91401HKd6oHa
winged wharf
Hi! I'm taking over from my colleague. Please, give me a moment to catch up. Sorry for delay.
Were you able to reproduce this in your testing environment?
I am thinking, since it's a server-driven integration, maybe somehow the Terminal IDs get messed up and the call goes out to a wrong Terminal in another location?
And since noone expects it to turn on in that other location, it gets cancelled after some time.
Not sure what are other possibilities.
tiny hazel
Yeah considered that but it doesn't look like it. https://share.zight.com/kpuebkgo - as you can see, after a few minutes (in which they reached out to use), they re-send to the same terminal and the payment is made
I was not able to reproduce this in my testing environment, I tried quite a few things (like stopping the wi-fi that the terminal used "mid-way")
winged wharf
Ok I recommend you to write to Stripe support and add all the relevant details, then my engineering team will look at it in it's own time: https://support.stripe.com/?contact=true
tiny hazel
Okay, will do. Thank you 🙂
winged wharf
Happy to help.