#jeffrey_terminal-serverdriven

1 messages ¡ Page 1 of 1 (latest)

queen pendantBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1270858625019150517

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

proven river
#

Ok now for the problem. Let's say the application loses connectivity, essentially abandoning the payment intent. The reader action will still continue to show "in_progress" forever, even if the associated payment intent gets canceled. And, here's the unexpected part, even if the terminal gets turned off and turned back on. When the terminal boots up and conencts to Stripe, it can't possibly be in the middle of an action, it must be idle. So why doesn't stripe null out the action property?

#

The only way out of the "stuck" situation is to use the cancel_action endpoint.

#

But there's no way for our application to confidently know whether the reader is really in the middle of processing a payment or not, so we can't confidently cancel the action otherwise we might get in the way of a legit transaction.

slender axle
#

You're making some good points but I'm struggling to understand

But there's no way for our application to confidently know whether the reader is really in the middle of processing a payment or not
Your application literally is the one starting the action. In my mind it's like a database transaction, you should know one is happening, you started it and didn't finish it

#

jeffrey_terminal-serverdriven

proven river
#

Let me try to lay out a scenario. Order 1 generates a payment intent and then fires up the terminal to process that payment intent. The terminal's action payload has the payment intent Id and the status is in_progress. Then the computer that was processing Order 1 crashes...in which case the payment intent is still active and the terminal still is still waiting for someone to swipe a card. The user gives up, powers down the terminal.

Then a different user wants to use the terminal, powers it up and it looks good to use. They create Order 2, generate a payment intent, and try to process payment on the terminal. However according to the API, the terminal is still processing that initial payment intent, so we don't let them use the terminal.

From the perspective of Order 2, Order 1 still looks like it's in the middle of processing. What it needs to know is what state the physical terminal is in to confidently call cancel.

slender axle
#

Then the computer that was processing Order 1 crashes...in which case the payment intent is still active
that computer should have told some "common server" that it's processing order 1. You need some kind of "global state" that tells you whaat's going on

proven river
#

sure but how would you tell the common server that we're no longer processing order 1...the computer crashed, it can't update state.

slender axle
#

the computer boots and the first thing it does is ask the common server "well was I doing something?" is how I'm thinking about it

#

conceptually the computer 1 should even know it was doing something, it should have some saved local state if I were building this

#

What I've seen people do is also have some kind of "timeout" and cancel after X minutes for example

proven river
#

yeah our actual implementation is far too complex to try and lay out here. anyways I still think the action property leaves much to be desired in the way it works...a reboot should clear it out, but I can make that request in a support case.

slender axle
#

because the whole "process payment intent" flow it's not something you get into and wait 2 hours

#

a reboot should clear it out
yeah that part I agree, it's really surprising we don't "auto-cancel" to me but I think it's by design

proven river
#

yeah well a PI will cancel itself automatically after some time right? it's weird that even after that point the terminal status will still show as "in_progress" for the PI, even if it's literally now impossible to process payment against it

slender axle
#

yeah well a PI will cancel itself automatically after some time right
no it doesn't. The PI can be active for years.

proven river
#

ah ok fair enough

slender axle
#

yep

proven river
#

which ostensibly would update the action status to timeout or something

slender axle
#

it's hard because a lot of this is async and internet could be lost at the wrong time

#

but I agree with your intuition here, I'd want the same thing

proven river
#

yeah I see it's tough. The one nice thing about SDK was realtime communication between the app and the terminal. but that has it's own terribleness...we still think the server driven is better overall.

slender axle
#

yeahhhhh

#

we really wanted the "local connection" thing to work. It would have been much better

#

but after the past few years where 99% of the problem are "why can't my reader talk to my local PoS on the same network" I think it has proven it can't work at scale

proven river
#

yeah unfortunately a vast majority of our clients hit connectivity issues

#

and often don't have the IT resources to figure out how to open up the correct paths in their network, or are operating on some other company's wifi or something that's locked down

#

anways, I appreciate the thoughts. I'll consider a few more things and see what I can come up with.