Billing systems are a nightmare for engineers

Heh, I'd say the operating system is easier to debug, because the accounting package could literally have "bugs" that are caused by errors in the tax laws, business processes, etc, which cannot be fixed, only worked around.

The linked page does not show it, but The Tao of Programming is actually a book which you can buy:

https://en.wikipedia.org/wiki/The_Tao_of_Programming

I own a copy; it’s great.

Depends on your requirements I would say. If your target customers are global, then yes, you'll have to deal with a lot of rules and regulations. But the engineering side of things I don't think is that hard.

Perhaps when you first enter the domain it seems like a lot because you are unfamiliar with it, but such is it with all things.

Also, these guys have an economical incentive of convincing you it's hard. So keep that in mind.

Not the OP, but anybody who has built a deep integration with any billing provider (inclusive of Stripe) knows there are some bodies buried, although you typically don't discover them until you're late in the game.

90% of your use cases are covered, and with excellent UX and docs to boot. But that sweet 10%!

---

For a concrete example, Stripe has a very nice "subscription" abstraction that makes it easier to operate a SaaS business. They also offer a nice "tax" product, that doesn't do filing for you, but does offer tax computation if you code your products appropriately. Sounds great!

But if you want to sell 2 subscriptions to the same customer, and those 2 subscriptions are fulfilled in 2 distinct taxable regimes (say, you're shipping widgets to NYC once per month and to a vacation home in NH once per quarter), you're screwed because Stripe only allows 1 shipping address for customer for tax purposes, and each subscription references this address when computing tax.

We went through support, which filtered through to engineering, and the eventual answer was "no plan to change this anytime soon", which is difficult to interpret any other way than "good luck". :)

There is no clean or even acceptably-dirty solution to this problem, tragically. So as a business we can't allow customers to transact with us this way. Oh well.

There's another, similar, story around creating draft invoices to give people quotes before checking out. The dashboard API has a function to modify the line items of a draft invoice, but it's not a public-facing API and there's no short-term intention to make it public-facing, so one has to build an ugly workaround.

This effectively means one needs to maintain internal models for subscriptions, products, taxes, invoices, invoice items, products, shipping addresses, on and on. And Stripe becomes a somewhat-dumb processor for these models (although the state machine for subscriptions is admittedly very valuable).

I'd love to "offshore" everything to Stripe, status as the source of truth for data included, but it's not feasible in a surprising frequency of scenarios.

Caveat that every payment provider is like this, Stripe is much better and actually improves over time.

I love it, sounds like the Swedish shops with no cashier https://mashable.com/article/swedish-store-cashiers Has it been tried before? How were disputes managed?