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.
11-03-2015 05:59 AM
Developers & Merchants,
As product manager for APIs & Developer Experience and on behalf of the API team I want to acknowledge that we messed up and we apologize for that. As a team we pride ourselves on delivering the features that our developers need (such as the update to GetCustomerPaymentProfile in this release) and we do that under the principle that we not break existing integrations. Unfortunately we fell short of our own high standards for maintaining integrations this time but please know we will do our best to assure this does not happen again.
Brian
11-06-2015 02:10 PM - last edited on 11-06-2015 02:30 PM by RichardH
Thank you, Brian, for owning your part in this. I am a developer, and I make mistakes too. It's nice to hear you as a person accepting responsibility for the affect you have on other people. That is increasingly rare in corporate-speak and the internet of anonymity.
So thanks for stepping up!
Ray Humphrey
11-08-2015 05:11 AM
Thank you brian for the acknowledgement of the mistake, it is very unfortunate that it made it through production and it affected many businesses. The main use case for this functionality is for customers who frequently buys products or services.
For me he main fault is the lack of support. Including the lack of official documentation on the changes that was pushed throuh. Look at the parameters in the documentation its still the same http://www.authorize.net/content/dam/authorize/documents/CIM_XML_guide.pdf .
.
11-09-2015 09:04 AM
Are these changes currently also in the developer sandbox? From my initial testing it didn't look like they are.
Also is there currently any resolution plan being implemented?
11-09-2015 10:12 AM
Documentation for these changes are available in the API Reference. You can read more about recent changes in our blog post: https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/New-Customer-Profile-a...
Richard
11-09-2015 10:39 AM