Comment by foxylad | Hacker News Reader

Comment by foxylad | Hacker News Reader

I think developers come at payment services with a mindset that it's such a simple thing (it's really just decrementing a number in one account and incrementing a number in another account) that they leave it to last to implement. Like security, it should be part of every decision you make, from day one. Particularly if you live outside the US.

CarGo's experience is a great example. For an app that lives and dies on efficient payment processing, they would have had been wise to have two payment processors coded up and ready to go. They should have been completely honest with their payment processors, built up a relationship, and sought assurances that their operation was acceptable.

The payment processor's biggest problem by far is fraud. That is why they have to charge significant margins, and why you have to send all your great-grandparent's birth certificates to them, and why they will suspend your account if there is the faintest whiff of suspicion. That's what makes the decrement-increment hard - really hard.

Treat the payments problem with the respect it deserves - as CarGo has found out, it can kill your business dead overnight.

The first thing they ask you when you open an account is how much volume you have.. There is no such thing as a "backup" payment gateway.

The first few weeks of operation the "backup" gateway would suspend your account for not providing the necessary volume of sales.

Not backup .. load balanced perhaps ? Across two or three ?.. you would not trust single server, cloud provider, DC , DNS for HA then why trust a single payment provider ?

This exists for high risk merchants -- there are a number of offerings like: https://www.easypaydirect.com/special-needs/load-balancing/

I'd need to do more research to find the best solution but it looks like payment processor risk is definitely something that can be mitigated.

Not in my experience. We have three payment providers at the moment, including one that only handles a few transactions a month. We've never been hassled over minimal volume.

I can't explain our difference experiences - maybe it's down to providers. We've been through five, and are currently very happy with Stripe.

True, you can't call them "backup" to their face. But you will trickle through traffic for weeks whilst you sort out teething troubles anyway, so there is not going to be volumes after a few weeks.

Then eventually you can make a decision which works best. The new provider (the backup) or the old provider. Then turn the volume to the best one.

Though I would never go 100% on any of them. Maybe keep some geoip through the backup. E.g. South America with one provider. France with another. Or a 5% load balanced volume.

It is good to keep them all up to date and active, as from experience they all frequently f-up and you have to feature toggle a provider off for a day or week now and then, or at least throttle them down.

It is not a matter of just being shut down due to low volume. The rates that you get depend on the volume. So the "back up" gateways end up so expensive you have no interest in even keeping them around.

From my experience you end up being tied pretty hard to pretty one provider and as long as you make fraud prevention yourself you can stay in business. Problem is that if you do all the fraud prevention stuff yourself then why do you need braintree for? To just invoke a .charge(100, "EUR")??

>It is not a matter of just being shut down due to low volume. The rates that you get depend on the volume. So the "back up" gateways end up so expensive you have no interest in even keeping them around.

The rate difference would be an investment in redundancy. If Provider A goes down, I would guess you'll be grateful to have Provider B taking the failover traffic, even if costs you an extra 2.9% in transaction costs. You'd keep feeding Provider B the minimally-acceptable amount of traffic at the higher price point to keep that redundancy alive.

Reply on news.ycombinator.com