At this point, I don’t know how any founder on HN doesn’t make their business…
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.
My most important overhaul for our business was abstracting over payments and ensuring we weren’t dependent on any one processor for online checkouts. It doesn’t matter who you are with or how flexible they are, sooner or later, for logistical, account, network, or other issues, if you have only one payment provider it is going to be unavailable and you’re going to be losing money.
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.
It’s nowhere near as comprehensive, of course. It only features the providers we’ve used ourselves.
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.
Or rather, get a contract with your cloud provider and payment processor that clearly lays out the terms under which they will and won't suspend you.
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????
Short generic answer for all SaaS/cloud: remarkably little. If you're a legit business, who can make payments as a business (rather than on a personal card), and have any small amount of spend, you should have no problem getting a basic contract that provides you some reliability for your business.
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)
They might like you being on their basic contract and high sticker price, but you know what they love even more? Having a person they can do sales calls with. It's amazing how much you can get out of companies just by, you know, talking to them.
How do you make a SLA were the compliance guy doesn't randomly kick you off, because he found your dark theme scary or don't understand your business model?
Getting a better contract, probably not big at all. That's more about the company being more verified than someone just signing up a landing page. Negotiating a better rate? I really don't know. We did it at ~6 figures per year in the very early stages of Stripe, but we were a UK beta account for them. I believe we continued to renegotiate at 7 and 8 figures per year, but we already had that relationship.
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.
Presumably, you'd have to start by talking to their sales people. There's a button near the bottom of their home page that leads to a sales contact form: https://stripe.com/contact/sales
Admirable, but neither of these are light lifts. Most startups are potentially better off just gambling they won't be in the %0.1 that get shut down due to big company shenanigans.
Any company that doesn't take steps that basically amount to insurance - and insurance is "just in case shit happens" - deserves the pain when the unthinkable happens.
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.
This is a terrible attitude to have, some startups are cobbled together by 1 or 2 people and get off the ground, yet you are expecting them to have a team of at least 12 and additional retainer resource of lawyers and similar otherwise "they deserve to fail"?
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.
Why? Can’t you have a dormant or lightly used gumroad account integrated into your site/app. It’s not trivial, but could be worth it. Most frameworks have these services already integrated.
In this case, it’s likely that they have set up recurring SEPA debit payments. Changing the payment provider won’t keep the revenue coming in - it would require every customer to sign up for debit again. And when stripe figures out the mess, you need to consolidate the two providers or you’ll end up debiting twice.
Looks like that might be the case. I might have been confusing Gumroad with Braintree. I was only attempting to give an example, not advocating for one specific processor.
A dormant account that suddenly gets a large influx of new users sounds like a great way to get auto-banned by some stupid automated process as well, just when you most need them to work :-}
Recurring payments have massive lock-in - typically there is no way to switch payment providers without requiring the user re-enter their payment details.
You'll typically lose ~half the user's each time you do that...
Being multi-payment processor still doesn't protect you fully. We had separate instances where Google In-App Purchases and Stripe halted payment processing until we were able to escalate via friends who worked at those companies to fix our issues. Customers on Stripe subscriptions through Google aren't going to all of a sudden switch. I guess it does limit blast radius somewhat, but it still sucks. It also forces us into the lowest common denominator of features supported across platforms (e.g., can't run a price reduction and an increased free trial period at the same time because of one payment provider).
I've been a founder and worked founder level for a long time.
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.
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.
On multi-cloud, it's rather don't be GCP only. On payment processors, used to be don't be just PayPal, then not just Stripe, and in general, yes, you want more than one.
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.
Way more than double the work to integrate two, since you need to define a generic API and product workflow on top of similar-but-different underlying APIs.
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.
VPs and PMs focused on updating things that are “concrete” to them like buttons, and logos soak up engineering agency.
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.
Have not used it myself yet, but Google has something called “Anthos” that seemed like it would reduce the work from 2x on the cloud front...
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.”
This is not a new idea -- it's a whole field of infrastructure called "Payments Orchestration". It probably doesn't make sense for small startups, but companies that process more than about $10M+ USD per year can (and do) definitely benefit from multiplexing transactions across multiple providers.
> 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.
Are you running any businesses this way now? What were the challenges?
Or you could just get your own merchant account for payment processing and do all the diligence and requirements upfront. And you get to talk to someone and explain what you're doing to resolve issues upfront.
How exactly does that help? We had a customer who told the payment processor he's going to be selling X. They were told it's perfectly fine. After a month, payment processor told the customer they found they're selling X and can't sell X using their service.
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.
Because merchant account is a contract with you and the bank. You get an individual merchant account that If any card provider doesn't like you, they can ban you. Stripe, you're using their merchant account. If banks ban that merchant account, they ban all stripe customers. Key difference in risk for your payment processor. I have had banks ban my merchant account but my payment processor didn't care.
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.