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.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

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, Ed, frankmullenger, biapar, Willr, Ingo, Jedateach, swaiba


Go to End

9 Posts   3876 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, 253 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, 224 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.


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 :)




Community Member, 3 Posts

18 November 2009 at 10:02am

Thanks for the reminder,

Here is what I've got at the moment, it is a lot more "bloated" than any other Payment method as I am planning to eventually include support for subscriptions and buy now buttons as a Field. I've also added a lot of formatting checks by way of setters/getters for each PayPal HTML Variable following the PayPal specs so errors are easier to catch and display via PHP.

Module is currently based off PayPals HTML Variables Reference (Updated on June 1, 2009) so it may pay to check that nothing major has changed between now and then.

Let me know if you need some help getting it to work.

Go to Top