cancel
Showing results for 
Search instead for 
Did you mean: 

Testing locally AcceptHosted

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?

tomtichy410
Member
6 REPLIES 6

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. 

JeffGTech
Member

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>

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. 

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.

jhoney12
Member

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.

tomtichy410
Member

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

seed
Member