Post by Qphoria » Wed Jan 13, 2010 3:42 am

that error means the page might exist but is being harshly rejected. Usually due to not having the right chmod on the folder I assume

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by ramblin54321 » Wed Jan 13, 2010 8:27 am

I get the same 403 error even with the opencart folder and all subfoders and files set to 777. Which file is the IPN going to? Do I need to give it the admin password somewhere?

Newbie

Posts

Joined
Tue Jan 12, 2010 7:47 pm

Post by vimal » Thu Jan 14, 2010 6:00 am

Hi Q,

Instead of getting people asking you questions on where exactly, which file, etc and also avoiding them pasting wrong, and then asking more questions...

I think it is better if you just make the files and upload it here. People can just copy and replace their original file with this new one.

Not stepping on your toes..appreciate your solution..but this post could have been shorted.. :)

www.beeshop.se
Starta webbshop, Starta e-butik, Starta e-handel


Active Member

Posts

Joined
Wed Aug 26, 2009 8:54 am
Location - Sweden

Post by vimal » Thu Jan 14, 2010 6:01 am

I will try and do it and upload the correct files if get some time..but I might also be one of the people asking...hey Q the solution is not working..what did I do wrong? lol ;D

www.beeshop.se
Starta webbshop, Starta e-butik, Starta e-handel


Active Member

Posts

Joined
Wed Aug 26, 2009 8:54 am
Location - Sweden

Post by Qphoria » Thu Jan 14, 2010 6:19 am

I made the fix in my paypal itemized patch file. Just dl that.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by pstreet » Thu Feb 11, 2010 10:30 am

Please excuse me if I'm wrong, but I found that the curl request to do verification to PayPal is returning an "INVALID" response. It lead me to believe it is an encoding issue, as it appears single quote marks are being switched over to their HTML entity '&039;' so I did some investigation and determined that this is the case.

Where the $request string is being built to send through to PayPal I changed it from the following:

Code: Select all

foreach ($this->request->post as $key => $value) {
  $request .= '&' . $key . '=' . urlencode(stripslashes($value));
}
to this:

Code: Select all

foreach ($this->request->post as $key => $value) {
  $value = urlencode(htmlspecialchars_decode(stripslashes($value), ENT_QUOTES));
  $request .= '&' . $key . '=' . $value;
}
The reason why this needs to be fixed is because PayPal relies on the fact that what we send back to them to verify it's a valid PayPal is matched against the verify_sign encrypted hash. It needs to match exactly what they sent. If the check works out we get a "VERIFIED" response. As far as I can tell, and I've had OpenCart for the last two weeks, the current implementation was not working (it may be something to do with how quotes are handled!? Maybe this code has been changed so they get translated into HTML entities - Daniel may have a better understanding of this, my PHP knowledge isn't the greatest, I come from a C/C++ background).

This was not the only change I made, I also added a 'pp_return' method so that if a customer clicks on the 'return to <your site name>' button from PayPal's successful payment page, it gets routed through similar logic that normally handles IPN as it's not actually necessary to wait for an IPN response in this case. PayPal sends the same value pair data through that would come via IPN. This way, orders should be getting a "VERIFIED" response now immediately upon successful return from PayPal, after the 'pp_return' method handles the data it then pushes them on to the 'checkout/success' page transparently.

I will attach my 'pp_standard.php' file so that people can review the changes. You should be able to diff against your existing file to see what has been altered. This is for version 1.3.2 of OpenCart, the fix may carry through to newer versions if it hasn't been corrected already. (Please be aware there are still some debugging code in that file - you will need to strip it out unless you want your error log to fill up - I should have taken this out beforehand apologies).

I do believe though that adding the extra safety catch to email when "INVALID" responses are received as detailed here earlier by Qphoria is worthwhile (I hadn't seen it till I came here looking to see if anyone had posted the fix I'd come up with).

In this way, if there ever does come through a case where PayPal sends "INVALID" in the future, at least you'll get a notification.

Currently unavailable for freelance work and consulting.


User avatar
New member

Posts

Joined
Tue Nov 03, 2009 2:00 pm
Location - New South Wales, Australia

Post by Qphoria » Thu Feb 11, 2010 12:21 pm

Ah.. I too had this notion a while back. But gave up on it. But it always seemed that people from countries that had weird characters were coming up invalid, so I figured it was something with the encode/decode. Never even thought to try specialchars.

Nice work! Maybe we can finally put this thing to rest in the next version!

An FYI to other users. The attached file by pstreet does not include the itemized patch. I will make the necessary change to the patch for those wanting the itemized version.

I've not looked at the code for pp_return but there is something that paypal offers called "PDT" which is meant for the http return path. It actually handles its own handshake process that, similar to the ipn handshake, does a verification step. I had this in the old 0.x Opencart Version.. but didn't bother to add it in this version. Technically "IPN" is paypal's number one son and should fire as soon as the payment is made, instead of waiting for user to click "return" or if autoreturn, waiting 5 secs.

Still, if done right, it is good to have both which is what many refer to the "Belt & Suspenders" method. But it is important that a user can't fake the url string to the pp_return function and force the order to update

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by flightoffancy » Thu Feb 11, 2010 12:29 pm

Thanks pstreet!

Q, I'll be waiting patiently for your itemized patch update. I love that mod.

New member

Posts

Joined
Fri Jan 22, 2010 9:34 pm

Post by pstreet » Thu Feb 11, 2010 12:50 pm

Still, if done right, it is good to have both which is what many refer to the "Belt & Suspenders" method. But it is important that a user can't fake the url string to the pp_return function and force the order to update
They won't be able to fake a call to pp_return really, as the curl or socket request is still pushed out to PayPal for verification (from the merchants side to PayPal). If it was an attempted fake, PayPal's response will return "INVALID", and after that they simply get redirected to 'checkout/success', no harm done.

Glad I could help try nut this one out, it was beginning to give me headaches when orders weren't appearing.

ADDENDUM:
Qphoria wrote:I've not looked at the code for pp_return but there is something that paypal offers called "PDT" which is meant for the http return path. It actually handles its own handshake process that, similar to the ipn handshake, does a verification step. I had this in the old 0.x Opencart Version.. but didn't bother to add it in this version. Technically "IPN" is paypal's number one son and should fire as soon as the payment is made, instead of waiting for user to click "return" or if autoreturn, waiting 5 secs.
"PDT" is not quite the same thing, it's used to retrieve transaction information at a later date.

The redirect that comes back on the return path from PayPal is a post that has exactly the same shape and form as an IPN response. You can actually handle the response as I do in pp_return immediately, and ignore a later IPN call. The main reason IPN is provided by PayPal is so that your site receives a callback in the case a customer doesn't return to your site using the return button (because if that happens you'd never know if not for IPN).

The only thing you have to watch out for and check is the case that you've already handled a response when the user returned so that you don't try to handle it again once you get the IPN. I think in the default case of how I wrote my solution there would be no harm.

In effect code to support both IPN and a return call from the button is an example of the "Belt & Suspenders" method ;)
Last edited by pstreet on Fri Feb 12, 2010 12:29 pm, edited 1 time in total.

Currently unavailable for freelance work and consulting.


User avatar
New member

Posts

Joined
Tue Nov 03, 2009 2:00 pm
Location - New South Wales, Australia

Post by datacon » Fri Feb 12, 2010 6:41 am

Thanks pstreet, and Q...I will wait for your update to the itemised patch for 1.3.4 also with this fix.

For me, sometimes the order is successfully updates, and other times the order is NOT. Completely random and strange. Even with that fix that sends an email near the bottom of the callback code to say "order id ## needs manual verification", I do not ever get this email as the code is not executed that far down for some reason.

Hopefully these fixes will solve everything... :)

New member

Posts

Joined
Tue Nov 17, 2009 11:10 am

Post by pstreet » Fri Feb 12, 2010 6:50 am

The reason why it sometimes works and sometimes doesn't is to do with whether or not data sent contains elements that are converted into an HTML Entity.

I managed to find the problem because I'd put in an address during testing that contained single quote marks (e.g. ' which was being converted to &039;). It explains why it sometimes works and sometimes does not, it may appear random, but I bet if you checked the orders that bugged out there would be a character in there that gets converted and really shouldn't.

Funny how something so small can be responsible.

Currently unavailable for freelance work and consulting.


User avatar
New member

Posts

Joined
Tue Nov 03, 2009 2:00 pm
Location - New South Wales, Australia

Post by Qphoria » Fri Feb 12, 2010 9:29 am

itemized paypal has been updated since i mentioned it.. in the itemized paypal thread

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by pstreet » Fri Feb 12, 2010 9:43 am

Do you know if your patch will be folded into the repository? Itemized PayPal would be a huge improvement to the standard distro of OpenCart.

Currently unavailable for freelance work and consulting.


User avatar
New member

Posts

Joined
Tue Nov 03, 2009 2:00 pm
Location - New South Wales, Australia

Post by Qphoria » Fri Feb 12, 2010 1:23 pm

It's been around since 1.2.5 and it still has not been. It could probably use some cleaning up and the addition of the return to merchant processing wouldnt hurt. Really it could use some enhancing too, like handling all the state updates from paypal, so if an order was canceled in paypal, it reflects on the cart... refunded, etc. I'll talk to daniel about it.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by webstudent1 » Wed Feb 17, 2010 10:50 pm

Hi,

Maybe I am missing something in what I have read while searching.
Qforia I am sure its posted somewhere i am not finding by searching.
But I wated to be clear on these settings.

I am using you latest Itemized paypal patch PaypalItemizedPatch_OCv140.2
I am runing opencart v1.3.4.

I when I get an order it still gets lost.

I go into SQL and find the order_status_id=0 in the order table.

What would be the proper settings to prevent lost orders in the following:

STORE ---> CONFIGURATION (Options Tab) for Order Status: Set the default order status when an order is processed.

Thanks Again.

AND in

EXTENSIONS ---> PAYMENT --> PAYPAL for Order Status.

It works perfectly in test mode with a sandbox account.

Thanks for your help.

I am still interested in the settings. However I think i resolved the problem it was an isssue with PayPal.

WebStudent1

New member

Posts

Joined
Thu Jan 07, 2010 2:24 am

Post by Qphoria » Sun Feb 21, 2010 6:11 am


Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by datacon » Mon Feb 22, 2010 12:44 pm

I applied the fix same as webstudent1 but I am still getting missing orders... :( No emails are firing at all, seems worse now :S IPN is working, emails work at beginning of call back, but not through it as provided by you.

Also, the TAX is not being sent correctly to PayPal, hence the customer actually paying less than they should be. The TAX from the shipping is not being sent across, only the TAX on the product is being sent to paypal. Was working before. What do you think if could be Q? (Screenshots attached)

Attachments

paypal.JPG

paypal.JPG (34.19 KiB) Viewed 53401 times

opencart.JPG

opencart.JPG (31.67 KiB) Viewed 53401 times


New member

Posts

Joined
Tue Nov 17, 2009 11:10 am

Post by Qphoria » Mon Feb 22, 2010 2:33 pm

I've never seen the tax not being sent. There were a few people having an issue where the shipping was not sent, but you are the first I've heard about having no tax. Oddly, I don't have this problem when I use it, and I've not heard of any problems before 1.4.0.

All the same, it has nothing to do with IPN, only to add support for invalid orders. If you are still getting missing orders, then be sure you they are getting through based on the info from the wiki link above.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by datacon » Tue Feb 23, 2010 8:56 am

Qphoria wrote:I've never seen the tax not being sent. There were a few people having an issue where the shipping was not sent, but you are the first I've heard about having no tax. Oddly, I don't have this problem when I use it, and I've not heard of any problems before 1.4.0.

All the same, it has nothing to do with IPN, only to add support for invalid orders. If you are still getting missing orders, then be sure you they are getting through based on the info from the wiki link above.
Great wiki post Q :)

I followed everything, even my webhost tested ports & IPN stuff but worked ok.. Dont know what to do with these missing orders, and with the tax not being sent. Can i hire you on hourly basis to have a look at our ftp and fix?

New member

Posts

Joined
Tue Nov 17, 2009 11:10 am

Post by datacon » Wed Feb 24, 2010 7:28 am

Qphoria wrote:I've never seen the tax not being sent. There were a few people having an issue where the shipping was not sent, but you are the first I've heard about having no tax.
I have done extensive testing on it now, and have concluded that the itemized patch does not pass on the tax component of shipping to PayPal if the seleted shipping methods is a "taxable good". This is why it shows everything fine in OC, but the itemized patch is only adding the tax for the products, not the shipping (if its set). This is tested on Australia Post module, dropbear 2 edition from superjuice...and I have also tested it on other shipping methods.

If I set:

Code: Select all

$useItemized = 0; // set to 0 if you don't want itemized
Then the script will only pass the total to PayPal, and the total amount is RIGHT, because its not adding anything up, its just sending OC's total. But when its set to "1", then the script add's things up, and the TAX amount is not right, hence the TOTAL not being right either (the customer is actually paying less than they should be).

Q, is it possible for you to have a quick look and let me know what code to change to add the tax of the shipping figure (ONLY IF the shipping method is set to add tax)?

New member

Posts

Joined
Tue Nov 17, 2009 11:10 am
Who is online

Users browsing this forum: No registered users and 114 guests