cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Recent changes to url validation for Accept?

On Wednesday at ~6:30PM MST we started getting E00013 errors about `Invalid Setting Value. hostedPaymentReturnOptionsurl must begin with http:// or https://`.

We haven't made any code or configuration changes to this application or its stack, so this is confusing. 

We are JSON encoding the URLs. What were passing looks like https:\/\/[URL]\/cart\/authnet_accept\/complete\/125280\/authnet_accept%7Ccommerce_payment_authnet_accept\/639345e3731cb4.71919701\/tYB_Ivn7GSu-BkenNc5KmCv4rCQ8H_GUhQVVlNUkg5M

This application has been running for years and there is nothing in the Authorize.net change logs about changes to the URL validation.

kreynen-cu
Member
9 REPLIES 9

Having the exact same issue. All started Wednesday night or Thursday morning. 

No transactions have processed for the client due to the token not generating.

We've confirmed that Authorize did deploy an update on 12/7 that "improved URL validation". No explanation about why https://developer.authorize.net/api/changes.html wasn't updated? 

No explanation about how to POST a URL as JSON that isn't encoded. 

I should have spent more time looking at the other posts before creating my own. https://community.developer.cybersource.com/t5/Integration-and-Testing/Authorize-net-Accept-js-Hoste... and https://community.developer.cybersource.com/t5/Integration-and-Testing/Accept-Hosted-Payment-form-to... are both describing the same issue we are seeing. 

kreynen-cu
Member

I've confirmed that while the Angular URL param style ";" is not passing validation, the basic query params style does pass ("?" + "&").

However.... the rendered page is basically empty other than the page title "Order Summary". 

Same issue for us. Working fine for years, then on 12/7  when we go from our site to the a.net hosted order page, get a white page with "Missing or invalid token". Our JSON matches up with what is required in their documentation. Last successful order placed 12/7 at 4:50 PM PST. We did once get the same error, but it cleared up on it's own in an hour. Filled out their integration template, and added to our support ticket to escalate. Level 1 support mentioned "recent changes" but couldn't detail what or when, only to check for invalid characters being passed.

Quisp034
Member

We were able to push a fix for our issue today. The way Authorize.net handled this is beyond unprofessional and we're actively evaluating new payment processors as a result, but I wanted to close the loop for anyone who finds this thread. As I already indicated, we had been JSON encoding in PHP of our URLs in the POST for years without issue. Adding the

JSON_UNESCAPED_SLASHES option to the json_encode functions changed the https:\/\/[URL]\/cart, but we were still getting the E00013 error. In addition to the https://, Authorize.net's API is now also rejecting URLs that include a URL encoded | (pipe). 

Our code was converting | to %7C. This functionality is part of the Drupal 7 Commerce solution still used by 27K sites. The | is exploded in https://git.drupalcode.org/project/commerce/-/blob/7.x-1.x/modules/payment/commerce_payment.module#L... so I had to rewrite that code as well.

%7C had been and still should be been a completely valid URL, but Authorize.net decided to change that on 12/7 without any advanced communication or even acknowledging the change on https://developer.authorize.net/api/changes.html.

Hope this helps someone.
kreynen-cu
Member

Upon further investigation, I was able to confirm that while the Angular URL param style , ";" is not passing validation, the basic query params style ("?" + "&") does pass validation.

Despite this, however, other than the page title "Or" on the rendered page, the rendered page is basically empty.

Naaz2
Member

Thanks for posting your findings. I also use Drupal Commerce. I found I was already outputting the pipe as %7C but still getting the same error. I finally found it would work correctly when I encoded it again so the final url included %257C. The encoding for a percent sign is %25 so the working solution is double-encoded. 

Same issue for us. Working fine for years, then on 12/7  when we go from our site to the a.net hosted order page, get a white page with "Missing or invalid token". 

dealycont
Member