battbot

[gritty holly]

Do you have the ID of a payment that took that long? (pi_123)

[mild meteor]

we don't

i have a video of the problem from the merchant

how can i share this with you

[gritty holly]

If it doesn't have identifying info and you can share it publicly, you can send in this thread. Otherwise you can DM me and I can take a look

[mild meteor]

did you get the video on dm?

[gritty holly]

Yes I did.

[mild meteor]

I found the payment intent id for the payment in the video

pi_3M6MTMJ93KfFVesb0wNeTffh

[gritty holly]

thank you was a about to ask

[mild meteor]

the store says sometimes the reader takes even longer than this video

causing the customer to think payment failed

and they would cancel on our pos

this is a self-service kiosk

[gritty holly]

As in there isn't an employee at that kiosk monitoring it? As a side note, I don't think we currently support that as a use case for Terminal. They need to be monitored still

[mild meteor]

well the issue here is the slowness

i don't think having a person monitoring or not has any impact on the speed of the processing

[gritty holly]

Right, I am still flagging separate issue because it is a potential security risk

[mild meteor]

the store is ok with the security part of it

they have the use case and we provide the solution

to the best of our capabilities based on what's available

[gritty holly]

I actually don't know if Stripe is okay with the security part of that. I am looking in to the speed thing but also reaching out to colleagues on that aspect to make sure I am remembering that correctly

Hey still looking in to the speed aspect of this. I see which calls took a bit, not quite sure why yet

[mild meteor]

ok

we have many customers complaining of the speed of the reader

not just this one

[gritty holly]

Across all of your locations?

[mild meteor]

also they said as the day goes on, the reader gets slower and slower

[gritty holly]

Or some of them etc?

[mild meteor]

a number of them

[gritty holly]

Has this always happened or only recently?

[mild meteor]

i'm not sure about that

[gritty holly]

Do you have IDs from payments from other locations?

[mild meteor]

no i don't

it's a general complaint from our customers

they don't tell us specific time/date, so it's hard for us to look up

since some of the stores has hundreds of transactions per day

[gritty holly]

Also from the self-serve angle, I may have been unclear earlier. As long as there is an employee covering the self serve area that is a supported use case. Stripe doesn't support things where the kiosk is left completely unattended like with a vending machine

From your video/description I am guessing it is more like the former but if it isn't I'd recommend talking to our support about your use case because it does pose a security risk

Looking in to that one payment still. Will see what I can find

[mild meteor]

yeah the employee is overlooking it

it's not a vending machine type

[gritty holly]

So from what I am seeing, the confirm and capture calls for that payment took about ~3 seconds total which isn't wildly out of whack for a credit card payment (just talking to credit card networks takes about that long).

Do you have any logging on your side for how long things with this specific payment took?

[mild meteor]

well the time it took to spin on the reader

i counted 6 seconds just for that

[gritty holly]

Also what terminal flow are you using here? Is this server driven? Or one of the js/iOS/android driven ones?

[mild meteor]

if you watch the video

that doesn't involve confirm and capture yet

[gritty holly]

I agree with what is on the video, I am talking about request times on our backend

[mild meteor]

the whole thing added together takes a while

[gritty holly]

A lot of time can get added by other things so I am trying to figure out what that is

Right, currently I don't know what your integration is doing for 4 of these 7 seconds that the payment in the video takes

[mild meteor]

we are using server-integration model

we aren't doing anything on the terminal side

the reader reads the card, when it success on there, then we get the webhook call from Stripe about the reader success event

so that 6-7 seconds of that reader spinning, it's all stripe logic

after we get the reader success event, then our system becomes involved to capture it

[gritty holly]

Gotcha, I am still trying to figure out what the delay might be here. It looks like your integration is making the capture call almost as soon as the confirm call ends so it isn't like that signal is getting delayed by an extra second or something

I will consult my colleagues on this and will get back with what we can find

[mild meteor]

ok thanks

[gritty holly]

Hey @mild meteor apologies for the delay. Our logs show the 6 seconds here was actually us waiting on the card network's response. Can you write in to our support team about this issue? I want to raise this to take a further look at your other patterns here as you are seeing this kind of wait time frequently.

If you write in to our support team here and DM me with your email, I can grab the ticket and keep you updated on what we can find https://support.stripe.com/?contact=true

[mild meteor]

I'm adding the ticket

the ticket is filed

[gritty holly]

Can you DM me your email? Just sent you a message

Oh right we already had the chat from the video. If you can send your email there that will be very helpful