#battbot

1 messages · Page 1 of 1 (latest)

velvet summitBOT
shy dawn
#

What error do you get when you make that call?

sinful charm
#

no error

#

the api is successful

#

but the reader doesn't cancel the payment action

#

the reader id is : tmr_E56ssgeGqbemsN

shy dawn
#

Thank you for the terminal ID. Do you have a request ID from a time that this happend? (req_123)

sinful charm
#

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

past forge
#

Hi 👋

sinful charm
#

hi

past forge
#

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?

sinful charm
#

yes

#

but the api call was successful

past forge
#

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.

sinful charm
#

it's server-driven

#

we don't poll the reader

past forge
#

So what is the behavior you are seeing that is not what you expect?

sinful charm
#

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

past forge
#

Let me fire up my test integration with my WisePOS E and see if I can reproduce

sinful charm
#

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

past forge
#

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

sinful charm
#

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

past forge
#

Hmmmm.. I was able to return my reader to the splash screen

#

when I canceled my payment

sinful charm
#

like i said, we only have the problem with this specific reader. the cancel works well for all other readers

past forge
#

Are the other readers on the same network?

sinful charm
#

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

past forge
#

Okay so the other reader on the same network, that has not had any problems with canceling actions?

sinful charm
#

that's correct

past forge
sinful charm
#

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

past forge
#

The failures I'm referring to are in the logs for this reader

sinful charm
#

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

past forge
#

Sure I'm just not certain where to modify those settings

#

or grant permission

sinful charm
#

but i'll share it here

past forge
#

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

sinful charm
#

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

past forge
#

Okay that is odd. I'm looking into the logs for that request

sinful charm
#

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

past forge
#

Can you share the terminal reader ID for that transaction?

sinful charm
#

tmr_E3nhvgLotTIHsA

past forge
#

Okay sorry to keep coming back but what about the serial number?

sinful charm
#

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

past forge
#

Yes the latest error message I am seeing is a timeout error

sinful charm
#

you guys probably need to handle this some how

#

and not end up generating an auth on the payment intent

past forge
#

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).

sinful charm
#

ok thanks

past forge
#

Okay, I have filed this as an important bug that needs attention.