Announcement

**graphicz** · 18-Aug-2015, 09:19 AM

I copied your address into Word Perfect then pasted it into SD: It displays OK here: http://www.graphicz.eu.com/smart/aca...More-Info.html

I have had this time to time with other things especially like double inverted commas that can be presented in a number of ways and when you paste them in they don't work until you have deleted them and re-entered them. It may not help you much but Word Perfect usually sorts it for me

**feemish** · 18-Aug-2015, 02:51 PM

Character encoding issues are causing problems for me too.

I recently had a call back failure from Realex due to this issue. The payment went through ok, but the order stayed in psp pending due to the failure. I dont check every payment with every order.. so this is a serious issue.. Taking money and not being alerted to an order! or a failure..

Initially Sellerdeck support suggested it was a 'temporary network error' until some investigation by Realex showed that their call back had been made.

I wouldnt let it lie and eventually Realex found this;

Code:

<html><title>SellerDeck Error</title><body><h1>Error reading prompt file (-1,24) {}.</h1>
<hr>Error reading prompt file (-1,25) {}.: Input contains invalid characters (Error 2).<hr>
Press the Browser back button and try again or contact the site owner.</body></html>

The problem was caused by;
�
& # 6 5 5 3 3 ; (no spaces but I cant even input it here!)

which is a '�'

Sellerdeck said;
"our encoding has not handled this character correctly and the subsequent '&' character which is correct and part of the calling sequence has tripped the script input validation process."

They have told me this is a 'bug' Bug (ref. PSP-540)

and their solution has alarmed me a little.
They want to edit the OCCRealexScriptTemplate file and remove all of this

# supply the cardholder's address details

Code:

AddPostValues ('&', 'SALUTATION', $::InvoiceContact{SALUTATION}, $OPTION, $REDIRECT);		# DETAILS REMOVED HERE
	AddPostValues ('&', 'NAME', $::InvoiceContact{NAME}, $ALWAYS, $REDIRECT);		
	AddPostValues ('&', 'JOBTITLE', $::InvoiceContact{JOBTITLE}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'COMPANY', $::InvoiceContact{COMPANY}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'ADDRESS1', $::InvoiceContact{ADDRESS1}, $ALWAYS, $REDIRECT);		
	AddPostValues ('&', 'ADDRESS2', $::InvoiceContact{ADDRESS2}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'ADDRESS3', $::InvoiceContact{ADDRESS3}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'ADDRESS4', $::InvoiceContact{ADDRESS4}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'COUNTRY', $::InvoiceContact{COUNTRY}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'PHONE', $::InvoiceContact{PHONE}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'FAX', $::InvoiceContact{FAX}, $OPTION, $REDIRECT);		
	AddPostValues ('&', 'EMAIL', $::InvoiceContact{EMAIL}, $ALWAYS, $NOENCODE);		
	#		
	# limit the buyer's postcode to 10 charcters		
	#		
	AddPostValues ('&', 'INVOICEPOSTCODE', substr($::InvoiceContact{POSTALCODE}, 0, 10), $ALWAYS, $REDIRECT);		
	#		
	# other fields		
	#		
	AddPostValues ('&', 'MOVINGCHECKSTATUS', $::InvoiceContact{MOVINGCHECKSTATUS}, $ALWAYS, $NOENCODE);		
	AddPostValues ('&', 'USERDEFINED', $::InvoiceContact{USERDEFINED}, $ALWAYS, $NOENCODE);

But surely Realex uses this to judge the fraud score for the transaction?

Announcement

Character encoding - accented characters

Character encoding - accented characters

Comment

Comment