TaxCloud Error only when checking out using express checkout shortcut button

[mikeymoto]

I've been running 1.5.1 fine for a while. I've had success using PayPal Express Checkout for payment, and also the Taxcloud module (v1.5) for tax calculation. This combination worked for a while. Then a customer reported getting an error message during checkout. In my investigation I found the following as a repeatable outcome but cannot determine its cause. If you can offer me some insight I would highly appreciate it!

When a customer clicks the express checkout shortcut button from the cart, they are directed to PayPal to enter relevant information. When the user is redirected back to my site, the billing/shipping address information is not shown and in its place is the following stack trace information, which also appears in the PayPal debug logs. If the user reloads this page, the appropriate address and other information display ok.

Here is some text from the debug log that should be relevant:

Jul-07-2013 20:21:55 (1373253715)
termEC-10
Redirecting to checkout_payment - Stack: checkout_payment
Message:
Session Data: Array

. . .

    [sendto] => 8
    [billto] => 8
    [shipping] => Array
        (
            [id] => usps_Priority MailRM
            [title] => United States Postal Service (Priority Mail® (1 day))
            [cost] => 5.8
            [module] => usps
        )

    [messageToStack] => Array
        (
            [0] => Array
                (
                    [class] => checkout
                    [text] => Error encountered looking up tax amount System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (2, 411). ---> System.FormatException: Input string was not in a correct format.
   at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
   at System.Xml.XmlConvert.ToDouble(String s)
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read5_CartItem(Boolean isNullable, Boolean checkType)
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read34_Lookup()
   at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer8.Deserialize(XmlSerializationReader reader)
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle)
   at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
   --- End of inner exception stack trace ---
   at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
   at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
                    [type] => error
                )

My limited read of this makes me think that when the system tries making the call to TaxCloud, the service call fails because some piece of required information is malformed. I can't tell what it doesn't like, and since the TaxCloud request is HTTPS I cannot sniff it to see what is being sent. There appears to be no debug logging for the TaxCloud module so I'm at a loss.

I apologize if this is not actually a PayPal Express Checkout problem, but the coupling is tight enough that I don't know exactly where the problem lies.

Note - in the PayPal Express Checkout module config I turned OFF the "Express Checkout Shortcut Button" option. When users check out using the normal checkout process and pay using PayPal, the error does NOT occur.

I thank you in advance for any insight you can provide.

Mike

PS - in case you care here is a little background server info:

• https://www.mikeymotoleather.com/
• PHP 5.4.12
• MySQL 5.5.30
• Running on my own FreeBSD server
• Installed using zc_install
• Running great for several months now
• Low volume site, but several transactions with no problems
• I have not installed additional modules since the problem started occurring

[mikeymoto]

Replying to my own thread with more info that may be relevant. I still don't know if this is a TaxCloud issue, a PayPal Express Checkout issue, or a ZC issue in general. Still looking for guidance.

I see the cartID presents itself in different places depending on if you're checking out using the express checkout shortcut button or if you're doing a normal checkout. See bottom for examples.

TaxCloud looks for the cartID from the SESSION structure (on line 196 of includes/modules/TaxCloud/func.taxcloud.php) and doesn't find it, which probably is why the subsequent lookup() fails with the returned stack trace.

    193                 $params = array( "apiLoginID" => TAXCLOUD_API_ID,
    194                                  "apiKey" => TAXCLOUD_API_KEY,
    195                                  "customerID" => $_SESSION['customer_id'],
    196       ----->                  "cartID" => $_SESSION['cartID'],                           <----
    197                                  "cartItems" => $cartItems,
    198                                  "origin" => $origin,
    199                                  "destination" => $destination,
    200                                  "deliveredBySeller" => false,
    201                                  "exemptCert" => $exemptionCertificate
    202                 );

Am I on the right track? Thoughts?


Here is a session dump from a SUCCESSFUL checkout. Note the 2 cartID definitions:

Jul-07-2013 20:58:19 (1373255899)
termEC-10
Redirecting to checkout_process - Stack: header
Message:
Session Data: Array
(
    [securityToken] => XXXX46744
    [customers_host_address] => OFFICE_IP_TO_HOST_ADDRESS
    [SESSION_IP_ADDRESS] => A.B.C.83
    [cartID] => 37336
    [cart] => shoppingCart Object
        (
            [contents] => Array
                (
                    [3] => Array
                        (
                            [qty] => 1
                        )

                )

            [total] => 35
            [weight] => 1
            [cartID] => 37336
            [content_type] => physical
            [free_shipping_item] => 0
            [free_shipping_weight] => 0
            [free_shipping_price] => 0
        )

Here is a session dump from a FAILED checkout. Note the 2 cartID definitions where the outer one is unset:

Jul-07-2013 20:21:55 (1373253715)
termEC-10
Redirecting to checkout_payment - Stack: checkout_payment
Message:
Session Data: Array
(
    [securityToken] => XXXX4bfa0
    [customers_host_address] => OFFICE_IP_TO_HOST_ADDRESS
    [SESSION_IP_ADDRESS] => A.B.C.83
    [cartID] =>
    [cart] => shoppingCart Object
        (
            [contents] => Array
                (
                    [3] => Array
                        (
                            [qty] => 1
                        )

                )

            [total] => 35
            [weight] => 1
            [content_type] => physical
            [free_shipping_item] => 0
            [free_shipping_weight] => 0
            [free_shipping_price] => 0
            [cartID] => 87172
        )

[RodG]

Replying to my own thread with more info that may be relevant. I still don't know if this is a TaxCloud issue, a PayPal Express Checkout issue, or a ZC issue in general. Still looking for guidance.

If you don't mind a bit of hacking, and a bit of guesswork I may be able to offer a little help (very little).

TaxCloud looks for the cartID from the SESSION structure (on line 196 of includes/modules/TaxCloud/func.taxcloud.php) and doesn't find it, which probably is why the subsequent lookup() fails with the returned stack trace.

Lets assume that your discovery/diagnosis is correct. The 1st thing to do is 'prove the point'. Soooo.......

Load the code you supplied into a text editor and make the change that I've highlighted

    193                 $params = array( "apiLoginID" => TAXCLOUD_API_ID,
    194                                  "apiKey" => TAXCLOUD_API_KEY,
    195                                  "customerID" => $_SESSION['customer_id'],
    196       ----->                  "cartID" => $_SESSION['cart']->cartID,                           <----
    197                                  "cartItems" => $cartItems,
    198                                  "origin" => $origin,
    199                                  "destination" => $destination,
    200                                  "deliveredBySeller" => false,
    201                                  "exemptCert" => $exemptionCertificate
    202                 );

Save the file.

Am I on the right track? Thoughts?

If you are on the right track the change above should (probably) take care of the issue. Well, not exactly 'take care' of it, but it will prevent any errors from being produced by the non existent $_SESSION['cartID'] variable. It will have proved/disproved whether this is the cause of the problem.

The next step (if the diagnosis is proven) is to figure out *why* this session variable isn't being set. My investigations indicate that this gets set by the /checkout_shipping/header_php.php file, which suggests that unless a shipping method has been selected the $_SESSION['cartID'] variable won't be set when the $params array is being created. It is also possible that this file has been modified in some way that is causing the variable setting to fail (?)

I will mention that the $_SESSION['cartID'] is just a copy of the $_SESSION['cart']->cartID, variable (which is why I think my 'fix' will work well enough to prove the point). However, I have also noted that other parts of the code will compare these two variables for security purposes (if they don't match the page is redirected elsewhere). This means that although my change will 'prove the point' of your diagnosis it probably won't solve all of the issues... To do this you'll need to figure out why the $_SESSION['cartID'] isn't being set in the 1st place.

FURTHERMORE. This *may* even be a bug in the original code, and perhaps my suggested change to prove the point is what the code *should* be reading in the 1st place. If you find things work flawlessly after this change this is a good possibility. However, before suggesting it as a 'permanent' solution I'd be waiting for input from one of the ZenCart developers. What they say should always take precedence over any of my suggestions, especially in this case where there is a definite security component involved.

Anyway, let us know how you go.... This could still be barking up the wrong tree....

Cheers
Rod

[Taxcloud]

One thing to note is that the PayPal Express Checkout bypasses the standard checkout process, so the tax lookup in TaxCloud is not performed. So when the customer returns from PayPal the cartID does not exist. We don't recommend using the express checkout because the taxes do not get calculated during this process.

If you would like to continue to use this you would have to modify the code slightly to make sure that the (empty) cart ID is not used and that TaxCloud does not get called to complete the transaction.

[DrByte]

One thing to note is that the PayPal Express Checkout bypasses the standard checkout process

Um ... that's not correct.

PayPal Standard is the one that bypasses the normal checkout process.

[Taxcloud]

I'm sorry if I wasn't clear. I was referring to the PayPal Express Shortcut button, which does skip the checkout.

[mikeymoto]

Thank you both for your feedback. Is there a good reason not to use Taxcloud for people using the Express Checkout Shortcut option? I am wondering if not doing this was an explicit choice on the part of Taxcloud to prevent a problem, or if it was just not implemented for lack of time, interest, or other reasons?

I can see how to pull the cartID, with thanks to Rod's feedback above. Is that the only change needed, or will I need to change any code later in the checkout process to be sure Taxcloud does not get called again?

Really what I want to know from those with more experience is whether I'm breaking some processing or business logic, or doing something stupid, by trying to get Taxcloud working for users who want to leverage the express checkout shortcut button.

Thank you again.

[DrByte]

I'm sorry if I wasn't clear. I was referring to the PayPal Express Shortcut button, which does skip the checkout.

I would still rephrase that statement, since the EC Shortcut Button doesn't bypass checkout at all. It just starts the checkout at a different point, and if the storeowner has opted to allow it to skip the shipping and payment pages by preselecting a best-guess choice for both, then it fast-forwards through those steps to the final confirmation screen.
While that might be skipping some stages that TaxCloud hasn't otherwise integrated to accommodate, it's not "skipping checkout".

Really what I want to know from those with more experience is whether I'm breaking some processing or business logic, or doing something stupid, by trying to get Taxcloud working for users who want to leverage the express checkout shortcut button.

I can't directly answer that question, but it does appear that you're trying to do something which the TaxCloud folks didn't intend at the present time.

[RodG]

Really what I want to know from those with more experience is whether I'm breaking some processing or business logic, or doing something stupid, by trying to get Taxcloud working for users who want to leverage the express checkout shortcut button.

Alas, I can't answer this either, because I'm even less familiar with the processes going on than the others that have replied.

In the absence of any further advice, my suggestion would be to apply the 'fix' as previously mentioned (assuming it works) and if there are no other problems apparent, assume that all is OK.

The 'fix' as supplied won't be the *cause* of any other problems (they will exist by virtue of this same variable missing elsewhere). It would be a different story if my suggestion was to add a line
$_SESSION['cartID'] = $_SESSION['cart']->cartID ;
somewhere just before the "$params = ....." line (which will have a similar effect as my suggestion, but *with* the possibility of having repercussions in another part of the code). Keep this suggestion in mind though, because if there are other parts of the code that depend on the $_SESSION['cartID'] variable being set this option may turn out to be the easiest solution.

Do keep a close watch on things though because it seems you are treading unfamiliar territory. I'm not in a position to say if my suggestions are good or bad, they are merely suggestions as to what *I* would be doing if I were in your position.

I'd also suggest that you don't try to fix this for other users. Fix it for yourself and yourself only. If others using the module have a similar problem they will either find their way to this thread for a solution, OR, if/when the module maintainer(s) determine the fix is safe/valid/ let *them* make the changes and upload the fixed version for others.
I'm sure that not everyone will agree with me on this one and will suggest you fix and upload (which has been done with many other modules, especially when the original developers seem to have disappeared). The 'problem' is if you 'fix' and re-upload the module the people that d/load it will consider you to be the 'expert' and will seek *your* advice for any problems they may have, advice that neither you or I are 'qualified' to give.

Cheers
Rod

[Taxcloud]

What I mean by "skipping checkout" is that this process skips the normal checkout steps which includes entering the shipping address, selecting a shipping and payment option, etc... The TaxCloud integration comes into play after the customer has entered their shipping address. We use the shipping address to determine the correct tax rate. After the rate is determined we add the cart ID into the session. This allows us to later identify the order when it is completed. This is why the cart ID is added to the PayPal process.

The reason the TaxCloud integration is not working with the PayPal Express Shortcut button is that we do not know the customer's shipping address at the time the button is clicked. This means that we can't determine the rate. Therefore, TaxCloud is not called and the cart ID is not added to the session.

The code you are looking at is based on the assumption that the normal checkout process has been followed and the cart ID has been set. If you remove references to the cart ID from the code that will solve your problem with the Shortcut button, but it will cause problems for anyone using the normal checkout process.

I'm not sure that it would be possible to "fix" this problem to work in all circumstances based on the way TaxCloud works. We recommend disabling the Shortcut button. Customers will still be able to use PayPal as a payment processor during checkout.