Which throws an exception (SquareConnect\ApiException) with the following message:
[HTTP/2 404] {"errors": [{"code": "NOT_FOUND","detail": "Could not find payment with id: some-payment-id","category": "INVALID_REQUEST_ERROR"}]}
Obviously, “some-payment-id” is an actual payment ID.
Our client - who’s the holder of the Square account with which our application integrates - in all cases can verify that these supposedly “non-existing” payments exist; they can locate the payments on their dashboard using the exact IDs our application is sending.
As stated earlier, this same bit of code only throws the exception for some payments, not all, and we have yet to find a common theme.
Has anyone else experienced this behaviour recently?
Are you calling GetPayment right after the payment is being made? Also are you retrying the request when you get this error? There are some asynchronous functions that have to complete in our servers prior before the payment being retrievable with the API.
No, @Bryan-Square. The call to getPayment is part of our workflow when issuing a refund; before we issue a refund, we need to get some info regarding the original payment.
So the payment I’m testing with now, for example, was made mid-August 2022.
What’s the payment_id and what’s the merchant_id of the Square seller you’r trying to get the payment from? Also can you try calling RetrieveOrder with the ID? It may be an order_id that your trying to call the Payments API with.
FYI, Bryan, our application is currently using version 2.20200122.2 of the Square Connect client library. I mention this because 1. it may account for the behaviour, and 2. there is no retrieveOrder method in this version.
The payment ID is bKPdBRDf3XhDk1yd4DFYZ1seV but the merchant ID I’m not sure about - I’ll have to contact our client. All we have on file is the application ID, location ID, and API key.
Okay, that’s an order_id which makes sense as to why you got payment not found when calling the Payments API with the ID. The payment_id for the order is zTFwM9OqUlRAYN77doH5QrpmuaB. You can also use BatchRetrieveOrder to get the order information. That version doesn’t have RetrieveOrder cause it wasn’t released yet.
Really appreciate your help, Bryan, thank you. We recently migrated from the Transactions API to the Payments API and obviously didn’t do a very good job.
So now our DB has a mix of actual payment IDs generated via the Payments API, and “payment IDs” that are actually transaction IDs - now order IDs - generated via Transactions API charges.
Any suggestions to help with our conditional logic? As in, any quick way to differentiate between the two types?
Is your DB logging all the ids a payment_ids? Also if there’s logic that knows that every ID from this point in time to this point in time is a transaction_id call the Orders API and every ID outside of that point in time is a payment_id call the Payments API that would help.
Unfortunately yes, the developer who originally did the work decided to call them all payment IDs (sigh). I’ll try to establish a timeline to help with our conditional logic.
Thanks again, Bryan, your help has been invaluable.
As this is my first time in these forums, do I flag message 5 as the solution?
