Hacker News Reader

Comment by capableweb | Hacker News Reader

Absolutely, payment providers block/suspend accounts left and right, and you're out of luck to find any humans to talk to. If you manage to find a human, 99% chance is that it triggered something in their "anti fraud" systems and then they'll simply state "We can't tell you why, and we can't unsuspend your account, sorry".

Best course of action I've found, is to build your initial MVP with one payment provider but as soon as you've validated there is a market and before you move on with other features, add a backup provider you can switch to at any time because chances are you will get blocked at one point. If not permanent, at least temporary.

If you're clever enough when you build the initial integration, you make sure to abstract out the specific payment provider so it's easy to plug in a new one. Shouldn't add too much complexity.

Sucks but the reality we live in...

View on HN

This works for normal payment processing, but Connect is something that doesn't have a viable alternative. Lago wants to abstract the Connect functionality and allow you to use Stripe Payments, Paypal, other processors, and get the Connect functionality to be open-source. Looking forward to their work and it is sorely needed.

If you have recurring payments, moving the payment methods over is a non-trivial amount of time and coordination to get done (and I'm not even sure how cooperative Stripe will be if you're on a fraud radar somewhere), and usually only involves the raw methods themselves, stuff like subscriptions you'll need to rebuild.

I don't think it's a bad idea necessarily, but it's very difficult to almost impossible to make this a "flip the switch" setup, particularly for SaaS businesses which are almost always recurring payments.

We're a largish Connect user and for us the key thing is just establishing good relationships with reps in the company and maintaining those. We've had a couple of customers run into freezes and other issues and while standard support is basically a brick wall in those cases, getting someone internal to escalate can be hugely beneficial.

I generally agree, but if you go through the process at your bank and get your own merchant account(it's a long drawn out process), then the risk for the bank/visa/mastercard/etc is much, much less, and you can generally always reach out to humans and get answers. It's worth the headache if you live or die on credit card payments.

Completely agree, that's why this Lago is interesting to me instead of using Stripe services. I'd rather use Stripe for the bare minimum so I can implement support for a backup provider as well.

This happens far too often. And because stripe handles the PCI compliance, you can't even take your customer's CC info to another merchant account. This is why people need to be using a PCI tokenizer like BasisTheory. Then you own the rights to the CC, without needing to handle PCI compliance, and you can switch vendors easily.

nice try mr sales person.

PCI tokenizer is pure snake oil.

"dear auditor, i do not store the credit card number, only an unique index to fetch it at any time on this rest service. i promisse it is totally not the same thing"

good luck trying to make thay avoid compliance work.

> you can't even take your customer's CC info to another merchant account

Blatant FUD. https://support.stripe.com/questions/export-customer-card-da...

I ran a medium/high risk payments firm and Stripe followed through on customers’ transfer requests perhaps 10% of the time. One cannot rely on it.

For low risk clients, were the results different? Which platforms (First Data, Tsys, etc) and ISO (FDMS, Gravity, Bank of America, etc) were you seeing success with?

I don't think the average ISO has the knowledge let alone a published set of credentials to receive card data, the ISO industry really sticks to the tooling platforms provide.

More issues with ISOs than PayFacs. I can speak to one platform (a PayFac) that seemed to bat 1.000 here: Tilled. Not only did they seem to have no issue with migrating low risk clients but they likewise migrated dozens of mid/high risk firms without a single rejection from Tilled themselves or refusal from Stripe to provide the requested data.

Conversely, if you’re anything but the most plain jane business, I would avoid transitioning from Stripe to Gravity like the plague. I watched them reject a candy company and a knitting goods business that were both reputable, over a decade in business each, and never had an abnormal spike in sales or questionable products on offer. Gravity either couldn’t get Stripe data transferred or properly integrated and ended up turning away both businesses (while blaming them for noncompliance).

I work at Tilled and we appreciate the shout out because we have worked tirelessly to make this experience possible with Stripe migrations in particular. While it is ultimately up to the incumbent processor to release the data, from a technology standpoint there is nothing that stands in the way to make this possible, especially here at Tilled since we have built our own API's from the ground up.

If anyone wants to learn more about how Tilled works directly with ISO's who need a payfac solution for ISV customers email us at partners@tilled.com

Reply on news.ycombinator.com