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