topic Re: sandbox wsdl oce-ex-cert-api nxdomain in Integration and Testing

sandbox wsdl oce-ex-cert-api nxdomain

kcartmell — Fri, 11 Mar 2016 16:31:31 GMT

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.

Re: sandbox wsdl oce-ex-cert-api nxdomain

RaynorC1emen7 — Fri, 11 Mar 2016 16:42:07 GMT

Why not use the https://apitest.authorize.net/soap/v1/Service.asmx

Re: sandbox wsdl oce-ex-cert-api nxdomain

kcartmell — Fri, 11 Mar 2016 16:56:02 GMT

Ahh, good point. The apitest host is probably what should be specified in the WSDL. I feed the WSDL directly into my SOAP client to teach it how to interact with the service. I can override the service address but it sure would be nice if the address in the WSDL was correct.

Re: sandbox wsdl oce-ex-cert-api nxdomain

Lilith — Fri, 11 Mar 2016 21:09:51 GMT

@kcartmell Thanks for reporting this. We're actively investigating the issue now.

I apologize for the response you got from Merchant Support. It is true that issues with Sandbox should be handled by the Developer Support team and the Developer Community, since Developer Support has more direct resources for supporting the Sandbox environment. But we definitely shouldn't be telling anyone their issue is "too detailed." Speaking personally, I'd rather have more details than less. I'll have this looked into.

Re: sandbox wsdl oce-ex-cert-api nxdomain

kcartmell — Fri, 11 Mar 2016 21:34:28 GMT

Thanks @Lilith!

Re: sandbox wsdl oce-ex-cert-api nxdomain

Lilith — Fri, 11 Mar 2016 23:58:21 GMT

We believe we identified the issue and are working on a fix that we anticipate will be released early next week. We can't commit on a firm date yet but we are eager to fix this as soon as possible.

In the meantime, if possible, directly post your Sandbox SOAP requests to https://apitest.authorize.net/soap/v1/Service.asmx rather than depending on the WSDL service definition.

Thanks.

Re: sandbox wsdl oce-ex-cert-api nxdomain

mitesh — Mon, 14 Mar 2016 12:05:23 GMT

the issue is still running for me .. have u able to get any decent solution to the problem .. please post if so .. thanks

@kcartmell wrote:
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.

Re: sandbox wsdl oce-ex-cert-api nxdomain

mikehil — Mon, 14 Mar 2016 15:52:36 GMT

Is there an update on the target date for this fix? This is highly impactful for our test team

Re: sandbox wsdl oce-ex-cert-api nxdomain

Lilith — Mon, 14 Mar 2016 16:05:36 GMT

I don't have a specific date, but we're pushing for a fix early this week. I'll make an update once I have a firm date.

Re: sandbox wsdl oce-ex-cert-api nxdomain

kcartmell — Mon, 14 Mar 2016 21:37:31 GMT

@mitesh @mikehil

Your SOAP client libraries almost certainly provide facilities to consume a WSDL but specify a service endpoint other than what was found within the WSDL itself. It is probably wise to tie this to an optional external configuration item for future instances of this class of problem.

As @RaynorC1emen7 observed, overriding the erroneous WSDL service endpoint with https://apitest.authorize.net/soap/v1/Service.asmx will return your test environments to full functionality.

Re: sandbox wsdl oce-ex-cert-api nxdomain

valkolovos — Mon, 14 Mar 2016 22:34:48 GMT

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.

Re: sandbox wsdl oce-ex-cert-api nxdomain

valkolovos — Wed, 16 Mar 2016 02:54:09 GMT

Any status on this?

Re: sandbox wsdl oce-ex-cert-api nxdomain

pwilliams — Wed, 16 Mar 2016 13:33:24 GMT

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

Re: sandbox wsdl oce-ex-cert-api nxdomain

Lilith — Thu, 17 Mar 2016 21:37:58 GMT

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.

Re: sandbox wsdl oce-ex-cert-api nxdomain

dbenedetto — Mon, 21 Mar 2016 01:45:25 GMT

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>

Re: sandbox wsdl oce-ex-cert-api nxdomain

briang — Mon, 21 Mar 2016 16:58:44 GMT

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

Re: sandbox wsdl oce-ex-cert-api nxdomain

kcartmell — Mon, 21 Mar 2016 20:44:44 GMT

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

Re: sandbox wsdl oce-ex-cert-api nxdomain

nealpatel588 — Mon, 21 Mar 2016 22:15:26 GMT

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!

Re: sandbox wsdl oce-ex-cert-api nxdomain

nealpatel588 — Tue, 22 Mar 2016 03:02:08 GMT

@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.

Re: sandbox wsdl oce-ex-cert-api nxdomain

dbenedetto — Thu, 24 Mar 2016 04:54:26 GMT

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?