#battbot

1 messages · Page 1 of 1 (latest)

fast starBOT
late temple
#

Hi 👋 I'm not certain offhand whether that is possible and will need a moment to dig a bit.

young ravine
#

sure

late temple
#

Thank you for your patience, there is not prebuilt functionality for this currently and you will need to implement your own logic to detect and block the card brands that you want to prevent customers from using.

Based on what I'm seeing, it doesn't look like our server-driven integration pattern for terminal supports this, is that what you're using, or are you working with either our Javascript or mobile integration paths?

young ravine
#

we are using the server driven physical Terminals

late temple
#

Gotcha, I'll need to double check with a teammate about whether that is supported.

young ravine
#

i'm not sure we can reject it ourselves

#

since until the tapping of the card on the terminal, we don't know what card type it is

#

and once they tap, the terminal will show successful

#

by the time the result reaches us, and we reject that, it's too late. Because the user will see successful on the terminal, and failure on our POS

#

that's poor user experience, we'll definitely have users arguing with the store about whether the payment was done or not

fast starBOT
opal gate
#

So you could listen for that event, inspect card.brand on the PaymentMethod that you are sent, and then proceed or error out accordingly

young ravine
#

so what does the payment terminal display while it's waiting for us to confirm the payment intent?

#

will it time out waiting for the confirmation?

opal gate
#

Good questions. Checking in to what will happen here. I would imagine you have a decent window to confirm or go forward, that is how our similar integrations work. Will confirm and get back to you.

young ravine
#

we have in the past alot of problems dealing with timeout scenarios with the terminal

opal gate
#

Timeouts related to responding to webhooks or general timeouts from things like network connections dropping while waiting on something?

young ravine
#

timeouts due to communication between the reader and stripe's own server

#

usually the reader only communicates with the stripe server directly and never with our servers, we only initiate the request to stripe's server, and then get results via webhook

#

but what you are suggestion, it seems like the reader will now have to wait for a response from our server regarding the confirmation of the payment, and that definitely involves some form of timeout

#

we don't want to confirm the payment positively, but because of timeout, the reader reflects a negative result to the user

opal gate
#

Unfortunately I am not finding much more info on this beta myself. I think the best way forward would be to reach out to stripe-terminal-betas@stripe.com describing your usecase (and history with these issues), the team running the beta should have a better idea on how well this flow can work with your situation

young ravine
#

ok thanks for the help

opal gate
#

Of course, good luck addressing this

#

The one workaround I can think of with our current server-driven integration would be to only initially place holds on these cards and then cancel the hold if it is on a card with a certain brand. That might be a bit clunky (and unclear to users why it failed when the terminal said the payment went through)

#

I was also going to potentially suggest radar rules but those would be account wide so you would have to add something else to the rule to narrow that down by location, potentially metadata. Then you could look at the decline on your server to see if it came from the radar rule and use that to surface something to the user at the location. Again would potentially work but would be clunkier. https://stripe.com/docs/radar/rules/reference#valid-conditions

Rules reference

Learn more about the structure of rules and the order in which Radar processes them.

young ravine
#

thanks for the suggestion we'll look into it