1) Multi-cloud
and…
2) Multi-payment processor
These stories are horrifying. These cloud and payment processors simply do not care. They print money and provide no human support. Any venture that I make in the future will be cloud-agnostic containers on several cloud providers with at least two payment processors handling an even share of the load. Double work be damned. Stripe and GCP simply do not care.
If you’re on the .NET stack, our abstraction [0] is over PayPal, PayPal credit card, Stripe, ChargeBee, CoinBase, Amazon Payments, and other providers that have since been replaced with no-op exceptions because the payment processors have gone under.
I think abstracting over payment APIs has gotten so much more difficult this side of 2014 or so. They’re doing all they can to achieve consumer lock-in and trying mighty hard to each offer their own custom services that they try really hard to convince you need and can’t live without, and invariably there might be something in there you want to support in your abstraction, sometimes necessitating cascading architectural changes. This is probably the third “major overhaul” of the abstractions we’ve written as a result.
My previous company had a business contract with GCP and so wouldn't be cut off for, for example, a dodgy employee account tied to the business in some way.
It's amazing how many people put their email and credit card in a form, pay sticker price for a service, and have their entire business depend on it. The terms of those contracts necessarily have to protect the service from all sorts of malicious users who just click sign-up. Talk to a person, get a contract, and the whole conversation changes (and yes GCP has account managers for this).
Do kids these days not realize you can negotiate anything and everything with your vendors/suppliers/partners?
Yes, most SaaS companies LOVE it when you sign up for one of their standard plans, using THEIR standard T&C's, and standard payments.
But, DID YOU KNOW, if something is critical to your business, you can negotiate directly with pretty much every business on the face of the planet, and if your spend is large enough, or you're willing to pay, you can negotiate anything????
It's nuts, I know :)))))
Negotiating significant discounts needs a bit more work, commitment, or growth story. Discounts tend to scale with spend.
(Disclaimer, I now happen to work at Google, unrelated to cloud, but this was my experience at my previous employer)
Not sure if this has changed recently, but this was in about 2018/2019.
By all means use another payment provider as leverage to negotiate better contracts and rates, but I think it's unnecessary from a business reliability standpoint until you're very big and Stripe's downtime level (very small) is a material business risk. Spoiler: almost no one is this big.
Gumroad has their own failures, but if ANY issue with payment processing is intolerable, don’t bother running a business.
With backups - onsite, offsite, security, code reviews, pen testing, separate environments for testing, etc... all things that take time and aren't "light lifts".
If you skip and don't cover your bases? You're going to fall and you'll deserve the broken leg - or worse - when it happens.
In the real world, many businesses aren't created in the Silicon Valley by established founders and friends with VC funds, who can afford the time and cost to have all this.
Edit: To clarify, I am not saying that the things suggested are unimportant or not vital to an established business.. But that the bottom line for a brand new business with very few people involved is to survive and be stable enough to have the change of introduce backing on/off site, distaster recovery plans, paying for pen testing, security consultants, dedicated QA, etc.
I didn't say "they deserve to fail"... I said karma will happen. Deserve or not? If you don't have "insurance" then you'll pay eventually.
If you don't have backups? Good luck when the Cyrpo Locker hits. if you don't have redundant hard drives? Good luck when the click of doom hits you.
If you only have one payment processor who is known to randomly lock accounts without recourse? Then it's a matter of time until it happens to you.
I do get that shortcuts have to be made when starting... but those short cuts don't sidestep reality.
You'll typically lose ~half the user's each time you do that...
Unless uptime or payment processing are core to your business (newsflash, they're not for most startups), this would be a waste of time and a velocity drag on _everything_ we do in the future.
Way, way more important to get traction than worry about theoretical risks.
I work for a company the does exactly this [0]
It’s amazing to see companies who not only optimize their business logic. But also their payments and how that generates direct revenue. Being able to switch payment providers at the push of a button has really opened up opportunities for growth and derisked a critical part of their business.
[0]: https://primer.io
In the late 90s we wrote code to distribute and aggregate fraud checking, card payment processing, settlement accounting, receipt reporting, and refunds across multiple gateways so we could handle mega live event signups. That needs to be an OSS product.
In particular payments are a nightmare to generalize. Either they assume directly interacting with the user (do you have your customer enter their data twice?) or you have to collect the info and ensure you capture the superset of fields required (particularly onerous for international) and then have a process for handling KYC/fraud cases on each. Payment routing becomes more complex, each rail has its own timing you need to learn, exception cases, support protocols, and so on.
For cloud infra if you pick your APIs carefully you can make it fairly easy to lift-n-shift (eg using k8s and running your own Kafka) but it’s not going to be trivial if you use hosted services such as RDS, SQS, etc.
IMO you are WAY more likely to die from running out of runway than because of problems with your payment rail. These are bad when they come up, but remember you are seeing the worst cases highlighted here, and not the 99.9(…)% of customers that don’t have business-impacting issues. TANSTAAFL etc.
Aggregate engineering and customer experience are cost centers.
Our management culture is irreparably broken. Somehow the Linux kernel runs the world without them. Very few CRUD apps out there need a literal people pipeline to copy-paste React deps into git.
We’re missionaries for nation state currency, sharing the wealth we create with our neighbors through make-work tasks. We’re not engineers engaged in craft.
I can't imagine that existing on the payment front though. Even as a separate startup, a payment processing multiplexer just seems precarious, like “OK my business is now less dependent on Stripe but it's entirely dependent on the availability of this tiny company.”
Are you running any businesses this way now? What were the challenges?
Due diligence, lol. In fact, the world is just a huge mess, and you have to have backup plans for all the important things in your business, or not care for downtime.
Even Democratic “rule of law” places like Canada can seize your funds for engaging in “politically incorrect” behavior.
EDIT: Did I just leak a b dollar idea? Have fun :)
I mean, the answer is obviously yes, depending on what you consider integrators.