PayPal 10413 error

Monsz:

What I did was: In paypaldp.php (Paypal Website Payments Pro class) insert this code to the rows 1301-1303, in paypalwpp.php (Paypal Express Checkout) insert to the rows 1519-1522:

unset($optionsST['TAXAMT']);
unset($optionsST['SHIPPINGAMT']);
unset($optionsST['HANDLINGAMT']);  

> 
> The modified code will like this in both files:
> ```php
    // subtotals have to add up to AMT
    // Thus, if there is a discrepancy, make adjustment to HANDLINGAMT:
    $st = $optionsST['ITEMAMT'] + $optionsST['TAXAMT'] + $optionsST['SHIPPINGAMT'] + $optionsST['HANDLINGAMT'];
    if ($st != $optionsST['AMT']) $optionsST['HANDLINGAMT'] += strval($optionsST['AMT'] - $st);


		//**************inserted code for unset subtotals********************************************************************
    unset($optionsST['TAXAMT']);
    unset($optionsST['SHIPPINGAMT']);
    unset($optionsST['HANDLINGAMT']);
		//*********************************************************************************************

/*  //PayPal API spec contradicts itself ... and apparently neither of these "requirements" are enforced. 
    //Thus skipping this section for now:

I suggest you, before make the change, backup both files, if you make mistake, you can upload the original files.

Thanks Monsz, it worked perfectly when all the other solutions failed. :clap: You have made me very very happy!!
Ab Fab :bigups:

I had the dreaded 10413 error for the first time today when a customer placed a large >$1K US order.

This fix did it for me, at least when I tested it. I will find out tomorrow if it worked for the customer when he resubmits the order.

Hi, I just came across this problem and have looked at the proposed change.

At first glance the adjustment which calculates the HANDLINGAMT should resolve the issue. When tax is included in the price, the HANDLINGAMT becomes negative and balances things up so an error is not raised and the line items are sent to paypal so all should be ok. However, just before the numbers are sent to paypal (but after the error check), the HANDLINGAMT is changed to a positive value because paypal does not accept negatives and so it no longer balances and hence we see the error.

The proposed change to unset TAXAMT, SHIPPINGAMT anf HANDLINGAMT resolves the error (10413), but it bypasses the problem by trigerring the error check at the end of the function so that the line items are not sent to paypal.

I would propose the slightly revised change below which does the following:

1. Unset TAXAMT but ONLY if your store is setup to include tax in the price. This is done before the existing adjustment to HANDLINGAMT so we don't need to unset it and it can continue to serve its original purpose.
2. Add line after the adjustment to HANDLINGAMT to ensure it is a positive value. This will make sure that if something else makes this negative, the errors checks will pick it up.

/includes/modules/payment/paypalwpp.php
LOCATE THE FOLLOWING CODE:

// subtotals have to add up to AMT
// Thus, if there is a discrepancy, make adjustment to HANDLINGAMT:
$st = $optionsST['ITEMAMT'] + $optionsST['TAXAMT'] + $optionsST['SHIPPINGAMT'] + $optionsST['HANDLINGAMT'];
if ($st != $optionsST['AMT']) $optionsST['HANDLINGAMT'] += strval($optionsST['AMT'] - $st);

ADD THIS BEFORE THE ABOVE CODE:

if( DISPLAY_PRICE_WITH_TAX=='true' ) unset($optionsST['TAXAMT']);

ADD THIS AFTER THE ABOVE CODE:

// ensure handlingamt is not negative
$optionsST['HANDLINGAMT'] = abs(strval($optionsST['HANDLINGAMT']));

If I understand you correctly, you are proposing this as a solution INSTEAD of the previously proposed fix.. Got it.. So if I follow your suggested changes can you confirm that this is what they should look like incorporated into the paypaldp.php & paypalwpp.php files.

if( DISPLAY_PRICE_WITH_TAX=='true' ) unset($optionsST['TAXAMT']);
 
// subtotals have to add up to AMT
// Thus, if there is a discrepancy, make adjustment to HANDLINGAMT:
$st = $optionsST['ITEMAMT'] + $optionsST['TAXAMT'] + $optionsST['SHIPPINGAMT'] + $optionsST['HANDLINGAMT'];
if ($st != $optionsST['AMT']) $optionsST['HANDLINGAMT'] += strval($optionsST['AMT'] - $st);
 
// ensure handlingamt is not negative
$optionsST['HANDLINGAMT'] = abs(strval($optionsST['HANDLINGAMT']));

gmail:

Hi, I just came across this problem and have looked at the proposed change.

At first glance the adjustment which calculates the HANDLINGAMT should resolve the issue. When tax is included in the price, the HANDLINGAMT becomes negative and balances things up so an error is not raised and the line items are sent to paypal so all should be ok. However, just before the numbers are sent to paypal (but after the error check), the HANDLINGAMT is changed to a positive value because paypal does not accept negatives and so it no longer balances and hence we see the error.

The proposed change to unset TAXAMT, SHIPPINGAMT anf HANDLINGAMT resolves the error (10413), but it bypasses the problem by trigerring the error check at the end of the function so that the line items are not sent to paypal.

I would propose the slightly revised change below which does the following:

1. Unset TAXAMT but ONLY if your store is setup to include tax in the price. This is done before the existing adjustment to HANDLINGAMT so we don't need to unset it and it can continue to serve its original purpose.
2. Add line after the adjustment to HANDLINGAMT to ensure it is a positive value. This will make sure that if something else makes this negative, the errors checks will pick it up.

/includes/modules/payment/paypalwpp.php
LOCATE THE FOLLOWING CODE:

// subtotals have to add up to AMT
// Thus, if there is a discrepancy, make adjustment to HANDLINGAMT:
$st = $optionsST['ITEMAMT'] + $optionsST['TAXAMT'] + $optionsST['SHIPPINGAMT'] + $optionsST['HANDLINGAMT'];
if ($st != $optionsST['AMT']) $optionsST['HANDLINGAMT'] += strval($optionsST['AMT'] - $st);

ADD THIS BEFORE THE ABOVE CODE:

if( DISPLAY_PRICE_WITH_TAX=='true' ) unset($optionsST['TAXAMT']);

ADD THIS AFTER THE ABOVE CODE:

// ensure handlingamt is not negative
$optionsST['HANDLINGAMT'] = abs(strval($optionsST['HANDLINGAMT']));

Yep, that's what it should look like.
I haven't tried it on paypaldp.php as I only use the express checkout but the function is almost identical so the same principle should apply.

gmail:

Yep, that's what it should look like.
I haven't tried it on paypaldp.php as I only use the express checkout but the function is almost identical so the same principle should apply.Cool!:cool: Thanks for the confirmation.. the target section of code is identical in both files.. (Express and Payments Pro) So in theory it should work in both.. I'm going to give this a shot..

Hi, I've tried your solution but the it didn't solve my problem. Can someone add a step by step guide?

Do anyone have the original files?

andersw:

Hi, I've tried your solution but the it didn't solve my problem. Can someone add a step by step guide?Not sure what you mean by a step by step guide.. The two solutions suggested througout this thread provide fairly thorough instructions as to what mods are needed and where they should go... (some posts even include the full modded code snippets) You might try posting the modded section of your code..

andersw:

Do anyone have the original files?The original file would be in the zip file you downloaded when you installed Zen Cart.

Haven't been on this thread in a while.

So Diva, is the new proposed fix by gmail functional? It does seem like it would be more ideal since from what I understand, instead of bypassing which is what I believe Monsz code does, it works with the tax issue to resolve it?

Sorry I haven't had time to test it myself. Been pretty chaotic few months.

Warm Regards,
Jason

DieuxSoldat_04:

Haven't been on this thread in a while.

So Diva, is the new proposed fix by gmail functional? It does seem like it would be more ideal since from what I understand, instead of bypassing which is what I believe Monsz code does, it works with the tax issue to resolve it?

Sorry I haven't had time to test it myself. Been pretty chaotic few months.

Warm Regards,
JasonI haven't tried this fix as of yet.. My client only had the 10413 error happen on a few isolated cases.. (he hasn't gotten the error in MONTHS) So we are going wait and see before making any changes just yet.. GMail's suggestion seems like a better solution though IMO..

While the solution proposed by Monsz seems to be working for folks, I am still not completely comfortable with that particular solution.. (no offense to Monsz at all). While I am no programmer, I always sorta felt as if the Monsz solution was bypassing something important. (there's a reason that code was commented out, and I was never completely comfortable that uncommenting it was a wise move -- which is why I hesitated on implementing it..)

Gmail's solution resonated with me, and I merely wanted to make sure that I was clear on the code required to implement his suggested modifications. I also wanted to post it for anyone else who may also have been a little fuzzy on how to implement it. (For the record.. GMail's directions were perfectly clear, I just wanted to make good and darn SURE I understood them..:yes:)

Hi everyone. I am new to the forum and have been searching long and hard for a solution that works. I tried the previous two solutions with no success. The latter solution didn't fix the error message and the first one i.e...

unset($optionsST['TAXAMT']); 
unset($optionsST['SHIPPINGAMT']); 
unset($optionsST['HANDLINGAMT']); 

...removed the error message, however my 1.13 transaction in Zen Cart translated into an actual 1.45 transaction once it got to paypal. I'm starting to sweat bullets because we are launching in two days. Back to the forum for me but if anyone has any suggestions I'm all ears. Thanks. :cry:

Monsz:

Hi!

I found a solution about this problem.
I'm testing it now, but i share it with you, because it passed the first tests.

I think the paypal is calculate with the tax ['TAXAMT'], shipping cost ['SHIPPINGAMT'], handling cost ['HANDLINGAMT'], but these costs are in the total cost ['AMT']. So, if i don't send the subtotals to the paypal, only the total cost, this problem will ending...

So there's a the paypalwpp.php file in includes/modules/payment directory.

I inserted to 1519-1522 rows this code:

unset($optionsST['TAXAMT']);
unset($optionsST['SHIPPINGAMT']);
unset($optionsST['HANDLINGAMT']);

> 
> After this modification, the paypal express checkout working properly, i tried it with tax, and with two different shipping mods.


Has anyone confirmed that this really works?? This issue is causing a major inconvenience. Thanks

cormiermt:

Hi everyone. I am new to the forum and have been searching long and hard for a solution that works. I tried the previous two solutions with no success. The latter solution didn't fix the error message and the first one i.e...

unset($optionsST['TAXAMT']);
unset($optionsST['SHIPPINGAMT']);
unset($optionsST['HANDLINGAMT']);

...removed the error message, however my 1.13 transaction in Zen Cart translated into an actual 1.45 transaction once it got to paypal. I'm starting to sweat bullets because we are launching in two days. Back to the forum for me but if anyone has any suggestions I'm all ears. Thanks. :cry:My suggestion is to NOT mess with PayPal Standard at all and activate and use PayPal Express.. I never had anything but one issue after another with PayPal Standard.. The problems were all different, and I decided to stop fooling with it.. PayPal Express works with NO ISSUES whatsoever..

DivaVocals:

My suggestion is to NOT mess with PayPal Standard at all and activate and use PayPal Express.. I never had anything but one issue after another with PayPal Standard.. The problems were all different, and I decided to stop fooling with it.. PayPal Express works with NO ISSUES whatsoever..

This is interesting because the only thing I am having problems with is PayPal Express.

Ok. I just made a few updates and both express and payment pro work fine. Now the problem is that i have no idea what I did. I'm going to retrace my steps one setting at a time and try and reproduce the problem. I will keep you posted on my findings.

cormiermt:

Hi everyone. I am new to the forum and have been searching long and hard for a solution that works. I tried the previous two solutions with no success. The latter solution didn't fix the error message and the first one i.e...

unset($optionsST['TAXAMT']); 
unset($optionsST['SHIPPINGAMT']); 
unset($optionsST['HANDLINGAMT']); 

...removed the error message, however my 1.13 transaction in Zen Cart translated into an actual 1.45 transaction once it got to paypal. I'm starting to sweat bullets because we are launching in two days. Back to the forum for me but if anyone has any suggestions I'm all ears. Thanks. :cry:

When I try this solution i get:

10525 Invalid Data - This transaction cannot be processed. The amount to be charged is zero.

This is happening to me also.

I have my Shipping Charges (postage) set to the Flat rate ... if that helps solve the problem.

Look HERE for a quick and dirty fix that worked for me.
Its not how it "should" be but it works.

I have been working to get it as it should be, but have no time to continue it.

Have a look HERE if you are interested in what I was trying to do.

Hope it helps others too!

I have tried for almost 3 years to get this sorted out. I have discussed it with PAYpal on numerous occasions and eventually they agreed there is nothing they can do as it is not their software and they say it is upto zencart to sort it out. I have decided to remove the VAT on all my products and not have it listed as VAT =0.00% on the receipt so the customer does not know. I am now able to go live and have my first sale. I hope the next Zencart release solves it, though if I will be brave enough to upgrade I don't know.