PayPal error page

[Paddington Bear]

Hi there,

I have recently done the approved thing (some of you may remember my arguments against switching) and switched to Actinic Payments for my payments processing.

I have Business v9 and was using PayPal Pro.
Now I have switched it to Actinic Payments and that all works.
I have left the option in for basic PayPal though, for those who wish to use it.

Now, the Actinic Payments orders work fine, but the PayPal orders, once processed, don't return to the website with a confirmation. The emails are sent, and the money is taken, but the page that comes up is as follows:

A General Script Error Occurred

Error: Bad input string "SEQUENCE=3&ACTION=Finish&ORDERNUMBER=PB21JG10000046&REFPAGE=http%3a%2f%2fwww%2eursulajames%2ecom%2facatalog%2ftest%2facatalog%2fcds%2ehtml&&tx=8TN5578479300013W&st=Completed&amt=16.00&cc=GBP&cm=&item_number=PB21JG10000046". Argument count 20.

Press the Browser back button and try again or contact the site owner.

This is all in test, I haven't rolled it into production yet.
I have done a full refresh, to no avail.

Any advice would be greatly appreciated.

[Paddington Bear]

Actinic generates the error

Okay, I've discovered that the error message above is generated by PayPal, as the 'bad string' is in the following URL, that generates the error:

http://www.ursulajames.com/cgi-bin/o...PB21JG10000048

(You may need to get clever to see the whole URL)

Does this information mean anyone can help?

[Paddington Bear]

Resolution

In case anyone else ever has this problem, here is the resolution:

This error occured because PayPal expects you to turn Auto Return and PDT on to use their website services, but Actinic needs them to be off.

Therefore, when I contacted PayPal they said I was fine.

Actinic got me to turn PDT off and Auto Return off, then it was fixed.

Note however, that this may lead you to a new problem discussed here:
http://community.actinic.com/showthread.php?t=47541

Fortunately, the solution is there too.

[zigzagad]

I've been having real problems with these errors when trying to come up with a PCI-DSS integration of Website Payments Pro Hosted Solution.

I've worked out that the error is caused by an extra ampersand in the query string generated:

..&&tx=1ME0906158522460U..

If you manually remove one of them and hit return you get forwarded on to the receipt page correctly.

I've no idea at the moment how to resolve this however.

[Mike Hughes]

That's interesting.

It certainly looks like there should only be one & in that part of the string.

This will most likely be a problem in the perl scripts. It shouldn't be too hard to find where the extra & is coming from.

Mike

[zigzagad]

I wondered if 'tx' was something to do with paypals transaction number, and it was the paypal system that was adding the extra ampersand?

[Mike Hughes]

I think you're right. That does look like a paypal generated bit doesn't it.

Which only leaves us the option of going back to PayPal and getting them to look at it. Perhaps Actinic will pick this up and get in touch with PayPal.

Mods: Can you raise this with Actinic and get them to take a look. It might be something they can get Paypal to investigate or provide a workaround for. Presumably it should be possible to parse the return string and remove any double &s if they occur.

Mike

DONE

[zigzagad]

I'm all over this at the moment, I've been in contact with an integration specialist at PayPal who says:

"regarding the return URL, I confirm tx is the transaction ID assigned by PayPal and in your return URL there is an extra ampersand. Please check how your application builds up the URL to see where the second ampersand is generated and, if necessary, you can change the URL by removing the second ampersand dynamically."

It looks to me as if the problem might be in one of the perl scripts somewhere, but I can't work out where the final url is built at the moment.

[zigzagad]

Got it I think!

os000001.pl, line number 6131:

"&ORDERNUMBER=$::sOrderNumber&REFPAGE=" . $sRefPage . "&";

amended to:

"&ORDERNUMBER=$::sOrderNumber&REFPAGE=" . $sRefPage . "";

removes the extra ampersand and now passes straight to the receipt page

[Mike Hughes]

Excellent. It does look like the culprit as it looks as if the other value names have the & already assigned to them.

You might need to edit the OrderScript.pl file for the change to remain. I think the os000001.pl file is generated from that.

Mike

[zigzagad]

You might need to edit the OrderScript.pl file for the change to remain. I think the os000001.pl file is generated from that.

Thanks Mike, I'd just worked that one out actually

The good news I seem to have a PCI-DSS compliant solution using PayPal Website Payments Pro Hosted Solution, I'm just about to document it all for myself and will try and get it posted here asap.

[Mike Hughes]

Excellent.

It sounds as if you've found one of the paypal problems that's been plaguing people for a while. I wonder if this helps sort out some of the paypal problems (and strange solutions) that we've been seeing.

Mike

[Paddington Bear]

Yes!!!

Indeed you are right.

Can other posts about this problem be directed here?