New 
Terra
-
Posts
887 -
Joined
-
Last visited
Posts posted by Terra
-
-
The customers has reported that he keeps receiving emails with an order invoice. Rob.
The payment status is updated every time PayPal sends an update to your site. These updates should only happen when the status of a payment changes (e.g. an eCheque clears). Order emails are sent when the payment update is to notify of a successful, cleared payment. On your site therefore PayPal keeps on sending the same success IPN update, resulting in the multiple entries.
Why this is happening on your site I don't know. If you have time, I'd suggest contacting PayPal and ask them about repeat IPN updates to your site. For some reason, PayPal seems to think that it hasn't notified you yet, so it keeps on trying.
And be aware -it's not just duplicate order emails, but also multiple stock reductions so I'd advise to check / correct your stock levels.
If you can't rectify it, I'd recommend downgrading to v1.4 - at least, then there'll be no duplicate order emails / stock reductions although your admin will still show the multiple entries.
Terra
-
Please correct me if i am wrong with my conlusions - but the most important for me at the moment is, the shop of my customer is up and runnig with your nice contrib and correctly returning from paypal. :)
I don't think you're wrong and the thorough work you've done is fab - many thanks for investigating this! In my reply I thought about the standard GET variables but forgot that osCom of course has its own complete session handling mechanism ... which I haven't really looked at in the past as on my sites I can use force cookie use which usually cures problems. I guess there's a function which picks up POST session ids.. either way, if it works, then that's the way to go! all the best - Terra.
-
Can someone give me some guidance as to what is happening? Where are these Paypal payments going to? How do we keep this from happening? How do I tell for sure if something is an abandoned order versus an error?
With the PayPal IPN all orders are pre-saved i.e. BEFORE payment. You will therefore see quite a few orders in the admin which are pre-saved and abandoned, i.e. unpaid -these can be deleted (without restocking).
I don't know where the information regarding "no table entry" comes from - that's wrong. The latest user guide states:
In the past shop administrators had problems, where a customer did not return to the site. Shop administrators received a payment notification from PayPal but no order details. The PayPal IPN Module addresses this problem by storing orders prematurely (before payment) in the database with the "Preparing [PayPal IPN]" setting and as soon as a customer pays the order status is automatically updated to the chosen setting (usually "Pending").This means that even when a customer fails to return to the site, the shop administrator will have a record of the order details even when no order emails are generated. Any remaining orders with status "Preparing [PayPal IPN]" have to be carefully checked and can fall into the following scenarios:
1) Orders in progress
Recent orders with the status "Preparing [PayPal IPN]" can show an order in progress, e.g. by a customer making amendments to his order or going through checkout. Action: None - recently generated orders should be left as they are.
2) Abandoned (unpaid) orders
If a customer chooses to abandon ordering, i.e. not continuing with payment, then a record of the premature (unpaid) order will be stored with the setting "Preparing [PayPal IPN]". Action: Delete - orders over 48 hours old with no payment can be deleted (option to restock must be unticked as "Preparing [PayPal IPN]" orders are not yet deducted from stock).
all the best - Terra
-
Hello,
i had the same problem, returning to the shop resulting in the login-page. I did some analyzing and found out, that PayPal uses for the <form> with the "Return to Merchant"-Button the method="GET". But in <form>s with GET-mode no (get-)name-value-pairs enclosed to the action-attribute are sent to the server, as far as i can see, testing with FF2.0, Opera 9 and IE 6.
That is the code PayPal generates:
<form method="get" id="merchantReturn" name="merchant_return" action="http://127.0.0.1/muvicom/osCommerce/checkout_process.php?osCsid=04bd1e97309feb127bf4c8c46ff1806a">
As the method "get" means, that all input-fields within the form have to be written behind the url of the action-attribute, the browsers seem to cut the action-url after the filename - i did not found any documentation about this part, but it behaves like that.
I tested PayPal some months ago with no problems returning to the shop, so i guess they changed something within the last weeks.
So i have taken the complete form from the PayPal-website and changed the method to "post" and everything was fine :).
SOLUTION
I found a way to instruct PayPal, which form-method it has to use for the "Return to Merchant"-form. (https://www.paypal.com/IntegrationCenter/ic_std-variable-reference.html) As it is a simple extra-value, the change for the paypal_ipn.php is simple, after these lines:
$parameters['bn'] = $this->identifier; $parameters['lc'] = $order->customer['country']['iso_code_2'];
ADD the following line (near line 417):
$parameters['rm'] = '2';
I'm not sure, whether this problem exists only sometimes, as there are more than one configuration-variant for the PayPal IPN Contrib. But as the get-method never functions with the return-link/action-attribute including the session-id, it should do nothing wrong, i believe.
I hope, this is helpful for someone, feel free to ask your questions.
drichter
Hi drichter - glad it's working for you! I'm just trying to work my way through the fix but I'm struggling to understand why the switch to post makes a difference. The session ID is normally handled as GET variable in osCommerce, unless cookie use is forced (in which case the session details are in the cookie). Appending the session ID to the return URL should ensure that the customer's session continues. Within the osC store, session IDs are always GET - they are handed from page to page via appending to the URL. Sometimes GET session variables can be hidden (e.g. when SEO URLs are installed) but they are still there in the background.
Can you confirm if in your testing the SessionID on checkout_confirmation and the SessionID in the PayPal return URL are the same?
NB: if there's a problem with the session ID you may not see in the testing, as checkout_process redirects to checkout_success.php and if there's a problem, it would strip out the session ID in the redirect. To see if the URL is correct, you could e.g. put an "exit;" command at the top of checkout_process.php - that would stop the transaction at that point and you can then check the URL in the browser bar.
all the best - Terra
PS: I take you are not using RC1?
-
I have it set to Aggregate in the setting and I heard it will does this when this setting it enable. I read that if set to Per Item it will pass the item to pay-pal but it had problems. So is their a fix for this to where it will pass the item being purchased to pay pal instead of it just showing the store name?
You can set it to "per item" but this can cause issues - if you want to use per item, give it a go & test thoroughly. The main problems are around tax (especially shipping tax) and CCGV - as long as your shop is simple (no tax, no CCGV) the per item should work. All the best - Terra
-
now all the method payments come out, just Paypal is still unavailable.
Make sure that each payment module has a unique sort order in your shop admin. Modules with the same sort order can cancel each other out.
PS: PayPal is a PAYMENT method, not a SHIPPPING method .. flat rate has nothing to do with it! All the best - Terra
-
Warning: fopen(/973453-3-data.txt): failed to open stream: Permission denied in /home/content/N/o/x/Noxwear/html/includes/modules/payment/paypal_ipn.php on line 426
You have enabled Enable Encrypted Web Payments but it's not working. Either disable it in your admin (set to false) or you'll need to configure it correctly. If you enable Enable Encrypted Web Payments you must enter all the other information (key, certificate, working directory, OpenSSL) correctly and OpenSSL must be enabled on your server. Please read the section about EWP in the user guide, there's also information on the support thread or see the PayPal site for help & advice. All the best - Terra
-
So far so good, the problem is that every 5 minutes or so I see in the backend another "PayPal IPN Verified [Completed (Unverified; $0.01)] " with status "Pending" and a duplicate email is sent to the customer each time!
This indicates that PayPal is trying to resend the payment information to your site - I've not come across this before, so in all likelihood it's a specific issue with your set-up. If you can't debug it, downgrade to v1.4 - at least then no order emails are sent out / no stock quantities deducted when the IPN update is sent. all te best - Terra
-
The title of the module is displayed as:
MODULE_PAYMENT_PAYPAL_IPN_TEXT_TITLE
This means you forgot to copy over the language level file (or copied it into the wrong place) - please double-check that you uploaded the correct file to /includes/languages/english/modules/payment/. All the best - Terra
-
A quick question. I have installed a copy of RC1 and in the modules list under admin it shows the IPN mobule. Does this mean it is already pre-included and just requires configuration, or do i still need to download and install the contribution?
As far as I know the contrib in RC1 is an old version from 2005 - Harald obviously thinks my coding is sh*** so what the heck - it's only 2 1/2 years out of date. Terra PS: don't forget that RC1 translates in "beta version" - not suitable for live sites.
-
Ok, Just to confirm this, you need to sign up for Paypal WebPro in order to use this module correct?
This module was NOT written for WebPro so if you're looking for WebPro then this is not the right contribution. For the private key etc. I don't believe you need a WebPro account - just a business account with PayPal. But if you have an SSL or cURL enabled, then you won't need the private key stuff. all the best - Terra
-
... In particular the module posts a variable H_PhoneNumber, but PayPal is unable to pick this up and map into the phone field because it actually expects contact_phone. ..
The IPN module I wrote is optimised for the UK and the variable you mention is the PayPal recommended field for UK phone numbers. I don't have plans to write a separate module for US optimisation but if any other developer has time, feel free to update the IPN with a US forke. Terra
-
Despite all of my research, i still cannot figure out how to get orders that were not completed (which are now marked as "Preparing [PayPal IPN] " off the orders page entirely, and just have those that were paid ("pending").
Pre-saving all orders (whether they are paid or not) is part of how the IPN works. There's no way around this - your client will have to check before sending out goods or use a different payment module. Terra
-
I am using Paypal contribution made by dynamo effects for a while ....
Please note that this thread is ONLY for the following PayPal contribution: http://www.oscommerce.com/community/contributions,2679
As you are using a different contrib please do not post in this thread - thank you for your help in keeping this thread on topic. Terra
-
When I click Continue on the CONFIRM page, it goes to https://www.sandbox.paypal.com/ login page
Your module is set to "Test" - switch it to "Live" (in your shop admin -> modules -> payment). More info in the contrib user guide - please read it, it contains the answers to the most frequent queries. All the best - Terra
-
a customer being re-directed to the login screen (rather than the checkout success)
b i noticed when I go to my admin page - it says - You are not protected by a secure SSL connection.
Regarding b - that just means your admin is not locked down under SSL (a separate issue, not for this thread. I'm sure Vger has some advice in her easy install guide). As for a - have you tried setting force cookie use to TRUE? I'm not 100% sure but it should work on 1&1. Please try & see if that cures it. All the best - Tera
-
For anybody who posted problems about customers ending up on the log in page: This usually means that the session was lost (when customer returns, the shop does not know that customer has an active session & returns them to the log in screen).
For session problems, I'd need to know:
1. Do you have your own full SSL?
2. If yes to above, do you force cookie use? (usually, forcing cookie use cures session problems but this can only be done with full SSL Certs)
As to the queries regarding v1.x versus v2.x - version 2.x does update stock & send out emails even if a customer does not return to the shop, so it will help but it won't actually solve the issue of customers not seeing the checkout_success.php page.
I hope this helps a bit more - if you still have problems, please post back with the info I mentioned above. All the best - Terra
PS: also - things don't go wrong all of a sudden without any changes - please include the name of your hosting provider and any recent changes they have done to your server. If they did not tell you of any changes, open a support ticket with your hosting provider and ask them about any recent server upgrades/changes before posting back to this thread.
-
I recently discovered that my client had changed her Primary email in Paypal, so of course, her orders started getting stuck in Preparing [Paypal IPN] status.
If the email address (which is also the PayPal account name) is wrong, then customers cannot pay. They would have a seen a message saying that this account does not exist. You would therefore have to contact the customers, apologise to them and tell them, that if they still want to order they need to resubmit (and pay) their orders. But in reality I believe those sales are lost.
PS: the problem isn't just that they got "stuck" in the preparing stage - the problem is that customers were unable to pay and therefore abandoned the checkout. As far as the customers are concerned, the site appeared broken and they abandoned the order.
All the best - Terra
-
Great contribution and has been working great on most installs...but got an odity on one site ... Bascially after paying at paypal and returning to the site it seems the customers_id session variable is no longer valid ...
This sound like a lost session problem which is not specific to the payment module but indicates a server / site error. For best results with sessions, cookies should be forced - but this can only be done if the site has a full SSL. Like you say - if the install worked before, then it's a site/server error, not a problem with the module. If you look at how the flow goes (are secure pages on the same server etc.) you may find your answer. all the best - Terra
-
Chaps - this is not a module problem, but a bug in osCommerce which exists since 2006. For the fix please see: http://www.oscommerce.com/forums/index.php?sho...mp;#entry932499
The bug sits in both compatibility.php files (admin & root).
You can also download the candidate release notes:
http://www.oscommerce.com/ext/osc22rc1_upgrade.html.zip
The compatibility fix is listed under "[bUGFIX] Compatibility Array Index" on the page.
all the best - Terra
Keywords: payment module updates not saved, update, updated,
-
OpenSSL and Shared/Dedicated SSLs are two different things. OpenSSL functionality is a server wide install which must be done by the server admin.
-
where in ipn.php and how do i have to call the analytics.php to submite also these orders to google?
Please start a new thread for this as it's not directly related to the IPN module. As far as I know, you need to custom-integrate your checkout with Google Analytics in order to get the e-com data (order value etc). There's an integration guide on the Google site but that's a much as I know. If you start a new thread with Google Analytics you should get more replies - also include what kind of integration you've already done. all the best - Terra
-
You are correct. If you have an SSL cert installed you do not need Encrypted Web Payments. The cert must be yours and not shared.
Shared Certs work fine with osCommerce - we use it for our hosting customers and it's much cheaper than full certs. As long as the server set-up / Cert is done correctly, there's no problem with using a shared ssl certificate with osCom and PayPal IPN. all the best - Terra
-
Thanks a lot for your answer. I created an account (in my store that is) where the user country is Bolivia ...
PayPal only supports a limited number of countries and as far as I know Bolivia is not one of them. This means that any customer with an address in Bolivia is directed to the default US page. From the PayPal Dev forum:
Country Codes AU, DE, FR, IT, GB, ES and US are supported. Any other value will default to US.So you could hardcode the parameter lc to ES for Spanish or maybe write your own code so customers with an address in Bolivia get the Spanish page (via a PHP if statement):
$parameters['lc'] = 'ES';
Hope this helps to explain it! Terra
PDF Catalog v.1.5
in General Add-Ons Support
Posted
To anybody who has the following error:
The fix is fairly simply - find all instances of
and replace with
But leave the first one alone:
Properties in Classes don't have $ signs in front of them. If they do, then PHP assumes we're calling a variable & tries to look for it's name. As it can't find a variable with the name it says "oi, this is empty!" and dies. By removing the $ sign you're back to standard PHP coding for properties in objects and all is well.
All the best, Terra