PayPal IPN Verification

I've just been looking inside the guts of catalog/controller/payment/pp_standard.php and noticed what I believe is a serious bug. The callback function in this script just verifies that the IPN response from PayPal is "VERIFIED".

Surely the script should also verify that:

• payment_status = MUST only set the order to complete if this variable is set to "Completed"
• receiver_email = MUST match the merchant's email as registered with paypal
• mc_currency = MUST match the currency of the order
• mc_gross = MUST match the cost of the order
• item_name = MUST match the order name / id (however I noticed opencart uses the custom field for this)
• transaction_id = MUST be unique (An item has never been purchased before with the same ID, therefore must be stored in the opencart database and matched against all new orders)

As it currently stands I should be able to easily change the value for "amount" sent to PayPal from let's say "100.00" to "1.00" and the currency from "GBP" to "USD". The order should still go through fine without this validation. In which case I just bought a £100 item for $1.

Forgive me if I have overlooked anything.

Yes, it is known.. but currently left unchanged in the core

A fallback solution:
http://forum.opencart.com/viewtopic.php ... 41&start=0

For me it only happens on certain foreign transactions.. So my thoughts were that there was possibly some strange url encoding or something when sending back to paypal, maybe due to strange country names or characters. But since its the same code that paypal tells us to use, it is confusing as to why it doesn't work sometimes.

I never had a problem using zencart's paypal but that part of the code verification process looks the same.

But

Comparing the older fsock code to the official paypal ipn sample code
https://cms.paypal.com/cms_content/US/e ... PHP_41.txt

Paypal's example shows: v1.3.0 shows: Perhaps that is something. Not sure why the curl method would be any better or worse tho

Update on my testing of this.....

Initially, with the default setup of OpenCart, I was getting 1in 6 cases where the IPN verification came back "INVALID".

I changed a few things.

The verification request string
FROM: TO: Brought it down to 1 in 15 coming back INVALID. The one that came back invalid most recently had an &amp in the business name. I am thinking that caused the validation problem. But that would mean the original code would have prevented that. So.. i'm still unsure. But other carts like zen have it the second way, and I don't think they have these problems. but that just makes it more confusing.

I'm getting all INVALID, but the paypal payment is going through, confirmation emails are sent, and the order is recorded into the database as "pending" as I've set in the paypal standard configuration. I haven't check closely, but I think during testing, the coupons, points, stock, etc is deducting also.

So I'm wondering is there any adverse effects if they're all being returned INVALID?

Which values have to match to get a VALID?

Someone mentioned in the post below, that changing the"PayPal button language encoding" to UTF-8 in his paypal profile fixed his problems, but doing this didn't work for me. I checked the callback and it has "windows-1252", which is what the PayPal button language encoding id set to by default. Is the callback what opencart sends paypal, or is it what paypal sends to opencart?

http://forum.opencart.com/viewtopic.php?f=113&t=104945

I'll give Qphoria's solution a try tomorrow.

Hello. I have the same issue. Last post was last year ago. Could you solved it. I have set the paypal encoding to UTF-8 but the response created on the calback is windows-1252. It can be because the sandbox?