#gyungi
mighty cove
Can you share the example error/request here?
mighty cove
Oh, this is a reader request
main ingot
yup! which is why I'm pretty confused as to how it errored with an invalid expiry month error
mighty cove
Yep - me too, looking 🔍
main ingot
thank you!
potent crystalBOT
mighty cove
Since this is coming from encrypted EMV data on the card we can't do much to inspect the value -- is the customer able to try another card here?
main ingot
I don't think so- I think they've long since left the store after trying another card
The problem is solved I'm just trying to figure out how we should be gracefully handling that error
warm widget
Hello 👋
You can treat it similar to how you handle declines, prompting your users again to provide a diff payment method
main ingot
Yup! Makes sense- is there a structure to the way that error comes back? It seems like it didn't have a last_payment_error attached?
warm widget
I don't think the error structure should change
Weren't you seeing the complete response body?
https://dashboard.stripe.com/logs/req_NggID8lZk2NB4Z
main ingot
I thought so, but we basically saw this in a loop where we continually Get the payment intent to check if there's a last_payment_error on it and it never escaped that loop
So I'm wondering if there's a special type of error that this was
warm widget
Ah interesting. I think you'd likely want to depend on confirmation call response instead rather than polling the API for this.
so when you call processPayment it should have returned with an error instead
https://stripe.com/docs/terminal/payments/collect-payment?terminal-sdk-platform=js#process-payment
main ingot
This makes sense if we're using the client to collect the payment, but we're using server-driven payment collection
potent crystalBOT
warm widget
Ah I see. Def weird to see it not get reflected in last_payment_error
main ingot
That's what I thought- is there some other way we should be looking for errors on the payment intent that aren't actual errors or the last_payment_error?
warm widget
I think you'd rather want to listen to webhook events instead
specifically terminal.reader.action_failed
main ingot
I think that's the right long term solution, yeah- is there anything we can do in the short-term to prevent this? is there some other error field on a payment intent that could be populated if this were to happen?
warm widget
The PaymentIntent might not reflect the error but the status should go back to requires_payment_method