Ask HN: What is the easiest and cheapest way to manage payments not manually?

Programmers / tech people consistently underestimate how much manual work there is in finance. All finance is a shiny UI on top of a busy back office of people emailing Excel files around and printing them out and circling or highlighting bits of them.

Sounds like you should hire a finance associate/book keeper/accountant/personal assistant/CFO depending on the exact extent and complexity of the work you describe to carry on doing it (or something similar) on your behalf.

You have to lookup the plan manually... By looking up the card? (PCI compliance anyone?)

Imho you don't need payments management, you need a proper way to do billing automatically.

You know the plan, discounts, promotions. Personal agreememts have to be kept track off just like a discount. You have the credit card on file? Charge at s specific date the amount owned. Send the invoice electronically ahead of the charge happening and educate your clients to contact you when something is off. Spread out the process throughout the month if you have a lot of customers.

You're at the point where you have very specific requirements and the point where you need expertise.

Delegate the task to your book-keeper or accountant.

That probably means finding one.

It certainly means spending money.

If that's a problem, raise your prices because book-keeping and accounting are a cost of doing business.

Good luck.

It’s a problem I’ve seen and faced personally in my business albeit the invoicing rules are less complexed. Even then, it’s been tricky to find anything that provides enough automation and flexibility for me to override changes. I’m currently assessing whether it’s feasible to automate the workflow with minimal code. It won’t be fully end-to-end automation - it might be just enough that there will be components here and there with some human intervention.

I'm not looking at developing any solution. Rather, I am ready to choose a system that will optimize at least this basic part of the work with invoices, their formation and sending. How to choose is another question. For example here (https://inai.io/) in general no-code, and it turns out to be possible, but I suppose such system will be much less enable to customization) In addition, a system must allow you easily migrate off with all the data.

Have you thought about using Paddle? It takes both PayPal and CC. Also takes care of the taxes.

P.S. Could you tell me more about your trading startup? Any links to check out?

Hi - my name is Melih, and I work in Stripe Billing. I'd love to understand more about your scenario, and why you think Stripe Billing wouldn't work - if you're up for sharing the feedback.

Feel free to email me at melih@stripe.com, and we can connect in the new year.

That’s definitely a problem I’ve heard people Ask HN about before. It is one of those problems that vendors like to call out. My first hunch is that the problem of implementing it in general is harder than coding up a specific policy, but if the general solution is done right it should come out ahead.

As I understand it, it's easier to write a program from scratch rather than implement an existing solution?

Not necessarily.

Using a platform is the best way to go if the platform fits your needs.

I'm guessing that you already suspect that your use case might not fit what Stripe or Recurly or other platform vendors offer. It might be tempting to build your own, but....

Read this: Billing systems are harder to build than anyone ever thinks

https://www.getlago.com/blog/why-billing-systems-are-a-night...

There is another way. Simplify your use case so that it does fit one of the platforms. Reduce some features, or change the complexity of your billing setup. It may seem counterintuitive, but often this is the way to go.

You don't need a custom kitchen if one of the IKEA cabinets does not fit in the corner. It may be better to go with IKEA after all, and leave the corner without a cabinet.

After spending years maintaining a home grown billing system, I recommend against rolling your own. It's frustrating to spend time adding yet another hack to account for some new use case while there is a stack of other priorities waiting (that more directly impact the value of the business). I learned through experience that billing systems are complex and the complexity can sneak up on you over time.

> It's frustrating to spend time adding yet another hack to account for some new use case while there is a stack of other priorities waiting

The key diff between 'build' vs 'buy' seems to come down to an accommodation of one-off and sometimes frankly 'wrong' processes.

Using off the shelf prevents accommodating many oddities companies have accumulated (via growth, acquisition, whatever).

Build from scratch seems to always implicitly include "we'll handle every weird-ass edge case anyone might come at us with in the future, because we built it ourself".

There could be a middle ground of "build with certain parameters, but also normalize some existing processes by refusing to spend hundreds of hours building weird accounting processes for 1 customer someone because a salesperson needed to hit their target and told them anything was possible".

Dealt with accounting stuff years ago, and ... there weren't any accounting systems which could simply/easily handle 20 years of homegrown cruft. "If the customer number starts with P or X, and the account rep is Randy, they get a 5% discount until next summer". They had... 5000 customers, and about 30% of them had ad-hoc 'rules' like that. Hundreds of business rules various people just 'knew'. Just documenting and classifying them can take weeks.

I'm not saying no commercial systems can ever support that level of customization, but "we'll import all your stuff with 3 mouse clicks"-style marketing fluff ignores the reality that ... you have to adapt your business some, or you have to build in house. But even building in house, you still need to adapt your business processes to reduce/eliminate ad-hoc rules that people just yell down the hall to the accounting team.

It sounds like we've had very similar experiences. The fact that what you've described is so similar to what I've seen may say something. There are reasons to have a bespoke billing system but people should try REALLY hard to avoid the situation.

Something I saw regularly with one-off style sales deals was not accounting for the collateral damage to business processes like end-of-month accounting. It's not just the development costs for adding support to things like subscriptions. Changes ripple all the way through the business. Updates to the bespoke billing system (and related business processes) end up half-baked because they aren't a core part of the business. I've seen sales deals end up as a net loss over time due to the increased labor costs on the backend. Having some reasonable constraints that an off-the-shelf product will intrinsically enforce can prevent a lot of pain for all involved.

It's never pain that the sales folks have to bear, it seems. :)

Ha. Nope.

"Build" vs "Buy" is the dilemma of enterprise software.

My first instinct as a software dev is that coding up a prototype of a billing system can be completed more quickly than evaluating two or three vendors of billing systems.

Either way you can be highly successful or deeply disappointed. What really matters is the match between the mental model behind the system and your domain.

In principle the product you buy can have a lot more labor in it both in terms of design and implementation. On one level you benefit from outside investment into vendor but on another level you (and the investors) are paying for sales, marketing and management at the vendor too. The commercial product almost certainly has a better looking UI for your team to use. Something you develop yourself will likely have a minimal UI but if it meets your needs than that's good enough.

I totally agree that this is a huge issue. Especially if you don't do much coding)

These vendors are probably solving the problem of letting you automate your billing and invoicing process without developing your own system.

As you said earlier, there's already a lot of Ask HN about this. So a solution does exist.

I take your point that on the other hand it may require a lot of input on my part into an already existing program.

For example, if you were going from project to project as a developer - you would probably be doing your own system. And if as a project manager - you would look for an existing solution on the market, hoping to reduce development costs))

Organizations and individuals tend to oscillate. Often they do a "build" project that goes badly, resolve they are going to "buy", then "buy" goes badly and they are going to decide to "build" next time.

It would be a mistake to assume that either "build" or "buy" is automatically superior in any given situation.

What I will say is that the vendor has a team of flying monkeys that will spread FUD about "build" and the other vendors because that is the marketing message that moves the needle.

How good the product is really depends on the mental model it is based on. If the mental model is right it will be excellent but if it is wrong you are in for a world of pain.

Hi there, I'm Raffi, one of the co-founders of Lago (Billing API). I think this dilemma is amplified with specific topics like authentication, permissions or billing. Even if you come with a home-made solution that took you a month to build, it's a month that you've not dedicated building your own product. The second reason is because they require a lot of maintenance. Building a first version is never enough, especially if you have a sales or marketing team with a lot of imagination/needs. When we built a billing engine for a fintech (Qonto, that is now an European unicorn), the home made billing system took a month or two to develop, but it became a monster: iterations every month, new features asked by non tech users, new behaviors, bugs. The team of 2 engineers working on billing ended up being a core team of 12 people. We switched from backend engineers to billing engineers (that is not particularly funny when it's not your core product).

Again, it depends your needs and the complexity required by your business. Happy to discuss that deeper if needed.

I've read your story and agree completely that billing is hard. However I see that you mixed billing/payment with pricing or bill calculation.

It is not easier, but in order to understand why it's not easier, writing from scratch is one of the best options. And without understanding, what are the chances you'll come up with a good solution (either yourself, or through another SaaS)?

In essence, whatever path you take, anticipate that you will do a bad job on your first attempt. Failing is a learning step you can't skip.

In the olden days they'd hire an accountant. Not the cheapest, but arguably the easiest.

Why not write some python code to automate it using cronjobs?

I’m bootstrapping and I have python code that connects to my credit card processor, banks via api, vendors, slack and email using postmark.

End of the month the script generates invoices, emails them to customer/charge customers if credit card is tokenized. Then wait until payment is received in the bank. After which everything is reconciled.

Any exceptions I get a slack notification.