Sometime last weekend our Opencart install, version 1.5.1.3 started to process duplicate orders for CC payments made through PayPal Website Payment Pro. It happens in the same order sometimes it will process twice. Sometimes 3 times.Payments made through Paypal Web Standard module is working fine.
I looked in the erros logs and about the same time this started happening, we started to get these php notices.
2013-04-23 3:44:01 - PHP Notice: Undefined index: customer_id in /var/www/vhosts/xxxxxxxxx.com/httpdocs/system/library/customer.php(170) : eval()'d code on line 4
2013-04-23 3:44:01 - PHP Notice: Undefined index: payment_address_id in /var/www/vhosts/xxxxxxxxx.com/httpdocs/system/library/customer.php(170) : eval()'d code on line 4
I don't know if they are related, but they started to crop up right at the same time. I went way back in the logs and did not see these anywhere else. Strange for this to pop up out of the blue the cart has been working fine, up until now.
I did a request of new API credentials from PayPal and reinstalled the web payments pro module in Opencart. This seemed to help initially, but we still had orders yesterday that came in as duplicate in the same order. We got a bit of feedback from some customers and it seems that that people are getting hung up on the "please wait..." part when they submit their order. We would get this initially from time to time, but all of a sudden it is much more frequent. The page submits the order, but then never returns the success page. Keeping customers from pressing the button again would help, so we put up a script that blocks the user from pressing the submit order button again.
Unfortunately it still doesn't solve the source of the issue, in that the communication between the site and the payment processor is getting hung up somewhere. I'm guessing paypal made some changes on their end to cause this issue, but any suggestions where I could look to get this corrected would be much appreciated. Thanks.
Related
You guys are my last hope... I created a website with WordPress and I'm using woocommerce. I have been doing test transactions in the PayPal sandbox. And it was working, but suddenly started to give this error in PayPal
/genericError?code=PAYMENT_ALREADY_DONE
And each time cancels my orders. I tried to solve the issue by adding a prefix to the order number but still is giving me that error. I am only using one shop.
and I've checked everywhere for hours, for most people it was a problem of forgetting to change the sandbox PayPal account to their real business account, for others it was because they weren't using a prefix and had more than one shop. All the others never got any answer or help.
how can i fix this?
By the way, after the process paypal redirects de user to cancel order page of woocomerce but in the woocomercer order panel appears te order was made.
in the image below you can see the order were created and the random prefix and subfix i added to order numbers.
picture
I am trying to do some very simple test payments with the rest-api-sdk-php and so far everything has been so SKETCHY!
First attempt worked fine, second attempt the redirect to paypal takes forever (like five minutes) so I assume.
Next attempt I get an internal server error on paypals site.
Next attempt I get redirected to the 1995 version of paypal (doing exactly the same thing as before)
Next attempt I get some big red warning with a page long list of errors on the 1995 paypal site.
Trying again takes at least 10 minutes to process and redirect to my site with a 400 error.
Now on my last attempt it worked fine...
So my question is, aside from asking paypal by telephone, how do I find out if their sandbox servers are crashed or experiencing issues?
I used PayPal's Integration Wiz to generate the code (PHP) for the Express Checkout Digital Goods functionality. I'll admit, I made a few minor changes to it so that it could work with my site... My site is a single page Angular.js app - so I need to pass back parameters to the app, and not go back to a different page (as it is, I'm not keen on leaving the page at all, but I'm not ready to shell out for a business pro account yet.. the PCI compliance is something I don't relish being on the hook for...but maybe one day... certainly not until I know I can get "basic" things working).
I would not expect any of my changes (basically changing the hardcoded URLS to being PHP session vars) to interrupt any of the flow of the Integration Wiz's processing.
However, when I test things in the sanbox, the process stops at the point of redirection to:
https://www.sandbox.paypal.com/incontext?token={somevariabletokenconent}
The token always starts with "EC-" so I'm assuming this is telling me I've been able to successfully start the Express Checkout process.
All I am seeing is a blank page, with Chrome telling me I'm getting:
Failed to load resource: net::ERR_CONNECTION_RESET
AFAICT my sandbox account is set up for EC/DG:
Your payment solution: PayPal Digital Goods (Express Checkout)
I HAVE updated my sandbox details in paypalfunctions.php
And other than the changes in checkout.php, I havent messed with any other code from the integration wizard... should this not "just work" ??
Or have I missed something else?
[Edit]
Update a few hours later...
I actually was able to get things to progress end to end. Once. But no record of the transaction can be seen on either side of the sandbox accounts. It did sit thinking for a long time... so I'm not sure what it was doing, but the final redirect was back with a success parameter, so I have to think that something behind the scenes must be having issues...
But now its not working anymore. Its stopping in the same spot again.
For the life of me, I don't believe I made any code changes to the PP wiz produced code prior to it working, or prior to it not working again.
I have logged into the sandbox to check the transaction as I mentioned. Both accounts are showing nothing. And the transactions are not processing.
[EDIT 2]
Ok - strange things are afoot. I know I did absolutely no changes since my last test...I havent even been at the keyboard. And upon trying again, the test proceeds to allow me to log into the sandbox, and approve a payment, but gets stuck processing at
https://www.sandbox.paypal.com/webapps/checkout/webflow/sparta/expresscheckoutvalidatedataflow?execution=e1s2
with the PayPal "Loading" icon spinning...
Is this a configuration issue on my side? With the Integration Wiz writing all the Express Checkout code, there's not to change, but it seems really flakey to me.
[EDIT3]
I've been hanging my head on this for about a day now, and got nowhere. My App is a single page Angular.js site, and triggers the PayPal purchase out of a Bootstrap Modal popup window.
As mentioned above, my process would get to the point of approving and confirming payment, then spin wildly at the point it should be redirecting back to the success (or failure) page.
Using the PP integration Wiz, the form code that was produced (and used) was:
<form name='ppcheckout' action='checkout.php' METHOD='POST'>
And it fails to proceed to the final redirect.
However, if I change the code to:
<form name='ppcheckout' action='checkout.php' METHOD='POST' target="_blank">
The processing occurs as expected.
Is there some interaction between PayPal's JS and Angular (or Bootstrap) that I'm not aware of? It seems strange that it "just works" when the target is added.
been trying to wrap my head around an issue I have with the IPN tester, not 100% sure if its my hosting company's problem or Paypal Developer 'beta' to be honest but my IPN's have worked fine on a few sites I have for atleast a year and now it doesn't on any of them. I've not changed anything and now im getting
IPN Delivery Failed:I/O error: www.mywebsitesname.co.uk; nested exception is java.net.UnknownHostException: www.mywebsitesname.co.uk
and none of my NotifyUrl.ashx handlers are working.
any ideas what this actually means in english? any more info. from me required to help you diagnose my issue?
#
AS AN UPDATE (27-08-2013), I thought I would try out the original C# SDK sample code from Paypal that I used to set up my IPN's with about a year or three ago (ie. it worked great with the IPN simulator). I have put it onto two different hosting companies servers to check its not an issue with a particular hosting server and my results using the IPN Simulator show "error 500: internal server error" for one and "IPN Delivery Failed:I/O error: www.ang##########.co.uk; nested exception is java.net.UnknownHostException: www.ang############.co.uk".
In short, I have the same identical sample file from Paypal (that used to work) in the root of each hosting companies servers and im using the same IPN simulator settings, with the exception of the IPN handler URL has the webaddress of the server followed by '/Handler.ashx' (which is the handler file) but i'm getting different errors.
Also to make this a bit more interesting, today I correctly received an IPN from Paypal to one of the same hosting server webaddress, with a 'transaction_subject : PayPal money request from xxxxxxxx' which was received and processed by my existing IPN handler (not the sample one from Paypal) and returned the correct info. to receive 'IPN Response: VERIFIED DateTime: 27-08-2013 19:05' so this got through and worked fine.
So in conclusion, I wonder if Paypal have either changed something and not informed the community or have an issue with their IPN simulator / CART IPN. If anyone can help or if a Paypal support engineer would like to work with me to try out some code, etc, please get back to me as I will keep trying to solve this but to be honest I see not what else I can do from my end as I've seen working IPN and a non working IPN simulator.
As extra info. here is an IPN Message as from my sandbox seller test account, that can't get through to my IPN handler on one of the same hosting servers (returns error 500) yet this used to get through and nothing has changed.
'mc_gross=2.75&protection_eligibility=Ineligible&address_status=confirmed&item_number1=BabyGrow2&payer_id=KHJGBQZNAFB7L&tax=0.00&address_street=1 Main St&payment_date=14:34:07 Aug 27, 2013 PDT&payment_status=Pending&charset=windows-1252&address_zip=95131&mc_shipping=0.00&mc_handling=0.00&first_name=Test&mc_fee=0.28&address_country_code=US&address_name=Test Buyer¬ify_version=3.7&custom=1csi4t45gy4gkz45r5r4t0ey&payer_status=verified&business=wow####gmail.com&address_country=United States&num_cart_items=1&mc_handling1=0.00&address_city=San Jose&verify_sign=AFcWxV21C7fd0v3bYYYRCpSSRl31A1fBAmiE5lcDRsQKQNaqoyQI7ucQ&payer_email=wow#######gmail.com&mc_shipping1=0.00&tax1=0.00&txn_id=8SG98957G0030294Y&payment_type=instant&last_name=Buyer&address_state=CA&item_name1=Baby Grow Age 0 - 1&receiver_email=wow#########gmail.com&payment_fee=&quantity1=1&receiver_id=8QRMB3QFHCL56&pending_reason=paymentreview&txn_type=cart&mc_gross_1=2.75&mc_currency=GBP&residence_country=US&test_ipn=1&transaction_subject=1csi4t45gy4gkz45r5r4t0ey&payment_gross=&ipn_track_id=7b4507c8c4313'
Still hoping we can resolve this soon.
Many Thanks.
Trev.
Asp.net / C# / HTML / CSS3
After spending several hours trying to get django-paypal (originally dcramer's fork) to get a 200 OK response from PayPal IPN, I pinpointed the error to PayPal adding an empty, spurious &cmd= argument when using the IPN Simulator. If I leave the &cmd= in, I get a 400 Bad Request response when I try to postback; if I take it out I get a 200 OK but, of course, the postback is invalid because it's not what PayPal sent my server.
Of course, I'd be absolutely happy to do away with the IPN Simulator entirely and simply use Sandbox accounts, but those are broken too: the ones I create through the developer interface can't login (login failed errors); the ones I created through the "regular" interface on the sandbox site don't send any IPN whatsoever no matter what.
So, actually there's two questions here:
is there a way to work around the IPN Simulator &cmd= bug?
is there a way to make the sandbox accounts work?
A reply to either one would make me very very happy.
Many of the issues you've experienced are now cleared up. The IPN issue and some developer/sandbox log in issues have been cleared up as of Monday evening. If you are still experiencing any issues please let me know and I'll be more than willing to look into this further.