sandbox wsdl oce-ex-cert-api nxdomain

[kcartmell]

I'm doing SOAP authorize.net things in the sandbox environment.

There's a document that tells me how to do that.

There is a (poorly indicated) WSDL specified in that document.

That WSDL specifies a service address: https://oce-ex-cert-api.authorize.net/soap/v1/Service.asmx

This has all worked flawlessly since December when I first integrated authorize.net. Yesterday I noticed that I couldn't transact in the sandbox any longer and a DNS error appears in my logs.

When I perform a DNS lookup on oce-ex-cert-api.authorize.net I receive an NXDOMAIN error message, which indicates that the domain requested does not exist.

I contacted Authorize.net support directly and was informed that this issue is "too detailed" and that I should use these forums to address the issue. I additionally emailed developer@authorize.net yesterday but haven't heard back yet.

Any assistance would be greatly appreciated.

[valkolovos]

This is really not a valid solution. Not all SOAP libraries (certainly not the one we're using) make this easy or even possible. We've found a temporary workaround, but it's hacky at best.

Please let us know when you have a fix in place.

[valkolovos]

Any status on this?

[pwilliams]

My test environments (which are many) are also impacted by this issue.  What is the status on fixing the endpoint (address) in the WSDL?

[Lilith]

Thank you all for your patience.

Upon further review, the dynamic WSDL generation on our end is being impacted by system changes we are making to support future improvements. Unfortunately, there is not a quick fix to this situation.

We are actively working on a fix, but will not be able to release it as quickly as we had hoped.

In the meantime, we recommend that developers needing an updated WSDL directly download the WSDL, manually replace all occurences of "oce-ex-cert-api" with "apitest", and point your SOAP instance at the manually updated WSDL.

I am looking into whether we can provide a temporary static WSDL with the changes made for you, but it would still need to be downloaded, and your SOAP instance pointed at that.

We will make a further announcement once the permanent fix has been released, at which point you may return to pointing at the dynamic WSDL we host.

[dbenedetto]

I'm using python package authorizeSauce and it's retrieving the URL from:

https://apitest.authorize.net/soap/v1/Service.asmx?WSDL

dynamically with every request. It's not conventional to update a python library package especially when it's a bug.

This address is providing the invalid url in it in the wsdl definitions:

<wsdl:service name="Service"><wsdl:port name="ServiceSoap" binding="tns:ServiceSoap"><soap:address location="https://oce-ex-cert-api.authorize.net/soap/v1/Service.asmx"/></wsdl:port><wsdl:port name="ServiceSoap12" binding="tns:ServiceSoap12"><soap12:address location="https://oce-ex-cert-api.authorize.net/soap/v1/Service.asmx"/></wsdl:port></wsdl:service>

[briang]

I am also using AuthorizeSauce... I am stuck until this is resolved. 

[kcartmell]

You could make a temporary hosts file entry on the affected servers.

[nealpatel588]

I added an entry to my host file on effected servers, and that didn't help, either.  Authorize.net, please fix this ASAP!  We are all in a bind here!

[nealpatel588]

@Lilith - any update here from the authorize.net team?  My dev QA team is at a standstill right now.  This is becoming quite costly for us, and I'm certain it is costing your other customers company as well.

[dbenedetto]

I too am awaiting a fix and an updated response from the authorize.net dev team. You said on 3-11 it would be coming next week and here it is 2 weeks later. Bump this up in priority please!

Or maybe it's time to find another card processing company. It's a competitive market. I'm not experiencing good service.

Is it possible to put a redirect on the old subdomain URL until you fix the wsdl file URL definitions?