cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Hosted localhost testing E00013 Invalid Setting Value. hostedPaymentIFrameCommunicatorUrlurl:

When calling https://apitest.authorize.net/xml/v1/request.api with a getHostedPaymentPageRequest body with hostedPaymentIFrameCommunicatorUrl of https://localhost:3010/IFrameCommunicator.html I'm receiving an error code 

E00013 with text "Invalid Setting Value. hostedPaymentIFrameCommunicatorUrlurl: must begin with https://."
 
The setting very much starts with https. If the url is changed to https://127.0.0.1:3010/IframeCommunicator.html the call is successful. However we unable to use the loopback IP due to other considerations within our app. This was working and seems to have started to return this error within the last few days. 
starbuckbt
Member
4 REPLIES 4

We are also having the same problem in our project. Code that was working a few weeks ago is now failing without any significant/related changes on our end. Any traction on this would be greatly appreciated.

luislecaro
Member

Actually in our case the problem was a little different. We were using the same domain in the iframe communicator URL as the app uses, but the iframe communicator URL has a query string on it that included the caret (^) character. That had been used as a delimiter between two values (because they don't allow the ampersand, so we only included one named value in the query string). The caret character was being URL encoded, but it still triggered an error using the new checks (it had been working for six years prior to this). We ended up changing the encoding used by the value in the query string to get around this.

rcourtois
Member

We are additionally having a similar issue in our venture. Code that was working half a month prior is presently coming up short with next to no huge/related changes on our end. Any footing on this sounds incredibly valuable, really.

honey010
Member

The caret character was being URL encoded, but it still triggered an error using the new checks (it had been working for six years prior to this). We ended up changing the encoding used by the value in the query string to get around this.

zeastom
Member