Hacker News Reader

Comment by hartator | Hacker News Reader

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

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.

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.

Spreedly is a very good provider for this.

Yes thank you, couldn't remember their name

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

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.

Reply on news.ycombinator.com