Earlier today -- between 12:04 and 12:07pm PST, to be specific -- Authorize.net changed the way their API worked, unannounced, that caused successful transactions to not be recorded by us and many others, including ZenCart customers, and who knows how many others.
A Silent POST is the mechanism by which Authorize.net POSTs back to our servers to inform us of the outcome of a transaction. An MD5 hash is used to authenticate that the POST is legitimate, and one of the values hashed is the transaction amount.
Starting today, they are now passing the x_amount parameter back as 19.9500 (as an example) but still using 19.95 as the amount for the x_MD5_Hash parameter.
An immediate fix would require stripping out the last two 0's from x_amount (if present) when calculating the MD5 hash so that the computed md5 hash matches the x_MD5_Hash passed.
After having spent the better part of today figuring out what the problem was, fixing it, and manually reconciling hundreds of transactions, I'm really hoping they don't change the x_MD5_Hash tomorrow to rely on the new price format (x.xxxx), as it'll break everything all over again, and pretty much scuttle any chances I have of getting any thing done tomorrow.
If you're wondering why your transactions aren't showing up in your billing system, this is why.
And if it isn't clear enough, this is absolutely unacceptable. Not only is an unannounced API change to a heavily-used billing system horrendous, but this specific change is severely impacting customers, and Authorize.net are completely missing to fix the issue or answer any support requests.
A Silent POST is the mechanism by which Authorize.net POSTs back to our servers to inform us of the outcome of a transaction. An MD5 hash is used to authenticate that the POST is legitimate, and one of the values hashed is the transaction amount.
Starting today, they are now passing the x_amount parameter back as 19.9500 (as an example) but still using 19.95 as the amount for the x_MD5_Hash parameter.
An immediate fix would require stripping out the last two 0's from x_amount (if present) when calculating the MD5 hash so that the computed md5 hash matches the x_MD5_Hash passed.
After having spent the better part of today figuring out what the problem was, fixing it, and manually reconciling hundreds of transactions, I'm really hoping they don't change the x_MD5_Hash tomorrow to rely on the new price format (x.xxxx), as it'll break everything all over again, and pretty much scuttle any chances I have of getting any thing done tomorrow.
If you're wondering why your transactions aren't showing up in your billing system, this is why.
And if it isn't clear enough, this is absolutely unacceptable. Not only is an unannounced API change to a heavily-used billing system horrendous, but this specific change is severely impacting customers, and Authorize.net are completely missing to fix the issue or answer any support requests.
