Extramaze: Using Racket, PostgreSQL, AWS, but no ads or JavaScript (2018)
greghendershott.com
greghendershott.com
https://www.theatlantic.com/technology/archive/2019/01/amazo...
The next month, a major legal change took place for such sites when the Supreme Court ruled that states can force out of state online vendors to collect sales tax. At least half the states now have such requirements, and most of the rest are in the process of getting it in place.
This made doing a "get paid directly by the end user" site a lot more complicated, both legally and technically.
If you don't have sufficient sales into a state, you don't have to collect tax, but unfortunately most states seem to be going with a threshold of 200 transactions a year or sales of $100k or $200k or some similar high number.
That "or" is the killer. If you are selling items that individually are cheap it is not hard to reach a state's "must collect and file" threshold by transaction count even if you have very little income from the state. You could easily lose all your profit and more in such a state to tax report filing fees.
A number of the larger companies had expressed a willingness over the years of implementing a sales tax, provided the states could clean up their tax codes to make it straightforward. A number of the states have tax codes that are so insanely complex for companies operating outside of the state that it becomes a near nightmare to correctly turn in to a computer program, for example Hawaii which doesn't have a sales tax but has a General Excise Tax.
Getting states to be willing to completely overhaul their tax system is an extremely hard battle.
edit: added link to the SST Project wiki page.
They did not give precise rules for what qualified, but did mention that South Dakota (the state involved in the case) was part of the SST project as being an important factor in South Dakota's law not being burdensome.
The general opinion I've seen has been that if a state joins SST, sets thresholds similar to South Dakota's, and does not make their law retroactive, it will almost certainly pass muster.
My guess is that this will bring most of the states into SST. That gets them safe tax collection right away. If they go it alone, they risk merchants making the state prove in court first that their particular law is not burdensome.
Voters might suddenly care about this legislation, if suddenly found themselves banned from large swaths of ecommerce sites overnight, with messages telling them it's because of their state's tax policies.
For these states I suspect that it is higher than for other states:
Arkansas
Georgia
Indiana
Iowa
Kansas
Kentucky
Michigan
Minnesota
Nebraska
Nevada
New Jersey
North Carolina
North Dakota
Ohio
Oklahoma
Rhode Island
South Dakota
Utah
Vermont
Washington
West Virginia
Wisconsin
Wyoming
A key aspect of the SST stuff is that if you agree to collect tax for ALL of those states, the states will pay the costs for you to use a third party service provider to calculate and track taxes and handle the required per state reports. The supported third party providers at this time are Accurate Tax, Avalara, Exactor, Sovos, TaxCloud, and Taxify.
I suspect that a common pattern for merchants, especially small merchants, will be to go through SST and collect for all those states, and deal with the rest on a case by case basis.
Note that all of those third party providers working with SST do provide tax services for non-SST states, but not for free.
For the big non-SST states, like California, it will probably be worth it (California's law requiring collecting tax kicks in 2019-04-01). For small states, I suspect a lot of small merchants might just stop selling in them.
I think that a lot of the non-SST states will be joining SST. I know that many of them have in their laws or policies statements that they agree with the principles of SST...I think some just haven't worked out the details yet.
For the non-SST states, a lot will also depend on which third party provider one is using for SST. With TaxCloud [1], for example, you can have them handle a non-SST state for 0.5% of sales in that state (that's for small merchants...the rate is lower for bigger merchants). That's not too bad, and the pain is the same regardless of whether the state is huge or tiny.
For some other providers the cost structure is typically a per transaction cost (e.g., $N for M tax API calls per month) plus whatever it costs for the state filing fees to file tax reports, and so if you aren't making a lot in a state that filing fee can kill you. You'll need to be a lot more selective.
There's another aspect of having to collect tax that is annoying. Tax depends on location, and tax boundaries do not line up with zip code boundaries. To lookup the right tax you will now have to ask for full address information, even if you are not shipping anything. Before all you needed was zip, to help reduce credit card fraud (and that is actually optional).
It would really really really make things nicer if Congress would step in and pass a law that says that IF states require out of state merchants to collect sales tax, the tax MUST be a function of 5 digit zip code. Then merchants would only need a simple look up table with under 50000 rows to determine the tax. We wouldn't need any real-time APIs for our shopping carts to use to look up tax rates from third parties, simplifying tax handing in our carts. We'd just need to use the SST third parties after the sale to record the tax for reporting, which I believe they all provide APIs for (to cover non-online sales).
Right now, there are places where the tax varies by building within a block. It is vary irritating.
[1] I generally use TaxCloud for examples because they are the best at making information available on their site to the general public. The others tend more toward making you sign up, or making you actually talk to someone, to get details.
I am also using Racket for a side project (Racket for the top level and 'business logic' with some Python/Keras stuff wrapped as services). Racket is very nice, and it is "weaning" me off of Common Lisp (which I have used heavily since the 1980s). The Racket ecosystem just keeps getting better. (I still love Common Lisp though)
Question for you: Do you use any services, tools, or methodology to organize your bookmarks? Personally it's an interesting challenge for me because of the myriad of devices, browsers, and platforms I use.
[1] https://news.ycombinator.com/item?id=19027400 [0] https://news.ycombinator.com/item?id=19043816 [3] https://news.ycombinator.com/item?id=19044409
I keep coming back to Racket, thinking it would be awesome to learn it properly and use it for a real project, then forgetting about it again due to busyness with existing projects... it's quite a cursed circle.
Not that I’ve actually touched any Lisp since the 80s.
Back to work in Java / Hibernate hell...
Now, if just all the lisp dialects would stop bikeshedding...
I was looking at Frog[0] yesterday and found myself in want of an example website. Today I found one, thanks to OP. :)
What would other ethical webmasters here do? Only use HTTP access logs?
EDIT: to be clear: i could also write a bunch of tooling myself to parse access logs or report events to a backend, but that feels like a lot of work + reinventing the wheel + maintenance/security scare.
what else do you need, honestly?
you could set a cookie on initial page load with a uuid and identify unique users from that (you can log cookies with nginx/apache).
just push the resulting log to Loki [1] (as an example) and you're done.
A service like this could definitely be worth the money. I used to watch sales at Musician's Friend and got things like harmonicas for $2, gig bags for $2, and Fender Custom Shop picks 6 boxes for $24.