#reyanshsharma

1 messages ยท Page 1 of 1 (latest)

warm questBOT
tacit elm
#

Hi ๐Ÿ‘‹ what part of the flow are you trying to understand?

gritty compass
#

Terminal server-side implementation:

  1. I created a PI --> Successfully created.
  2. Called ProcessPaymentIntent method to start the payment process on reader --> Got reader busy exception. Got 400 errors --> request to stripe failed.
  3. Retried ProcessPaymentIntent but got null as a response.(We have a retry logic so in case of this exception we recall ProcessPaymentIntent). Got request to stripe completed.
tacit elm
gritty compass
#

Are we supposed to get a null response from ProcessPaymentIntent endpoint/request? My assumption was it can't be null if no exception so I have some further steps based on that assumption.

#

If this can be null I have to change the logic.

tacit elm
#

I would not have expected it to return a null response. My understanding is expected return values are either a Reader object or an error.

Do you by chance have a request ID from the request that returned null that I could take a closer look at?

gritty compass
#

Let me check If I can find that.

#

I was on the PI request only.

warm questBOT
gritty compass
#

I am only able to find the one which resulted in exception
req_pdeh2Xriyhx0Yt

#

and the one which succeeded req_LfnXBLQkGHTOl3

tacit elm
#

Gotcha, and that aligns with the behavior I'd expect to see, where an error is returned. I do think it's unexpected for a null value to be returned, but I'm not sure offhand hat could have caused that behavior. I would recommend adding logging to check for a null value being returned, and try to capture as much relevant data as possible when that happens so we can try to get a better understanding of what is going on.

gritty compass
#

Sure will add logging on else block in the code

#

Though I ended up getting return from else block from point 3

#

Any recommendations for the type of info I can log as only info I have in hand is null reader ๐Ÿ™‚

tacit elm
#

Oh, I may have misunderstood the concern initially. I see you have that wrapped in a try block, what type of exceptions is the associated catch block catching?

gritty compass
#

Trying retry for ProcessPaymentIntent 3 times before actually throwing an error.

  1. terminal_reader_timeout
  2. TerminalReader_Status_Busy
#

In my scenario, there was an exception when I tried calling [ProcessPaymentIntent] the first time so retried. There was no exception on the second try but the reader was null hence I got response

Success = false, ExceptionMessage = "Unable to process the payment intent: " + paymentIntent.Id

#

Also before retry e are waiting for 1 second.

tacit elm
#

Hm, is ReaderActionStatus something you added? (I'm having trouble finding references to it)

And is there an additional catch block further down that catches any other exceptions? I'm wondering if there is an exception that is being thrown that isn't being caught/detected.