Jump to content
Sign in to follow this  
devosc

PayPal_Shopping_Cart_IPN

Recommended Posts

I came across another contribution yesterday that was of interest called held_orders which put an order into a seperate table prior to updating the main 'orders' table, which I think would be the way to go for pending status; but (I assume) all this would then require a lot more changes within osC, etc.

 

Anyway, if I have the time, I will try and put together another version update soley to include the remedies discussed so far in this thread - to save others from trawling through the first 20 odd pages of this thread. Please post any ideas.

 

I haven't had time to think about pending payments all the way through, so if someone could clearly outline what they think should generally happen, a better picture can be built from which it would be easier to actually develop.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Hi i have installed your paypal addon and tested it

when i pay and click continue it goes to a blank screen with

 

www.airsoftmart.net/catalog/checkout_process.php in the address bar

 

i have the ipn in paypal setup ok

 

www.airsoftmart.net/catalog/ipn.php

 

when i go to that page though i get this error

 

Parse error: parse error, expecting `')'' in /home/sites/site5/web/catalog/ipn.php on line 14

 

any clues !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Share this post


Link to post
Share on other sites

See page 15 of this thread, also look at page fourteen, both pages have suggested code changes, you might also read page 1 which discusses email.

 

Upload a new version of catalog/ipn.php, you shouldn't of receieved a parse error on that page for that line, unless you edited it.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

i have uploaded a brand new ipn.php which has not been edited

 

still get the error

 

so i downloaded paypal 1.5

 

unpacked it

 

copy the files

 

error still comes up

 

still get a blank screen after clicking continue

 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Share this post


Link to post
Share on other sites

ok changed the ipn.php as on page 14 now i get these errors

also the sale is still not recorded till i click CONTINUE ?????????

after clicking CONTINUE me and the customer gets email and amin too

no ipn info though

nothing filled in on the customer invoice or in the ipn screen

 

via email

 

1.

Airsoftmart PayPal IPN: unkown verification occurrence

Connection Type

curl= socket=tcp:// domain=www.paypal.com port=80

#####################

 

2.

Airsoftmart PayPal IPN: unkown transaction type

I received an unkown post from

Are you running any tests?

 

3.

Airsoftmart PayPal IPN: Invalid Customer Transaction

A transaction occured but PayPal did not verify it, this could be due to a communications error, but it could also be an attempted hack.

Customer 3, cust name has been allowed to continue their order.

Please Check Your PayPal account.

 

4.

Airsoftmart PayPal IPN: HTTP Error

An HTTP Error occured during authentication curl= socket=tcp:// domain=www.paypal.com port=80

#####################

 

any clues !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Share this post


Link to post
Share on other sites

sounds like you might need to do this:

Others have had this problem too;

Replace the existing authenticate($domain) function in /catalog/includes/classes/paypal/ipn.php with the following code:

  function get_paypal_response() {
   $paypal_response = file('http://www.paypal.com/cgi-bin/webscr?'.$this->_response_string);
   return $paypal_response[0];
 }

 function authenticate($domain) {
   $paypal_response = $this->get_paypal_response();
   if (strstr($paypal_response,'VERIFIED')) {
     if($this->_debug >1 ) $this->send_email('VERIFIED',"Connection Type\r\ncurl=$curl_flag socket=$socket domain=$domain port=$port\r\n#####################\r\n".$paypal_response."\r\n\r\n");
     return true;
   } else if (strstr($paypal_response,'INVALID')) {
     // log for manual investigation
     if($this->_debug > 1) $this->send_email('INVALID',"Connection Type\r\ncurl=$curl_flag socket=$socket domain=$domain port=$port\r\n#####################\r\n".$paypal_response."\r\n\r\n");
     return false;
   } else {
     if($this->_debug) $this->send_email('unkown verification occurrence',"Connection Type\r\ncurl=$curl_flag socket=$socket domain=$domain port=$port\r\n#####################\r\n".$paypal_response."\r\n\r\n");
     return false;
   }
 }

Hopefully this will get you on track.

Greg.

Also remember page 15.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Hi i have added the code as sugested but now when i checkout and pay and

click continue to come back to my site

 

the checkout page does not come up

 

i think i may have pasted the code in the wrong place

 

can you give me some idea when it has to go

Edited by airsoftmart

Share this post


Link to post
Share on other sites

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.

 

osCommerce:

Sub-Total: $20.00

MD TAX 5.0%: $1.00

Table Rate (Best Way): $5.00

Total: $26.00

 

PayPal:

Pay To:  RIVNA Arts 

User Status:  Verified Business Member

Payment For:  Shopping Cart 

Currency:  U.S. Dollars 

Amount:  $20.00 USD 

Shipping & Handling:  $5.00 USD

Sales Tax:  $7.00 USD 

Total Amount:  $32.00 USD

 

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

Share this post


Link to post
Share on other sites

Rob :),

 

PayPal only works to 2d.p.

You could try setting the the decimal places in osC admin and/or (if possible) also set this in the PHP.ini file, otherwise might have to further coax osC.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

You can view the source of the page when hitting the osC confirm button.

 

It's been awhile so it's not fresh in my mind, if you could list the products price their respective quantities, it migh jog me. If I can remeber correctly PayPal will multiply the tax for an indivual product and then multiply it by the number of items for that particular product, whereas the osC tax calculation might be just a percentage of the total figure, but I can't remember right. Have a look in /catalog/includes/modules/payment/paypal/php to see how the info is being pulled.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

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">

Share this post


Link to post
Share on other sites

Hi, Rob

 

Try this:

 

find $order->info['tax'] in catalog/includes/modules/payment/paypal.php

and replace with $order->products[$i]['tax']

 

If that doesn't do it, because it could be the tax amount of say 7 items for that individual product, could try dividing by $order->products[$i]['qty']

Edited by gregbaboolal

"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Hi Greg,

 

Handling refunded is not hard to do, but a clear definition of what is expected to happen when a refund notice needs to be made.

 

Specifically, IMO what is required is simply handling the various payment statuses sent by PayPal. Each new status from PayPal for a given order would be stored in a PayPal transaction table always preserving all of the various transaction statuses from PayPal along with the transaction timestamp. A given order would keep track of the current transaction status by looking at the last timestamp. I imagine this is similar to what you have now.

 

A more general feature that belongs in osCommerce is a way to tie a given payment method along with the payment status to an order. This way, if someone pays with PayPal for example, you refund their money, and then they pay with money order we have a way to keep up with that. This would require several generic payment statuses such as unpaid, pending, cleared, refunded, ... It would also require some admin screen for handling those refunds. This is where inventory re-stocking should happen -- at the order level, not handled by a payment method.

 

Of course, I can help with this. I would think that would want to track all non-core oscommerce database changes in a separate table (e.g. orders_transactions). I generally try to steer clear of altering osCommerce tables, because it can burn you later when trying to port your contribution to the next versions.

 

Handling a pending payment probably isn't that difficult either, depending, again, on what you expect to happen, do mean that the status of the IPN is simply updated, and that when a notification is received that the payment is 'Completed' that the stock levels are then updated.

 

IMO, when a *general* payment method is marked Pending, the inventory should be decremented to reserve the item. If payment later fails (either IPN notification or manual change of payment status), the inventory is added back.

 

Further scripting would also be required in order to prevent downloads from immediately being available if a payment is still pending.

 

Agreed. Again, generically, however.

Share this post


Link to post
Share on other sites

Hi Tony,

Some quick responses:

PayPal transaction table
This could be accomodated with a paypal_ipn_history table similar to the orginal osC order_status_history table.
A more general feature that belongs in osCommerce is a way to tie a given payment method along with the payment status to an order.
A new osC db table could be made called order_payment_status, similar to the original osC order_status, but listing the payment status types
unpaid, pending, cleared, refunded, ...
This way, if someone pays with PayPal for example, you refund their money, and then they pay with money order we have a way to keep up with that.
This needs further clarification, the following is some first impressions:
  • The customer can view the payment status in the account history
     
  • If the payment status is not completed or terminated, then in account_history_info.php the customer has the opportunity to recommence the checkout process and select a new payment method (is the shipping address then allowed to be changed?).
     
  • For the storeowner to be able to edit the payment status from the above list etc...
     
  • For the storeowner to be able permanently terminate a transaction order
     
  • Would there still be a need for a sperate paypal_ipn_history table or should there be a generic order_payment_history table - requires more thought maybe.

It would also require some admin screen for handling those refunds. This is where inventory re-stocking should happen -- at the order level, not handled by a payment method
This could be handled on the order page, maybe with some javascript to display a re-stock item checkbox when the storewoner selects refunded. This would be similar to what happens when deleting an order but here the order is not actually deleted - which would then suggest updating the actual deleting order option so that the checkbox does not appear if the products have already been reassigned - how to test requires further thought.
IMO, when a *general* payment method is marked Pending, the inventory should be decremented to reserve the item.
The storeowner can be given this choice as a configuration option.
If payment later fails (either IPN notification or manual change of payment status), the inventory is added back.
This could also be another configuration option.

 

:rolleyes: That's alot of work; It is interesting and I would be willing to help in its development but I am currently obligated elsewhere. I think if a few of the above steps was focused on an re-iterated again explicitly in plain english then transposing it into osC code would be alot less hassle to quickly implement.

 

I won't mention MS3 :blink:


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Quoting David's earlier post:

the old Paypal IPN contribution was all these pending orders that were created in the order table - none of them was ever completed. There was always the risk of despatching the order by mistake and it used to ruin the sequence of order numbers. I hope that feature doesn't get introduced into Paypal Shopping Cart IPN (at least not in the same way)
Given the previous post it would now seem prudent/essential to utilize the held_orders contribution to act as a temporary placeholder for orders until they become completed - again more thought required.

"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Hi

 

This problem has been raised earlier in the thread but I cant seem to get mine fixed.

 

Im getting the following error message in my control pannel in the customers page.

 

1146 - Table 'soundsalarmingdb.TABLE_PAYPAL_IPN' doesn't exist

select count(*) as total from TABLE_PAYPAL_IPN as p, TABLE_PAYPAL_IPN_ORDERS as po, orders as o where p.paypal_ipn_id = po.paypal_ipn_id AND po.paypal_ipn_id = o.paypal_ipn_id AND o.paypal_ipn_id = p.paypal_ipn_id

[TEP STOP]

I have checked to make sure the table is defined in my admin/includes/database_tables.php file, and this seems to be the bit that was added, I presume this is ok?

 //begin PayPal_Shopping_Cart_IPN
 define('TABLE_PAYPAL_IPN', 'paypal_ipn');
 define('TABLE_PAYPAL_IPN_ORDERS', 'paypal_ipn_orders');
 define('TABLE_PAYPAL_IPN_ORDERS_MEMO', 'paypal_ipn_orders_memo');
 define('TABLE_PAYPAL_IPN_TXN_TYPE', 'paypal_ipn_txn_type');
 define('TABLE_PAYPAL_IPN_REASON_CODE', 'paypal_ipn_reason_code');
 define('TABLE_PAYPAL_IPN_PAYMENT_TYPE', 'paypal_ipn_payment_type');
 define('TABLE_PAYPAL_IPN_PAYMENT_STATUS', 'paypal_ipn_payment_status');
 define('TABLE_PAYPAL_IPN_PAYMENT_PENDING_REASON', 'paypal_ipn_pending_reason');
 define('TABLE_PAYPAL_IPN_MC_CURRENCY', 'paypal_ipn_mc_currency');
 define('TABLE_PAYPAL_IPN_PAYMENT_ADDRESS_STATUS', 'paypal_ipn_address_status');
//end PayPal_Shopping_Cart_IPN

Is there anything else that I need to check?

Share this post


Link to post
Share on other sites

re: Problem with taxes passed via Shopping Cart Method 2 (Itemized)

 

Try this:

 

find $order->info['tax'] in catalog/includes/modules/payment/paypal.php

and replace with $order->products[$i]['tax']

 

If that doesn't do it, because it could be the tax amount of say 7 items for that individual product, could try dividing by $order->products[$i]['qty']

 

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

Share this post


Link to post
Share on other sites

re: Problem with taxes passed via Shopping Cart Method 2 (Itemized)

 

...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).

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...

Share this post


Link to post
Share on other sites

I asked in the PayPal forum here but so far had not had a response.

 

When using Method 2 you cannot pass an aggregate tax for the entire cart as in Method 1, and so the tax must be passed per item, say $0.0007 now when you multiply this by the qty of that item paypal will give a different result due to 2dp issue, e.g:

 

1000 @ $0.01 each with a tax rate of 7%

 

i.e 1000 x 0.0007 = 0.7

 

Perform a search in catalog/includes/modules/payment/paypal.php

 

and replace $order->info['tax']

 

with: $order->products[$i]['tax']

 

or ($order->products[$i]['tax'] / $order->products[$i]['qty'])


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Not too sure what your suggesting, would have to think some more.

 

But in case not clear;

 

If you were to print to the screen:

 

$order->products[ 0 ]['name'] you would get the name of item_1

 

and

 

$order->products[ 1 ]['name'] you would give the name of item_2

 

So (I think) $order->products[ 0 ]['tax'] is the total tax for item_1

and:

$order->products[ 0 ]['qty'] is quantity number of item_1

 

So when you replace $order->info['tax'] with ( $order->products[ $i ]['tax'] / $order->products[ $i ]['qty'] )

 

You are getting the passing the tax amount for a single item_1, hence paypal should/will then multiply the tax amount for that item by the item_qty of item_1 and thus giving the total tax for that particular item/product.

 

This repeated for each item and passed to paypal who will mutiply and then sum up the total tax.

 

I have to look at the code to see what's happening, I can't remember why I went with $order->info['tax'].

 

But even if this bit is still sorted out 'properly', the problem will still exist it is how osC calculates the figures in the first place, some on in posted in this thread earlier that they had no problems because their server was configured to work to 2 decimal places.

 

If I get the chance I will extract the code calculations, but not today.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

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:

 

<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">

<input type="hidden" name="tax_1" value="5.00">

<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="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">

<input type="hidden" name="tax_2" value="5.00">

<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="European Swallow">

<input type="hidden" name="item_number_3" value="TEST-3">

<input type="hidden" name="quantity_3" value="7">

<input type="hidden" name="amount_3" value="1.00">

<input type="hidden" name="tax_3" value="5.00">

<input type="hidden" name="on0_3">

<input type="hidden" name="os0_3">

<input type="hidden" name="on1_3">

<input type="hidden" name="os1_3">

 

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:

 

<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">

<input type="hidden" name="tax_1" value="1.67">

<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="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">

<input type="hidden" name="tax_2" value="2.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="European Swallow">

<input type="hidden" name="item_number_3" value="TEST-3">

<input type="hidden" name="quantity_3" value="7">

<input type="hidden" name="amount_3" value="1.00">

<input type="hidden" name="tax_3" value="0.71">

<input type="hidden" name="on0_3">

<input type="hidden" name="os0_3">

<input type="hidden" name="on1_3">

<input type="hidden" name="os1_3">

 

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

Edited by bobonala

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×