Sudden case of Missing or invalid token

[DAL07]

Hi all.

We've been using the getHostedPaymentPageRequest/Response with a redirect to https://accept.authorize.net/payment/payment for years now with overall success and reliability. Last Thursday November 7th the payment page started failing with a message "Missing or Invalid token" on every single transaction request. We haven't changed anything in our code that calls all of this nor have we had any upgrades to the application itself. We do get a token back successfully but it's on the redirect to the form where we seem to have an issue. On discovering this was happening we attempted this in our test environment to the auth.net sandbox and the same is occurring there. We acknowledge that something else might have changed on our end to cause an issue with how the token is being received and/or passed back out (or something else?) but none of our extensive troubleshooting has gotten us close to a resolution nor has my ticket with authorize.net support where I get very little contact or details.

I realize this is a shot in the dark because of the large number of variables that could be at play here but I'm wondering if anyone else has experienced this or could provide any ideas at all on what might have caused this or what to look for. We've been down for days now and could use any help anyone might provide.

Thanks in advance,

Debi

[dipespat]

Hi Debi, 

We have try to repro at our end but, I could not able to repro. Could you please provide more details with sample payload (stripping out the sensitive data) that you are sending.  This will help us to troubleshoot the issues. 

Thank you,

Dipesh

[DAL07]

Hello

We solved this after I sent the message and I'm just getting back to this update. I wanted to provide our solution for anyone else that runs across this and is stuck. Unfortunately what we discovered is that the HTML we were sending had the end tag for one of the lines in the wrong location. How it ever worked to begin with let alone for years that way I cannot explain. Something must have changed somewhere down the line in November that caused a stricter validation of the HTML and highlighted this issue for us.