#intelagent_api
ionic sleetBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1251189038711443566
đ Have more to share? Add details, code, screenshots, videos, etc. below.
shell cobalt
It's quite easy to understand that a payment has succeeded, ie we fetch the payment intent and see what the status is. But the tricky scenario is telling the operator of the stripe reader that the payment has failed. We may fetch the reader and that failed status be gone at this point if another payment has been sent to the reader
surreal wrenBOT
shell cobalt
On second thought, it seems like even if a payment intent status is succeeded that doesn't necessarily mean the payment went through a reader, and could have been processed some other way. All of these edge cases just make me think that I'm going about this the wrong way.
worn portal
In that case I think you would want to look at the latest_charge on the PaymentIntent. That will change if there has been a charge attempt since your last API call. I think there is actually an easier way to get the specific decline or error looking in to that.
Can you explain more of the context of how Terminal works with your integration? Is there a situation where you are pushing the PaymentIntent to a reader but also potentially showing the user the same PaymentIntent on a webpage to be confirmed otherwise?
shell cobalt
Yeah great question. In theory no, but two different users could potentially both be on a customer's booking at the same time and each send a request to process the same payment intent on 2 different readers
Or one takes a moto payment while one sends to a reader. This might not be worth thinking about but I am trying to only integrate once and want to do it right
worn portal
The nice thing about PaymentIntents are that they are state machines, the second attempt to confirm the payment would error out
shell cobalt
Right, totally understand that the actual payment intents will be fine I am more worried about showing the correct payment status to the operator
worn portal
In this scenario I think that would mean checking the error, seeing that it is the status from multiple confirmations, and display the user an error based on that
shell cobalt
It seems my question boils down to the question of is it even possible to make an airtight terminal integration using polling. It looks like it may not be possible since using anything like last_ means you may have missed an update to the object.
worn portal
Can you tell me more about the scenarios that you are worried about with having the wrong state for the payment intent?
shell cobalt
It's more about the wrong state of the reader as opposed to the payment intent
The payment intent I feel great about due to it's state machine nature. But if I'm polling a reader status and I poll at t=1 and then t=2 but at t=1.5 the payment failed and another operator started a payment on, then at t=2 that information is lost?
worn portal
What information are you looking for here? Are you trying to completely error out after some number of attempted payments, or do something else? It is often impossible to have complete information on things, but I'm not immediately clear on how missing an error would negatively effect your payment experience here.
shell cobalt
No not necessarily. I'm trying to make sure if the customer taps their card and the payment fails, that is relayed to the operator.
But maybe this isn't worth even thinking about as it seems it would be exceedingly rare and the end result is just a missed error and not a double payment or something of that nature.
Thanks for your help!
worn portal
Happy I could provide some reassurance there. Also if it helps, the Terminal itself will show a kind of error. So they will be able to tell that something went wrong, even if it takes your system a bit to catch up. So this scenario would be confusing, but I think worst case would be that they try to pay again and find it was already paid by the customer with the other operator.