-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address Verification Failed #28
Comments
@arun057 At the moment the spree_tax_cloud extension doesn't do any address validation (it's on the roadmap, and PRs are welcome!). However, issues in the address—for instance, a ZIP code that doesn't match the state—may still cause the tax_cloud API to return an error, in which case the error propagates up to Spree. At the moment this gem doesn't contain the functionality to do an address validation with TaxCloud and return the user to the Spree address checkout step if it doesn't pass. I would certainly love for it to do that, however, and any PRs to that effect would be very welcome! Otherwise, it's possible that I may get to it later this year. |
I'm seeing this error as well. I've added in some logging to see what the actual error is from TaxCloud: Spree::CheckoutController.class_eval do
rescue_from SpreeTaxCloud::Error do |exception|
flash[:error] = exception.message
Rails.logger.info("SpreeTaxCloud Error: #{exception.inspect}")
redirect_to checkout_state_path(:address)
end
rescue_from TaxCloud::Errors::ApiError do |exception|
flash[:error] = Spree.t("address_verification_failed")
Rails.logger.info("TaxCloud API Error: #{exception.inspect}")
redirect_to checkout_state_path(:address)
end
end Here is a snippet of the log:
The address looks fine, no mismatched zip code or state. The Spree Order actually goes through (so I'm assuming this proves there's nothing wrong with the billing or shipping information?). Wondering if anyone has any more information on this type of error from TaxCloud? |
@rloomba Without being able to inspect it more deeply at the moment, I know that TaxCloud expects first to "authorize" an order and then to "capture" it. If it changes from the one to the other, there may be an error. So I would look into the logs and see what's going on at the "authorization" level. Spree itself does not (to my knowledge) do any kind of address verification, so I'm not surprised that the order is getting through – from Spree's perspective, there is some address filled out, so it's happy. The other possibility is that this is a complex address where the zip code may require the additional 4 digits, or may be different from the main zip code for that town -- something like that. If that's the case, I think you'd be able to reproduce the error for specific addresses reliably, but not for others. Is that the case with your store, or does it happen more erratically or more broadly? It might be worth bringing up with TaxCloud as well. As I mentioned earlier in this thread, address verification is one of the missing features in the Spree::TaxCloud extension, and the Spree team and I would be very happy to receive a PR implementing that! |
thanks @brchristian for this insight, will dig into the logs more and report back.
Unfortunately, this is not the case for any of the errors I'm seeing.
It's happening very erratically on my current store. I'm not noticing a pattern. I would love to implement address verification, I'll see if I can squeeze it into some spare cycles. |
@brchristian One thing I've been noticing is that we're seeing this error occur for products that aren't supposed to be taxed. In my backend setup I have created a tax category, For products that are not supposed to be taxed, the tax category is set to none, but I'm still seeing a box with a TaxCloud TIC: and it appears to be making an API call to TaxCloud even though it's not a taxble product. Is this the intended behavior? I'm on Spree 2.4, and running Rails 4.1.11. |
@rloomba It would be possible to make a PR that disabled the If I recall correctly, TaxCloud expects to process all Spree orders that ship within the United States, including ones with tax-free items. My guess (without looking into the code) is that an order containing a mix of Tax Categories will confuse TaxCloud. This could probably be made to perform more stably, but on the other hand, the plugin is designed to be used for all products. I believe the preferred method for making items tax-free is to set the TaxCloud TIC to the appropriate code. What are your tax-free Products, for instance? It should be possible to find the appropriate TIC for those, and I think that (using the TaxCloud Tax Category but a tax-free TIC) will give you the behavior you're looking for. |
This happens after the order is placed and email is delivered successfully. Spree admin shows the order as ready to ship
The text was updated successfully, but these errors were encountered: