I wanted to jump on this bandwagon with my own experience. I worked for a software company about 4 years ago that had 6 people (including myself). Our company did $40M - $50M a year in revenue. No VC funding. We took thousands of transactions a month on Stripe and we basically never thought about payments. The software auto-handled collections or cut people off if they weren't paying (which in turn got them to pay-up). It automatically re-charged delinquent accounts, it automatically let people know that their card was about to expire, it automatically updated credit cards issued from banks (yes, really), and much more. We really never thought about payments at all. 90% of our transactions were USA, about 8% were Canada. And the other 2% was from Singapore. Never ran into any problem with these.

6 person crew generating $40M a year with no VC funding. It was all operated off the money that came in the door. It can be done.

>> 90% of our transactions were USA, about 8% were Canada. And the other 2% was from Singapore. Never ran into any problem with these.

And I once ran a python script on my local computer and had no scaling issues. I dont know what all these people are talking about nginx, load-blanancers, blah! heck, I just used python -m simpleserver and Viola! it worked! See -- everyone can run a global business right from their macbook with 0 FTEs! I did it! (Please dont mind I picked the easiest script and conveniently based my business in places where Stripe works!)

So, people who ARE doing it are replying on this thread.

People who don't need 15 FTEs, or even one FTE to take pretty large volumes of payments from many countries in the world.

Another reply is talking about $40 million turnover without a FTE.

The latest revenue figures I can find for meetup is $15 million.

So it begs the question, are you the incompetent and inexperienced one for needing to overengineer, or are we, for doing it cheaply?

Its really not about scale. I can process 1 or 1million JSON messages with the same effort. Now also support 25 other message formats? Doesnt scale the same way.

I can support a trillion of US/Canadian/European transactions with mostly the same effort.

I can also do payments myself in "7 or 8 countries". If you can do payments in 100 countries by yourself, please please let me know how!

I think a lot of technologists confuse deploying code with actually handling transactions, charge-backs, local tax rates, etc. Also, just because you are small enough to ignore local tax laws does not mean everyone is.

Move fast and break things is all fun and games until you get charged for tax avoidance.

Five years ago, it was difficult to comply with tax laws in every US state, county, and jurisdiction (now there are services) -- can you imagine doing this globally?

But there is a service to handle that for you! https://www.avalara.com/us/en/index.html

Yes, and if it doesn't need even close to one FTE to do this for 5-10 countries, why the hell would you suddenly need 15 to do it for 100? The other question becomes, that if you're not going to become the next Facebook, why even try?

I think you've never actually done this, have you?

>> Yes, and if it doesn't need even close to one FTE to do this for 5-10 countries, why the hell would you suddenly need 15 to do it for 100?

Because things dont scale linearly? I mean I can support JSON messages in 5min. Another five minutes and I can support XML. So I should be able to support all the historical mainframe message formats in 5 minutes each right? No...

Until you have to deal with customer support. That takes an insane amount of bandwidth.

Its a $10 product, how much support are you expecting?

People expect the same level of support whether they're paying $1, $10, or $100 per month.

You can throw bodies at the front end by having support staff, bodies at the middle end by writing extensive help articles/documentation, or bodies at the back end to ensure you have robust data and reporting for pre-empting issues.

In any case, you need to think about it, and it'll take bodies.