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.

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.

How would Gumroad prevent this? Hell Gumroad has an entire FAQ devoted to account suspensions so it's clearly an issue for them too.

Isn’t Gumroad runs on top of Stripe itself?

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.

An alternate processor while stripe figures out the mess - revenue keeps coming in.

Gumroad has their own failures, but if ANY issue with payment processing is intolerable, don’t bother running a business.

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.

I wonder of a health club is preventing account cancelation, playing games, and end users are doing chargebacks.

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 :-}

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.

Whether you're 1 person or 10,000... if you skimp? you're going to get bit where your weakest.

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.

Do not take this advice.

The reason is simple. Cost. It makes everything a lot harder (and thus costly) at a time a startup can afford neither.

Are there any integrators that shim out multi payment processors?

EDIT: Did I just leak a b dollar idea? Have fun :)

What's the actual "idea" here?

I mean, the answer is obviously yes, depending on what you consider integrators.

A layer that makes it more palatable to switch between payment processors

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).

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.

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.

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.

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).

This x 1000!

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 :)))))

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 much do you need to spend to negotiate with Google?

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)

I got decent support from actual human beings for Google Cloud even when spending ~£100/monthly.

Not sure if this has changed recently, but this was in about 2018/2019.

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?

How big would a business have to be for this to work with a company like Stripe?

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.

So how do you get Stripe to send you a signed contract?

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

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.

[0]: https://www.nuget.org/packages/NeoSmart.Payments/

Reminds me of PHP's Omnipay

https://github.com/thephpleague/omnipay

Omnipay does not support Stripe SCA and is basically abandonware.

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.

> Multi-payment processing

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

Does it have a multiparty payment solution like Stripe Connect or is that per method, nothing to do with Primer?

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...

We use VGS to tokenize credit cards. Makes it much easier to switch payment provers.

Startup idea: wrapper around payments providers.

And then the wrapper company gets massive and starts wrongfully suspending customers...

Why the wrapper needs to be some open source software not owned or depending on anyone.

We just need a payment-wrapper-wrapper company! (We have to go deeper!)

There used to be one (Spreedly) but then it went out of business or changed models so I had to convert everyone anyway!

New challenge unlocked: design your application in an wrapper agnostic way to avoid getting locked out when the wrapper service bans you.

Better than losing all users though…?

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.

Just hope that your startup will make enough to pay for egress.

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.

This is the best argument for bitcoin.

Even Democratic “rule of law” places like Canada can seize your funds for engaging in “politically incorrect” behavior.

> 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?