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.

[RichardH]

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

[carl]

 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.   

[trayhumphrey]

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

[Bill_Lansa]

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.

[carl]

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.   

[lancetx]

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

[naalpert]

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/3352...

[studyblueops]

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.

[npiasecki]

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.

[simeyla]

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.