[HN Gopher] Pains of building your own billing system
___________________________________________________________________
Pains of building your own billing system
Author : arnon
Score : 292 points
Date : 2024-02-26 11:41 UTC (11 hours ago)
(HTM) web link (arnon.dk)
(TXT) w3m dump (arnon.dk)
| jchw wrote:
| This is a great article for people who are in the situation where
| they have to make decisions about billing and don't have much
| experience (and as a handy reference for those who do, but want
| some reminders, too.)
|
| However, I will admit, I had a hearty chuckle at this line:
|
| > "why can't we just dump a file of what we need to bill on S3,
| and have a CRON job pick it up and collect payment?"
|
| Under no circumstances does my engineer brain think this is a
| good idea. At all.
|
| But, I will dump one aspect of my engineer-brain thoughts: My
| favorite "billing architecture" decision is to try to decouple
| billing as much as possible from credit in a system. For example,
| if you have a subscription system where the user pays ahead for a
| given billing period, I prefer to have the entitlement itself
| just store the expiration date and the details about what
| entitlements the subscription grants during the time period it is
| active. The billing system can store the subscription and sync
| back to the entitlement as-needed. This makes both manual billing
| by human operators (not to mention debugging and patching around
| momentary issues) _and_ something like a Stripe integration
| _very_ easy. You should, of course, be _very_ careful to leave it
| open for extension in the future, but this seems to be a very
| nice decision that doesn 't, in itself, limit you too much.
|
| Obviously, this is not my original idea, but it's still something
| I've grown to like a lot, especially after having tried other
| things less successfully.
| brettermeier wrote:
| Is that legal in germany? I don't know but I guess it isn't.
| timvdalen wrote:
| Which part?
| marcosdumay wrote:
| Probably sending your customers information in plain text
| to Amazon.
|
| But there is probably a way to do it, and even if there
| isn't, there certainly is some equivalently insane design
| that is legal.
| shepherdjerred wrote:
| S3 is encrypted in transit (like most data nowadays)
|
| S3 can also be encrypted at rest. The encryption can be
| performed client-side or server-side [0]. Nowadays, AWS
| performs server-side encryption by default, unless you
| disable it.
|
| [0]: https://docs.aws.amazon.com/AmazonS3/latest/userguid
| e/UsingE...
| aftbit wrote:
| Thereby proving that checkbox security is pointless.
|
| What threat models does AWS server-side at-rest
| encryption protect against? Someone breaking into an S3
| data center and walking off with a box of hard drives?
| AWS reselling obsolete hardware on eBay and forgetting to
| wipe a disk?
|
| And yet what does it not protect against at all? A
| misconfigured load balancer that can access
| 169.254.169.254 and dump your AWS access key straight to
| an attacker, who can then use it to ask AWS to politely
| decrypt all of your data.
|
| What does it really not protect again? The US.gov issuing
| a National Security Letter to Bezos threatening jail time
| if they don't decrypt and hand over the data.
|
| To reach the spirit of the "data must be encrypted at
| rest" laws, I believe you should encrypt the data using
| your own keys which are maintained in an HSM that AWS
| cannot access. This means that you cannot run your entire
| stack on one cloud, which would be a huge driver of cost
| and complexity.
| shepherdjerred wrote:
| > What threat models does AWS server-side at-rest
| encryption protect against?
|
| A lot of threats. A rogue employee sucking up data.
| Malware on AWS servers.
|
| Not likely, but certainly possible. Server-side
| encryption is useful, but if you want to be _certain_
| that your data is safe, then client-side encryption does
| exactly what you're asking for.
|
| Client-side encryption can use a local key, or a key in
| KMS.
|
| https://docs.aws.amazon.com/amazon-s3-encryption-
| client/late...
|
| Is there a reason you have such a negative take?
| aftbit wrote:
| Yeah I generally have a pretty negative take about tech
| regulations, especially security ones. They are often
| written by people who don't understand either the
| technology or the threats, and are often implemented by
| people who don't really care about the threats, just
| about compliance.
|
| Client-side encryption is a lot better. If the
| regulations were drafted in a technology and security
| aware way, maybe they would include something more
| detailed than "data must be encrypted at rest" which
| would require such practices. As it stands today, you can
| be in compliance without actually gaining much in the way
| of practical security improvement.
|
| > A lot of threats. A rogue employee sucking up data.
| Malware on AWS servers.
|
| IMO server-side encryption-at-rest does not protect
| against either of these, although there might be some
| edge cases where it does. For example, malware on the S3
| gateway would see the data decrypted. A rogue employee
| with very limited access may be stopped by this, but I
| would guess that most rogue employees would be abusing
| the support impersonation processes or would deploy evil
| code that can access the data after decryption.
|
| Client-side encryption would prevent both of these
| threats as well as the more common ones like losing
| access to your AWS keys somehow. As long as the method
| that leaked the AWS key didn't just leak your client-side
| encryption key as well.
|
| All security evaluations should start with a threat
| model. If you're trying to protect yourself against APTs
| or nation states, you have a very different challenge
| than if you're trying to protect against drive-by
| ransomware.
| actionfromafar wrote:
| Even such an insane design can be made passable, by
| making the file in-practice-a-queue if you squint.
|
| Remove old entries, keep a large margin of old entries.
| Append new records to the file. Use a counter. (Make it
| 64 bit if you are paranoid.)
|
| On the "receiver" end, keep track of what you last saw.
| Could be as simple as keeping track of the counter.
|
| Add only records you never saw before.
|
| Process new records.
|
| There are of course nowadays _so_ many better ways, but
| "real" and stable systems have been built with such duct
| tape.
| q3k wrote:
| > Under no circumstances does my engineer brain think this is a
| good idea. At all.
|
| Yeah, if that's the model engineer in the "don't build your own
| billing system" mantra then the article had the opposite effect
| on me. Now I want to build such a system because this made me
| feel like I'm significantly more qualified than I previously
| thought.
| arnon wrote:
| Don't do it
| q3k wrote:
| Now I'll also do it out of spite! :)
| arnon wrote:
| Don't say I didn't warn you
| jerf wrote:
| Naw, you still don't want to, at least not in a context in
| which you're billing enough to be a real workout, because the
| non-engineering aspects will still get you. Like this:
| https://news.ycombinator.com/item?id=37557989 which, in
| short, refers to the fact that nobody in the company
| considers billing a system to be designed in the first place,
| so it gets approached with a _truncated_ Waterfall that doesn
| 't even have a requirements analysis phase, so you'll have no
| support whatsoever for your attempt to bring higher quality
| to billing.
|
| Also, with all due respect to those working on billing I have
| seen that it is generally handed to engineers who are, shall
| we say, adequate for the task but no more, and unless you're
| 100% greenfielding you're going to be dealing with their
| stuff no matter what.
|
| From another cynical point of view, it is a situation where
| you can fail miserably and bring great pain to the company
| that is traced directly to you, but there is no success; a
| functioning billing system is just what is expected. It's all
| downside and no upside for you personally.
|
| I have a billing system (a component of the larger whole) and
| I'm pleased to be able to hand it off next month. I've not
| enjoyed my stay there. Though it was miles better than when I
| brushed the data lake/data analysis world. If I had to
| maintain this system for another few years I could and I
| wouldn't scream if I had to do it again someday. Dealing with
| the data analysis world beyond just throwing them some data
| is a "never again".
| specialist wrote:
| > _...miles better than when I brushed the data lake /data
| analysis world_
|
| The data pond, puddle, and lakeside cottage methodology
| would have spared you that pain.
|
| More seriously, my experience with that world reinforced my
| view that it's all monkey motion (much effort, negative
| value).
|
| Otherwise, spot on summary of IT dev work. Which now
| applies to "web services" too.
|
| I've long been befuddled by the rise of "agile". It's not
| meant for product dev, right? Well stupid me took forever
| to realize that most work is actually IT (aka data
| processing) and not product dev.
| robertlagrant wrote:
| > I've long been befuddled by the rise of "agile". It's
| not meant for product dev, right?
|
| It...is?
| specialist wrote:
| Is "agile" meant for product dev? IMHO, no.
|
| Very loosely, "product dev" projects have concrete
| deliverables, deadlines, and high cost of change
| (updates). So therefore are ameniable to PMI-ish critical
| path like methodologies. (Avoiding the evergreen
| unresolvable sophistry wrt "waterfall".)
|
| The original motivation for "agile" was to protect the
| dev team from terrible customers (clients). Those who
| cannot or will not commit to requirements, actively
| resist any kind of formalism, have no clue what "done"
| even means.
|
| Meaning most IT (data processing) efforts. And now most
| web stuff.
|
| "Agile" is totally rational in those unwinnable
| situations. Because the dev team would always have
| _something_ to show for their suffering. Lessening the
| likelihood of being the scapegoat come the inevitable
| failure.
|
| Unfortunately, "agile" became a fad, a belief system, an
| identity. Curtailing any kind of introspection. Only in
| the last few years have we been able to have calm, frank
| discussions about "agile". Mostly because some of its
| progenators have broken ranks and done mea culpas.
| robertlagrant wrote:
| > Very loosely, "product dev" projects have concrete
| deliverables, deadlines, and high cost of change
| (updates).
|
| Why? A web based product can iterate, for example. We see
| the most experimentation in places like Amazon, where
| they're constantly deploying updates and experiments. Why
| should such a product have a high cost of change?
| ttymck wrote:
| > but there is no success; a functioning billing system is
| just what is expected. It's all downside and no upside for
| you personally.
|
| I just wanted to say thank you for giving a robust voice to
| the frustrations I've felt after building multiple billing
| systems. This and your linked comment were a pleasure to
| read, and simply spot on.
|
| Coincidentally, I am also pursuing a career transition
| toward data analysis. If I understand correctly, you are
| lamenting "data engineering" in contrast to "ad hoc data
| analysis deliverables"?
| bluGill wrote:
| The problem is there are a lot of detail that is different
| just for the sake of being different and those will suck your
| soul. There are interesting problems in billing. However most
| of the issues are another government has a law that is
| essentially the same as every other government, but some
| small detail is trivially different so you need to figure out
| which subset of customers that government covers and then
| apply those details correctly to them. Nothing hard about
| this, just the same old tax but the details are annoyingly
| different.
|
| Note that you need to get the above details 100% correct in
| all cases. They can put you in prison for mistakes (almost
| always they will just fine the company a lot of money, but
| they have the right to apply prison and you never know when
| they will want to make an example of someone)
| doctor_eval wrote:
| Despite what jerf said, which I whole heartedly agree with,
| there are plenty of interesting billing problems for a good
| engineer to sink their teeth into.
|
| But there is also a long, long tail of boring problems that
| you won't have time to do properly.
|
| To put it a different way: even after you've solved the
| "mathematical" problems of billing, you still need to solve
| the operational stuff. Like payments integration, GL
| integration, invoice formatting, tax, reports, etc etc.
|
| I think most engineers underestimate both the difficulty of
| the "mathematical" problems, and the length of the long,
| relatively boring tail.
| rapind wrote:
| > and something like a Stripe integration very easy
|
| What I did (and would recommend others do), was a deep dive
| into Stripes API when designing my schema. It doesn't even cost
| anything to create an account and run some test charges,
| refunds, disputes, balance changes, etc. Of course I was
| modelling a more complicated setup (charges on behalf of
| customers), but still, useful stuff IMO.
|
| If you have access to an accountant / bookkeeper (relative?)
| that can help too.
| spiffytech wrote:
| Another great article from Arnon on doing exactly that:
|
| https://arnon.dk/why-you-should-separate-your-billing-from-e...
| ylere wrote:
| My experience has been that there are typically two types of
| engineers: those who have worked on billing systems before and
| those who haven't.
|
| I think a lot of the issues arise from the difference between
| payments and billing [0]. When just starting out and signing up
| your first customers, you primarily care about collecting a few
| (recurring) payments - and it's really easy to set that up with
| Stripe (or even just manually invoicing your first customers).
|
| However, over time, more billing requirements gradually sneak
| in, such as more complex entitlements, multiple plans,
| grandfathering, and eventually enterprise/high touch sales
| customers (where the money is!) who need custom billing cycles,
| terms, and entitlement provisioning. Since billing is never a
| technical focus, numerous additions and small hacks accumulate
| over time, taking engineering resources away from the actual
| product. Eventually, this turns into an unmanageable mess that
| can significantly slow down the sales process or limit what you
| can sell.
|
| The complexity of billing is riddled with hidden pitfalls and
| edge cases, and it has become even more complex now that most
| plans include many different limits and usage-based components
| and that most SaaS companies sell globally. Many later-stage
| companies have teams of 15+ engineers working solely on
| billing. I fully agree with the author that, unless it's at the
| core of your product, no organization should build a billing
| system themselves (Disclaimer: I'm the CTO of Wingback, a SaaS
| Billing Platform).
|
| [0] https://www.wingback.com/blog/saas-payment-vs-saas-billing
| kkajla wrote:
| > I prefer to have the entitlement itself just store the
| expiration date and the details about what entitlements the
| subscription grants during the time period it is active. The
| billing system can store the subscription and sync back to the
| entitlement as-needed. This makes both manual billing by human
| operators (not to mention debugging and patching around
| momentary issues) and something like a Stripe integration very
| easy.
|
| Having worked with SaaS companies using our (Warrant) solution
| for customer entitlements [0] for the past couple years, this
| is the approach we arrived at as well (e.g customer stores
| entitlements in our system and checks against them when needed,
| adding rules/entitlements as subscriptions are updated/deleted
| with their payment provider). It makes it easier for companies
| to work with any (or multiple) payment providers, and there's a
| clear separation of concerns. Someone shared another blog post
| by OP about separating your billing and entitlement systems [1]
| below, but I'll share it here since it's more relevant within
| the context of this comment thread.
|
| I think the ideal entitlement system is (1) dynamic (i.e. rules
| stored in a database), (2) can handle one off scenarios (for
| enterprise customers, etc.), and also has a policy layer built
| on top (so it supports almost any scenario a developer can
| throw at it -- e.g. pro plan supports <= 5 seats, growth plan
| supports X feature up to N times per day, etc). I think it's
| also a huge benefit to have a UI where non-technical folks can
| make changes for customers without needing to involve
| engineering (which was always a drag on engineering in my prior
| roles as an engineer).
|
| [0] https://warrant.dev/use-cases/pricing-tiers-and-
| entitlements... [1] https://arnon.dk/why-you-should-separate-
| your-billing-from-e...
| doctor_eval wrote:
| The way that we ended up with is similar:
|
| - your billing is just a mechanism to compute the invoices.
|
| - you accumulate billing using a ledger of invoices sent and
| payments made (and adjustments, etc) - ie, receivables
|
| - you have a set of entitlements, yes
|
| - but in the middle you have a policy mechanism that determines
| when the entitlements should/should not be applied.
|
| The trick is that entitlements are not just about billing. The
| policy mechanism is the "glue" between entitlements and
| everything else. It means you can give an entitlement to the
| boss of your biggest customer without it necessarily being
| linked to billing in any way.
| chasd00 wrote:
| I worked on a billing and AR system for a small pharmacy chain
| years ago. Our company would get pretty large random checks from
| ins carriers totally out of the blue. As in, we had billed them
| nothing and they would send us $150k checks in snail mail. They
| wouldn't realize their mistake and come asking for it back for
| months. We had a special account named "magic money" for it. The
| billing world is crazy town.
| dns_snek wrote:
| Fascinating, is there ever a point where this "magic money"
| legally becomes your property, after a certain amount of time?
| kasey_junk wrote:
| Depends on the jurisdiction but typically no.
| scott_w wrote:
| Short answer "it depends." Long answer:
|
| It depends on your jurisdiction, the entities involved, the
| amount of money involved, and probably more. However, it's
| not possible to know ahead of time, you'd need to go to court
| and argue why this entity is being unreasonable in demanding
| the money be returned.
| indymike wrote:
| In the US, you are supposed to turn it over to the state, and
| the government holds it for an extremely long time until it's
| owner claims it.
| alsetmusic wrote:
| Also, you're probably not going to win a dispute with a /
| the state. The USA government stole my money once (bank
| transfer). It was a rent payment to a landlord with a
| Muslim-sounding name. I contested it by sending in their
| form with the case number that they'd provided me.
|
| They responded saying they had no case matching my info. I
| gave up before investing more time because I thought it was
| unlikely to end well for the amount of effort I'd have to
| invest.
|
| I started directly depositing money orders into his
| account. No problems after that. The USA government
| profited one month of my rental rate. I nearly got evicted
| when my rent wasn't delivered. No explanation was ever
| given to me.
| aftbit wrote:
| Ah but if you _do_ want to win a dispute with the state,
| you must not give up when you hit a logical
| contradiction. The only way out is through.
| pc86 wrote:
| This isn't "I lose a dispute with the state," it's "I hit
| a pebble-sized roadblock and immediately gave up."
|
| I'm glad that a month's rent isn't a lot of money to you
| but this probably shouldn't inform your opinion on how it
| is to interact with the state.
| hansvm wrote:
| There was a fairly recent case [0] exploring a situation in
| which the amount of time is 0. In that jurisdiction, if
| somebody owes you money and pays you money, they aren't
| entitled for that particular payment to be returned just
| because it was an "accident".
|
| [0] https://www.google.com/amp/s/amp.cnn.com/cnn/2021/02/16/b
| usi...
| pjc50 wrote:
| The "if they owe you money" is very important here.
| cschneid wrote:
| that is a different case. That was a payment on a real
| debt, just earlier than intended (and due to a mistake).
|
| The top comment was talking about money that wasn't even
| billed. They don't have any actual service or product it
| was tied back to. Also if they do have agreements with that
| insurer (just no payments pending), there is going to be a
| contract overriding default law which probably covers how
| to handle mistakes.
| rmasters wrote:
| That ruling was overturned on appeal.
|
| https://www.reuters.com/markets/us/citigroup-wins-appeal-
| ove...
| PKop wrote:
| The question was obviously referring to money _not_ owed.
| bluGill wrote:
| Check with a lawyer, this varies all over the world and you
| don't want to mess this up. Not only might the money become
| theirs again, it might become theirs with interest. Though
| you might be able to charge them storage fees. don't forget
| that laws change so keep in touch with your lawyers so they
| notify you when laws changes so you can remain complaint.
| Make sure you keep record of what the lawyers say as well -
| if (when?) you mess something up record of trying to do the
| right thing can work to your favor in court.
| chasd00 wrote:
| I was just a kid at the time, I can't remember what they
| did with it over time. I do remember it getting pretty
| large one time and the executives were nervous about this
| pile of money they didn't know what to do with. The
| CEO/owner was a very honorable and decent guy though and I
| have 100% confidence whatever was the RightThing(tm) to do
| is what he did.
|
| heh 20 something years later and he still takes my calls to
| listen to my crazy business ideas.
| mytailorisrich wrote:
| Why did you cash/deposit the checks?
| ceejayoz wrote:
| Because the people with letter openers in the mail room
| aren't accountants?
| djbusby wrote:
| Right, they open the mail and give the check to the
| accountant, who deposited it.
|
| And we still want to know why.
| arnon wrote:
| Cashflow and Revenue are two separate concepts.
|
| You can cash a check today for revenue you accounted for
| 90 days ago.
|
| You need to reconcile it but it doesn't have to happen at
| the same time. It's very normal to reconcile months
| later.
| ceejayoz wrote:
| The minimum wage employee who stamps the check and
| deposits it at the bank with the hundred others in the
| pile isn't an accountant either.
|
| The accountants just go "huh, this one doesn't match up
| with anything" later on.
| velcrovan wrote:
| > The minimum wage employee who stamps the check and
| deposits it at the bank with the hundred others in the
| pile isn't an accountant either.
|
| That's not how any of this works lol
| staunton wrote:
| > That's not how any of this works lol
|
| How does it work?
| throwaway201606 wrote:
| It is exactly how all of this works
|
| In Canada, one of the main players in the space is INTRIA
|
| https://www.cibc.com/en/cibc-websites/intria.html
|
| They have an office full of people processing cheques,
| cash etc etc. In the old world, all cheques were
| processed by hand but in the new world, all cheques are
| processed by a combination of electronic imaging and
| MICR: people only look at the ones where tech processes
| fails. Which are a lot of them.
|
| This area of finance is called "Corporate Cash
| Management" - a bit of misnomer because it is not just
| cash and is primarily electronic these days. It is
| essentially about the processes that need to be in place
| to physically and electronically move money around.
|
| Here are some examples of what the biggest bank in Canada
| offers in this space.
|
| https://www.rbcroyalbank.com/business/paying-and-
| receiving/m...
|
| The do not explicitly mention cheques because that space
| is really well automated these days but it is mostly done
| really well by technology and most banks are trying to
| move away to electronic payments. But if you ask for it,
| you will get it at specially quoted per customer rates.
| robocat wrote:
| Nice article on declining cheque usage in Canada:
| https://www.bankofcanadamuseum.ca/2023/09/a-checkup-on-
| chequ...
| marcosdumay wrote:
| Probably, they open the mail and send checks directly to
| the bank. Then the bank sends the deposit information to
| the accountants.
|
| They certainly have all kind of strange things they must
| send to all kinds of people.
| thallium205 wrote:
| It is typical in the health insurance billing world where the
| check is sent separately from the explanation of benefits
| which details how they are paying for everything. You may get
| a random check in the mail that is paying for claims
| described in a separate letter or fax you received weeks
| earlier.
| pc86 wrote:
| Or later! As a patient I've received both payments from
| insurance providers and overpayment reimbursements from
| medical providers before the explanation of what the check
| is for. Usually just a day or two if that, but if something
| gets missed and has to go through a reconciliation process
| I could easily see that EOB letter going out a month or
| more later.
| snowwrestler wrote:
| It's way easier and more reliable to keep track of money in
| an accounting system than in random tiny pieces of paper.
| Money is safer in a bank account than as a tiny piece of
| paper.
|
| In terms of business process, it's better to have one single
| standard procedure of depositing (not cashing, ha) every
| check right away. Rather than asking any person handling a
| check to go through some sort of decision tree on the spot.
|
| If you need to return the money later you can always cut your
| own check.
| SoftTalker wrote:
| If you deposit a check for which you have no receivable or
| sale, what entry do you make in the accounting system?
| snowwrestler wrote:
| You use a suspense account.
| paulhart wrote:
| AKA a suspense account (in this case tied to the sender). "I
| have money from this entity but I don't yet know why".
| chasd00 wrote:
| sometimes the eob (explanation of benefits) would eventually
| show up but it would have no check number to tie it back to
| the payment. It would also span checks so you really had no
| way to tie what payment went to what prescription. You just
| had a pile of money and a pile of billed prescriptions. AR
| reconciliation, trying to figure out who paid for what and
| how much you're owed and how old it is, was a dark art and
| the code had all kind of tweaks for specific payers
| accommodating for all their payment inconsistencies. Some
| payers met the terms of the contract, some didn't, some had
| bugs where they'd over/under pay $1 in certain circumstances
| etc. It was a mess, i'd tell the payers to fix their system
| but they'd just blow me off (I was pretty naive at the time).
| Interestingly, i could tell when multiple payers leased the
| same system because there would be strange bugs consistent
| across payers. That $1 over/under payment sticks out in my
| mind 25 years later.
| throwitaway222 wrote:
| I wonder if you billed other entities (people?), and those
| bubbled to insurance carriers, meanwhile you left the accounts
| of those people in debt because no one cared to follow it back
| - call it magic money and leave the debt on people's accounts
| anyway?
| mattbee wrote:
| I don't know about this advice, you ain't gonna need half the
| features it talks about, and you absolutely can build it out
| gradually as your business grows.
|
| You do need to understand the concepts of invoices, credit, tax
| periods, pro-rata billing changes and so on... but all of that
| knowledge can be used to make an informed decision on build vs
| buy, rather than an automatic reason to outsource.
|
| The only external API you _need_ for software-as-a-service is a
| credit card processor, two if you 're fancy. Sure after the first
| year you will probably have a bunch of manual work to do and your
| accountants will tell you the dumb stuff you've done, and you'll
| learn a lot about accounting :)
|
| (I would still shop around to start a new business today, but
| with the confidence that building isn't very scary)
| rtpg wrote:
| The core thing with B2B SAAS is you make money off of higher
| touch sales, that lead to requirements.
|
| The objective as someone working on this kind of billing is
| simple: offer your sales teams the right options so they can
| close deals. This involves collaborating with your sales team
| to figure out what is in the "easy to implement x good enough
| to close deals" bucket
|
| I can't stess this enough. Your sales team is closing sales!
| Stop whining about your perfect billing system. Yes it is
| shocking but sometimes you have to apply elbow grease to
| problems involving business relationships
|
| You should try to do things in straightforward ways when
| possible but really you should have a system that is legible to
| other teams in your company, and one that is easily to manually
| tweak even with automation running around it. This is like 80%
| of why Stripe feels so good to use. Manual tweaks are a fact of
| life, even if for some businesses they're rare
| scott_w wrote:
| As someone who's been involved in both building and integrating
| billing systems, I can say you speak from a position of
| blissful ignorance.
|
| Building the system always looks easy, and on day 1, it really
| is. It also guarantees you'll spend many hours with your
| Finance Director explaining why the reports you send them are
| complete garbage; many hours with your Support team explaining
| why your invoicing failed, why you charged incorrect
| subscription prices, any many more fun edge cases you never
| knew existed.
|
| Next up, regulations change that you need to adapt to, or maybe
| your chosen gateway doesn't support a growing region.
|
| And before you say "just build it better," remember: that's
| also time. Time not spent on your product, improving your
| pricing model (oh, you need to build that yourself, too, of
| course), or any number of things you want to do that _actually_
| grow your business instead of standing still.
| regularfry wrote:
| > As someone who's been involved in both building and
| integrating billing systems, I can say you speak from a
| position of blissful ignorance.
|
| As someone who has worked on _exactly the same billing code
| and running system_ as the GP, I can say that you have
| dramatically underestimated their experience in this area.
| scott_w wrote:
| >>> Sure after the first year you will probably have a
| bunch of manual work to do and your accountants will tell
| you the dumb stuff you've done, and you'll learn a lot
| about accounting :)
|
| > I can say that you have dramatically underestimated their
| experience in this area.
|
| No, I really haven't.
| fatnoah wrote:
| My very first startup (early 2000's) was a SaaS billing
| platform. It was acquired long ago, but I've yet to work on
| any system that approached that level of complexity. Ignoring
| all of the challenges of taxes and such, things rapidly scale
| in complexity as soon as one needs some level of flexibility.
|
| For simple cases where entitlements are limited and the
| billing is generic, I think it's fine to built it yourself as
| long as you're aware of the time and cost of doing so vs.
| buying it. As others have said, time spent on building
| billing is time NOT spent on building products.
| marcosdumay wrote:
| Whatever route you are going, talk to your accountants _first_
| and see what information you must have attached to a payment
| for legal reasons.
|
| You can ignore everything else, but if you can't calculate your
| taxes later or end on the bad side of a KYC law, you'll have a
| really bad time.
|
| Also, keep in mind that just because some system sells for more
| money than you'd expect to spend and lots of companies that you
| imagine were savvy use it, it doesn't mean that the system is
| fit for purpose, and even less that it's fit for the purpose
| you want to give it. Buying doesn't free you from research.
| makeitdouble wrote:
| It comes down to what you want to be your core competency.
|
| If it's billing, sure go for it. Being fully able to customize
| your billing stack is I think a strength, exactly because of
| all the points the OP is making, plus many other traps. I think
| it can be genuinely interesting and there's always more to
| discover, but it's a full time job for a at least a small team
| for most companies.
|
| If instead your goal was to run a business or build user
| features, do other things, offloading the billing part is
| definitely the best (probably the only) option.
| jameshart wrote:
| Obtaining income from customers, and correctly accounting for
| it such that you can pay the right amounts of taxes on it so
| the government and your customers' lawyers will let you keep
| it, is in many senses the _only_ core competency a business
| needs.
| stevev wrote:
| For such systems that are commonly used by many, it's best to
| open source it. Don't reinvent the wheel.
| tuyiown wrote:
| We have hard time having proper implementations of interesting
| problems, how can we expect an workable open source billing
| system implementation ? With the proper engineering tradeoffs
| and flexibility needed to comply with all businesses and legal
| specificity ?
| TomNguy wrote:
| Have you tried Lago (open source billing)? This is precisely
| what they do, their HN launch is here:
| https://news.ycombinator.com/item?id=34773442 They listed the
| billing engineering nightmares too:
| https://news.ycombinator.com/item?id=31424450
| Axsuul wrote:
| We looked into them. Unfortunately they're very expensive.
| AnhTho_FR wrote:
| Lago co-founder here, although we have an Enterprise plan
| (which, by definition, is for Enterprises), we invest
| considerable resources in the open-source and free product,
| used by a lot of early stage companies/bootstrapped
| projects, let me know if we can be helpful.
| Axsuul wrote:
| I'm referring to the Premium Plan. We are not an
| enterprise but need a lot of the features offered at that
| tier, stuff that I feel most businesses need like credit
| notes and invoices sent by email.
| 6510 wrote:
| What really impressed me was the need to be able to run the
| entire Rube Goldberg machine backwards.
|
| You really want to have "the order" as static as possible, for
| "the invoice" there is even legal obligation.
|
| Then it goes something like...
|
| _I bought 5 and got a discount but I want only 3 and ohh there
| is a typo in my name and one in my address - sorry about that._
|
| No problem, you credit the invoice, make a new one for the same
| amount with the name and address correction, then you wait for
| the items to be returned and checked and credit it again, make a
| new invoice again. The return shipment stays in limbo for a
| while, they order 5 more, one arrives broken, they want a refund
| rather than a replacement. With 2 delivery dates the system
| doesn't apply the 5+ discount.... and all of a sudden you have
| tons of transactions and "paperwork" for what you initially
| imagined to be 2 simple orders. They also forgot their password
| so they made a new account using a different email address.
| Looking over the logs a year later it is hard to figure out why
| they got a discount for just 3 units.
| bearjaws wrote:
| Worked for a large travel website that rolled its own billing...
|
| Absolute nightmare when we blew up, had to hire 6 people to beef
| up the billing side of the website and it definitely cost us way
| more than those 6 people due to mistakes.
|
| I ended up working on parts of it for our customer service
| portal, lots of band-aides applied in a rush as we scaled.
| tuyiown wrote:
| How would you balance failure attribution of that bad scenario
| between "own billing" and "problematic implementation" ?
| bearjaws wrote:
| I am not going to go into every nuanced issue, but to give
| context rounding errors alone costed us hundreds of thousands
| of dollars in customer support and eng time. I am talking
| Office Space style fractions of pennies type problems. Mostly
| due to how long it was an issue before it was caught.
|
| Sure we could have probably botched implementation of some
| vendor, but we made every dumb mistake you could make and
| instead of doing it slowly we did it at scale.
| 6510 wrote:
| I wrote my own arithmetic functions just to deal with the
| paranoia.
| madsr wrote:
| Speaking of fractions of pennies: I've configured my AWS
| Cloud invoice to be in Euros, and every month the Net
| amount plus the VAT amount is always 1 cent off the Total
| fee :P
| zie wrote:
| Don't worry, every jurisdiction and bank will do the
| rounding of pennies differently, so you know, that's always
| a fun time.
| scott_w wrote:
| Because they're actually the same thing. A team that thinks
| it's the right thing to build their own billing system lacks
| the experience and knowledge to do it correctly.
| whydoineedthis wrote:
| I know the founders of bunny.com (which tries to solve this very
| problem). They sold a different b2b startup after 10 years and
| billing was such a pain they created a whole nother startup just
| to try and solve it. Lol.
| baq wrote:
| Don't know about them but they surely aren't the only ones.
| It's a proper mess.
| nickjj wrote:
| One thing this article doesn't mention are affiliate sales which
| depending on how far you want to go can be a decent amount of
| work. This is the system that lets other people get commission
| based payouts for sales within your platform.
|
| You need to track affiliate codes back to sales and a user,
| handle sending payouts to an affiliate at their configured
| payment provider and if you want to go all out then handle
| metrics around visitors and present a UI to the affiliate so they
| can see their conversion rates and payout history.
|
| Fortunately most of that can be built incrementally. As long as
| you associate a unique code to a user and wire up associating
| that to a sale with a specific commission % amount everything
| else can be done manually or skipped. For example I pay
| affiliates out once per month where I goto Zelle or PayPal and
| send out the payments. It takes less than 10 minutes. There is no
| front end for tracking conversions and it's also never been a
| cause of someone saying they don't want to be an affiliate
| because of that.
| etewiah wrote:
| There are actually quite a lot of solutions out there that fly
| under the radar but do a great job. Billsby for example has
| slowly crept up to becoming a significant player in the field by
| starting with a focus on one segment: recurrent billing. I can
| see a world where there could be multiple unicorns just in the
| billing sector of fintec.
| talkingtab wrote:
| The 14 pains of crossing the street and why you want to pay me to
| read my book.
|
| Many people think it is a good idea to close your eyes and just
| start walking, resulting in untimely injuries or even death.
|
| 1. Countries and even cities have different rules for crossing
| the street. 2. You may not know this yet but you need to look
| both ways. 3. Many people do not realize they are color blind,
| resulting in death and injuries because they cannot tell red from
| green. 4. You may look both ways, but do you look up as well? In
| cities people can drop things from windows, in the country birds
| may fly over head. More and more space junk is falling to earth.
| 5. Thing may come at you from multiple directions. 6. etc.
|
| Not saying this article is that bad, but I would appreciate an
| article framed as a how to. I am much more likely to read
| articles that are not framed negatively.
| brainzap wrote:
| streets are made up, a virtual seperation, just walk
| baq wrote:
| I work in a billing team now. Haven't been for majority of my
| career, though.
|
| The article is spot on.
|
| It's the ideal 'how hard can it be?' joke project, except it's
| all true.
|
| The list of examples is too long to count, but if you approach
| the problem incorrectly you're soon left with the question 'how
| much should the customer pay' and then 'why didn't we charge
| this amount but something else' and when this happens too often
| finance comes in and asks what did you do because the reports
| which run the company (including whether to lay off people or
| not) are not trustworthy.
| talkingtab wrote:
| I do not disagree. Like many problems, the simple cases are
| okay, but it is what you don't know that can lead you down
| the wrong path. But this is true of almost everything I can
| think of in software products. Databases? OMG don't get me
| started. After some short amount of experience everyone will
| flinch if someone says "how hard can it be".
|
| The issue I have is that while an article that gives people a
| heads up of what lies ahead would be very useful and helpful
| this was not that. Instead it was framed as "don't do it".
| Just not my cup of tea.
| spintin wrote:
| You should never build your own billing system because you do not
| want to do the global VAT work.
|
| itch.io is a good alternative if you sell digital assets and even
| services as you can verify payments with mail.
| surfingdino wrote:
| I really want one for physical goods. The global sales/vat
| network is a nightmare to navigate for a small business.
| komali2 wrote:
| I encountered this recently when I set up dolibarr for my
| restaurant in Taiwan. We have VAT in Taiwan but I feel like
| nobody actually knows how VAT is supposed to work. Sometimes
| a shop will charge us VAT, sometimes not, but what _never_
| happens is seeing VAT on your bill as a consumer, which means
| that every B2C in the country, other than Uber Eats, is
| eating the VAT. I assume. Or everyone 's committing tax fraud
| all the way up the chain. Honestly both are just as likely.
|
| If dolibarr didn't have auto handling for it I would have
| encountered it for the first time in my own program and
| instantly thrown my hands in the air and just done paper
| ledgers. I can't even imagine coding around it.
| baq wrote:
| The point of VAT (...in EU) in B2C is that the B eats the
| VAT. You'll see the VAT-less subtotal on receipts - but
| prices on shelves are strictly including VAT.
| bluGill wrote:
| You build things yourself because A: you really like doing that
| (that is a hobby thing, not something to run a business on); B:
| you are really good at it and so have made it a core business
| item you use to make money (you are selling your system to
| others) C: you can't trust anyone else to do it.
|
| In finance C is a big one! A bad billing system can kill you,
| and so despite the complexity it might be worth doing just
| because you now are in control. If you choose to buy a billing
| system anyway, you still need to understand how it works in
| enough detail to audit it. A corrupt billing system can hide
| how it is siphoning your money away and the numbers seem to
| balance and so you don't realize it is at fault. A bad billing
| system will not apply some tax it should and when you fail an
| audit the government will demand you pay - the unexpected bill
| will kill you. There are many variations on both of the above.
| You need to audit your systems to ensure they don't happen to
| you.
|
| Despite the above I generally would suggest you buy a billing
| system not build your own. However that doesn't absolve you
| from understanding billing in enough detail to audit yours on a
| high level. You also need to select one that your independent
| auditors (which might be too expensive to have but you really
| want) can audit in whatever detail needed.
| jokethrowaway wrote:
| You generally hire third party auditors at scale.
|
| I agree you should use an existing system and learn it well,
| so you can audit.
| bluGill wrote:
| Good idea, but you need to audit your auditors.
| skerit wrote:
| > C: you can't trust anyone else to do it
|
| Services are also mostly made for the average user, and that
| average user is never you.
| idlewords wrote:
| My shameful secret as a small US-based company is that nothing
| happens if you don't do the VAT work. You just get email from
| irate Germans sometimes.
| lakomen wrote:
| There's a form and you put in all the VAT information of the
| foreign countries. You need their VAT numbers though.
|
| That's how it works in Germany.
|
| And I'm not running a shop, just for Google Adsense.
|
| It's just normal procedure. You have to keep all invoices for
| several years, 1 out of 365 days I do the yearly tax. It's just
| part of running a business.
| actionfromafar wrote:
| Of course unless you only have a select number of customers,
| all or most in your country.
| huqedato wrote:
| AFAIK, in EU countries you cannot build/run "your own" billing
| system. Unless you have a special type of company/enterprise that
| is accredited and registered specifically for this purpose. This
| is officially named "Payment Processor".
| brettermeier wrote:
| Really? Do you have a link to laws for that?
| huqedato wrote:
| It depends on each EU country. For Italy:
| https://www.bancaditalia.it/compiti/sispaga-
| mercati/normativ...
| gizmo wrote:
| Why do you believe that? You can just write software to bill
| your customers. There are no special laws prohibiting
| automation.
| huqedato wrote:
| At least in EU, nope! Because it's not just "automation".
| It's more about dealing with other people's money,
| accounting, taxation, sensitive data collection etc.,etc. You
| should be first registered as a "payment processor" type.
| gizmo wrote:
| You can charge customers by direct debit (bank to bank)
| with an API. You can create your own pdf invoices and email
| them. You can charge customers with paypal or use credit
| cards or any of the EU specific online payment methods.
|
| There is no EU directive or law prohibiting this. You don't
| need any kind of "special data collection" authorization.
| Most SMBs just print their own invoices with MS Word or
| some generic software package.
| jokethrowaway wrote:
| That's incorrect, at least for some countries in Europe,
| including Italy (which you mention below).
|
| You can have your in-house billing system (but all the
| other eu crappy regulations apply, eg. GDPR, VATMOSS), what
| I think you are referring to is becoming a money
| transmitter, which requires a special license.
| arnon wrote:
| Not in all EU countries, but there's a new law in Spain that
| aims to address this
|
| https://www.fonoa.com/blog/spain-publishes-draft-ordinance-r...
| huqedato wrote:
| I think it's regulated at the EU level:
| https://finance.ec.europa.eu/consumer-finance-and-
| payments/p...
| avtolik wrote:
| Looks like this is regarding payment processors like banks,
| credit card companies, various payment fintechs like
| revolut, paypal, etc.
| pjc50 wrote:
| This isn't true. Your own billing system is fine. It's only if
| you're handling money for third parties - billing for goods or
| services that you didn't sell - that it becomes a problem.
| Every single B2B business does not have to be its own "payments
| processor".
| ThePhysicist wrote:
| I think you confuse billing with payment processing, those are
| two different things. Also there are tons of companies that do
| e.g. use SEPA direct debit to charge customers (of course
| relying on a bank to do the transactions), that's illegal now?
| I think the legislation concerns payment processing services
| like PayPal and in general any service that processes payments
| for third parties.
| lakomen wrote:
| Automated payments in the EU, since the PSD2 law, are no longer
| possible. Because of the "security" aka TOTP requirement for
| every activity.
|
| You can become a financial information service or a financial
| transaction service.
|
| The information service requires the periodic purchase of a
| certificate and registration with some very annoying hurdles.
|
| The transaction service requires a certification procedure and
| a lot of money as well as all of what the information service
| requires.
|
| The EU is a POS. Lobby-created laws that favor the established,
| rich companies.
|
| It's an elite club and you're not in it, and they're making
| sure you won't be part of it. I tried to get information about
| the information service registration process from the German
| Bafin, for over 6 months over several mails. Just tell me what
| to do, I want to open a financial information service.
|
| They have not given me any information at all. The employed
| lawyer kept evading my questions and responded with things that
| have no reference or meaning in regards to my questions.
|
| I'm not part of the club and they're keeping me from becoming
| part of it.
|
| Corrupt.
| avtolik wrote:
| Huh? I live in EU and I pay for a lot of stuff with automated
| payments.
| carlosjobim wrote:
| Not true at all. You can build and run your own billing system.
| You can bill on hand written paper notes if you want! And many
| still do.
| atonse wrote:
| I don't know what this person is talking about, our billing was
| brain dead simple, it's only got like 20 lines of Stripe Billing
| code. :-)
|
| But in all seriousness, we looked at Stripe, thought about "aw
| man is it worth spending the .5% extra" and then spent about 30
| seconds thinking about how much time it would take to roll our
| own, and it was an absolute no brainer.
|
| (replace Stripe with any of the other similar competitors, not
| trying to be too biased, but stripe is kind of the mind-share
| default for SaaS startups, aren't they?)
| Rafsark wrote:
| (Lago co-founder here.) I guess it depends on how complex your
| pricing and monetization process are (is it the same pricing
| for everyone or custom ; is it a simple subscription: or a is
| there revenue share, transactional pricing, usage-based, tiers
| ; is it self-serve or sales-led with a quoting system, do you
| have grandfathered plans, do you need to use other payment
| processors than Stripe - "Stripe Billing" is only usable with
| "Stripe Payments").
|
| In some cases, it's "brain dead simple", in a lot of cases it
| ends up "being much more complex than it seemed".
|
| Related threads: - "Why Stripe doesn't use Stripe Billing":
| https://news.ycombinator.com/item?id=33191307 - "Stripe's real
| pricing: a primer" :
| https://news.ycombinator.com/item?id=33920019
| godzillabrennus wrote:
| I helped build a billing system for a smallish family business.
| It had cost overruns and was way behind schedule. A year or so
| after planned release and after bringing in some more senior
| leadership it was a huge success for them. Integrated their
| customers database with their new SaaS products and facilitated
| very unique workflows that a legacy business needed to get
| through a digital transformation.
|
| Very unique circumstances but huge undertaking.
| epberry wrote:
| On the other side of this, understanding usage based consumption
| billing as a customer is very tough. First got exposure to this
| working on https://ec2instances.info.
| baq wrote:
| I postulate this has been the true cause of the cloud
| revolution: accurate usage billing.
|
| Everyone can rent out a server. Not everyone can rent out
| 16.83% of a server and bill it by the second and by the byte.
| idlewords wrote:
| Summary: just use picodollars!
| jdwyah wrote:
| What are y'all using for entitlements? Do you use your feature
| flag system? A different saas like Stigg? Or a separate internal
| system?
|
| I was just coming to hn this morning because I wrote about using
| FF for entitlements: https://prefab.cloud/blog/modeling-product-
| entitlements-with... I took some inspiration from another of
| Arnon's posts about SKU format for the post.
|
| FF don't seem like the perfect place for entitlements, but in my
| experience they're often the best tool at hand to deal with the
| challenges. I'd love to hear alternative opinions.
| heipei wrote:
| We just use a combination of numerical limits (e.g. API calls
| per day) and product flags as an array of tags
| (features:["module1", "module2"]). These limits and flags are
| attached set on "plans" which can be attached to accounts.
| Plans can be combined, in which case we'll take the larger
| value for each numerical value and combine the tags using
| union. Additionally one can override / add to any of these
| values on a per-account basis, so if your customer needs PlanX
| but a custom API quota then you just override that single value
| directly on their account.
|
| Call me old-school, but I don't get why something like this
| should be outsourced to a third party.
| jdwyah wrote:
| yeah, the overhead of another system for people to understand
| is non-trivial.
|
| So your accounts can have N plans. Do each of those plans map
| directly to a sku that they are paying for?
| baq wrote:
| If you already have a process for repackaging entitlements in
| plans and addons whenever some bright mind in marketing has
| an idea, the it's completely fine.
| LeFever wrote:
| I'm actually working on a solution to plan entitlements among
| other similar functionality right now. While you can get a
| basic solution set up with feature flags, we've found that the
| organization and evolution of billing/pricing-related
| entitlements (E.g. plans, editions, etc.), especially over
| time, is increasingly complex with lots of requirements in the
| peripheral. Think things like varying combinations of feature,
| seats, and usage-based/metered strategies, team subscriptions,
| plan migrations, one-off enterprise plans, multi-subscription
| customers (E.g. promotion periods and layered subscriptions),
| usage aggregation, automated upselling, etc.
|
| As you show in your blog (Nice post btw!), while you can have a
| flag with a numerical value representing a limit, the
| infrastructure for tracking usage is left to the business to
| implement. Imagine instead that you emit usage of that lever to
| an entitlement service and entitlements based on that usage are
| updated in real-time, even across teams. Also imagine that you
| have other entitlements that may be dependent on that
| entitlement that update as well. In addition, as limits are
| approached or crossed, you can choose to have soft enforcement
| (I.e. let them continue, but notify sales to reach out) or hard
| enforcement and display a prompt to upgrade.
|
| In the spirit of OP's link, we work alongside existing billing
| solutions rather than try to reinvent the wheel there. We're
| bootstrapped via a previous successful exit and working with
| early customers, so if anyone's interested in chatting, even to
| just geek out on this topic, please reach out: trent at
| planship.io.
| jdwyah wrote:
| yes, this is needed too. Specifically for real usage based
| systems, how do we get these limits to apply all the way down
| to our API rate limits / filters? And how do we output the
| usage of these things back to the billing system for
| metering.
|
| Sooo many usage based pricing things out there (ironically
| with totally non-transparent pricing), but I agree that it
| doesn't feel like the right solution has been built yet.
| LeFever wrote:
| > ironically with totally non-transparent pricing
|
| Oh man tell me about it. I also think the trend towards
| metered, pay-as-you-go pricing in general doesn't make
| sense for many businesses or their customers, but I
| digress.
|
| Curious if you've thought much on how to distill feature-
| flag entitlements, service-limit entitlements, role-based
| entitlements, billing-based entitlements, and so on to a
| single interface like "Can I [action]?"
|
| Edit: Ha, just saw your reply in a separate thread. Yes,
| you have thought about it. :) Would be curious to learn
| more.
| jdwyah wrote:
| So yeah, some assorted thoughts:
|
| 1. Some of these are primarily updated in a UI, some are
| driven from some other system. Flags are customer UI, but
| Auth is often customer's customer (admins setting RBAC)
| or derived from SAML Role / etc.
|
| 2. There are very different personas / different blast-
| radiuses for different changes. This means that there
| should be different interfaces for the creation and
| administration of the different type of things.
|
| 3. Different scales. Dynamic configuration / feature
| flags are great, but you don't want the rule payload to
| be GB, which you would have if you tried to store fine
| grained permissions inside it. Zanzibar is awesome and
| should be available to more people.
|
| 4. It would be best if we could all agree on the names &
| types of these objects. I think schema files and code-
| generation are underused.
|
| 5. My inclination is that entitlements are just feature
| flags under the covers, but that there's enough different
| that a custom UX is warranted.
|
| 6. It's easy to add a ton of latency to applications with
| this stuff. First we spend 50ms getting the user... then
| we go get the billing for 50ms... then we get the
| entitlements for 50ms... There are big gains to be had by
| having this solved holisticaly.
|
| hmu anytime jdwyer at prefab.cloud would love to hear
| your thoughts.
| jschorr wrote:
| "Can I [action]?" is the exact question that Zanzibar[0]
| was designed to answer in a highly performant and
| scalable way.
|
| With multiple data sources reading and writing to SpiceDB
| [1] (our OSS implementation of Zanzibar), those questions
| can further be extended into "Can [subject] [action] on
| [resource]", which allows for supporting not just
| permissions, but (as you suggested) feature flags,
| entitlements, role-based access control and even billing-
| based entitlements (if the billing system's information
| is supplied in as relationships or dynamically via caveat
| context [2]).
|
| As a concrete example, feature flags can be represented
| as a straightforward permission:
| definition user {} definition featureflag {
| relation enabled: user permission is_enabled =
| enabled }
|
| They can then be checked directly: check
| featureflag:somefeature is_enabled user:{currentuserid}
|
| The real power comes into play when different aspects of
| the system are combined, such as only allowing a feature
| flag to be enabled if, say, the user also has another
| permission: definition organization {
| relation member: user } definition
| featureflag { relation enabled: user
| relation org: organization permission is_enabled
| = enabled & org->member }
|
| In the above example [3], a feature flag is only enabled
| for the specific user if they were granted the flag _and_
| they are a member of the organization for which the flag
| was created. While this is somewhat of a constructed
| example, it demonstrates how combining the models can be
| used to grant more capabilities.
|
| With caveats [2], these kinds of questions can even
| depend on _dynamic_ data, such as the time of day,
| whether the user 's account balance is positive, or even
| be random based on some distribution (to enabled, for
| example, partial enablement of feature flags)
|
| [0]: https://zanzibar.tech/ [1]: https://spicedb.io [2]:
| https://authzed.com/docs/spicedb/concepts/caveats [3]:
| https://play.authzed.com/s/eML6cLz9ByAZ/schema
|
| Disclaimer: I'm CTO and a cofounder at AuthZed, and we
| build SpiceDB
| aftbit wrote:
| Feature flags are one of those beautiful systems that are just
| expressive enough to be shoehorned into doing everything. Beta
| rollouts? Role-based auth? Billing entitelments? One-off
| customer requests? Yes. They can all be feature flags. The very
| best feature flags can optionally have a value attached to
| them. Then your API plan limits can just be feature flags.
|
| Now... is that the best way? Probably not, for any one of those
| use cases. But once you've built it, it is very tempting to use
| them for everything.
| jdwyah wrote:
| 100%
|
| I'm really interested in getting stronger opinions here about
| how to set people up for success. Being the founder of a
| feature flag company I feel like I'm a rope dealer.
|
| I'm really interesting in providing good authorization
| primitives as well. This is kinda the whole reason/vision for
| why Prefab exists. If you have an authorization tool and a
| separate feature flag tool and a separate billing tool.
| You're going to be tempted to do some weird un-holy things.
| If you can use one provider for it, then we can really help
| when it comes to putting things in the right place. My dream
| is that you can type user.can_do?(:thing) and get back a
| response that has checked the authorization, ff &
| entitlements system and gives you a clear and comprehensible
| answer.
| ylere wrote:
| I think as long as "feature flag entitlements" are seen as
| distinctly different from what engineers usually use feature
| flags for (small incremental changes of individual components,
| testing, roll-outs, A/B testing) they can work well. An
| entitlement should have a clear link to a _customer-facing
| feature_ , which are conceptually much larger blocks of
| functionality. One difficulty with this approach is that you
| still have to take into account a lot of billing-related
| aspects, e.g., handling customers in arrears, overage charges
| if they go over a certain limit, having different pricing
| models for the same feature, or resetting/carrying over usage
| counters on plan changes/upgrades - this can add a lot of
| complexity over time!
|
| That's why we decided to offer separate feature entitlements
| that are tightly coupled to the billing chain and metering as
| part of Wingback (disclaimer: I'm the CTO). In the end,
| depending on your plan complexity and how much you have already
| invested in feature flags, I think both approaches can work
| well. Having some kind of feature gating in place for your
| customers will also make your life a lot easier for
| provisioning customer accounts and being able to offer custom
| packages.
| d_burfoot wrote:
| I don't buy the overall structure of this argument: system X is
| very very complex, so you should never try to do it yourself,
| instead use an off-the-shelf solution for X.
|
| Perhaps the _general case_ of X is enormously tricky and complex,
| but in my use case I only need to handle a specific subset of the
| complexity. Therefore I can build my own solution that only
| handles the complexity I need, and it will be much simpler than
| off-the-shelf tools.
|
| I absolutely adopt this stance for X=datetime. My approach to
| datetime requires two function calls to be provided by the
| library: convert an epoch time to an ISO formatted time string in
| a particular TZ, and the inverse. I never touch any other library
| code; I do all other time manipulation in my own code, in terms
| of those two functions.
| makeitdouble wrote:
| > in my use case I only need to handle a specific subset of the
| complexity
|
| Thing is billing money leaves very little room for error and is
| regulated.
|
| From the start you'll need to understand all the dos and don't
| of personal info handling, the cycles and lifetime of the
| different billing options, cashback thresholds, support
| idempotency, sane DB transaction management with models that
| are adapted to the task, invoicing and exposing that to your
| client etc.
|
| It's not everything at once, but at least half of it just for
| your first workable implementation.
| msluyter wrote:
| I worked on a fairly complex invoicing system and couple of
| things not (directly) mentioned: * Forward
| billing vs billing in arrears. We had to treat different
| customers differently. * Tiered billing -- e.g., if a
| customer used > X amount of services, they got a discount.
| * Special rules around when billing starts for new customers
| (e.g., no bill for the first month).
|
| There are probably more I've forgotten. We billed by data usage,
| mostly, and I used to say that their bill was the integral of the
| customer's usage graph over a month -- which was true -- but that
| explanation didn't gain much traction with the accounting folks.
| wdb wrote:
| Can't be worse then needing to change a SAP system to work with
| the business processes than instead what is the cheaper and
| quicker way of changing the processes to better match SAP.
|
| Sometimes you had to reimplement whole systems that SAP comes out
| of the box with. Thanks not to be named fashion brand.
| paulhart wrote:
| If you're building a product, is the billing component a part of
| your USP?
|
| Really?
|
| Odds are that it's not, and therefore you should farm out that
| work to someone who _does_ make it their job. There are reasons
| why companies implement software from Microsoft, Oracle, and SAP,
| including that it's better to reduce costs on things that don't
| differentiate you in your market (and it's nice to have someone
| to "pointedly talk at" when things go wrong).
| 6510 wrote:
| I haven't really explored it but one idea I had (for small
| volume) was to make everything manual data entry then put
| suggestions and warnings with the form fields. Even if you
| perfect automation there will be exceptions and mistakes made. By
| doing it manually everything also gets reviewed.
| zie wrote:
| My rule of thumb: Always ask about rounding. If they don't have a
| sane answer, it's basically guaranteed that their system is
| broken in countless ways. Pretty much the only sane answer: Until
| you realize that every jurisdiction, bank and organization you
| interact with financially can and might round pennies
| differently, you don't understand financial systems enough to
| implement one. i.e. rounding is configurable or you are doing it
| wrong.
| gizmo wrote:
| Why does rounding matter? It's not important from an accounting
| perspective. And your billing system doesn't need to angrily
| send invoices when a customer owes a penny.
| zie wrote:
| For accounting, if your auditors and accountants don't care,
| I'm jealous. I've never met one that doesn't care.
| gizmo wrote:
| Tax laws were written for cash businesses where the cash in
| the register never 100% matches the sum of receipts. What
| matters in my experience is that your books are balanced,
| but there is no such thing as "perfect accounting." In the
| real world inventory goes missing for reasons unknown
| (broken, stolen, never delivered properly) and as long as
| you've got an entry in the books that plugs the hole it's
| fine in practice. Accountants and auditors don't do
| forensic investigations, not even for publicly listed
| businesses.
|
| I have never met an accountant who cared even slightly even
| about very significant tax compliance issues. Businesses
| don't want to change their sloppy ways either. They want to
| make money first and let the accountants clean up the mess
| later (impossible).
| zie wrote:
| We are talking about very different things. You are
| talking about mistakes that happen, sure that happens,
| write-offs of inventory or what have you obviously happen
| in every organization. We lose track of things, it
| happens, it's fuzzy. All accountants get that.
|
| That's not what I'm talking about at all. I'm talking
| about rounding math. If you always round down, and I
| always round up, and then we supposedly have 50M
| identical transactions, what is the likelihood that we
| are even in the same ballpark? fairly low.
|
| There are even many movie and TV shows involving rounding
| get rich schemes, including Superman:
| https://skeptics.stackexchange.com/questions/14925/has-a-
| pro...
|
| When you are talking about millions or billions of
| dollars, a rounding error can account for significant
| sums of money.
|
| When you and your bank are off on how much money you
| supposedly have by 6 or 8 figures due to rounding, you
| absolutely better care.
|
| The US has no consistent rounding laws for accounting,
| but the EU has a consistent rounding rule around the
| euro. The EU has an entire paper around rounding the euro
| available here: https://ec.europa.eu/economy_finance/publ
| ications/pages/publ... The US basically _shrugs_ and
| makes no ruling, because if you ever go interact with
| many different banks, you will find out that they don 't
| all round the same.
|
| Also you might find the wikipedia page interesting:
| https://en.wikipedia.org/wiki/Rounding There are plenty
| of rounding options, and sometimes figuring out how an
| organization you interact with decided to do their
| rounding can be a fun exercise :)
|
| If you know anything about dealing with money in
| computers, you know that floating point math and money
| math are completely incompatible, so you have to do
| decimal math to deal with money. This is like engineering
| of financial systems 101. Rounding math is financial
| systems 201.
| Aspos wrote:
| Each individual problem listed isn't that hard on its own. Some
| are even trivial. However there are so so many constraints one
| has to keep track of so system complexity quickly snowballs into
| something unmanageable. Each cog is simple, but the whole clock
| is insanely complex. And by the way, the clock can't stop and has
| to be running 24/7/365 while you keep changing it. Your code will
| quickly turn into a tangled up mess of stinky petrified
| spaghetti, so you will end up re-building your entire system from
| scratch every few years. And with each rebuild you will keep
| having the same trivial problems you already solved again and
| again and again.
|
| Billing problems in general are a subset of problems one has in
| banking because banking system basically = billing + interest
| calculation + payments + accounting + multiple equally complex
| things and it has to work in real-time in a super-regulated
| environment while working in perfect sync with other systems you
| don't control.
|
| If you do everything just right and manage to keep the can
| rolling down the street for sometime, there will be a moment when
| regulation changes or your business changes and your architects
| suddenly resign and you will end up with a mess which requires
| more engineering dollars than off-the-shelf system would.
|
| Don't build your business on such foundation. It is XXI century
| already, no need to re-invent stuff which is readily available
| for peanuts.
|
| Yet, every new neobank comes up with their own shiny corebanking
| ledger because they can't be bothered to look into somebody
| else's petrified spaghetti.
| WirelessGigabit wrote:
| > why can't we just dump a file of what we need to bill on S3,
| and have a CRON job pick it up and collect payment?
|
| Sounds like an engineer with not enough experience. We all did
| thought like this once.
|
| This is a solved problem. Don't roll your own queue / job system
| where you inevitably run into transactional problems. Use
| something like Airflow.
|
| And mentioning S3 in this sentence has no value. S3 is merely a
| way to store the data temporarily. But using S3 immediately makes
| us not consider (more suitable) alternatives.
| wolfspider wrote:
| I built one for the government keeping track of licensed
| professionals and receiving their payments for things reported in
| the field (mobile first web app). It collected over a quarter
| million dollars in 30-40 dollar payments with different tiers,
| refunds, overrides, and even penalties for non-payment all while
| being PCI compliant. One thing that helped a lot- create an auth
| system that lets the admin impersonate the customer to walk them
| through it. It's a tough paradigm to start with but pays off
| immensely. Another was generating excel files and reports on
| demand from any view of the data in the app. One of the
| developers on the project implemented a simple state machine for
| payment histories and stored it in a number of tables with FK
| constraints. Do not do this! That means in the future your app
| will need to deserialize every customer's history and after a few
| years the app will grind to a halt. This was the one issue with
| the app looking back. A state machine looks like a good fit for
| billing but if my future self could go back in time and warn
| everyone it would be with this one common problem or I wouldn't
| even make this comment in the first place. If you do consider
| using a state machine just create thousands of customers with
| long detailed histories up front and if you can load them all up
| quickly then that is a good sign. Your billing system will only
| perform as well as you can transform and index data from customer
| history in bulk.
| zengid wrote:
| I'm on the billing team and we just shipped our new platform send
| me your regards!
| coolThingsFirst wrote:
| Seems simple enough for a startup idea but prolly has been done
| thousands of times
| zackmorris wrote:
| This is why I'm so disappointed with Stripe.
|
| I found the documentation both overly verbose and lacking, so it
| took me longer than it should have to understand basics like
| subscription item ids and the 50-100 id types which people have
| collected into lists. Then there are simple bugs like how the go
| live button only shows in test mode, with no simple way to copy
| live mode data back into test environment(s), so developers have
| to manually export/import stuff that business people set up in
| their attempt to save time. The most basic features are missing,
| like a way to copy any object as json from the browser dashboard,
| forcing us to look down in the logs/events to copy the latest
| version, often with wildly inconsistent/unpredictable formats.
|
| And Stripe does little to support actual real-world use-cases,
| for example: subscription events come through webhooks ok, but
| subscriptions have a state like "active" or "incomplete" (meaning
| that payment hasn't gone through yet), causing subscriptions to
| become stateful. Meaning that instead of a user being subscribed
| (yes/no), the app has to consider additional criteria and edge
| cases around missing or lapsed payments. And there doesn't appear
| to be a synchronization mechanism for eventualities like a
| backend server being down for a day, causing events to be missed.
| Stripe does a best-effort resend some low number of times, but
| then the events are lost. It's up to the developer to diff the
| backend's database with the Stripe subscription list and then
| sync individual subscriptions manually.
|
| These are all just exactly the kinds of bugs/features I predicted
| would be there before I used it, which is why they felt like such
| a slap in the face. I suspect that there are conceptual
| shortcomings throughout nearly every service provided by Stripe,
| and I'd be over 50% confident that any ones I predict here would
| be found upon first use. These are artifacts of favoring agile
| over waterfall for formal engineering challenges.
|
| Basically what I'm saying is that I consider the Stripe API to be
| what an MVP payment processing system might have looked like back
| in the 1990s under older paradigms like SOAP/XML. But nobody has
| created a wrapper for Stripe yet that works how people expect,
| more like Venmo/PayPal that maps customer use-cases to CRUD
| operations.
|
| I thought that maybe Laravel Cashier would do some of the heavy
| lifting, but it appears to be just a thin wrapper over Stripe,
| with its own set of oversights.
|
| I know that everyone uses Stripe and apparently loves it, and I
| applaud its efforts and accomplishments around reducing the
| friction of payment processing. But I can't help but feel that
| there is an element of having to drink the kool-aid here. I would
| still recommend Stripe though, so this rant is directed more at
| its developers who may not be aware of these issues. Stripe would
| do well to perform some new user testing like Apple used to do
| when designing its human interface guidelines, to enumerate the
| pitfall(s) in each step of Stripe onboarding.
| ivanmontillam wrote:
| I'd argue that the pains of building a billing system are not the
| right approach to the topic. If building your own billing system
| is a path so much sought after, well, let that be.
|
| Billing systems are of high complexity; I recognise that.
| However, if Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome,
| Lago, Togai or anyone else has that body of knowledge, we could
| instead collect that knowledge in one place.
|
| Indeed, there's no better approach than the one that serves you.
| If you're a subscription-based SaaS, you have specific solutions
| for your business. If you're a usage-based API, you have specific
| solutions to the billing.
|
| But we could have all that knowledge, approaches, paradigms,
| programming patterns, better and best practices in one place,
| instead of discouraging the practice. There are also edge cases
| where a company is not U.S.-based or European, and a billing
| solution like Stripe wouldn't work, e.g. your company is based in
| Venezuela, and you can't have a Stripe account. What do you do in
| that case? You must forcefully build your own billing solution
| and connect it to the local payment gateways with their arcane
| SOAP-XML APIs.
|
| --
|
| On a separate note, "building your own billing system" reminds me
| of the topic of "rolling your own SIEM" with the typical Elastic
| + Grafana setup.
|
| I don't recommend it, but I understand why it's such a hot path
| for an IT Security department to do it.
| gopher_space wrote:
| The article considers billing systems in an interesting way.
| There are topics presented as problems that I'd hand off to
| accountants or other specialists we're probably already
| employing.
|
| > Billing systems are of high complexity; I recognise that.
| [...]
|
| They're less complex than whatever your developers are working
| on. The article tries to paint hard legal requirements as a
| difficulty, but in practice this means the specs are easy to
| find and well documented. Parts of the process _do_ change
| frequently, but those parts are well labeled and well
| explained.
|
| > Indeed, there's no better approach than the one that serves
| you. If you're a subscription-based SaaS, you have specific
| solutions for your business. If you're a usage-based API, you
| have specific solutions to the billing.
|
| I mean, will your customers allow you to shift the burden of
| responsibility? Is your income important enough to verify? Can
| you afford the haircut?
| doctor_eval wrote:
| > There are topics presented as problems that I'd hand off to
| accountants or other specialists we're probably already
| employing.
|
| But aren't we supposed to be automating this stuff? What
| software do you think the accountants use?
|
| You go to the accountants to ask the questions, but if you're
| billing at scale you can't just push the problem aside. The
| accountants already have jobs to do and _billing is not one
| of them_.
|
| > They're less complex than whatever your developers are
| working on
|
| I worked on billing systems for a long time. They are
| definitely more complex than whatever your developers are
| probably working on. It's all in the article.
|
| Just take proration. The user joins half way through the
| month and you have a monthly billing cycle. How much do they
| get charged?
|
| If you think this is an easy question, you don't understand
| billing.
|
| > The article tries to paint hard legal requirements as a
| difficulty, but in practice this means the specs are easy to
| find and well documented.
|
| That's the funniest thing I've read here in a while! The
| legislation is not even kept in one place. It's often opaque.
| You need an accountant to explain it to you. It gets worse
| when you're working with public companies.
|
| I'm sorry but your replies are the typical "billing is not
| that hard" of an inexperienced engineer, posted to an
| excellent article explaining exactly why billing is hard.
| meekaaku wrote:
| > Just take proration. The user joins half way through the
| month and you have a monthly billing cycle. How much do
| they get charged?
|
| If n days of m day month is used, the charge will be n/m *
| monthly_rate, no? And it would be just another line item in
| the monthly invoice.
| arnon wrote:
| 1. You assume monthly_rate exists. It's usually not
| defined that way...
|
| 2. Imagine some things are billed on a recurring basis
| (e.g., every 30 days), and some are every 1st of the
| month...
|
| 3. Assume, for example, that you charge per-user. What if
| there are 300 users added and 20 removed in one day. Do
| you refund the remaining time in the month? Is this a
| credit on their next invoice, a negative item on the
| current invoice, etc...
|
| There are many more situations that can mess this up even
| further.
| doctor_eval wrote:
| Ok. Hold my beer.
|
| What time zone is the billing performed in? And what time
| zone is the user in? Is the user part of a group billing
| scheme that is billed in a different time zone? Or do you
| bill everyone in the same time zone regardless of where
| they sign up? You need to know this in order to compute
| both "n" and "m".
|
| Do you need to break the billing into separate line
| items, for example, a service component and an
| entitlement component? What about addons or powerups? Are
| they all prorated? _are you sure?_
|
| What about fixed up-front charges? Surely these are _not_
| prorated?
|
| Do you charge in arrears or in advance? If you charge in
| advance, how many days/months in advance? If in arrears,
| when do you actually raise the charge? You need to know
| this to compute "m" and "n". How do you remember to pro-
| rate it? Bonus question: what's the process you use to
| ensure that arrears charges are _always_ raised? Not a
| cron job, surely?
|
| Is your billing cycle even monthly? Could it be
| quarterly? Weekly? Annual?
|
| Do you need to prorate _entitlements_? What about
| quantity entitlements like download volume? What about
| fixed entitlements like per seat licenses?
|
| Do you prorate to the millisecond, or the day? Is there a
| minimum proration period?
|
| Are there any accounting rules related to proration _in
| the accounting regime of the user being billed_?
|
| If you provide a signup bonus or coupon that exceeds the
| value of the prorated first billing period, how do you
| apply it to the account?
|
| Ok. That covers the stuff I can think of off the top of
| my head. There are probably just as many questions that
| I've forgotten.
|
| Ultimately, the problem is not determining how to
| prorate, since that's a simple ratio. The problem is to
| work out what "m" and "n" even means, and to compute
| their values in a way that works within the policies of
| the business you're billing for. And even a simple
| business will change requirements over enough time.
|
| Then, of course, there's dealing with things like refunds
| and cancellations. Which, in my experience, _everyone_
| gets wrong and pushes off to manual processes. And then
| there 's the other 12 things in TFA, each of which has at
| least as many twists and turns.
|
| (edited to focus only on proration.)
| wredue wrote:
| I built out billing in grocery, supply chain, oil & gas,
| tabs and subscriptions and without a doubt, they all have
| annoying complications that a person without experience
| would probably not consider.
|
| I wouldn't call billing "difficult" as much as it is
| "annoying", but I also have ~18 years experience in it.
| doctor_eval wrote:
| I think it's difficult because it's like an iceberg,
| there is so much more to it than what's obvious.
|
| I build billing systems in telco for 20+ years, so I
| don't think it's difficult any more either, but with that
| experience, I'd certainly do it very differently to how
| most people would approach it.
| trollied wrote:
| I have worked in billing for 20 years. Each country has its
| own laws & quirks. Things like having to issue corrective
| invoices instead of refunds/adjustments in some countries.
| Others require document numbering to be sequential in
| different ways (by customer, period etc). Rounding is
| another fun thing - want that done at an invoice level,
| line level? Up or down? Taxes are not fun, especially
| geocoded US taxes. You've got a leased line with rented
| equipment at both ends - Which of these is the service
| address for tax purposes? Both with different rates?
| Something else?
|
| I could go on.
|
| Just when you think you've learned it all, another crazy
| requirement pops up.
|
| You're correct when you say people underestimate the
| complexity.
| jacurtis wrote:
| Billing systems are complex... but so are most other SaaS
| systems. If you take any other SaaS product, it generally
| seems simple, "i could build it in a weekend". But having
| worked at these "simple" SaaS products, there is always a
| long tail of edge cases that you need to deal with that get
| deeper and deeper into complexity. That is what these
| articles about billing systems usually dive into. I agree
| they exist, but you see this on any system or platform when
| you start building it for many customers/users.
|
| I say this because building your own Billing System isn't any
| harder than any other platform problem. The difference is
| that most companies aren't in the business of building a
| billing system. They could hire engineers to focus on it, and
| they could build it just fine (it's not THAT difficult). It
| would just cost a lot of money and all they would do is
| recreate something similar to Stripe, Chargebee, and the
| other billing platforms out there, which have already solved
| these problems for you. These platforms charge you a
| relatively low fee (lower than the cost of a team of skilled
| engineers and PMs) to use it, so it doesn't make sense.
|
| It's not that the problem is debilitatingly difficult. There
| is just not enough value in building it when off-the-shelf
| solutions exist. There are some businesses that might benefit
| from a custom billing solution because they are too unique to
| use an off-the-shelf solution. These companies do build their
| own billing systems and do just fine, but maintain a large
| team of developers dedicated to the billing product. Examples
| of this might include AWS with their billing, AT&T or Verizon
| with their billing, and so on. For most companies though, it
| would cost far more to build and maintain your own billing
| system, than it might generate in revenue. Especially
| relative to just paying a 3% finance fee and getting it "for
| free" with a provider like Stripe or paying a low fee for a
| wrapper like Chargebee (which charges only $500 for $100,000k
| in MRR).
|
| So if you generate $100k MRR, would you rather go through the
| headache of building a billing system and spend $50k a month
| in a small team of engineers to maintain it, or would you
| rather just pay $500 for essentially the same thing with no
| headache? THe choice seems simple to me.
|
| So it's not that Billing Systems are hard... they just don't
| make sense to build. Any competent engineering team could
| solve the problems from a billing system, it just isn't worth
| it.
| tombert wrote:
| My first job after dropping out of college the first time was
| working for a Tae Kwon Do management firm, writing software to
| help people run martial arts studios. The job had me doing
| ColdFusion and Adobe Flash [1].
|
| Most of my job involved working on their marketing pages, but at
| some point they had me work on the credit card processing
| platform, and I've sort drawn a soft line in the sand that I
| won't do that ever again.
|
| Part of it was just that the code was really messy (it was
| ColdFusion after all), but a lot of it boiled down to having to
| deal with the million edge case conditions required to achieve
| PCI Compliance. Somehow, that company had managed to get a PCI
| Compliance label, and I have no idea how, because the code was
| held together with duct tape and prayers; there were hundreds of
| nested if statements, and if's nested inside else nested inside
| other ifs.
|
| I'm not saying that it's _unnecessarily_ complicated, but I know
| I 'm not smart enough to deal with it.
|
| [1] I'd like to point out, this was 2012; it was considered kind
| of outdated even at the time!
| kyrra wrote:
| 2 problems not talked about here that are things I've had to deal
| with:
|
| 1) Month/Quarter close. While this post talks about the account
| ledger, when you start dealing with a public company that has to
| report numbers, you have hard-cutoffs and have to make sure
| everything goes smoothly for month or quarter close.
|
| 2) Cash-in-transit accounting: this post assumes your payment
| processor is 100% correct and nothing goes wrong. When you get
| big enough, you need to be able to match any money that lands in
| a bank account with a given invoice/billing entry. You need to be
| able to detect any invoices that do not have a paired bank
| statement line. And as others have called out, the reverse can
| happen where you get paid for something that may not have an
| invoice item associated with it. Being able to deal with credits
| on a bank account not associated with a billing invoice can be
| equally important.
|
| Maybe you can say that these are all accounting departments
| problem, but they are tightly coupled and the 2 teams need to
| work together that there are no discrepancies between their
| books.
| dmoy wrote:
| > Month/Quarter close. While this post talks about the account
| ledger, when you start dealing with a public company
|
| Anyone even accounting adjacent to a big public company
| probably just had a mental brain shudder by mentioning this
|
| Whether it be the actual accountant having to stay up to
| midnight repeatedly because of close, or someone on
| tech/business side who needed something from accounting but
| they just dropped off the face of the planet for N time period
| because of close, or a family member, or whatever.
| gizmo wrote:
| If you don't do (2) from the very beginning you have no hope of
| getting your taxes correct. Your internal accounting and your
| bank account(s) will slowly diverge and the accountants won't
| know where to start looking for the problem.
| _pdp_ wrote:
| The general rule is not to build anything that is not your core
| expertise.
| welder wrote:
| I built my own hybrid billing system and yes it was painful, but
| it opened the door to more payment methods and allowed prorating
| across the different payment methods seamlessly. I think it
| increased my revenue, but I can't know for sure because maybe
| everyone would have just used credit cards if that was the only
| supported payment method.
| aChattuio wrote:
| What exactly did you build?
|
| PCI dss conform cc handling?
|
| What about liability in case of fraud?
| welder wrote:
| Just integrated with payment APIs Stripe, Braintree &
| Coinbase. I let them handle recurring transactions while my
| system handles setting up those recurring transactions
| including pricing, prorating, discounts, and trials.
| rahimnathwani wrote:
| "Let your ERP handle your RevRec/Accounting (or use what's built
| in with something else)."
|
| With that approach, how do you:
|
| 1. Make your ERP recognize revenue correctly? An ERP system isn't
| magically going to know how your revenue should be amortized
| based on certain events, or what should happen when a partially-
| amortized order is later upgraded/downgraded to a different
| package/plan.
|
| 2. Ensure that your refund/upgrade/downgrade calculations are
| consistent between product systems and the ERP system.
|
| Even if you emit all the necessary events (and each contains all
| the necessary data), there has to be some system that's
| programmed (or, at least, configured) to apply your revenue
| recognition rules to the event stream. Given how much difficulty
| people have even describing how things should work, I don't think
| you can just abdicate the revenue recognition to another system
| and just assume whoever configures/programs that system will do
| it right. Even if you can assume that, it's equivalent to saying
| "it's complicated so you shouldn't do it yourself; have someone
| else do it".
___________________________________________________________________
(page generated 2024-02-26 23:01 UTC)