#battbot
1 messages · Page 1 of 1 (latest)
What error do you get when you make that call?
no error
the api is successful
but the reader doesn't cancel the payment action
the reader id is : tmr_E56ssgeGqbemsN
Thank you for the terminal ID. Do you have a request ID from a time that this happend? (req_123)
it happened on Dec 21 around 13:47 EST time
but i'm having trouble looking it up on the logs of the developers section, since you guys don't have a way to filter by date
i'm not sure how to filter by the API endpoint when there's path parameters in your logs section
ok i found it:
req_tb0spAGELxf1MQ
req_BqUt0GtHggtW22
req_cLOBHqoBSC1TMU
i have a video the store recorded of what happens on the terminal when these requests were sent
i can dm you if you need
Hi 👋
hi
So let me get this straight. You have a reader with action.status of in_progress and you make a request to cancel that action. And the reader does not cancel?
But when you poll the reader it returns the action property with data instead of null?
I am seeing a fair number of of duplicate request errors as well as failures to connect to Stripe networks. How are you integrating the Wise POS E? It looks like a server-driven integration but I want to be sure.
So what is the behavior you are seeing that is not what you expect?
the cancel_reader api responds successfully
but the reader display doesn't change. It still displays the payment
can i send you the video?
i can't dm you without permission
Let me fire up my test integration with my WisePOS E and see if I can reproduce
It seems like only with this reader that we have problems with, other readers are fine
i sent earlier the request ids for the cancel reader actions. they were all successful
You're saying the screen stays on the screen to collect payments? I just want to make sure I try to cancel at the right spot
yes
there's several tries, the screen stays on whatever screen it was on
normally cancel will bring it back to the initial splash screen
for this case, the reader screen was on the first payment screen which asks for the user to select the tip amount
Hmmmm.. I was able to return my reader to the splash screen
when I canceled my payment
like i said, we only have the problem with this specific reader. the cancel works well for all other readers
Are the other readers on the same network?
this location has two readers
they are on the same network
as for other locations, they are different locations, so different networks
we are not a single store, we have many stores
Okay so the other reader on the same network, that has not had any problems with canceling actions?
that's correct
I ask because I'm seeing a large number of failures to resolve some of the Stripe domains. Have you tried any of the troubleshooting steps we outline here?
https://stripe.com/docs/terminal/readers/bbpos-wisepos-e
are the failures specific for this reader?
Because the /v1/terminal/readers/%s/process_payment_intent API works perfectly for this reader
it's only the cancel that doesn't work
The failures I'm referring to are in the logs for this reader
can i dm you the video?
i'm not sure what the failurs entail, but sending payments to the reader works every time, but canceling those never seem to work
Okay. That doesn't really tell me anything new at this point. Except that I would review the troubleshooting steps for that reader just to rule out any potential DNS issues
we have another issue
we made a request to pay on the reader
req_7oapWIBF2tSeua
and we got an error message as part of the request
but somehow that reader still displayed the payment, and the end user tapped their card
but because we got error initially, we handled it like a failed payment
this is a different store and reader than the previous issue
This is the payment intent that's associated with the reader request: pi_3MK8ohJ93KfFVesb0fDhJZCo
Okay that is odd. I'm looking into the logs for that request
this resulted in the customer's online card statement registering a pending transaction, but on our side it's a failed transaction. The customer ended up refusing to pay for their order due to the pending
Stripe needs to handle these edge cases because right now it's a loss for the store
Can you share the terminal reader ID for that transaction?
tmr_E3nhvgLotTIHsA
Okay sorry to keep coming back but what about the serial number?
WSC513221040814
What I think happened, is that the Stripe server sent the request to the Reader, but your server didn't get the response from the reader. So your server gave us an error, but in fact Reader did get the payment intent, and went ahead to collect the card info
Yes the latest error message I am seeing is a timeout error
you guys probably need to handle this some how
and not end up generating an auth on the payment intent
I agree we need a better fallback behavior when on unstable networks
I am going to raise this internally to ensure we alert the correct team(s).
ok thanks
Okay, I have filed this as an important bug that needs attention.