v1.5.3.1 Paypal Standard not completing orders

I upgraded to v1.5.3.1 and since I've done that, orders paid using "Paypal Standard" never get flagged as "Completed". I'm unsure what I need to debug to figure out where the breakdown is. I'm not using any special extensions or anything.

The "Complete" status for orders is "Completed", but all orders stay as "Pending".

Have you logged in to your admin and double checked your PAY PAL standard order settnigs? Perhaps that got placed on pending. You have two. You have main order status and payment order status.

Thanks for the response. All my settings appear to be correct...

This thread seems to have fallen down... /bump

I'm still experiencing this issue which is causing me to have to manually approve each transaction

So the order is being completed and money is being placed in your Pay Pal account. Just no CONFIRMED Status correct?
This prob is an issue with not updated correctly.

Yes, that's the issue.

When you say it's not updated correctly, do you mean my 1.5.3.1 version didn't update correctly? Or do you mean it's Paypal not updating my cart? I realize that's the case. I'm just not sure exactly where to begin debugging it.

Hello,

We upgraded from 1.5.2.1 to 1.5.3.1 recently and started having problemas with Paypal Standard not getting our orders to the Completed state, leaving them as Pending.

After checking the insides of the pp_standard module, we have noticed that OC 1.5.2.1 checks for the order amount coming from Paypal to match the payment, whereas OC 1.5.3.1 also checks for the email receiving the payment to match. In our case, we have two emails and Paypal is returning the "other" email.

If you have not done so, activate the error logging and check the error log after a Paypal transaction. If the pp_standard module fails to match the Paypal email, it will show there.

Best Regards.

Also remember checking IPN.

You're right, it was the email address!

I am experiencing similar problems with Paypal Standard. When using Paypal Standard the customer is redirected to Paypal and successfully pays for the order. However the order does not appear in OC except under missing orders.

DISCLAIMER: I am actually using MijoShop which is a port of Opencart to Joomla. However there is very little changes to core files especially modules. It is based on OC 1.5.5.1.

Paypal IPN History appears to show that the IPN message was successfully sent with response code 200. HOWEVER the Paypal IPN History is showing "Latest delivery attempt date/time" as xx/xx/1984 or 1985??? I have raised this issue with Paypal and am waiting for a response. Screenshot attached.

No corresponding IPN is recorded in the Logs. My Coder did make some changes and managed to get the IPN to show in the logs and the Order Status to be changed to Pending but not Processing which is what we are after. We have undone the changes as we are also trying to get some assistance from Mijoshop support and Paypal.

We do/ did have 2 email addresses registered in Paypal but as far as I can tell this is not causing the issue. I have also removed 1 of the emails to be sure.

From the timestamps it appears that something on one of the machines is trying to default to one of microcomputers' or mainframes' Genesis chapters, as it were. (Does anything go anywhere through something like Fortran for bean counting, or through a "Y2K" crack in the flooring in unfixed Cobol somewhere?!) If e-mail address were incorrectly utilized, you'd know it; PayPal's account settings for e-mail addresses are pretty well kept straight on its end.

Thanks for the response.

Seeing as I have no idea what you're talking about I can't be certain one way or the other. However as far as I know there is no Fortran or Cobol running on the server, so unless it is a fairly standard thing they they are probably not installed. It is a managed VDE (virtual dedicated environment) only used for webhosting.

Regards

redmonds

(1) If your money is going all the way to you, then you're essentially okay.

(2) The point above is, WHATEVER threw "1985" went completely screwy.

The imaged, suspect date goes absurdly far back, into EIGHTY-FIVE: where templated text says, "Last delivery date date/time" JUST BEFORE DYNAMICALLY MACHINE-INSERTED "07/04/1985 07:08 AEST" is a virtual Genesis chapter. It could have been thrown by a mainframe, mincomputer, or microcomputer, but not with equal likelihood. Banking-related mainframe computers could throw those, and some of those still use, yup, Fortran and Cobol. PayPal jolly well might use them, behind its webserver(s). A webserver or mailserver would not use them. If "07/04/1985 07:08 AEST" was somebody's idea of computerese for "none" then somebody might have miswritten code in the first place.

You would not likely have entered into your own cart records going back well into 1985.

With "1985" appearing, the problem you started with may be affected. And if YOU put it in somewhere, it would probably be good to change.

I was 4 years old at that time. Basically he was asking if you were using anything ancient serverwise. I've had problems where it didn't update was caused by curl over ssl when php and openssl in apache weren't properly compatible with eachother.

One of the (at least two) servers involved in the overall transactions is goofy.

Thanks for the feedback. I am pretty sure my server would not have any reason to be running said software. And while I certianly have little to no experience with payment gateways My reading of the IPN history leads me to believe that would be a date and time recorded from a paypal system.

As I said I have logged a support call with Paypal and am still waiting for some contact. I did expect they would be quicker better support than this.

I am certainly actually recieving the money it is just a bit frustrating having to manually cross checjk payments and move orders from Missing to Processing.

On slightly related question. How do I deal with having multiple seperate websites/shop sending money to the same Paypal account. Assuming IPN was actually working how/is it possible to have 1 paypal account reporting payment status back to 2 seperate stores. Is it possible to code the IPN call back address into the Opencart Paypal settings so that each shop can send its own IPN call back address at the time of processing?

Thanks
redmonds

PayPal and the banks would be the ones likely to be using mainframes, some lingering "Y2K" surprises, and "1985" dates. PayPal support takes a while, even if you telephone and hold, so hang in there.

Apart from aggravations that lead to, and that may be worsened by, turning to support, PayPal overall is reasonably easy overall to make work. The documentation is occasionally updated and bears reading anew if it was changed. The forums there sometimes give insights that were unavailable otherwise.

PayPal will return customers and electronic paperwork back to each appropriate originating website (the referrer, as seen by PayPal). If PayPal's secure server encounters any confusion at all, or any differences between referrer code and what the Merchant account has preset or assigned within it, then the server will not even show the pending sale or take the payment.

You may need to look inside your Merchant account and some documentation to see where the various steps are. Within one PayPal Merchant account you can set up differences (e-mail addresses, business names, etc.) that will let you know where what came from, and that will keep return traffic (payment to originating website) straight. One way is to set up an additional e-mail address for yourself for each shop. Buyers will ordinarily see one seller (they'll see that as one seller, or if they're aware of plural stores, as same seller), unless you're actually using multiple business names (such as yourself, businessname1, businessname2, etc., as to which PayPal will have verified their bank accounts). I haven't checked this detail in a while, but I assume that if there are multiple business names, then each can be set up with its own IPN. Ones that are different "hats" of sole proprietorship (d.b.a. each f.b.n., doing business as each fictitious business name) can routinely be handled within on Merchant account, although separate accounts for them can be advisable. Ones that are separate "person" entities (corporate, etc.) would need their own Merchant accounts anyway. Where multiples share just one Merchant account, there can be workably just one "proprietor" and just one IPN but a separate e-mail address for each business-related website, which in turn can each concern a different non-overlapping kind of business and can each have either a vastly simplified payment portal or an outright even if simple cart, and its own database.

I have a similar problem to redmond, although I'm using OpenCart 1.5.4 and not the Joomla port.

I also contacted PayPal and am waiting for a proper response. All they've said so far is "We are aware of this issue and we are working to resolve it."

My shop has been working fine for months and I did NOT have IPN turned on within PayPal. When the problem started I did turn it on, however the IPN History kept saying "retrying". I didn't see a Response Code or a Notification URL or the IPN Message details. I did see the weird 1985 date.

I've contacted my server company and they assure me that they aren't blocking anything from PayPal.

I've used the PayPal Sandbox IPN Tester, however after I submit it the page returns a "The connection was reset" error.

Why the heck would it just stop working?

Where they naturally didn't just say, "We know there's a problem and we still don't know how to fix it," neither your OC nor your server is causing the throwback to antiquity, and PayPal has pretty well admitted that, lo, they're causing it. If you can, you could try setting up a second IPN or a replacement IPN instead, but now that the problem isn't sitting in just one OC lap, a second or replacement one might well equally not work, either. I would test it "for real" from your server into the actual payment portal. An obvious alternative to test is, shut off using the IPN itself. A good idea gone somehow dreadfully awry is merely yet another escapee from Herr Dr. Prof. Frankenstein's la-bora-tory wandering around in the dark. It wouldn't be PayPal's first escapee into the night.