topic Re: test server wsdl errors in Integration and Testing

test server wsdl errors

treii28 — Fri, 11 Mar 2016 20:33:23 GMT

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?

Re: test server wsdl errors

RaynorC1emen7 — Fri, 11 Mar 2016 20:40:35 GMT

Which https?

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

Re: test server wsdl errors

Lilith — Fri, 11 Mar 2016 21:06:19 GMT

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

Re: test server wsdl errors

Lilith — Fri, 11 Mar 2016 23:58:54 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.

Getting 403 Forbidden with AuthorizeSauce-0.4.1 over https://apitest.authorize.net/soap/v1/Service.a

igorkooo — Tue, 15 Mar 2016 17:40:00 GMT

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

Re: Getting 403 Forbidden with AuthorizeSauce-0.4.1 over https://apitest.authorize.net/soap/v1/Servi

RichardH — Tue, 15 Mar 2016 18:16:15 GMT

@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/53972#M29040

Richard

Re: test server wsdl errors

treii28 — Wed, 16 Mar 2016 17:51:42 GMT

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*

Re: test server wsdl errors

treii28 — Wed, 16 Mar 2016 21:57:50 GMT

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.

Re: test server wsdl errors

Lilith — Thu, 17 Mar 2016 21:39:14 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: test server wsdl errors

Lilith — Thu, 17 Mar 2016 21:40:57 GMT

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