Jump to content

bobonala

Members
  • Content count

    12
  • Joined

  • Last visited

Profile Information

  • Real Name
    Rob Chalmers
  1. Matt, Sorry I don't have an answer to your question. However, on Friday (the 13th!) PayPal unveiled a "new and improved" IPN which has been giving lots of people headaches. Have a look here: http://www.paypaldev.org/forum.asp?FORUM_ID=10 Rob
  2. bobonala

    PayPal_Shopping_Cart_IPN

    Are you sure about that? No, not really sure. I THOUGHT that IPN would send a communication back to the osCommerce store as soon as the customer successfully reached PayPal's "You Made a Payment" page. There's a "Continue" button on that page which will submit a form passing payment details back to the osCommerce store (and redirect the customer there as well). If the customer clicks this button, the order should get logged in the osCommerce database, but -- as far as I understand it -- this is not IPN. IPN is supposed to work independently of the above operation. However, on the osCommerce side of the fence, I don't know whether the IPN transaction BECOMES the order in the event that the customer didn't click "Continue", or whether it merely provides a report that so-and-so has made a payment. I thought that it merely served as a detailed receipt from PayPal, which -- in the absence of an order -- could be used to construct a customer order. I did not think that an IPN transaction alone was able to actually insert a new order into the osCommerce database. But maybe this is my misunderstanding? I tried a test transaction just now, but unfortunately I didn't get any IPN information logged back on my server. I don't know if something's broken on my end (it worked when I was testing it earlier), whether it's just a temporary hiccup, or whether the IPN changes that PayPal implemented today are to blame. Rob (hoping someone will shed more light on this topic)
  3. bobonala

    PayPal_Shopping_Cart_IPN

    Shanna, re: orders not being received after PayPal payment... This is a known "feature" of osCommerce. You won't get the order unless the customer follows the link back to your site after paying via PayPal. The IPN partially addresses this problem by at least giving you notification that a Payment was received, and the Itemized Cart option helps even further. But it's still a nuisance. If it's working properly, the IPN reports will be available to you from the osCommerce "Customers" section of the admin interface (you should find "PayPal IPN" listed beneath "Customers" and "Orders"). The restriction to only 2 product "attributes" in the paypal.php code... I believe this is a limitation of the PayPal IPN. The interface provides only two variables for passing extra information for items in the cart. Take a look here: http://www.paypal.com/cgi-bin/webscr?cmd=p...-manual-outside Rob
  4. bobonala

    PayPal_Shopping_Cart_IPN

    Lupine - Thanks for the contribution. This fix is working for me! Greg - i hope you'll add this update to your contribution in the download area. The fix doesn't address the two-decimal place truncation issue, so there can still be errors in the final calculation ($0.075 being passed as $0.08). But the only real fix for this is for PayPal to make a change on their side. Even doing something "tricky" (using only one line item in the cart as the "tax conduit") doesn't handle all cases. Rob
  5. bobonala

    PayPal_Shopping_Cart_IPN

    Just got an email from PayPal regarding a change they are making to IPN. I think that it only affects the way the IPN handles refunds and reversals. More info here: http://paypal.typepad.com/pdn/2004/02/noti...pal_i.html#more The change is scheduled to occur on 13 February. Rob
  6. bobonala

    PayPal_Shopping_Cart_IPN

    More debugging... This is extracted straight from the submit form that is embedded in the confirm page of my sample shopping cart. It was produced with an unmodified install of PayPal Shopping Cart IPN 1.5: The sales tax for the entire order ($5.00) is correctly displayed on the confirm page. I don't think that it's a coincidence that this is the same value showing up in the form data that is being passed to PayPal. I've tested it with several different shopping carts that I've passed to paypal.php. From what I've seen, the only way that a cart will ever pass the correct tax is if it contains a single item. Here's your suggested fix #2... before fix: $paypal_fields .= tep_draw_hidden_field('tax_'.$index, number_format($order->info['tax'] * $currencies->get_value($my_currency),2)); after fix: $paypal_fields .= tep_draw_hidden_field('tax_'.$index, number_format((($order->products[$i]['tax'] / $order->products[$i]['qty'])) * $currencies->get_value($my_currency),2)); This code results in the following: Unfortunately, this result is not correct either. The code change merely caused the total tax for the entire order to be divided by the quantity requested of a given line item. As you can see, I ordered 3 of item 1, 2 of item 2 and 7 of item 3. Doing the math: 3*1.67 == 2*2.50 == 7*0.71 == 5.00! In order to achieve the correct total as far as PayPal is concerned, the above tax values would each need to be divided by the total number of line items in the cart (3 line items in this case). However, even after doing this, the values being passed will still be meaningless as individual numbers (I should not be paying $1.67 in tax on a Killer Rabbit that only costs $1!). However, for someone like me who doesn't understand the code, a good fix seems to be in reach (this is what I was trying to point out in my previous message). We've verified that the current, unmodified code can reliably obtain these two pieces of information: a] the total tax for the entire order b] the quantity of line items in the order Furthermore, from the results of your modification #2 above, we also know how to divide the total tax for the entire order by the quantity of a given line item (i.e. divide $5.00 by 3 Killer Rabbits). Or divide $5.00 by 2 African Swallows. It doesn't matter. This is good because we know that when this cart finally gets passed PayPal, PayPal is going to multiply the line item tax by the line item quantity. So, the simple thing to do is to just send this already-existing information with one of the line items in the cart, and "zero out" the tax values that are sent with all of the remaining line items. As I mentioned, in addition to being easier than trying to figure out how to get the proper values in the proper places, I think it may be a better solution overall, due to PayPal's roundoff/truncation problem. Rob
  7. bobonala

    PayPal_Shopping_Cart_IPN

    re: Problem with taxes passed via Shopping Cart Method 2 (Itemized) ($order->products[$i]['tax'] / $order->products[$i]['qty']) I think that your second solution (above) is definitely on the right track. The PHP is still over my head, but just looking at the result it looks like the code still needs to divide each component value by the total number of line items in the cart. I'm guessing that this is "sizeof($order->products)"? My test cart contains multiple quantities of three different items, and with your second solution, the total tax calculated by PayPal is only $14.98 (should be $5). Unfortunately, the truncation error is already significant, and it'll only be worse after dividing by 3. I just had an idea that might solve the whole thing and also help with the truncation problem. What do you think of this: Right now, your unmodified code passes "order_total_tax" as "tax_n" for each line item in the order. What if the code were tweaked to divide "order_total_tax" by "quantity_1" and pass that result as "tax_1" for the first line item in the order? For the remaining line items (n>>1), we would simply pass a value of zero as "tax_n". In pseudo-code, something like this... do i = 1, n_line_items tax_(i) = order_total_tax / quantity_(i) if( i >> 1 ) tax_(i) = 0. enddo In essence, you're using only one line item as your conduit for passing tax information to PayPal. As far as I can tell, this little bit of sneakiness will be completely hidden to the customer, and won't alter the transaction information reported by PayPal or osCommerce in any way. This approach would also help to reduce the total truncation error because order_total_tax will be passed to PayPal with a single line item rather than tallied up among many items. In fact, if the cart happens to have a quantity of 1 associated with line item 1, PayPal will calculate the tax perfectly, regardless of what the rest of the cart contains! Anyway, for my test cart (3 line items), Before and After results would be: <input type="hidden" name="item_name_1" value="Killer Rabbit"> <input type="hidden" name="item_number_1" value="TEST-1"> <input type="hidden" name="quantity_1" value="3"> <input type="hidden" name="amount_1" value="1.00"> before fix:<input type="hidden" name="tax_1" value="5.00"> after fix:<input type="hidden" name="tax_1" value="1.67"> (should we round up or just truncate?) new "tax_1" is original "tax_1" divided by "quantity_1" (5.00/3) ... <input type="hidden" name="item_name_2" value="African Swallow"> <input type="hidden" name="item_number_2" value="TEST-2"> <input type="hidden" name="quantity_2" value="2"> <input type="hidden" name="amount_2" value="45.00"> before fix:<input type="hidden" name="tax_2" value="5.00"> after fix:<input type="hidden" name="tax_2" value="0.00"> tax is only passed with first line item, set this one to zero ... <input type="hidden" name="item_name_3" value="European Swallow"> <input type="hidden" name="item_number_3" value="TEST-3"> <input type="hidden" name="quantity_3" value="7"> before fix:<input type="hidden" name="amount_3" value="1.00"> after fix:<input type="hidden" name="tax_3" value="0.00"> tax is only passed with first line item, set this one to zero Extra Credit: :P With a little extra coding (well, maybe a lot!), you could actively seek out the line item that has the lowest "quantity_n" and use that one for your hidden "PayPal tax pass through", setting the tax on all the others to zero. This would minimize the number of times you might wind up facing the awkward situation where your $5.00 "order total tax" gets divided by 375 cheap little widgets (Murphy's Law placed them as item #1 in the cart). So, your $5.00 tax winds up getting divided by 375, truncated to two decimal places, passed to PayPal, and then reconstituted (badly) to only $3.75!! If the customer had been so helpful as to place only 1 ugly little widget as line item #2 in their cart, you could have used your extra coding to choose that item to be your hidden tax pass through, and PayPal would (miraculously!) calculate the tax perfectly. rob
  8. bobonala

    PayPal_Shopping_Cart_IPN

    re: Problem with taxes passed via Shopping Cart Method 2 (Itemized) Oops, my bad. I realize that the IPN is for the communication received back from PayPal. I've just downloaded a copy of the PayPal Shopping Cart Manual and see some stuff in there that seems relevant. Gonna go do some more reading now...
  9. bobonala

    PayPal_Shopping_Cart_IPN

    re: Problem with taxes passed via Shopping Cart Method 2 (Itemized) No joy on the first suggested fix. I haven't tried the second because I don't yet understand the code well enough to know exactly what you're suggesting (I've never fooled around with PHP before). However, it doesn't seem right to me that a tax value should be passed for every line item in the order. Is that what PayPal IPN expects? Seems like it would be more sensible to pass a single tax value for the entire order (i.e. in the same manner that shipping is passed). If I can find a little time to make sense of PHP syntax, I may be in a better position to offer an idea. FWIW, I found this forum on the PayPal Developer Network, and I may be poking around over there in hopes of learning more... http://www.paypaldev.org/forum.asp?FORUM_ID=24 Rob
  10. bobonala

    PayPal_Shopping_Cart_IPN

    Aha! Thanks for the tip; I took a look at the source on the confirm page and all is revealed. All of the individual products in the shopping cart are being passed as expected. However, it's incorrectly including the aggregate tax with each item ($10.50 in the sample below). So, unless you have only one item_name in your shopping cart, the computed tax in PayPal is going to be some multiple of the correct tax. Hopefully, this will be easily fixable in paypal.php... <input type="hidden" name="item_name_1" value="Big Dumb Thing"> <input type="hidden" name="item_number_1" value="BIGDUM"> <input type="hidden" name="quantity_1" value="3"> <input type="hidden" name="amount_1" value="50.00"> <input type="hidden" name="tax_1" value="10.50"> <input type="hidden" name="on0_1"> <input type="hidden" name="os0_1"> <input type="hidden" name="on1_1"> <input type="hidden" name="os1_1"> <input type="hidden" name="item_name_2" value="Little Dumb Thing"> <input type="hidden" name="item_number_2" value="LITDUM"> <input type="hidden" name="quantity_2" value="1"> <input type="hidden" name="amount_2" value="50.00"> <input type="hidden" name="tax_2" value="10.50"> <input type="hidden" name="on0_2"> <input type="hidden" name="os0_2"> <input type="hidden" name="on1_2"> <input type="hidden" name="os1_2"> <input type="hidden" name="item_name_3" value="Silly Test Item"> <input type="hidden" name="item_number_3" value="TEST-1"> <input type="hidden" name="quantity_3" value="2"> <input type="hidden" name="amount_3" value="5.00"> <input type="hidden" name="tax_3" value="10.50"> <input type="hidden" name="on0_3"> <input type="hidden" name="os0_3"> <input type="hidden" name="on1_3"> <input type="hidden" name="os1_3">
  11. bobonala

    PayPal_Shopping_Cart_IPN

    Thanks, I've read about PayPal's 2 decimal places limitation. But this error is grossly big (osCommerce correctly determines sales tax to be $1 but PayPal thinks it is $7!). Do you know if there's an easy way to see exactly what information is being passed when customer hits the button that redirects to PayPal? Maybe the debug modes? I'm going to enable debugging and try some more experimenting... rob
  12. bobonala

    PayPal_Shopping_Cart_IPN

    Greg, I've installed PayPal_Shopping_Cart_IPN_v1.5 (great contribution!) and have run across a little problem. I'm running osCommerce 2.2MS2. When I select Shopping Cart Method 1 (aggregate), everything seems to work well. However, when I choose Shopping Cart Method 2 (itemized), I'm seeing a bad sales tax calculation appearing on the PayPal confirmation page. The sales tax is displaying correctly on the osCommerce side. Has anyone else had a problem like this? Any tips on how to debug? I do NOT have any sales tax calculation enabled in my PayPal profile (Selling Preferences). Thanks, Rob
×