3 ms·
We pay an external service provider for the raw zipcode-to-rate mappings. Their company exists solely to manually aggregate all these rates in a mostly-machine-
by burke 13y ago
We pay an external service provider for the raw zipcode-to-rate mappings. Their company exists solely to manually aggregate all these rates in a mostly-machine-friendly format. We developed all the peripheral logic through skimming documents and talking to customers, and it changes very rarely.
It's not hard to google for the rate provider services, but they don't give you all the information you need to handle all the inane edge cases properly (at least, not the ones I've investigated)
- mblakele 13y agoHow does this approach handle zip codes that are split between two municipalities? I happen to live in one of those, and there is a 0.25% difference between the two cities.
- burke 13y agoWe don't deal with that case adequately right now. It's up to chance which one you get charged. For customers (ie. one-time sales), we unfortunately lump this into "get it close enough and the taxation bodies won't really care". For merchants located in these two-rate zips, we can usually work around it, targeting the correct rate with some ugly hacks. This is something I'd like us to do better on. I have an idea for how to improve without adding an intolerable amount of complexity or expense, but I haven't had a chance to implement it yet.