Accept Hosted Payment form token not getting generated

[AshwiniMetasys]

I am using sandbox account and mode is set to live for account. I am using accept hosted payment form, implemented form using iframe as per given examples from Authorize.net accept hosted example web page. Code was working smoothly till yesterday  suddenly from today morning token is not getting generated for accept hosted payment form. 

It is giving error E00013:Invalid Setting Value. hostedPaymentIFrameCommunicatorUrlurl: must begin with https://.

Below given is screenshot how i am passing setting value to generate token  

For hostedPaymentIFrameCommunicatorUrl settings i am also using same url in api call for accept hosted customer profile save page, there token is generated properly and showing UI in iframe.
Only accept hosted payment is broken.

Please help me with this issue urgently.

[markflores]

I'm having the same issue with another setting parameter: 

{"code":"E00013","text":"Invalid Setting Value. hostedPaymentReturnOptionsurl must begin with http:\/\/ or https:\/\/."}

The url contains `;` characters. After removing them the request goes through without errors.
But then, I can see that the character `&` triggers other error on the payment page.
It would be interesting to know if this is happening for live environment since I'm using a sandbox account as well.

Can I get someone's help on this?
Thanks

[danfbach1]

I've opened a similar ticket here. https://community.developer.cybersource.com/t5/Integration-and-Testing/Authorize-net-Accept-js-Hoste... 

Yes, it is happening in the Production environment.

My return links use a generated hash parameter in order to securely redirect customers to the proper pages...so until they provide a list of invalid characters, i expect my implementation will now fail 9/10 times - after having been built and fully operational for several years.

That said, I've disabled my hosted payment option for authorize and am using stripe's hosted payment page for now.

Until they can fix the bug, or provide actual clarification, I will consider it "broken."

[kreynen-cu]

We're seeing the same thing.

[jaquingcara604]

Having the exact same issue. Started the exact same day. Auth.Net support are saying to check the values sent. The property values have not changed and are still valid. Have you received any assistance?

[jaquingcara604]

Yes, found the same issue. Authorize.Net does not work with Angular routing parameters anymore (as of Thursday). 

Need this fixed ASAP.

[VeraciTek]

Hi anyone that visits this thread (we'll try to update all the threads we're aware of). We had this problem and just resolved it. Here are some tips:

1. localhost is NO LONGER ALLOWED, that is not in the error, but it produces that error.
2. the errors are stacked in an array. so look at all of them, not just one of them like we were.

The 2nd above was our issue, we assumed wrongly that the hostedPaymentIFrameCommunicatorUrlurl error would not be on the stack if it were not an issue. It was fine... but our hostedPaymentReturnOptions setting was not fine. We didn't use that setting for anything and just had some static relative urls in that setting. As soon as we corrected that it worked again.

The disabling of localhost has thrown a monkey wrench for developers that requires creating bogus local dns settings that are not localhost as well as issuing certs for those. So if you're using webpack, or anything that automatically generates a localhost cert, you're going to have to work around it with the 12/7 update. I sure hope we're solving some big vulnerability here with the localhost issue because this sure won't be convenient.

[chauffeuurr]

Having the exact same issue. 

[AshwiniMetasys]

No i did not received any reply from support team, is there any helpline contact no?

[CCruzWCB]

Having the same issue - I cannot do local testing because using a "localhost" in the address causes the request to fail.  Between this and the unresolved "processing" bug, I'm about to tear this module out of my company's project and switch to another processor.