Closed (fixed)
Project:
UC Linkpoint API
Version:
6.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Jan 2011 at 22:04 UTC
Updated:
21 Jan 2011 at 01:40 UTC
Linkpoint apparently isn't the most robust processor. We've noticed a number of times where it tries to do the postauth/void combo due to fraud settings and it returns the error:
Voiding error while trying move transaction to POSTAUTH: SGS-005000: The server encountered a database error.
Currently the module still blocks checkout, even though the auth/sale is still valid which can lead to multiple charges on a card. Change it so that if it encounters a failed void it just lets the order through. That seems the lesser of two evils and if folks need more robust fraud detection they can pay for linkpoint's fraud service.
Comments
Comment #1
bkosborneAccording to their nifty reference PDF of what the SGS codes mean, this one says "Typically, this occurs when the MAXLENGTH parameter for one or more of the XML fields has been surpassed". Let's first check and verify this.
Comment #2
jrust commentedI don't think this is it because in the orders where this occurred, the customers attempted to submit the order multiple times and there were multiple cases where the auth->void process worked for their submission. Even if we can find something wrong I'd like to have this safeguard in place in case some other error causes a failure. Agree?
Comment #3
bkosborneInteresting. I do agree with you there. Will make the code a bit ugly but whatever.
Ever call first data before? I highly suggest calling them and explaining the problem to them. They may be able to tell you what's up with that.
I'll try and push a patch tonight to let voids go thru if they fail. Just to be clear, they are failing on the POSTAUTH or the VOID?
Comment #4
jrust commentedActually, I had already written the patch because it was urgent. I think you'll like it as it actually cleans it up a bit by abstracting the voiding stuff to a separate function. Good idea about calling them, it might help to get their idea. However, when I called them earlier asking what was the best way to use the fraud info they provided to void an auth they were at a bit of a loss :)
My guess is that it's a bit of a race condition. Meaning that they probably have multiple database nodes syncing and because we succesively issue an auth and then a postauth it occasionally hasn't committed the auth to disk on all nodes. If that's correct then we could try sleeping for a second before voiding or trying to do the void X number of times before giving up. The latter method seems more robust so maybe I'll look into adding that today.
Comment #5
bkosborneI like your second idea there...
Just make sure that all the transactions are still logged in admin comments.
I called FD a month or so ago and remember them saying there is no best way of voiding. The only two options are really to just let a PREAUTH stay on the card and do nothing, or POSTAUTH and VOID. They said it doesn't matter.
Comment #6
jrust commentedCalled Linkpoint and they confirmed they've been seeing these errors and are working on it. They suggested attempting the void a second time so I added some code to attempt the void a max of 2 times.
Comment #7
bkosborneNice looks good. I'll add to my sites.... Probably no need to do another release though.