Bug / Warning. Unclosed tag can prevent transfer to PSP in Chrome and Safari.

[NormanRouxel]

Scenario: Using Chrome or Safari browsers on a V10 site, the "Confirm" button that transfers you to the external PSP seems to do nothing. Sage and PayPal were affected but probably all external PSP's will be. Other browsers are OK.

Cause: Amazingly, the layouts had been tweaked and a single <strong> tag without a matching </strong> tag in the left hand nav was the cause.

Technical info: Seems that the AJAX code used to fetch the PSP page is very sensitive to errors in the DOM and the return statement marked in red in the following code in function GetPSPFormAndSubmit in actinicextras.js was executed, abandoning the submit.

function GetPSPFormAndSubmit(nPaymentMethod)
	{
	var ajaxRequest = new ajaxObject(document.location.href.split('?')[0]);
	ajaxRequest.callback = function (responseText) 
		{
		if (responseText.substring(0, 6) == "Error:")
			{
			alert(responseText);
			var elemConfirmOrder = document.getElementById("idBtnConfirm");
			if (elemConfirmOrder)
				{
				elemConfirmOrder.value = g_sConfirmOrderInitText;
				}
			return;
			}
		//
		// Get the placeholder span for the PSP form
		//
		var elemSpanPSPForm = document.getElementById("idSpanPSPForm");
		if (!elemSpanPSPForm)
			{
			return;
			}
		elemSpanPSPForm.innerHTML = responseText;
		//
		// Get the PSP form
		//
		var elemPSPForm = document.getElementById("idPSPForm");
		if (!elemPSPForm)
			{
			return;
			}
		//
		// Submit the PSP form
		//
		elemPSPForm.submit();
		}
	var sParams = "ACTION=GETPSPFORM&PAYMENTMETHOD=" + nPaymentMethod;
	var elemPONumber = document.getElementsByName('PAYMENTPONO');
	if (elemPONumber.length)
		{
		sParams += '&PAYMENTPONO=' + escape(elemPONumber[0].value);
		}
	var elemPayUserDef = document.getElementsByName('PAYMENTUSERDEFINED');
	if (elemPayUserDef.length)
		{
		sParams += '&PAYMENTUSERDEFINED=' + escape(elemPayUserDef[0].value);
		}
	ajaxRequest.update(sParams, "GET");
	}

[kakshaks]

Just for clarity - are you saying this problem would only be encountered if you, for example, opended a strong without closing or is the error being hit right now in everyones default code.
Thx

[NormanRouxel]

Error isn't in default layouts. It only happens if an error is made in tweaking them. Even then it's hard to cause, but I've definitely seen it happen and am posting this to save others the huge amount of time it took me to diagnose the problem and find the reason.

I've amended my original post to make it clearer that there's nothing to worry about with original layouts.

[NormanRouxel]

If anyone is experiencing a similar problem and wants to determine if this bug is causing it then try the following:-

Edit actinicextras.js in your Site folder and look for:

		if (!elemPSPForm)
			{
			return;
			}

Temporarily change it to:

		if (!elemPSPForm)
			{
			alert('Chrome / Safari quirk');
			return;
			}

Update your site and try the checkout. If you see an alert message "Chrome / Safari quirk" when the Confirm button is clicked then you've got this threads problem.

[David Clarke]

Although this thread is old it has just solved a problem I had in Sellerdeck 2013. the problem occurred both with Chrome and internet explorer 10.

As I am not a web coding person and know nothing about java so when I read the original post I read it incorrectly. I assumed that the problem that was being explained was in the large bit of code in the middle of the page. It wasn't. The error that was causing the problem was on my checkout page 3 design.

I looked through that page at the parts I had changed and did find I had missed a </font> in one place. When I put this right internet explorer and Chrome now get to the basket again.

I am not complaining just writing this so that anyone else with the problem who is as thick as me does not waste time cutting and pasting code in the actinicextras.js file.

[Mike Hughes]

Norman to the rescue again.

Having edited a header message that appears on every page on my site I went away for my day off to be suprised how few orders were coming in.

On returning I've find a huge number of unpaid orders, with most having tried five or six times to pay.

It turns out I had left a <b> tag open in the header message and this had buggered up the submit form as described by Norman.

Oddly, the Alert didn't appear after making the javascript edit but I knew from the description of the problem that it had to be that edit I'd made to header text.

So thanks Norman.

Now off to email the customers who had problems and couldn't order.

Mike

PS. This was on V11.0.5 and the problem was showing in both IE and Chrome

[scottish]

SagePay Link Failures

Customers to http://www.scotsmeat.com have recently reported failures with a link to SagePay when placing orders on iPads. The most recent instance was a customer using a double underscore in her email address but other instances look like examples of the issue highlighted in this thread.

I have looked at html validators but see differing results and, not being a coding expert, I do not really understand. The site design was produced by John Higgins (Bikster) so sadly I can't ask him to help.

Can anyone point me in the right direction to identify and solve the issue?

Thanks

Bernie

[Mike Hughes]

I think you have a different problem.

I just tried a test order and got as far as sagepay where I got this message.

MALFORMED

Status Detail: 3109 : The BillingFirstnames field is required.

You could search the forum for solutions as this has come up before but if you still have problems you should think about starting a new thread on the forum as the issue you have doesn't seem to be related to the problem this thread is about.

Mike

[scottish]

Thanks for the prompt response Mike. I can see the test order that you placed and the 'payment' failure; test orders through IE and Chrome have all successfully reached SagePay. The customers who reported failures didn't get the Malformed message that you got - they said it was 'gobblegook'.

Was it an iPad that you used? I will get someone else to do a test order through this route and, unless anything appears obvious, will post a separate new thread.

Regards

Bernie

[Mike Hughes]

Was it an iPad that you used?

No, This was Google Chrome on windows 7.

The problem on this thread relating to the unclosed tag isn't device specific (AFAIK) and leads to no response at all when the 'confirm' button is clicked.

Having experienced this problem myself what you're seeing sounds to me like something very different.

Mike

PS. I do wonder if the problem I received could have been due to just using a single name 'test' for the test order rather than 'test test'. I would try to see but don't want to waste your time with test orders.

[Mike Hughes]

I've tested using safari on an Iphone and with multiple words in the name I got through to sagepay without any problems.

If you don't mind more testing I can try with chrome on an ipad and also with single / multiple words in the name field but at the moment there's not much sign of anything else wrong with the checkout.

Mike

[scottish]

Thanks again for your help Mike - the test order with the fuller name format came through OK along with the standard SagePay notification of customer payment abort. I would be grateful for your further tests.

The problem is odd because nothing has been changed on the website. If not the issue highlighted at the original start to this thread, I was wondering if it was related to the V3 upgrade at SagePay. At least the bulk of orders are getting through and the order completion failures allow us to contact the potential customer.

Best wishes

Bernie

[Mike Hughes]

OK. Here's what I've found using safari on the ipad.

If I use just a single word entry for the name field then I get the same sagepay error as before except the ipad doesn't parse the error html code and just displays the full html text. Probably what a typical customer would call gobbledegook.

If I enter two words in the name field then it goes through to sagepay fine.

You could see if this is consistent with your problem orders by looking at the name the customer has entered. if it is then that gives us an area to look at in detail.

It's probably a good idea to get this tied down soon as the sagepay v3 integration is in beta now ready for release before the July 31st deadline.

I have seen several orders come in myself recently with just a single name entered. I think this is mostly people using autocomplete to fill in the data.

[scottish]

Mike, the most recent instances of failed links to SagePay have included customers using a single name but one was a full name. I have changed the text on checkout to show that the full name is required and have added the option to request a phone call.

I will continue to monitor the situation. Your responses have been most helpful.

Thanks

Bernie

[Mike Hughes]

a quick look at the previous occurence of this suggests that the sellerdeck script defaults to a blank first name if it can't find two parts to it.

This would be dead easy to change but I suggest you report it to sellerdeck as a bug as:

1. they might already have fixed it.
2. they can make sure the fix is included in the new update if needed
3. if we do it outside of sellerdeck then it needs redoing after every update

Mike