test server wsdl errors

[treii28]

We have been getting what appear to be sporadic errors retrieving the WSDL from the sandbox server since early this morning. Is there a problem with the api test servers?

[RaynorC1emen7]

Which https?

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

[Lilith]

@treii28 Thank you for reporting this. We've received a couple more reports of similar issues, and we're investigating.

[Lilith]

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.

[igorkooo]

Hello,

Due to historical reasons, we are using AuthorizeSauce-0.4.1

When trying to create a payment profile, the call is failing using https://apitest.authorize.net/soap/v1/Service.asmx?WSDL and returning 403 Forbidden.

The same call worked, last time on March 9, 2016. using same setup.

The same call still works using production API: https://api.authorize.net/soap/v1/Service.asmx?WSDL

I tried to create new senbox account, but that one is having the same issue.

I tested that new account using provided python sample and it works just fine with sendbox configuration.

Was something changed / upgraded lately on Sendbox without having that done to production URL that might affect behaviour of my 3rd party libs ? 

Thank you

[RichardH]

@igorkooo I moved your post under this topic because they are the same issue.   

https://community.developer.authorize.net/t5/Integration-and-Testing/test-server-wsdl-errors/m-p/539...

Richard

[treii28]

similar but not identical, we were using 

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

(capital WSDL)

Not sure if that makes a difference. The errors actually helped me detect a problem in our live scripts where the PHP was trying to pick up the WSDL from the test api (using a default fall-back value in the code) before the connection credentials were set. I've since updated the live code to use a different fallback value so our live transactions are not failing when the WSDL cannot be retrieved at the start of the exchange, but now our testing ability is not functioning at all. (getting a Soap Fault after too many retries)

Of course, it has been so long since I have had to tinker with the test account, I'm not sure what credentials to use to check the status in the merchant screens on the sandbox. *groan*

[treii28]

Our current system was written relying on the existing WSDL set-up. While I can re-write the code to allow non-WSDL mode, it is at such a fundamental level of the SoapClient library, it would require a retest of the entire system.

However, for purposes of testing, I did a quick hack on a development box and ran some tests with the non-WSDL mode and now I get 'forbidden' as the SoapFault coming back using:

'location'        => "https://apitest.authorize.net/soap/v1/Service.asmx",  // service uri
'uri'             => "https://api.authorize.net/soap/v1/",                  // target namespace

I also tried saving a copy of the WSDL file itself and accessing it locally but got the same error as before. 

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

[Lilith]

@treii28 -- Regarding the local WSDL, was that with modifying the file so that oce-ex-cert-api.authorize.net is replaced with apitest.authorize.net?