I'm in production, I can tell you that it was a perfect storm: because they inserted it right smack in the middle of the response, the "Ok"/"Successful" part of the message element came through, but the customerPaymentProfileId came back as zero. So our system said "everything's great!" and saved a zero to the database -- then any future interactions against that payment were interpreted as declines.
It was through a combination of "there sure are a lot of declines this morning," then the sinking feeling of "I've not seen that message before," then "OMG why are they all zeroes," to "shouldn't there have been an exception", to "OK the first one happened around midnight", to wire sniffing the response, and then noticing the new element and guessing that was the culprit. So I had to fix all that, go through and manually look up the correct IDs to fix those customers and e-mail them, which was not a great way to start the morning.
I suppose our system should have sanity checked the ID returned from Authorize.Net and said "zero doesn't look right," but we always treated it as an opaque token. I doubt Authorize.Net will respond, as they seem more focused on JSON and POX endpoints than the SOAP ones.
