Jump to content
Mark Evans

Official PayPal IPN Support Thread

Recommended Posts

The solution should be easy but I havent tested it. Just change:

 

'comments' => $order->info['comments']);

 

in paypal_ipn.php to:

 

'comments' => $order->tep_db_input(info['comments']));

 

 

The code you posted wasn't in there, exactly, it was more like this:

 

'comments' => '[Unfinished / In progress PayPal IPN Order] ' . $order->info['comments']);

 

so I did this:

 

'comments' => '[Unfinished / In progress PayPal IPN Order] ' . $order->tep_db_input(info['comments']));

 

And now unfortunately I'm getting this error:

 

 

"Parse error: parse error, unexpected '[' in /homepages/46/d133701933/htdocs/catalog/includes/modules/payment/paypal_ipn.php on line 185"

 

 

I think that the tep_db_input function doesn't like square braces? Is that the problem, should I just get rid of the braces and substitute with parentheses or something?

Share this post


Link to post
Share on other sites

Yeah, tep_db_input doesn't like the square brackets there. Not sure why because I think that's appropriate syntax. This is probably easy to solve but I don't know where to look for a syntax reference.

 

And does the tep_db_input function do automatic apostrophe stripping?

Share this post


Link to post
Share on other sites
Yeah, tep_db_input doesn't like the square brackets there. Not sure why because I think that's appropriate syntax. This is probably easy to solve but I don't know where to look for a syntax reference.

 

And does the tep_db_input function do automatic apostrophe stripping?

Opps, my mistake. I think it should be:

 

'comments' => '[Unfinished / In progress PayPal IPN Order] ' . tep_db_input($order->info['comments']));

 

This function changes every ' to \'


Ian-san

Flawlessnet

Share this post


Link to post
Share on other sites
Opps, my mistake. I think it should be:

 

'comments' => '[Unfinished / In progress PayPal IPN Order] ' . tep_db_input($order->info['comments']));

 

This function changes every ' to \'

 

Damn, I made that change, and I thought we had the problem licked! But here is the new error message, that comes up when paypal returns me to /catalog/checkout_process.php?

 

 

1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 't it accept the apostrophe?' where orders_id = '31' AND orders_

update orders_status_history set customer_notified = '1', comments = 'Will it or won't it accept the apostrophe?' where orders_id = '31' AND orders_status_id = '4'

[TEP STOP]

 

The strange thing is that in the admin CPL under orders, I see that in the comments box it says:

 

[unfinished / In progress PayPal IPN Order] Will it or won\'t it accept the apostrophe?

 

So the escaped apostrophe is being inserted by that tep_db_input command, but for some reason when the buyer returns to checkout_process the apostrophe comes back. >_<

Share this post


Link to post
Share on other sites
Damn, I made that change, and I thought we had the problem licked! But here is the new error message, that comes up when paypal returns me to /catalog/checkout_process.php?

1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 't it accept the apostrophe?' where orders_id = '31' AND orders_

update orders_status_history set customer_notified = '1', comments = 'Will it or won't it accept the apostrophe?' where orders_id = '31' AND orders_status_id = '4'

[TEP STOP]

 

The strange thing is that in the admin CPL under orders, I see that in the comments box it says:

So the escaped apostrophe is being inserted by that tep_db_input command, but for some reason when the buyer returns to checkout_process the apostrophe comes back.  >_<

 

For a non-paypal order and payment, the comments are checked by the input box which put in the back-slash. So the database input is not further protected by the tep_db_input.

 

However, when these comments go off to PayPal they lose the back-slash.

 

There are about 4 places in my store where comments might be inserted into the database in the Paypal IPN modules so the simple solution would be to put the tep_db_input function around all of them as it will do no harm if it is not actually required.


Ian-san

Flawlessnet

Share this post


Link to post
Share on other sites
For a non-paypal order and payment, the comments are checked by the input box which put in the back-slash. So the database input is not further protected by the tep_db_input.

 

However, when these comments go off to PayPal they lose the back-slash.

 

There are about 4 places in my store where comments might be inserted into the database in the Paypal IPN modules so the simple solution would be to put the tep_db_input function around all of them as it will do no harm if it is not actually required.

 

Who should I contact about this, so that they can make an update to the IPN contrib for the next version. This is a problem likely to be seen by many.

 

And if I understand you correctly, I am to dig through the file and put that wrapper around every occurrence of

 

$order->info['comments']

 

Right?

 

But only if it's somewhere that goes into an array that has a tep_db_perform on it, right?

Share this post


Link to post
Share on other sites

I ended up finding one tep_db_query which had the comments variable in it, and I wrapped that comments in tep_db_input. Looks a bit weird having all that recursion, I hope it doesn't impact performance, but it looks like the SQL errors are fixed.

 

HOWEVER, I have found a *MAJOR BUG* in paypal-ipn. I assume that this is the place to post it. This doesn't actually stop the IPN's from being sent/received, but it does prevent osC from properly recognizing them and therefore upgrading the Status on an order (as defined in the admin CPL for paypal IPN).

 

I spent an eternity thinking the errors were caused by illegal characters in the comments of a transaction, but this turned out to be a three-hour red herring. Here is the problem:

 

1. Under certain mathematical circumstances, if products are priced in USD, and the user switches to another non-default currency, in my case CAD, there is a peculiar rounding error (not sure if it's in the paypal-ipn module or elsewhere). This causes the Sub-Total + Shipping Cost to be actually one cent *greater* than the listed Total.

 

2. You see this when you get the checkout confirmation page. By this time, even before going to paypal, the IPN part of the transaction is doomed. You look at the subtotal, the shipping cost, and then think "what? why is that total off by one?" The total is one cent less.

 

3. From this point on, assuming you have IE and a test shopper in one window, and Firefox and the admin CPL in another window, you can monitor the following progress.

 

a) admin sees an order in Preparing [Paypal IPN] status. Clicking on it shows the comments field containing the "Interim transaction Paypal IPN" message preceding the actual customer comments.

 

B) shopper logs into paypal, and completes the payment. shopper does NOT yet hit the continue button to return to the store.

 

c) admin refreshes orders and sees that there are two status entries now. The first one, documenting the Preparing [Paypal IPN] status, still looks the same. There is a red X beside it for customer notification. The second entry has a different timestamp (depending on how fast the IPN came back). This is the actual IPN, verified by the message from paypal saying user is a verified user, transaction complete, etc. HOWEVER, the status is still set to Preparing [Paypal IPN]. This is obviously wrong, as the notification has not only been sent but been actually (momentarily) recorded by osC.

 

d) shopper hits the continue button on paypal to return to osC, which triggers a bunch of stuff, including an email being sent, and...

 

e) admin refreshes order, and suddenly sees that the "Interim Paypal IPN transaction" message has disappeared from the first status-comment pair, to be replaced by just the comment itself. There is a green check mark beside it saying the customer has been notified. HOWEVER, here is another bug, the second status message NO LONGER contains the IPN information from Paypal, it now matches the original customer comment. In fact it even has a green checkbox beside it (which is ridiculous since only one email was sent out). It looks like a dupe in every way except for the timestamp, which is still the correct one -- and this is the only vestige of the successful IPN from paypal.

 

 

 

So basically what is happening here is that Paypal is sending an IPN for a given amount, say X, and paypal-ipn.php (I'm assuming) gets confused, because it was for an order with a total, in its mind, of X - 0.01. Since the amounts don't match it ventures off into absurdly buggy territory, the status is never automatically fixed, and it has nothing to do with IPN being broken from Paypal.

 

This is a potentially huge bug for anyone selling items that need to become automatically available through IPN, like software. I am not sure if this ever happens in the base currency, looks like it can only happen in a non-default currency, and then maybe only if the exchange rate causes potential rounding errors.

 

So the question is, whose fault is this, and where should it be fixed? Is the rounding occuring in the paypal-ipn module, or the order total module, or shipping, or what?

 

If anyone wants more details, I've got 'em! Please don't let this post fall through the cracks; this is important to fix!

Share this post


Link to post
Share on other sites

The patch titled:

 

missing tep_get_prid() function calls - PATCH for PayPal IPN Module v1.1

 

has a .diff file to download.

 

 

Can anyone tell me exactly how I would patch v 1.1 with this .diff file so I can see my product attributes?

 

Thanks.

Share this post


Link to post
Share on other sites
I ended up finding one tep_db_query which had the comments variable in it, and I wrapped that comments in tep_db_input. Looks a bit weird having all that recursion, I hope it doesn't impact performance, but it looks like the SQL errors are fixed.

 

HOWEVER, I have found a *MAJOR BUG* in paypal-ipn. I assume that this is the place to post it. This doesn't actually stop the IPN's from being sent/received, but it does prevent osC from properly recognizing them and therefore upgrading the Status on an order (as defined in the admin CPL for paypal IPN).

 

I spent an eternity thinking the errors were caused by illegal characters in the comments of a transaction, but this turned out to be  a three-hour red herring. Here is the problem:

 

1. Under certain mathematical circumstances, if products are priced in USD, and the user switches to another non-default currency, in my case CAD, there is a peculiar rounding error (not sure if it's in the paypal-ipn module or elsewhere). This causes the Sub-Total + Shipping Cost to be actually one cent *greater* than the listed Total.

 

2. You see this when you get the checkout confirmation page. By this time, even before going to paypal, the IPN part of the transaction is doomed. You look at the subtotal, the shipping cost, and then think "what? why is that total off by one?" The total is one cent less.

 

3. From this point on, assuming you have IE and a test shopper in one window, and Firefox and the admin CPL in another window, you can monitor the following progress.

 

a) admin sees an order in Preparing [Paypal IPN] status. Clicking on it shows the comments field containing the "Interim transaction Paypal IPN" message preceding the actual customer comments.

 

B) shopper logs into paypal, and completes the payment. shopper does NOT yet hit the continue button to return to the store.

 

c) admin refreshes orders and sees that there are two status entries now. The first one, documenting the Preparing [Paypal IPN] status, still looks the same. There is a red X beside it for customer notification.  The second entry has a different timestamp (depending on how fast the IPN came back). This is the actual IPN, verified by the message from paypal saying user is a verified user, transaction complete, etc. HOWEVER, the status is still set to Preparing [Paypal IPN]. This is obviously wrong, as the notification has not only been sent but been actually (momentarily) recorded by osC.

 

d) shopper hits the continue button on paypal to return to osC, which triggers a bunch of stuff, including an email being sent, and...

 

e) admin refreshes order, and suddenly sees that the "Interim Paypal IPN transaction" message has disappeared from the first status-comment pair, to be replaced by just the comment itself. There is a green check mark beside it saying the customer has been notified. HOWEVER, here is another bug, the second status message NO LONGER contains the IPN information from Paypal, it now matches the original customer comment. In fact it even has a green checkbox beside it (which is ridiculous since only one email was sent out). It looks like a dupe in every way except for the timestamp, which is still the correct one -- and this is the only vestige of the successful IPN from paypal.

So basically what is happening here is that Paypal is sending an IPN for a given amount, say X, and paypal-ipn.php (I'm assuming) gets confused, because it was for an order with a total, in its mind, of X - 0.01. Since the amounts don't match it ventures off into absurdly buggy territory, the status is never automatically fixed, and it has nothing to do with IPN being broken from Paypal.

 

This is a potentially huge bug for anyone selling items that need to become automatically available through IPN, like software. I am not sure if this ever happens in the base currency, looks like it can only happen in a non-default currency, and then maybe only if the exchange rate causes potential rounding errors.

 

So the question is, whose fault is this, and where should it be fixed? Is the rounding occuring in the paypal-ipn module, or the order total module, or shipping, or what?

 

If anyone wants more details, I've got 'em! Please don't let this post fall through the cracks; this is important to fix!

 

just experimenting here, but would it help to set admin/mystore/tax decimal places to 4?


:-)

Monika

 

addicted to writing code ... can't get enough of databases either, LOL!

 

my toolbox: Textpad - Compare and Merge - phpMyAdmin - WS_FTP - Photoshop - How to search the forum

 

Interactive Media Award July 2007 ~ category E-Commerce

my advice on the forum is for free, PMs where you send me work are considered consultation which I charge for ...

Share this post


Link to post
Share on other sites
The patch titled:

 

missing tep_get_prid() function calls - PATCH for PayPal IPN Module v1.1

 

has a .diff file to download.

Can anyone tell me exactly how I would patch v 1.1 with this .diff file so I can see my product attributes?

 

Thanks.

Check out the comments on this diif file in the latest download 1.2.1

 

I had a note back from the author of this diff file explaining that the way to proceed was to subtract the lines with a "-" in front of them and replace it with the lines that had a "+" in front of them

 

However it would seem that it doesn't apply to all mods that you have installed and could be a bit of a red herring

 

Steve

Share this post


Link to post
Share on other sites
Made no difference whatsoever.

 

If I understand you correctly, I think the problem is down to a combination of decimal places and rounding - PayPal uses different settings to osC.

 

Then, this line fails:

 

if ($_POST['mc_gross'] == number_format($total['value'] * $order['currency_value'], $currencies->get_decimal_places($order['currency']))) {

 

so the status is not updated correctly to give an indication of a problem. The answer would seem to be to set your osC to exactly the same decimal places and rounding method as PayPal (what is it???) or to make the above line a bit more fuzzy?


Ian-san

Flawlessnet

Share this post


Link to post
Share on other sites
If I understand you correctly, I think the problem is down to a combination of decimal places and rounding - PayPal uses different settings to osC.

 

Then, this line fails:

 

if ($_POST['mc_gross'] == number_format($total['value'] * $order['currency_value'], $currencies->get_decimal_places($order['currency']))) {

 

so the status is not updated correctly to give an indication of a problem. The answer would seem to be to set your osC to exactly the same decimal places and rounding method as PayPal (what is it???) or to make the above line a bit more fuzzy?

 

yup, that's why I suggested the 4 decimals ... you could try 2 too :-)


:-)

Monika

 

addicted to writing code ... can't get enough of databases either, LOL!

 

my toolbox: Textpad - Compare and Merge - phpMyAdmin - WS_FTP - Photoshop - How to search the forum

 

Interactive Media Award July 2007 ~ category E-Commerce

my advice on the forum is for free, PMs where you send me work are considered consultation which I charge for ...

Share this post


Link to post
Share on other sites

Well, here is what I think, so correct me if I'm wrong.

 

I am passing the totals to paypal as an aggregate (not per item).

 

It looks like Paypal is basically just accepting what it receives from osCommerce, namely that the SUBTOTAL is X, the SHIPPING RATE is Y, and it looks to ignore what osC claims as the total.

 

So, Paypal just adds X+Y and comes up with a total. This total is sometimes one cent off osC's own total, due to some bizarre rounding error.

 

Looks to me like the solution would be to fix osC's rounding so that its own total works out to be the sum of the subtotal plus shipping (I'm not messing around with tax yet).

 

But you are saying it might be a mismatch between the rounding scheme used on PayPal and that on osC? I don't see how that's the case, though -- the problem is, osC's own total doesn't even match with its own subtotal and shipping!

 

I can try the 2 decimal places thing, but I doubt it'll help. The main goal here is to eliminate osC's rounding problem, but in the install.html that came with the paypal-ipn module, it does list that as one of the known issues when using foreign currencies. I wonder what the technical reasons for that could be.

Share this post


Link to post
Share on other sites
Well, here is what I think, so correct me if I'm wrong.

 

I am passing the totals to paypal as an aggregate (not per item).

 

It looks like Paypal is basically just accepting what it receives from osCommerce, namely that the SUBTOTAL is X, the SHIPPING RATE is Y, and it looks to ignore what osC claims as the total.

 

So, Paypal just adds X+Y and comes up with a total. This total is sometimes one cent off osC's own total, due to some bizarre rounding error.

 

Looks to me like the solution would be to fix osC's rounding so that its own total works out to be the sum of the subtotal plus shipping (I'm not messing around with tax yet).

 

But you are saying it might be a mismatch between the rounding scheme used on PayPal and that on osC? I don't see how that's the case, though -- the problem is, osC's own total doesn't even match with its own subtotal and shipping!

 

I can try the 2 decimal places thing, but I doubt it'll help. The main goal here is to eliminate osC's rounding problem, but in the install.html that came with the paypal-ipn module, it does list that as one of the known issues when using foreign currencies. I wonder what the technical reasons for that could be.

 

The PayPal guide seems to suggest that PayPal can only work with two decimal places - I guess it truncates after that.

 

On the other hand, osC can work with multiple decimal places. So for a foreign currency, the calculated amount will be in many decimal places but only displayed in the required number. I guess you are unlikely to price in your own currency to multiple decimals.

 

I dont think changing the decimal places in admin will have any effect as it is just changing the display not the calculated or stored amount.

 

The solution would require a change to osC core code to force everything to be stored and displayed in 2 decimals which wouldnt suite everyone. Alternatively, you could force payment in your home currency so that rounding problems dont exist. Or, as I said above, make the if statement in ipn.php more fuzzy.


Ian-san

Flawlessnet

Share this post


Link to post
Share on other sites

I have a question about an added parameter for this mod. I read what Ian said about the necessity for the customer to click through so that the email actually gets sent. So I pasted this code into my paypal_ipn page.

$parameters['cbt'] = 'Click to Complete Order!';

 

Now when an a customer is on paypal and they hit "pay" or "submit" or whatever that button is, Paypal brings them to a page that says "please wait while you are redirected within 10 seconds" and automatically redirects them to my own checkout_suceess.php page. I thought this was a great thing, until I got more orders in with no actual OSC order emails.

 

Do I need to paste all my paypal_ipn code here? I did add a few mods to this contrib, for example the parameters to move the shipping info, as well as the tax total mods..

 

Thank you.

Share this post


Link to post
Share on other sites
Check out the comments on this diif file in the latest download 1.2.1

 

I had a note back from the author of this diff file explaining that the way to proceed was to subtract the lines with a "-" in front of them and replace it with the lines that had a "+" in front of them

 

However it would seem that it doesn't apply to all mods that you have installed and could be a bit of a red herring

 

Steve

 

 

Thanks, but even with that in mind it is very confusing :blink: It is very important that I start getting the correct attributes in my e-mail - I have no idea how to use this patch though!

Share this post


Link to post
Share on other sites
The PayPal guide seems to suggest that PayPal can only work with two decimal places - I guess it truncates after that.

 

On the other hand, osC can work with multiple decimal places. So for a foreign currency, the calculated amount will be in many decimal places but only displayed in the required number. I guess you are unlikely to price in your own currency to multiple decimals.

 

I dont think changing the decimal places in admin will have any effect as it is just changing the display not the calculated or stored amount.

 

The solution would require a change to osC core code to force everything to be stored and displayed in 2 decimals which wouldnt suite everyone. Alternatively, you could force payment in your home currency so that rounding problems dont exist. Or, as I said above, make the if statement in ipn.php more fuzzy.

 

What I still don't understand is what values are actually passed to Paypal. Are you saying osC passes the subtotal and shipping amounts (to multiple decimal places) and then Paypal rounds it to 2 places?

 

I'm just not following why, even *IN* osC itself, the subtotal + shipping is a different number than the listed total.

 

I'm all for changing the code wherever it needs to be changed.

 

if ($_POST['mc_gross'] == number_format($total['value'] * $order['currency_value'], $currencies->get_decimal_places($order['currency']))) {

 

Do I have to change $currencies->get_decimal_places by putting some sort of rounding wrapper around it?

 

I'd be grateful if you could tell me what to change it to, or at least point me in the right direction by telling me which function reference I should look up.

Share this post


Link to post
Share on other sites
I have a question about an added parameter for this mod.  I read what Ian said about the necessity for the customer to click through so that the email actually gets sent.  So I pasted this code into my paypal_ipn page.

$parameters['cbt'] = 'Click to Complete Order!';

 

Now when an a customer is on paypal and they hit "pay" or "submit" or whatever that button is, Paypal brings them to a page that says "please wait while you are redirected within 10 seconds" and automatically redirects them to my own checkout_success.php page.  I thought this was a great thing, until I got more orders in with no actual OSC order emails.

 

Do I need to paste all my paypal_ipn code here?  I did add a few mods to this contrib, for example the parameters to move the shipping info, as well as the tax total mods..

 

Thank you.

 

OK... well I got the redirect to stop, by turning off the paypal option that automatically redirects you to a page after payment. BUT, even when I test it by clicking the "Confirm Order" button... I still get no emails from OSC. This was all on sandbox though. I am going to wait and see what happens when I get another order in. I would still appreciate any thoughts.

Edited by MechBun

Share this post


Link to post
Share on other sites
I have a question about an added parameter for this mod.  I read what Ian said about the necessity for the customer to click through so that the email actually gets sent.  So I pasted this code into my paypal_ipn page.

$parameters['cbt'] = 'Click to Complete Order!';

 

Now when an a customer is on paypal and they hit "pay" or "submit" or whatever that button is, Paypal brings them to a page that says "please wait while you are redirected within 10 seconds" and automatically redirects them to my own checkout_suceess.php page.  I thought this was a great thing, until I got more orders in with no actual OSC order emails.

 

Do I need to paste all my paypal_ipn code here?  I did add a few mods to this contrib, for example the parameters to move the shipping info, as well as the tax total mods..

 

Thank you.

 

Somebody else may know better than me - all this line does is to rename the final "continue" button. I am not aware of any auto-direct so this must be the result of some other setting you have made to your PayPal?


Ian-san

Flawlessnet

Share this post


Link to post
Share on other sites
I ended up finding one tep_db_query which had the comments variable in it, and I wrapped that comments in tep_db_input. Looks a bit weird having all that recursion, I hope it doesn't impact performance, but it looks like the SQL errors are fixed.

 

HOWEVER, I have found a *MAJOR BUG* in paypal-ipn. I assume that this is the place to post it. This doesn't actually stop the IPN's from being sent/received, but it does prevent osC from properly recognizing them and therefore upgrading the Status on an order (as defined in the admin CPL for paypal IPN).

 

I spent an eternity thinking the errors were caused by illegal characters in the comments of a transaction, but this turned out to be  a three-hour red herring. Here is the problem:

 

1. Under certain mathematical circumstances, if products are priced in USD, and the user switches to another non-default currency, in my case CAD, there is a peculiar rounding error (not sure if it's in the paypal-ipn module or elsewhere). This causes the Sub-Total + Shipping Cost to be actually one cent *greater* than the listed Total.

 

2. You see this when you get the checkout confirmation page. By this time, even before going to paypal, the IPN part of the transaction is doomed. You look at the subtotal, the shipping cost, and then think "what? why is that total off by one?" The total is one cent less.

 

3. From this point on, assuming you have IE and a test shopper in one window, and Firefox and the admin CPL in another window, you can monitor the following progress.

 

a) admin sees an order in Preparing [Paypal IPN] status. Clicking on it shows the comments field containing the "Interim transaction Paypal IPN" message preceding the actual customer comments.

 

B) shopper logs into paypal, and completes the payment. shopper does NOT yet hit the continue button to return to the store.

 

c) admin refreshes orders and sees that there are two status entries now. The first one, documenting the Preparing [Paypal IPN] status, still looks the same. There is a red X beside it for customer notification.  The second entry has a different timestamp (depending on how fast the IPN came back). This is the actual IPN, verified by the message from paypal saying user is a verified user, transaction complete, etc. HOWEVER, the status is still set to Preparing [Paypal IPN]. This is obviously wrong, as the notification has not only been sent but been actually (momentarily) recorded by osC.

 

d) shopper hits the continue button on paypal to return to osC, which triggers a bunch of stuff, including an email being sent, and...

 

e) admin refreshes order, and suddenly sees that the "Interim Paypal IPN transaction" message has disappeared from the first status-comment pair, to be replaced by just the comment itself. There is a green check mark beside it saying the customer has been notified. HOWEVER, here is another bug, the second status message NO LONGER contains the IPN information from Paypal, it now matches the original customer comment. In fact it even has a green checkbox beside it (which is ridiculous since only one email was sent out). It looks like a dupe in every way except for the timestamp, which is still the correct one -- and this is the only vestige of the successful IPN from paypal.

So basically what is happening here is that Paypal is sending an IPN for a given amount, say X, and paypal-ipn.php (I'm assuming) gets confused, because it was for an order with a total, in its mind, of X - 0.01. Since the amounts don't match it ventures off into absurdly buggy territory, the status is never automatically fixed, and it has nothing to do with IPN being broken from Paypal.

 

This is a potentially huge bug for anyone selling items that need to become automatically available through IPN, like software. I am not sure if this ever happens in the base currency, looks like it can only happen in a non-default currency, and then maybe only if the exchange rate causes potential rounding errors.

 

So the question is, whose fault is this, and where should it be fixed? Is the rounding occuring in the paypal-ipn module, or the order total module, or shipping, or what?

 

If anyone wants more details, I've got 'em! Please don't let this post fall through the cracks; this is important to fix!

 

 

I followed the above through, using the Sandbox and although the default currency is in Euro when I select USD OSC rounds the sub total down by 1 cent, however this does not seem to impact the sale as the downloads appear on the download page and my account is credited with the (incorrect?) amount.

 

Does this mean that although a one cent difference is displayed but not actually used in the calculation...I cam live with the one cent diff in the FX amount!!

 

Steve

Share this post


Link to post
Share on other sites
I followed the above through, using the Sandbox and although the default currency is in Euro when I select USD OSC rounds the sub total down by 1 cent, however this does not seem to impact the sale as the downloads appear on the download page and my account is credited with the (incorrect?) amount.

 

Does this mean that although a one cent difference is displayed but not actually used in the calculation...I cam live with the one cent diff in the FX amount!!

 

Steve

 

It doesn't impact the sale at all. I am not sure how it interacts with automatic downloads, because I have no experience with that.

 

The one thing it impacts is the automatic updating of order status. Even though the IPN is successful, osC does not update the order's status to what it's supposed to (upon IPN verification). I thought this was a huge deal for automatic downloads because I thought maybe they are dependent on the order entering a "Payment Received" status, but maybe not.

 

It's still an issue though, because the store admin has to manually change status on these orders, or manually verify that payment has been sent, because unfortunately, the Paypal IPN status codes *are deleted from the comments of the order* once the buyer returns to the store.

 

In a way, it's better for the buyer not to return to the store in this case, so that the IPN notification remains in the order (easier for the seller to verify payment was made without opening another window and going to paypal). However that opens up another can of worms, such as the order not being stored in the user's "View Orders" page, and of course *STOCK NOT BEING REDUCED BY THE ORDER AMOUNT* which is rather a huge problem.

Share this post


Link to post
Share on other sites

Hi

 

I hope this is the right thread to ask for this module! I'm a complete noob, so answers are not obvious to me!

 

I have been lurking on the forums for a few days now, and I haven't seen this question in any of the threads I've read.

 

I have the os commerce paypal IPN module installed (ver 1.2.1).

 

The issue is that when I turn on encryption in the admin console, and then make a test sale. I go to the checkout screen and select a payment method (the paypal IPN module). when i click continue, the next screen says "this page cannot be displayed".

 

When I elect to turn off the encryption, and go through the same process, it takes me to my sandbox test account.

 

Why is this? Can someone help me on this issue?

 

I'm pretty sure I have all the other settings correct, I have the public and private certificates listed correctly in the admin control panel, as well as a certificate ID. I left the working directly and the openssl directory as the default values.

 

I even backed up everything, and reinstalled os commerce, with just the IPN module, set everything up, but I run into the same error situation as described above. My webhost suggested to me that I needed a paypal merchant account. I didn't think so, but can anyone confirm this?

 

Does anyone know how I can fix this?

 

Thanks

 

Scott

Share this post


Link to post
Share on other sites

Just to add an addendum, I am absolutely positive that I've installed this correctly, with the correct options. I even found a page that exactly spelled out what options to choose, and what to enter here.

 

maybe it's something with the webhost? they had said I needed a merchant gateway. I don't believe so, since it seems like sooo many other people here just installed, and away they went.

 

anyone have any insight? (see previous post for my problem)

 

PS. my web hosting company is www.dot5hosting.com. hope this info helps someone help me!

 

Thanks!

 

Scott

Edited by sukotto

Share this post


Link to post
Share on other sites

I wish I could help you, but I just don't know enough about it. I never got that error page that you get. I did initially have a problem with the IPN's not coming back, but that was my fault (forgot to copy ipn.php to the top level, i.e. in /catalog!!)

 

I realize this isn't helpful, but I just wanted to say I'm sure someone will help you figure it out soon. It took me billions of tries, and in the end it wasn't my Paypal IPN config at all, it was a missing file!

 

Make sure the paths to things are absolute, though. Can never be too sure. And of course check that the certificate ID you got from paypal is correct. Make sure the key you got from paypal is readable, and in correct text format.

 

I recall some other trick, too, where you had to do some pasting to your own public key. But anyway, I followed the official instructions and in the end it worked.

 

Post your Paypal-IPN config values.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×