Yesterday I saw something in my production system that I haven’t seen before: a TerminalCheckout had more than one payment_id
The first Payment was in state “FAILED”, and the second was in state “COMPLETED”.
Is this intended behaviour? It seems very rare if so: it’s the first time I’ve seen it in more than 65000 transactions!
What’s the best way to check Payments returned in a TerminalCheckout for validity: should I be looking for status==“COMPLETED”, status not in (“FAILED”, “CANCELED”), authorized_money not being zero, or something else?
(This was checkout ID QqmME8C5P4gqO at location L8MSBCS94TPG5 showing payment IDs FcZIlS8UbDaUUlhatOTS8mmjuaB and 7F25QybkT2T7yZ5iaGwi2FY7vaB.)
A followup question: it’s really difficult to test for this kind of case at the moment. Could we get a testing device ID in the sandbox that will create a TerminalCheckout with multiple payment IDs in various different states, please?
@Bryan-Square
I’m not facing the same issue, but just learning the terminal API,
I also noticed the payment id field in TerminalCheckout is a list (payment_ids) rather than a string, so if it’s not supposed to be more than one payments under one TerminalCheckout, why it’s a list?
If for some reason it has to be a list field but not supposed to have more than one payment normally, will it be safer for our application to use the last payment id instead of the first payment id in the list?
It’s designed to be an array of payments because it leaves the door open for multiple payments to complete a checkout in the future like split payments without changing the response which would be a breaking change. We’re always trying to set developers up for success so they’re not constantly refactoring to stay current.
