Testing locally AcceptHosted

[tomtichy410]

Hi,

How does one test AcceptHosted solution locally?

I am having problems passing url with `localhost` in it to Authorize.Net whether inside hostedPaymentReturnOptions, or hostedPaymentIFrameCommunicatorUrl

the back responds with E00013:Invalid Setting Value. hostedPaymentIFrameCommunicatorUrlurl: must begin with https://

The message is misleading, because it doesn't care about https. It does care about localhost.

I guess I could edit hosts file and setup a fake domain. But that's not a great solution.

Any ideas?

[JeffGTech]

It doesn't support 'localhost' anymore as far as I know. I ended up doing what you did with fake domain. If you want to test the iFrameCommunicator with it, then it's better to actually use a static hosting service like S3 with AWS. 

[tomtichy410]

Thanks. Fake domain brought a host of other issues. 

So I ended up just using http://127.0.0.1:3000 for the URL. Because that passes aNet's url validation.

<sarcasm>Great developer experience</sarcasm>

[JeffGTech]

Haha, I didn't think of using just the loopback IP address instead of localhost. Good find, but really silly that localhost is blocked. Be aware though, that I ran into some issues with the iFrame closing properly when it can't fetch the iFrameCommunicator.html if you're using it. Probably just the React lib I was using, but something to watch out for. 

[jhoney12]

Oh, interestingly, it didn't occur to me to utilize the loopback IP address instead of localhost. It's a clever discovery, although it seems a bit absurd that localhost is restricted. However, I did encounter some challenges with the iFrame closure when it couldn't fetch the iFrameCommunicator.html, especially if you're utilizing it. It might be related to the React library I was working with, so just a heads-up on that potential issue.

[tomtichy410]

Yeah, I've had some strange issues with the iFrameCommunicator as well. Usually hard refresh does the trick. I can live with that working locally.

[seed]

"Facing challenges testing AcceptHosted solution locally due to issues with passing URLs containing 'localhost' to Authorize.Net. Error message indicates 'https://' requirement, but the real issue is with 'localhost'. Editing hosts file for a fake domain is a workaround, but seeking alternative solutions for smoother testing process. Any suggestions or insights appreciated."

[locateparcels]

I ran into a similar issue while testing locally — especially with URLs being rejected just because they included localhost. Using the loopback IP worked for me too. When I was debugging return callbacks, I kept checking the status flow the same way I usually verify shipment events on tracking tools like locateparcels.com, just to make sure everything lined up properly. Might help others who are trying to confirm whether redirects are behaving consistently.