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.
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.
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?
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.
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.
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.
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.
https://www.merchantmaverick.com/what-is-a-merchant-services...
Seems what they posted above is accurate.
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.
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://woocommerce.com/product-category/woocommerce-extensi...
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.
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.
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.
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
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.
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.
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.
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.
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)
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.
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.
You probably already knew that, but for the benefit of anyone reading this who didn't.
Always have at least two payment processors. If you've got a lot of money on the line, get a third lined up, too.
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.
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.
... 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.
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.
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 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.
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.
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.
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.
(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
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.
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.
A link to an HN thread is opaque, uninteresting, and context-less.
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.
A blog post also feels more trustworthy than a random social media site comment.
Shocking, I know.
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.
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)."
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.
The other side has one chance to learn.
Thank you for sharing your insight!
Your best bet is to pay the slightly higher fees by going directly through your actual bank.
[1]https://www.elavon.com/industries/cenpos.html [2] https://www.tempuspayment.com/default.aspx
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.
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.