Yesterday I came across a very strange zen cart failure. What happened was that on a dev site the payment options JavaScript validation was broken and the payment selection form was submitted without any checking.

Now, that is not that bad – I am sure that will happen in real live quite often. However, the page I was redirected to was completely broken (blank).

The url looked something like this:

index.php?main_page=checkout_payment&payment_error=usaepay_api&error=The+credit+card+number+starting+with++was+not+entered+correctly,+or+we+do+not+accept+that+kind+of+card.+Please+try+again+or+use+another+credit+card.&usaepay_api_cc_owner=me&usaepay_api_cc_expires_month=01&usaepay_api_cc_expires_year=10


As you can easily see from the url, the selected payment module was USA ePay but other modules will be affected too.  After some digging I noticed a strange response header: 406 Not Acceptable.

And soon enough I found that in application_top.php a very long list of $GET parameters is checked for urls and also length. Turns out that the allowed max. length is not 42 or 44, but exactly 43. Not sure why 43 is more secure than 44, but that is beside the point.

Does this mean it is not advisable to use those parameters as all? I don’t know, but on the other hand putting error messages into the url is not really necessary anyway.

Either way, something to be aware of and keep in mind should you ever have unexpected blank pages after a redirect…