Used to work for a “high risk” payment processor, we inherited tons of accounts that were terminated by Stripe, Square, and PayPal. Here’s one small bit of inside info that may help the newer businesses out there:
Most real payment processors (e.g. banks, merchant services companies) “underwrite” a company BEFORE allowing them to process. Underwriting means they look over the business model, financials, etc and make sure the business is an acceptable risk, not doing anything illegal or against their terms, etc. So you’re more likely to be declined initially, but if you’re lit up, you should be good for the future because the underwriters actually saw the deal and approved it.
While I haven’t worked for these other companies, a lot of experience seems to show that Stripe, Square and PayPal operate differently: they light up ANYONE, and then only underwrite when the account hits a critical threshold of revenue. So it’s easy to get an account there, but if you scale up, that’s when you’ll be scrutinized and potentially terminated. It’s a very unethical practice because it ends up hitting businesses at the worst possible time, when the termination or suspension causes a huge financial hit.
So basically, always have a backup processor and use these web based services at small scale to prove out your model, but NEVER rely on them as your sole payment solution.
Great post, thank you. Makes sense. Have applied for stripe myself, and was amazed there weren’t more hoops to jump through. I guess they eat the risk until a threshold, as you say.
seriously you should write this as a blog
(or if you are trying to be pseud, let me interview you and I'll write it)
if this is SOP it's important information
I’m curious what benefit you think publishing the comment as a blog post would provide over the existent HN comment (which also has its own URL: https://news.ycombinator.com/item?id=32855106 https://news.ycombinator.com/item?id=32855106). Possibly better SEO?
I don't think it's unreasonable to think that a blog post has an easier time gaining traction than a HN comment outside of HN users.
I've literally never seen a link to an HN comment go viral on social media, such that my non-HN friends would read it. It happens for blog/medium/substack posts all the time.
More detail?
Good question. Feels like there's two Qs in there: 1) when is long-form better than short form, 2) why write about problems at all?
2. Why write at all: consensus drives policy change, and information drives consensus. Writing, of any length, assembles information, bundles it into an argument, and (if the argument lands) becomes a 'capsule' around which consensus can form.
1. Why long form: room for nuance and research. Long form can include different perspectives (including stripe's -- perhaps they have a reason for these practices). It can address questions like 'what % of the industry behaves this way, what are the downsides to the banks' approach'. The interview + editing process can tease out anecdotes that sharpen the argument, or uncover new aspects of the problem.
This part is selfish, but for the writer, long form lets you improve your own knowledge of the topic, and your ability to make arguments around it.
Ok, I thought you meant publishing the same text as in the comment, but as a blog post. So what you actually meant was “please expand on this in longer form”. So “blog” not necessarily as a publishing medium, but as a genre of text.
People outside of HN are more likely to click on and read a link to a blog post than a link to a random HN comment.
A blog post also feels more trustworthy than a random social media site comment.
Shocking, I know.
Would appreciate this blog or further deep dives; I’d like to take it to legislators and regulators demonstrating a regulatory gap.
What specifically is the regulatory gap here?
'due process' concerns around sudden blocking of routine traffic -- should platforms give notice, are they required to justify the ban in terms of their TOS + enforcement history, what is the time scale of appeals, can customers appeal to an independent body, and reporting transparency for enforcement
The “gap” is a customer choice though. I ran payments myself in 1999 and had to get a merchant account and deal with the bad APIs of the time. People can do this today. Or use Stripe. Not a great choice, but still a choice.
Agreed this deserves a blog post. Very interested in best practices around providing payments.
This explains all the mysterious and opaque decisions that are regularly posted here by affected businesses.
Thank you for sharing your insight!
And don't they use a bank's services so they don't have to go through the normal 'if you're going to be a bank' scrutiny? I'm guessing that they have a requirement from the banking service to vet anything that would normally need underwriting otherwise.
> a lot of experience seems to show that Stripe, Square and PayPal operate differently: they light up ANYONE, and then only underwrite when the account hits a critical threshold of revenue.
Sounds similar to how subprime lenders doled out the mortgages without any due diligence. They skimmed their bit off the top in transaction commissions, but later dumped them before they became a compliance hassle.
As a rule, there's nothing wrong about a default to accepting making deals with strangers.
And that's the only thing similar in here. The payment processors are not selling anything by fraudulent claiming they evaluated their quality.
What they do have is a very bad customers service that is prone to a different kind of crime (withholding people's money) and create a very unique kind of risk they don't communicate to their customers.
I'm pretty sure this would be considered a deceptive business practice by most courts of law. You can't just straight up lie about the terms of a business agreement - i.e. if you say you've evaluated a customer's creditworthiness but you really haven't I think there is a very good argument that any agreement was not made in good faith, however, Stripe's ToS probably requires mandatory arbitration, etc, so I'm not sure what recourse you have as a customer.
I also learned the hard way to never rely on a single payment processor. It was an expensive lesson. Of course, being thick-headed, I had to learn this lesson twice before it stuck.
Always have at least two payment processors. If you've got a lot of money on the line, get a third lined up, too.
Yep, as I was reading OP's story I kept waiting to get to the part where he switched to his backup payment processor and life went on. My brain: "You do have a backup payment processor, don't you? Don't you??"
If you're running a business and you find that it is utterly dependent on some single point of failure, you'd think that would be something you'd want to correct ASAP.
I think the part you missed is he's using Stripe Connect and its 35% of the merchants through him that lost the ability to process cards?
I used to work in technical/customer support for an internet payment gateway. The esoterica of internet payments are pretty out there; most of the people who called us just wanted to sell their widgets -- they barely understood what we were talking about when we'd ask them where they had their merchant bank account.
... which is to say that, yes, you and I as people who work deeply in a space, of course we know this thing is a SPOF. Everyone else? They don't know that. It took me a long time to acquire the empathy needed to talk them through this stuff, but it made me a better communicator, and it helped an awful lot of them understand.
It is a hard lesson with an expensive solution.
I agree with you, as you grow, you have to diversify. However, services like Stripe Connect are more difficult and time consuming to replicate. Stripe connect handles the processing of many different accounts and handles skimming the commissions and then depositing the proceeds into the individual bank accounts of your users after doing some cursory KYC. This service is of course not compatible with similar services offered by other processors, so you will have to write all the handling logic and integrate with the KYC providers and possibly separate ACH deposit providers on your own.
In other words, there is a lot of lock-in with services like Stripe Connect.
So if Stripe is one of the best "low risk" processors, who is the Stripe of "high risk" payment processors?
Cash.
There is no such thing. High risk means high transaction costs, high underwriting costs, and lots of insurance/legal/compliance work.
Your best bet is to pay the slightly higher fees by going directly through your actual bank.
Right, but who's got all that and an easy API and SDK? i.e. if you were willing to trade off higher fees for safety and slowness of ramping up in a compliance sense, but you do want quick dev ramp-up, who do you use?
CCBill
The difference is between the company having their own merchant account with a bank (which is what most large companies do) using an online payment gateway, and not having one and leveraging the processor's instead (which is what Stripe, Paypal, etc provide). When you apply for a merchant account you get that approval and underwriting, but with a hefty application fee for obvious reasons. If your payment gateway shut you down, you can just switch to a different one, but there'd be little reason for them to do so. Your bank is much less likely to shut you down, because you were preapproved. The main reason would be for high fraud/chargeback percentages.
When you use Stripe or Paypal or similar, you don't apply for your own merchant account. You make transactions using their merchant account. If there's a fraud or chargeback percentage issue, the banks will have a problem with them, not you, but it also means the service needs to be proactive in policing their clients so the banks never come after their merchant accounts.
When starting up a company, use a Stripe or a Paypal to get up quickly, but probably ramp up to using multiple quickly, so you have backups. As your revenue increases, apply for a merchant account and move your transactions over to that. There is an upfront cost, but the processing fees are significantly cheaper, and no one will pull the rug out from under you without quite a bit of correspondence. Even when using your own merchant account, you can find processors who will handle all the credit card input and transmission on their end instead of on your site, which greatly limits your PCI compliance requirements. Regardless, when you build your service, abstract the payment process such that you can easily add or switch providers. Don't be married to a single one, because at the least you should be switching to a merchant account when the application fee is lower than the transaction fee percentage difference.
Source: I also worked for (and was the principle developer of) a high risk payment processor, providing a processing gateway for individual merchant accounts serviced by an ISO. We tried to look at becoming an IPSP (I think that's the acronym), letting customers leverage our merchant accounts like Stripe or Paypal do, but it was significantly more work and process with credit card companies than we wanted to deal with.
Costco Merchant Services did exactly this to us way back in the day( 2007-ish?). We switched from our previous merchant account bank due to better rates near the beginning of that year.
Everything was fine, up until right after Thanksgiving. This was an ecommerce company, so a sudden 500% increase in authorization volume is pretty normal and expected. Well, not to Costco ( or rather, the bank whose services they were reselling ). Our account was immediately deactivated, and we ended up having to spend a week begging our previous bank to reactivate our previous account.
That first night was, personally, an all-nighter writing janky code to encrypt cardholder data with ephemeral keys and store it off-database on an isolated, firewalled host (in order to pass the PCI-DSS SAQ coming to us in January), ship the product anyway, and hope that we'd be able to authorize a reasonable percentage of that unauthenticated cardholder data in the future.
This is what happens when you make business decisions based purely on price -- or in the case of Stripe, developer convenience.
Why those web services don't leverage from the fact/data that a real bank has already vetted you? And you use a real visa/mc/ae cards. They anyway block you.
This is how an auto insurance company I used to work for wrote policies. They didn’t underwrite them until there was a claim and then they would rescind the policy and deny the claim when they found a “material misrepresentation”. They called it underwriting on the back end.
>It’s a very unethical practice because it ends up hitting businesses at the worst possible time, when the termination or suspension causes a huge financial hit.
You forgot the part where Paypal get to keep your money when they close your account. And it's not like they only keep it temporarily in case of lawsuits/chargebacks, they just keep it forever. I still can't believe that crap is legal.
Added benefit, those real service providers, banks, cannot let you hang for that long without repercussions. Especially if it is reasonably sized business accounts and clients they have quite an incentive not to. Not all rosy of course, but much better it seems than those oyhet payment providers.
FWIW, PayPal tells you that if you expect to run a large business with them you should call them and escalate yourself to underwriting BEFORE you massively scale something up that might cause them to flag your account; and so, unlike with Amazon Flexible Payments--which did screw me over soon after I started operating--I never had issues with PayPal, as I followed their process and thereby had an assigned sales agent who could negotiate with underwriting from the get-go.
My company uses Stripe among others. We do on the order of 8 figures of transactions over all our payment channels. Not a whale by Stripe's standards, but not nothing either. We also have enterprise agreements in writing and signed contracts with all of them. It wasn't necessarily an underwriting process as far as I know, more of an enterprise software licensing agreement. But either way, they are obligated to provide services under the terms of the contract. The terms include some commitment to future use and get us at least a smidge of discount off their fees. As much as startups love buying services with transparent pricing where you just pick a service level and plunk down a credit card, when it's business critical, just call their biz dev team and ask for a contract.
This has been very informative. My gratitude to everyone who has elaborated on how underwriting works with these providers.
> Most real payment processors (e.g. banks, merchant services companies) “underwrite” a company BEFORE allowing them to process.
Sounds like there's an opportunity for a Stripe competitor that businesses can somewhat trust to not pull the rug, though that'd be quite the bootstrapping process.