CIM WSDL Breaking Change on 11/3?

[npiasecki]

Recently (may have been last night, from what I can tell), Authorize.Net inserted a "customerProfileId" field in the WSDL for the CIM CreateCustomerPaymentProfileResponseType. For older clients using the standard svcutil tool provided by the .NET Framework, this causes deserialization of the customerPaymentProfileId field to fail silently (returning zero) because the order of elements in the WSDL has changed.

So I was left scratching my head as to why I was getting an "OK" response but a customerPaymentProfileId of zero. Once I started sniffing the responses over the wire, I noticed the new customerProfileId and noticed that was throwing the .NET serializer off. I'm posting this here in case other folks on .NET are caught off guard by this change. The solution is to simply re-run the tool to update the WSDL to the latest version.

[nwolford1]

I had a similar issue with the GetCustomerProfileResponseType returning all 0s for payment profiles. Updating the service reference did the trick. This code is not yet in production, but what would happen if it were?

[npiasecki]

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.

[reedyb]

Same thing is happening to us. Did we miss something that should have alerted us to this?

[lindashore]

has anyone updated the wsdl and got themselves back online?

[lindashore]

were you able to update and get back online? we updated and we are still seeing errors

[reedyb]

Yes. We were able to update and are now functioning.

[carl]

same thing is happening to us.  only happening to already made accounts.  new accounts work though

[quintus_slide]

OK, why the hell would we need to update?  It seems a no-brainer that in most cases like this, the interface provider should version the interface.

It terrifies me to have my business dependent on a business that does stuff like this.

[dpk]

Was there any announcement regarding this change?