Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
11-03-2015 12:36 PM
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.
11-03-2015 04:22 PM
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.
11-04-2015 04:57 AM
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.
11-04-2015 07:19 AM
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.
11-04-2015 08:31 AM
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.
11-04-2015 01:57 PM
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:
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.
11-04-2015 02:13 PM
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:
11-04-2015 02:18 PM
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
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
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.
11-04-2015 06:56 PM
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.
11-05-2015 02:41 PM
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.
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:
I'm not sure what /v1 in the URL is given that this is clearly not V1.