Skip to main content

In one of our commercetools implementations, we need to integrate with Avalara for tax calculations and have some custom logic to calculate shipping cost - the shipping can be a fixed cost defined at the variant level or have to be fetched from UPS based on the variant attribute. To make a pure composable implementation instead of having the logic written in Apihub, we had different api extensions for shipping and tax calculations which are invoked when the cart has items and has shipping address and has an anonymousid/customerid populated.

This worked perfectly fine in local/stage environments but when we tried to validate this in Production -- we had this issue where the extensions werent called in any sequence (as the document mentions) so we had erratic behaviour and we saw the shipping gets calculated after tax and wiping out tax values -- etc, We ended up merging the two extensions into one but this means the extension should return within 2 secs which was a problem, so we had to request Commercetools to extend the timeout which helped resolve the issue - but this looks like some kinda restriction that we should try and overcome.

Did you have any similar issues and how did you solve the same? Share your ides/suggestions/thoughts/experiences.

 

Thanks,

-Naga

Hi @Naga , tax integration is always a hot topic and you will likely get different opinions on the best method.

I almost always recommend using the server application (API Hub in your case) as an orchestrater for checkout flow. This gives you the most control over the implementation and allows you to sequence the calls as needed. As features and requirements change, you will have much more flexibility with this approach. API Extensions for shipping/taxes make the most sense when you have multiple distinct clients using the exact same checkout flow, which is almost never the case. I’ll refrain from opening up the argument as to which approach is more “pure composable” 😉

If API Extensions must be used, consider breaking the shipping and tax calculations into 2 distinct steps, if possible. Each step should have its own target function and use conditional triggers to control if/when the extension is fired (not on the same update action).

Business requirements often dictate that up-to-date taxes are provided in the mini-cart but that does not usually align with customer expectations nor most retail implementations. If it were me, and I needed to use API Extensions for taxes, I would only call the tax service when the user enters the checkout process. At which point the cart can be frozen which can be used as the condition for the tax calculation trigger. This would not only prevent the extension collisions, but will likely save you some money on Avalara API calls.

Do you need to call both shipping and taxes throughout the checkout flow? 

Thanks for the detailed response @Chris Hough Yea the idea was to support the integration update-able in future without having to redeploy the apihub backend. The whole point of composable to swap-in out different integrations without having to touch the middleware BFF (ok ok i wont talk about it 🤐).

We had conditional triggers setup in such a way that the outgoing calls are minimal and when we merged them (ship and tax in one api extension) we lost the 2secs timeout per api extension to 2 secs for the single api extn (shipping + tax). And you also definitely do know the Lambda timeout issue even if we drop that in Apihub anyways. 

But again like we have Payment extensions now available in MC - if we have like default Tax/Shipping extensions or have a facility to add them as extensions with preconfigurable timeouts - as per the custom needs that would be ideal. 

Personally its good to have external service invocations as pluggable as possible.

Reply


Terms & ConditionsCookie settings