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