Hacker News Reader

Comment by orionint | Hacker News Reader

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.

View on HN

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.

One thing that is almost impossible to do on your own is to get a merchant account that you will be using to process payments on behalf of others. So if that is your business model, you are almost certainly in for the fight of your life with banks and merchant providers, along with some stupidly high reserve funds.

Stripe makes this super easy, but it is a house of cards based on stories like this one. So I agree, you still need to get your own merchant account, and not rely on stripe as you get larger, but depending on your business model it might be taking more of your time generating due diligence documents than an acquisition.

More specifically: if you're in the business of processing payments on behalf of others, you actually have "bank" as a core competency / requirement of your business model and need to make your plans accordingly (or carry the added risk of having your core business model outsourced).

What magic wand do banks possess that enables them to declare-into-existence a merchant account, anyway? I mean in a technical sense, not a legal sense. What are payment gateways and other banks seeing, that allows them to know that a particular merchant account X is a "real" account, that can be targeted with credit card payments, rather than a made-up one?

Is there an X.509-based hierarchical bank registrar system for charge-origination signing certificates, for putting charges onto the card networks? Is there a DNS registry of merchant accounts for pre-checking charges before attempting them? Do banks underwrite other banks into existence by signing their certs?

Pretty much none of that. What exists is a whole lot of money, a willingness to lose that money if a bank makes bad bets on the trust and security of a customer, a bunch of laws to adhere to, and willingness to go to jail if those laws aren't followed (or, perhaps willingness being the wrong word, an understanding one will go to jail if those laws aren't followed and protected parties lose money as a result ;) ).

In short, it's a different category of risk than the category that an individual business or even a business that is acting as a middleman for transactions takes on. And it's a different category precisely because most of the solutions aren't technical; they're legal, social, and financial. If a bank gets screwed it just gets screwed; even if the law intervenes to deal with transgression, money is often just gone as a result of such fraud. So they are comparatively more conservative in their decision-making.

Banks have a whole lot of bank laws. While mostly it is paperwork, it also means some trust and responsibility that can be used to do things that banks do fornon banks like process money. Check with the local laws. The law protects customers of banks at the expense of the bank, which is what you want customers to know before using you for bank like things.

Yes, this is why my previous company never went the IPSP route (letting customers accept payments with your merchant account). They are incredibly arduous to get approved, you practically need to have a bank CEO as your godfather to get it. Also you need to be at least PCI Level 1, which involves actual auditors going through your business and policies. That part is significantly easier than the IPSP though. OP doesn't sound like they were trying to do that though. They talk about their client's individual Stripe accounts being turned off.

This is probably what a business like OP's would need to do. When their customers are small, use a processor like Paypal or Stripe. But as customers get larger, OP should probably do what we did: partner with an ISO, who can get the customer their own merchant account. OP still does the processing for them, but the risk and finances run directly through the client, not OP. The ISO can also add in a margin on the transaction fees for OP if that's part of their business model.

What is a "large company" in this context? My employer is on track to run about $5m through Stripe this year, which will be our fourth full year using Stripe. Our first year we did about $2.75m. This year I've been getting occasional emails from a Stripe sales rep for the first time, which suggests that we've crossed some sort of threshold...

Your stripe transaction cost is probably around the advertised fee, 2.9% + 30¢

With an actual merchant account you can probably get closer to 2% or at least 2.5% + 25-30¢

At 5 million in transaction revenue, a .5% decrease would be 25k a year. You can probably get a larger decrease depending on how much risk your company's business has.

Stripe's sales rep might be contacting your company because you've hit the threshold where it's probably worth getting a merchant account, and they want to see if you're considering leaving to give you a discounted rate to stay. You're pretty much in Stripe's retention department because of your volume. It is definitely worthwhile at this point for your company to shop around for a merchant account. Some don't even have application fees if you're not a high risk business. At the least they can get an idea of how much they could save, and use that to leverage lower fees from Stripe.

I would still consider trying for a processing gateway that handles all the card transmission, though, even at a slightly higher margin. Handling the card at all means you need PCI Compliance. At your revenue you're probably PCI Level 2 or 3, which only requires a self-assessment questionnaire (that is lengthy but doable), and a quarterly vulnerability scan. At 6 Million transactions a year, you'll be PCI Level 1, which means you'll need an auditor to come in and look at your processes and policies.

Stripe will offer interchange plus model so you are actually paying the real interchange rate + whatever they tack on for settlement probably 25 basis points and some fixed rate of 0.05 a transaction. You shouldn’t be paying a blended rate if you’re doing significant volume.

If you’re using a gateway, there are some that Handle tokenization so you never have to touch the PANs and you don’t have to worry about PCI levels and audits. There’s no reason your systems should be touching PANs unless you’re really large and using multiple payment processors for scalability and redundancy like if you need to process a million transactions in a few hours.

thanks much for the tips!

Had to verify this information.

https://www.merchantmaverick.com/what-is-a-merchant-services...

Seems what they posted above is accurate.

Interesting. What will be the provider you recommend? Any local banks?

Unfortunately I know little about the process for actually applying for a merchant account or where to get it from. That's what the ISO we partnered with handled. Also it was "high risk" accounts (cough adult cough), that is different banks than you'd be using. Same with the competitor payment processors I'm aware of. If you're unfamiliar with the process and can't find a bank to walk you through it, an ISO is not a bad idea. They'll walk you through the process and help you find a bank, and also a processing gateway. They'll also add a margin on the processing fee, but it's not a big one, and certainly less than paypal or stripe.

For processors starting out, there's nothing wrong with using Stripe or Paypal etc. When you ramp up to using your own Merchant Account, Authorize.net isn't too bad as long as you're not doing recurring payments (those get tricky), or maybe even Rocketgate.

I think the best solution here, is add a payments orchestration solution to your stack.

There are others, I know of this spanish startup integrating with stripe.

In this way,you can have both your bank TPV/ Payments and Stripe working alongside, if any fails just put the other, or the one giving better prices by default, etc

https://monei.com/es/features/payments-orchestration/

If someone uses WooCommerce for their store, they have 79 different payment integrations, including Stripe, Paypal, Amazon Payments, along with merchant account gateways like Authorize.net. Some of them are paid extensions but rather cheap considering the use.

https://woocommerce.com/product-category/woocommerce-extensi...

If in fact High risk is necessary then NMI is the most common gateway. Be careful they require a rolling reserve and can require multiple buckets capped at a certain amount, commonly 50k / month.

We write a few a high risk accounts per month. As a matter of fact I just had a call center run across my desk a few hours ago.

Exhaust all underwriting options as each processor has a different risk tolerance. For instance this call center is now using NMI and a rolling reserve, I've found another processor (one of the big 5) that will not fall under the High Risk thus saving a boat load not to mention negating the accounting nightmare that comes with rolling reserves and high risk processing.

What Im talking about is to add another abstraction layer, so you can have both payment processors and decide which use on the fly, both integrated with any ecommerce framework you use

You're still going to have some grief is you sign up 2 years worth of customers to recurring subscription via Stripe and then have them pull the rug out from under you. Sure you can switch to your backup processor(s) for new customers, but you'll need to go back to all your existing subscription customers and ask them to re sign up to their recurring subscriptions with the new processor.

Its much harder to engineer a payment abstraction layer with recurring payments where you're not relying on Stripe's subscription features that are not migratable to another payment processor.

When building out your business, you need to look for possible points of failure, assess the risk of each point, and then consider mitigations.

Payment processing is a possible point of failure. Chances of it failing? I think anyone who's read HN/Reddit/etc would have to evaluate the chances as fairly high. Cost to the business of it failing? Often extremely high.

Having done this analysis, you can look at mitigations: sign up with both PayPal and Stripe, get a merchant account, etc.

Then build the redundancy into your system. Yes, this probably means you cannot use the fancy features because there's no good cross-provider abstraction. That's the cost: you might have to implement recurring transactions yourself.

This happens over and over again. Your individual business is worth basically nothing to your cloud provider, your payments provider, your CDN, your domain registry, etc. They do not care if it breaks.

You have to have redundancy for anything you cannot operate without.

Maybe the abstraction can be a selling point for your customers. They can sign-up for the recurring Stripe subscription but it comes with the risk of suspension. If they are ok with it, atleast they can't claim "I didn't know this" if/when it happens (this risk can be included in the contract to deal with executives leaving/"amnesia"). Or they can also have redundancy, which of course costs extra but can be thought of as an insurance and the abstraction does the rest.

This seems sound for one off transactions, but I'd be interested in how to make this work with subscriptions, assuming you don't want to take the PCI burden of holding the raw card details - is it a case of asking all your customers to resubmit their details to the new payment processor?

I guess in the case of the orchestrator you linked they retain the card details and can then charge using any of n processors, though I'd be interested in thoughts from the overall thread where people are advising to be ready to change payment processor

Spreedly is a very good provider for this.

Yes thank you, couldn't remember their name

Thank you for bringing the "payments orchestration solution" term here! Have something to learn about.

American Express and Chase. I have both and they are awesome... so far.

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

Are you saying you should empty your account constantly (nightly?) in case paypal gets shut down your account, for unknown and un-communicated reasons?

> Are you saying you should empty your account constantly.

When I was involved with taking payments through paypal that's what we did. For us there was no value in keeping payments in there but there was plenty of risk. We stopped using them very quickly though, their fees were ridiculous.

>Are you saying you should empty your account constantly

This doesn't really help. When you link your bank account with PayPal the link is 2 way. I.e. PayPal can, without any input from you, transfer money out of your account. They can even do that if the account is empty. Your bank will almost certainly allow an overdraft on your account and you're still liable for the amount + overdraft fees.

I had some issues with PayPal about a year ago and a senior rep at my bank talked me through these details.

With my bank, it wasn't even possible to turn off the overdraft feature.

Bottom line is, PayPal almost always wins.

You can upon sign up of any bank account not allow overdraft. In fact it is an opt-in feature, that depends on your bank they communicate properly with you. I have for instance ensured there is no overdraft added in our business accounts.

Or perhaps I am missing something here?

But yes, please remove overdraft from your accounts. I have no input to offer on paypal at this time.

P.S. Are you in the U.S.? I am just really surprised they bank deemed overdraft as a necessary feature in your case. I am personally interested in this case.

Not quite the same situation here, but overdrafting is a rather nasty feature in my experience. As a student I used a debit card to simplify my banking do I wouldn't have to think about how much money is in my account (if I'm unsure, simply send a text to get my balance or transfer); if I didn't have enough money in my account to buy a $10 lunch, then I wanted my transaction to fail, for budgeting reasons. This didn't work for two reasons:

1. Overdrafting. My bank would not allow me to turn off overdrafting on my checking account; any money in my savings account would be used to cover an underfunded purchase from my debit card, causing a $25 fee and there was nothing I could do about this, short of closing my savings account or reducing the amount of money in it. Since free checking was dependent on a linked savings account with $500 minimum balance, this wasn't an option. The overdraft/fee could cause the savings account balance to go below the minimum, and if I didn't notice I'd get a $25 fee for my savings account as well.

2. The school would constantly charge my debit card as a credit card, and the transaction wouldn't appear for up to two days. Doesn't really help me keep track of my balance when transactions don't show up. Cashiers at the student store could usually process the card properly, but every time I bought something to eat at the cafeteria it would process as credit, regardless of what I told them.

Today, I think bank policies have changed (though I switched banks before this) and I believe you can disable overdrafting on most large banks (WF and BofA, anyways)

I'm in Australia, there is no way for me to remove the overdraft.

Which bank is that? Seems very strange that they would do that, personal or merchant.

Yes, absolutely. Some banks offer "sweep accounts" that do this automatically. If they have to come to you to claw back some money, they're more likely to tell you why.

You know what's better than learning from your own mistake? learning form other people's mistake.

If you login during a vacation overseas and get your account locked, they keep everything in it. Doesn't matter if you never did any transactions yet and all that money is yours from the bank account you linked. If you get banned, you lose it. Getting your account and/or your money back is about the same level of difficulty as getting unbanned from a google account. It's not impossible, but be prepared to take them to court.

If you only use PayPal to purchase things online, the protection is great, but you don't want to be on the other end of that transaction.

I've had my Paypal account frozen because I was cheating by living in a different country, not just on holiday. I managed to recover it by giving them the documents they wanted to "prove" that I lived in the country my account was in. I think this included getting my bank to send statements to a family member's address and have them email me a copy. I know some people really do get locked out for good but that wasn't my experience.

Trying to get money from a real bank account (Lloyds in England) after moving out of the country was much harder though. It involved writing several letters and getting a policeman to stamp something, as well as multiple phone calls, including to several staff who gave me wrong advice. But still, they returned my money eventually.

yes. the paypal horror stories were very common and frequent ~10 years ago. that's how Braintree, Stripe, etc. got started.

Nb PayPal has owned BrainTree since 2013.

You probably already knew that, but for the benefit of anyone reading this who didn't.

There is even a feature called auto-sweeps that can be requested via support to enable automatic daily payouts

they still have $4k from me, I just gave up on it.

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.

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.

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

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?

How do you handle recurring subscriptions with this setup?

You use a 3rd party payment orchestration platform. Spreedly and Very Good Security both offer this and we use them for our business.

I am not familiar with this. What makes them less of a single point of failure?

All they really do is handle tokenization and pci compliance. They're not an active participant in the financial process, basically just a technical proxy. Thus no risk (to them) of charge backs or anything like that, so aside from you not paying your bill, they would have little to no reason to nuke your account.

They're just a tech solution orchestrating (recurring) payments to your payment processors. So they don't have to do the same checks as processors. So they are only a technical single point of failure.

Presumably you have to get certified with SAQ D for actually storing your custopmers payment info instead of tokenizing. Huge hassle.

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.

Costco or Elavon ?

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.

Sounds like private health insurance.

Initial form questions like "tell us if you have ever been to hospital for anything serious?", you're thinking "I'm not sure if that time I dropped in to the GP 5 years ago with a headache counts as serious [same for other things that seem trivial over the years, just being sensible]".

You phone the insurer to check, they say "oh there's no need to put that down, it's not meant for trivial things, you'd have to write an essay in a small box if we meant literally anything conceivable; don't worry about it". You couldn't possibly hope to remember every tiny thing over the years anyway, unless you had access to your various written medical records held by various parties.

10 years of premium payments later you make a claim because you now have MS, you need support and treatment, a brain scan confirms physical issues, and..... "your policy is invalid because you didn't tell us about that time you went in about a headache 15 years ago". They still keep the 10 years of premiums though.

You take them to court. Your lawyer mentions that this is extremely common practice by health insurance companies. They don't provide you with any way to confirm if your policy is valid until you make a claim, then it's too late. You did what you thought you were supposed to do. The lawyer says most people who then take the insurer to court are unable to prove they were misled, and the insurer keeps the premiums you paid despite not providing any actual insurance.

Don't ask me how I know.

I am not surprised.

I am disappointed the American people is simply putting up with this healthcare situation. I don't think it matters if your doctors welcome room is fancy. Or they have 10 administrators replying to you within minutes. In the end you want to be treated fast and efficiently, and it fails. But I digress.

I can see why paypal does this and I am glad we are planning on avoiding them in our back end.

This seems like straight fraud.

What company!!!??? Please don't just leave all of us hoping we aren't the unlucky guy that is using that company.

I wouldn't be surprised to find it is most insurance companies. The insurance industry as a whole is seriously messed up and congress seems unwilling to do anything about it.

> I wouldn't be surprised to find it is most insurance companies.

In the U.S. I guarantee you that most insurance companies are NOT doing this. What this company is doing is called "Bad Faith" in insurance jargon. And the penalties for this sort of behavior are enormous, and can even include the possibility of the company losing its license to sell insurance in a particular state.

> The insurance industry as a whole is seriously messed up and congress seems unwilling to do anything about it.

Congress doesn't do much with insurance because insurance in the U.S. is regulated at the state level, not the federal level.

LOL, wait until you hear about ERISA and learn that everything you just said is wrong for most employee insurance plans and that you can't even get damages when they act in bad faith.

> LOL, wait until you hear about ERISA and learn that everything you just said is wrong for most employee insurance plans and that you can't even get damages when they act in bad faith.

We may be talking past each other here. I was referring to property and casualty insurance in my comment, while it sounds like you're talking about health and disability insurance. Two completely different worlds and regulatory frameworks.

Fair, those are definitely much more fair but just a quick search will show there is no shortage of courts ruling in insurance companies favor even when acting in bad faith. Just looking at complaints on the insurance commissioners website for my state seems to indicates even when they do get fined the amounts are small.

It's half true. There's not really underwriting for auto policies like there is with life or home insurance. You register your rating rules with the state and anyone who qualifies gets a policy. All the risk calculations and pricing are just look up tables and done automatically.

Now if you are in line for a large payout the insurance company will definitely review your application to see if you lied. Significant lies will get your policy cancelled and no payout. So don't lie on any insurance applications.

Thanks! This makes sense of it.

Come on give us a hint or maybe just the company mascot?

Huh? That sure seems like fraud, unless there are details I'm missing here.

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

Would appreciate this blog or further deep dives; I’d like to take it to legislators and regulators demonstrating a regulatory gap.

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.

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

This. If you’re providing financial infrastructure, there should be exception recourse versus customers having to come to public forums to beg for help. You know, like banking regulation.

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). Possibly better SEO?

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.

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.

> I've literally never seen a link to an HN comment go viral on social media

I've never thought about this, but now that you've pointed it out, I'm realizing this is genuinely a fantastic feature.

Sounds like yet another of the many perks of the spartan design here. All substance, with just a hint of (cascading) style.

But for what reason? The styling?

Definitely. HN is suspiciously devoid images. To most people on the internet in 2022 that alone makes it wholly uninteresting.

I often wonder how the site survives without sticky autoplay videos popping up halfway down the page and covering 80% of the content...

Surely it's due to the mobile application that HN is always pushing. And the invasive tracking. And the paywall. And the ads, the ads go without saying.

The ads keep HN alive. But because each one only needs to sell "one product" (the job they're hiring for) nobody hardly notices them.

It uses images for the upvote/downvote arrows, the Y in the header, and the spacer gifs in the table layout (yes, HN uses table layouts)

HN reads like grumpy old tech and finance guys in Dockers pants and Alligator t-shirts stuck in 2000.

They're alligator polos, you rugrat!

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.

How, other than SEO? If you want to share a link to it, you already can.

More that you can go deeper in context / detail, with images, styling, better links

Rich-embeds in social media/communications platforms, mostly. Simply taking up more space in a Discord/Slack/Teams/$SOCIAL channel with a bold title, an excerpt, and an image adds visibility, context and is more interesting to the viewer.

A link to an HN thread is opaque, uninteresting, and context-less.

Name a blog post that has stuck with you because you learned something useful. Could you search for it and find it easily? Now do the same for an HN comment.

I'm pretty confident I could find any HN post that I remember with the search box at the bottom, or by googling it with site:news.ycombinator.com.

With, half of the blogs that I liked I can't remember the name of the blog, it's probably either been dropped from search engine indexes for being older than a year or two or pushed to the 10th page by better SEO, or the site has simply vanished.

OK, I have little doubt that many readers of HN could find something here, but I think that for the vast majority of people finding a blog post will be a lot easier than an HN post. Styling will be an obvious advantage, you will be able to take a very quick look at a blog post and be able to remember if it's what approximately you saw before or not. You will need to read at least partially through an HN post to gather if it is the wrong one and reject it.

That’s usually easy using Algolia when you have sufficiently unique search terms, but otherwise that’s what I meant by SEO. Any other reasons?

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.

More detail?

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

It's also the exact same model that private health insurers used before Obamacare. Do minimal underwriting unless someone gets really sick, then scrutinize the hell out of it, even offer bonuses to employees based on how many claims they find reasons to deny.

Did "Obamacare" do anything to end this phenomenon? That hasn't been the experience of people I know.

Yes. Everything is guaranteed issue unless you go with one of those weird Christian health insurance things. Insurance companies can't deny coverage now because of a pre-existing condition, and they can't go back and deny claims because of something someone put on an application. No one gets their insurance dropped because they get bone cancer and THEN a claims adjuster went and poured over their original application.

https://www.kff.org/health-reform/issue-brief/pre-existing-c...

"Before private insurance market rules in the Affordable Care Act (ACA) took effect in 2014, health insurance sold in the individual market in most states was medically underwritten.1 That means insurers evaluated the health status, health history, and other risk factors of applicants to determine whether and under what terms to issue coverage."

"Prior to the ACA’s coverage expansions, we estimated that 18% of individual market applications were denied. This is an underestimate of the impact of medical underwriting because many people with health conditions did not apply because they knew or were informed by an agent that they would not be accepted. Denial rates ranged from 0% in a handful of states with guaranteed issue to 33% in Kentucky, North Carolina, and Ohio. According to 2008 data from America’s Health Insurance Plans, denial rates ranged from about 5% for children to 29% for adults age 60-64 (again, not accounting for those who did not apply)."

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.

Arbitration doesn't mean no-recourse or bias toward to the provider.

Arbitration does absolutely means a bias to the party that requires it. You can't have a long-term relationship with a company and not acquire some bias.

Even if the arbiter is pure and just the company will learn how to represent its side in the best light before the arbiter; it has many chances to learn.

The other side has one chance to learn.

Right, think about it as a consumer. I don't want a gas station to run a credit check, or ask for proof of employment before I fill my tank. They just accept the card. But that does mean they bear risk for chargebacks if the card was stolen.

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.

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.

While you can enforce the contract later, does it save you from the algorithm and "I don't have that information"?

Honestly, idk. It at least gives you grounds to seek redress via legal channels in the case that you do lose business. I'd hope that the threat of legal consequences makes them be a little more deliberate in their actions.

This explains all the mysterious and opaque decisions that are regularly posted here by affected businesses.

Thank you for sharing your insight!

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.

So if Stripe is one of the best "low risk" processors, who is the Stripe of "high risk" payment processors?

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?

You can try CenPOS [1] or tempus [2]. Both are easy and fairly quick to implement.

[1]https://www.elavon.com/industries/cenpos.html [2] https://www.tempuspayment.com/default.aspx

Thank you. Definitely a bit harder than Stripe. I understand the difference now.

Cash.

CCBill

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

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.

Agreed this deserves a blog post. Very interested in best practices around providing payments.

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 has been very informative. My gratitude to everyone who has elaborated on how underwriting works with these providers.

Reply on news.ycombinator.com