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.

[RaynorC1emen7]

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

[kcartmell]

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.

[Lilith]

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

[kcartmell]

Thanks @Lilith!

[Lilith · Accepted solution]

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.

[mitesh]

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.

---

---

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

---

[mikehil]

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

[Lilith]

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.

[kcartmell]

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