topic Re: CIM WSDL Breaking Change on 11/3? in Integration and Testing

CIM WSDL Breaking Change on 11/3?

npiasecki — Tue, 03 Nov 2015 13:59:54 GMT

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.

Re: CIM WSDL Breaking Change on 11/3?

nwolford1 — Tue, 03 Nov 2015 14:42:58 GMT

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?

Re: CIM WSDL Breaking Change on 11/3?

npiasecki — Tue, 03 Nov 2015 15:08:11 GMT

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.

Re: CIM WSDL Breaking Change on 11/3?

reedyb — Tue, 03 Nov 2015 16:12:22 GMT

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

Re: CIM WSDL Breaking Change on 11/3?

lindashore — Tue, 03 Nov 2015 17:22:33 GMT

has anyone updated the wsdl and got themselves back online?

Re: CIM WSDL Breaking Change on 11/3?

lindashore — Tue, 03 Nov 2015 17:26:09 GMT

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

Re: CIM WSDL Breaking Change on 11/3?

reedyb — Tue, 03 Nov 2015 17:27:53 GMT

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

Re: CIM WSDL Breaking Change on 11/3?

carl — Tue, 03 Nov 2015 17:39:47 GMT

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

Re: CIM WSDL Breaking Change on 11/3?

quintus_slide — Tue, 03 Nov 2015 17:50:24 GMT

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.

Re: CIM WSDL Breaking Change on 11/3?

dpk — Tue, 03 Nov 2015 20:27:49 GMT

Was there any announcement regarding this change?

Re: CIM WSDL Breaking Change on 11/3?

RichardH — Tue, 03 Nov 2015 20:36:38 GMT

Hello everyone

I've reported this issue to the product team for analysis.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

Re: CIM WSDL Breaking Change on 11/3?

carl — Wed, 04 Nov 2015 00:22:53 GMT

dpk, i checked the blog on the changes (https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/bg-p/DeveloperBlog) and there is no announcement. i chatted with the support and they said they did not announce since this is an "internal" change. they also said it was only affecting <1% of the customers, i hardly beleive that.

Richard, thanks we would really appreciate it. changes like these needs to have a process such as proper testing and planning.

i looked at the xsd and it seems there is a new parameter in the "getCustomerPaymentProfileRequest" method having a new parameter "unmaskExpirationDate", i checked the documentation and that parameter is missing, i added a false and it seems to work. but the question is it a bug? and theyre gonna fix it or is it a new change that we should change our applications for? whatever case it is, it disrupts business.

Re: CIM WSDL Breaking Change on 11/3?

trayhumphrey — Wed, 04 Nov 2015 12:57:24 GMT

We use AspDotNetStorefront as an ecommerce package. It integrates with Authorize.Net for credit card processing and does use CIM.

Thanks to npiasecki who started this thread for the source of the problem. I was able to update the WSDL file. What I found is that the call to GetCustomerPaymentProfile has a new required Boolean parameter, unmaskedExpirationDate. Luckily, we have purchased the source for ADNSF, so I was able to update our source and add a false value to that new parameter. After that everything worked.

It is unbelievable to me that Authorize.Net would add a new required parameter to a Get call and not announce the change. Why not make the parameter optional? To say that it affects <1% of customers is wholly beside the point, if it's even true. It is just bad programming, and we have certainly come to expect more from Authorize.Net.

I don't know if Authorize.Net developers read this forum, but if you do, I hope you learn a lesson from this. This was NOT an "internal change". It affected two of our production sites for an entire day. And every AspDotNetStorefront customer who uses your payment processing has had the same problem.

Ray Humphrey

Re: CIM WSDL Breaking Change on 11/3?

Bill_Lansa — Wed, 04 Nov 2015 15:19:28 GMT

I want to echo the last few comments.

All of our customers were impacted by this and we had to address the two changes we've identified in this thread so far.

I did a diff to compare the old WSDL to the current one and see quite a few other differences. (Example, I see some attributes went from MinOccurs="1" to MinOccurs="0") We are forced to push the fix up to production without completing proper testing.

IMO this affects way more than the 1%. Even if it affects a small group, it is their duty to announce this breaking change -- and for us to determine if a change is necessary. Makes me lose confidence with authorize.net and would definitely consider alternatives.

Re: CIM WSDL Breaking Change on 11/3?

carl — Wed, 04 Nov 2015 16:31:34 GMT

well sure we can do changes, test it and push it to production. but if the documentation doesnt reflect the changes, it makes me think it is a bug. and if they fix this, and that would also mean that we are going to roll back our changes as well. that is really not acceptable.

Re: CIM WSDL Breaking Change on 11/3?

lancetx — Wed, 04 Nov 2015 21:57:04 GMT

The programmer who first generated the code from the WSDL is long gone, so I'm trying to pick up what needs to change.

I've gathered I need to regnerate the access code from the new changed WSDL - I think I can handle that. Our code just referred to the WSDL at:

https://api.authorize.net/soap/v1/Service.asmx?wsdl

Is this the same location - they just changed the format in place? Or is there a new WSDL somewhere else?

I would appreciate a little direction.

Lance

Re: CIM WSDL Breaking Change on 11/3?

naalpert — Wed, 04 Nov 2015 22:13:37 GMT

We experienced the same issue starting 11/3 as well. Specifically it was affecting our call to CreateCustomerPaymentProfile, where the customPaymentProfileId in the response was appearing as empty, due to their unannounced addition of the customerProfileId field above it. I've been in contact with support and they're definitely aware of it.

An "Update Service Reference" through Visual Studio and a recompile did fix it for us. But like others on here, now I'm concerned that if they decide to roll back the change, they'll end up breaking all of us who have already worked around it.

Also, there's a thread about this on stack overflow:

http://stackoverflow.com/questions/33509576/authorize-net-getcustomerprofile-not-returning-data/33528630#33528630

Re: CIM WSDL Breaking Change on 11/3?

studyblueops — Wed, 04 Nov 2015 22:18:59 GMT

We have a Java application using the v1/SOAP interface into authorize.net. I don't recall why, but we simply copied the files from

https://github.com/AuthorizeNet/sdk-java/tree/master/src/main/java/net/authorize/api/contract/v1

into our application. With the recent changes we started getting the following error back from authorize.net :

org.xml.sax.SAXException: Invalid element in net.authorize.api.soap.v1.CustomerPaymentProfileMaskedType - customerProfileId
at org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeserializer.java:258)
at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1035)
at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141)
at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236)
at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384)

.....

We were able to solve this problem my downloading a new WSDL ( via https://api.authorize.net/soap/v1/Service.asmx?WSDL ) and modifying the class CustomerPaymentProfileMaskedType. The only modification need was to add the member field

private long customerProfileId;

we also had to add getter/setter for this method and include this field in the equals() and hashcode() methods, which is straightforward.

In the end, we have a "hack" fix for the problem, but we are disappointed in authorize.net communication both before and after this change.

Re: CIM WSDL Breaking Change on 11/3?

npiasecki — Thu, 05 Nov 2015 02:56:40 GMT

Generally, all .NET clients should have to do is update the WSDL. Pass in 'false' to the new parameter for unmasking the expiration date to maintain the previous behavior.

Unfortunately, they have backed themselves into a corner: they cannot revert to the old WSDL without breaking customers who have already updated. I would not expect a resolution from Authorize.Net on this issue. An admission from them would be nice, but I would not expect that either. You can either update against the latest WSDL or find a new payment gateway.

Someone at Authorize.Net seemed to be under the impression that adding additional fields was safe in terms of backwards compatibility. This is generally true for well-coded JSON and plain old XML endpoints. It's even true for SOAP/WSDL if it's added as a minOccurs="0" in a request element. But it's not true for a SOAP/WSDL response element. Because WSDL is supposed to be a contract, the tools provided expect it not to change. The safest thing to do is to simply version the endpoint, which is why FedEx has 17 versions of their Ship WSDL. PayPal is on something like version 119. Internally, they map all of the older versions to the most up-to-date version and do some mapping back and forth, which is nice for everyone involved: clients are not worried about changes, and their developers are mainly focused on the latest version, since older clients pass through a cascade of compatibility mappings.

I could rant about Authorize.Net, but they will not change. Suffice it to say: we've been through hell the past 18 months. It used to be a great service, but something happened. Our last 2 clients on Authorize.Net will move off in 2016.

Re: CIM WSDL Breaking Change on 11/3?

simeyla — Thu, 05 Nov 2015 22:41:33 GMT

Ironically the 'unmaskExpirationDate' feature is something I have been waiting for for years, but on final release it broke certain requests when using generated entities with svcutil.

For me this was GetCustomerProfile and unlike what some others have said I was not able to fix this merely by regenerating their WSDL because they added TWO fields to the response and FORGOT to add them to the actual WSDL.

CustomerPaymentProfileMaskedType

now returns the COMPLETELY REDUNDANT fields : billTo and customerProfileId

Regenerating the Reference does NOT fix this.

I assume if using their API DLL everything works fine, but many older carts haven't been touched in YEARS and this is a very bad breaking change.

I had to manually add these fields to a local copy of the WSDL as shown here:

http://stackoverflow.com/questions/33509576/authorize-net-getcustomerprofile-not-returning-data

I'm not sure what /v1 in the URL is given that this is clearly not V1.