Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

E-Commerce Modules /

Discuss about the various e-commerce modules available:
Ecommerce, SS Shop, SilverCart and SwipeStripe
Alternatively, have a look the shared mailinglist.

Moderators: martimiz, Nicolaas, Sean, frankmullenger, biapar, Willr, Ingo, Jedateach, swaiba


Go to End

10 Posts   3211 Views


Community Member, 501 Posts

10 November 2009 at 8:43am

I'm trying to get the trunk Payment module working on Paypal, with trunk e-commerce.

However there seems to be an issue with the AuthorisationCode, I cannot find anything in the code that sets this.

On the PayPalForm it's put as:

$inputs['custom'] = $this->ID . '-' . $this->AuthorisationCode;

which is always like '5-'.

Paypal returns this, but in the 'complete' method of the handler this is checked:

if(isset($_REQUEST['custom']) && $custom = $_REQUEST['custom']) {
$params = explode('-', $custom);
if(count($params) == 2) {
if($payment = DataObject::get_by_id('PayPalPayment', $params[0])) {
if($payment->AuthorisationCode == $params[1]) {

But, as $params[1] is never set, nothing of this ever happens and I get errors.

Anything I'm missing here?

Someone on IRC apparently had this problem as well and changed the code, set the AuthorisationCode on the form as the order uid:

$this->AuthorisationCode = $order->UID;

However, what is the real purpose of AuthorisationCode? I cannot see it working as currently implemented in trunk?


Community Member, 247 Posts

10 November 2009 at 12:35pm

Edited: 10/11/2009 12:39pm

Hi Dio5,

Now i remember, that was an issue that i had. I just generated my own authorisation code if i remember correctly, or i removed it from the code. It didnt seem to serve any purpose whatsoever.

Lol, i just read all of your post and realised that you had seen i made up my own! I have no idea of its point!


Forum Moderator, 220 Posts

11 November 2009 at 2:51am

as the author of most of the PP code, let me start with an apology for it not working...

From memory, the authorisation code is there to prevent people from faking a payment. That is, you can go all the way to the checkout then you get forwarded to PP, at this stage, you dont pay, but fake the return variables from PP. Doing so, can make it look like you have paid. The idea of the Authorisation code was to save some sort of code that is being checked against your return variables, thereby making it more secure (i.e. code must match with payment ID). Well, that was the theory.

I just had a look at the code, and it is indeed a mess. Does anyone want to write a patch. I dont really have time this week or next week to fix it unfortunately.




Community Member, 3 Posts

11 November 2009 at 11:13am

Edited: 11/11/2009 11:06pm


Read the post about potential security bugs and decided to remove this post.


Forum Moderator, 12 Posts

11 November 2009 at 6:40pm

Yes, that bits of code is originally designed for using IPN, but lost its functionality during version merge and introduce bugs. For now, you could simply add this piece of code to solve the problem to PayPalPayment class:

function populateDefaults() {
$this->AuthorisationCode = md5(uniqid(rand(), true));

This piece of code is picked up by me from the last version where the db field AuthorisationCode is moved from Payment class to PayPalPayment class but its population is just simply dropped from Payment class.

The solution is not added for solve the security problem until somebody can summit a pitch for IPN, though I am not convinced that IPN is fully secured, ie. what happen if somebody fake IPNs?


Community Member, 501 Posts

11 November 2009 at 9:22pm

I had a feeling something odd was going on with this, and even with authorisationcode implemented it would be obviously insecure.

Still fail to understand how so little people had this problem, unless nobody's using this Paypal class?


Community Member, 3 Posts

11 November 2009 at 11:00pm

Hey Norman,

I've implemented IPN in a new PayPalPayment Class, however I need to tidy it up and remove some extra crap I put in there for what I was using it for and then its free for all to use.

In regards to the security of IPN, It is just as secure as any other type of commercial Credit Card/Payment processing method and would be very hard to fake. IPN works by a request being made from the server to PayPal and the response of the IPN being the body of that request, therefore unless someone could somehow modify the PHP code its self to use a different IPN address or use a "man in the middle" type attack to change where the IPN address really points (which would work on all types of Credit Card/Payment processing methods and points to a larger security concern) it is perfectly secure and accurate to use.

I've used it in several successful sites that require instant access to purchased and am happy to share what I've got after I tidy it up.


Community Member, 501 Posts

18 November 2009 at 7:18am

Hey Michael,

any idea when you can share the code with IPN?

I'd have a throw it at myself but no use going into the trouble if you're happy to share :)



Go to Top