Hacker News

Ask HN: Stripe closed us after one $1,500 invoice and never asked for evidence

88 points by snirgbs ago | 32 comments

We're a small business that sells pre-booked appointments with homeowners to local contractors, billed per appointment that actually happens.

Our first client agreed to this on a recorded call and saved his card through a $1 Stripe payment link, which we planned to use for billing later. That $1 payment went through.

A few weeks later we invoiced him $1,500 for 3 completed appointments and charged the saved card. Stripe blocked the payment. Two days after that the account was closed with this wording: payments "don't appear to have been authorized by the customer."

What happened next:

- We appealed through the Dashboard with an appeal letter, our company documents and the invoice. It was rejected the next day as an "unacceptable level of risk."

- Support told us our "business model presents a level of risk we're unable to support" and that the decision is final.

- After a Stripe employee escalated it internally, we got a short email saying Stripe still won't accept payments for our business.

In all of this, nobody asked us for the call recording, our messages with the client, or a confirmation from the client himself. As far as we know, he never disputed anything, and he has told us he is paying by bank transfer outside Stripe.

I'm not saying our setup is perfect. It's a new account, the first real charge was large compared to the $1 test, and billing a saved card later is probably what looked wrong. If there's something specific we should fix, I'll fix it.

What I'm asking:

1. Is there anyone at Stripe who can look at this with the evidence, including getting the client on a call?

2. For people who've been through this: how would you structure per-appointment billing so it doesn't look unauthorized (an invoice with a link each time, an email confirmation before each charge, something else)?

I can share the account details, the call recording and the messages with anyone from Stripe who wants to look. Thanks for reading.

breue |next [-]

I had stripe fleece me for 4.5k - tried to complain about them on HN - they nerfed the post: https://news.ycombinator.com/item?id=50398646

The sad part is I was one of their first customers - I helped onboard over a 70 clients for them over the years.

And my top project generated them $1.6m in pure fees revenue. I even tried emailing Patrick and John - they don't care one bit. Its sad - they used to have a soul - became a ruthless/soulless company.

Sorry you are dealing with this...

aleqs |root |parent |next [-]

Are you still using stripe today, or have you found something else?

breue |root |parent [-]

yes, unfortunately i have a lot of projects with them and don't know of a better alternative.

The_President |root |parent |next |previous [-]

Loading their dashboard now takes as long as brewing an 11 oz k-cup coffee.

weird-eye-issue |root |parent |previous [-]

So you allowed people to do card testing on your platform and never recognized it was happening? You have to keep on top of things like that especially if using Stripe Connect where users can withdraw money since you are facilitating theft and money laundering

> there was very little negligence on our side

Lol

> they nerfed the post

Nobody nerfed the post. It just isn't interesting since it's your fault. Lesson learned, hopefully!

aleqs |root |parent |next [-]

It's very interesting actually, and there is no evidence that they 'allowed card testing on your platform'. Not to mention it would be stripe that would be the main facilitator of card testing in this scenario, so it would be on them to detect and alert the user if that was happening.

weird-eye-issue |root |parent [-]

No evidence? They said that's exactly what happened in that thread, I guess you missed that

Card testing is the merchant's responsibility because whether it gets through or not largely depends on settings the merchant controls. I guess you've never used Stripe, otherwise how would you not know that?

And yes even if you use Stripe Radar and the recommended integrations which will prevent most card testing you still have to have a process to manually review transactions from time to time. Again, merchant's responsibility. If you don't like that, don't take credit card payments....

matheusmoreira |root |parent |previous [-]

So the corporation doesn't care about a guy who generated 1.6 million dollars in fees and onboarded additional clients? Even when they post about their problem publicly on HN?

I suppose it's hopeless for the rest of us.

weird-eye-issue |root |parent [-]

He misused their platform by failing to do proper verification of marketplace users and transactions and allowed criminals to extract several thousand dollars from victims of credit card theft. He's the one at fault here and his unverified claims about fees sounds like it's from a different project anyways so what exactly do you expect support to do? Roll out the red carpet and help him out with these fees related to the funds he helped launder? If he was negligent and didn't do the proper verifications of the buyers and sellers on his platform then he shouldn't have set it up in the first place. It's basic common sense and if he's really used Stripe so much he would know that. Instead of immediately blaming Stripe why don't you ask him if he followed all of the best practices for using Stripe Connect

It's a relatively risky thing to implement so you should only do it if you have all the checks in place and can accept a certain level of risk: https://docs.stripe.com/connect/risk-management

aleqs |root |parent [-]

You're trying hard to make it sound that this user and not Stripe is at fault here, without saying anything concrete/specific at all. If it was the user's fault - what specifically did they do wrong and what should have they done differently (doing ID checks on all users/buyers is obviously not a real solution for many reasons)?

Stripe is the one actually facilitating the payments, verifying the cards, enabling card testing, etc.

weird-eye-issue |root |parent |next [-]

> doing ID checks on all users/buyers is obviously not a real solution for many reasons

I have a feeling you really don't understand how this works or what even happened. The problem is the sellers pretending to be buyers using fake credit cards to buy their own stuff and then getting money transferred to them. So while you say it's impossible yes you absolutely need to do verification of all of these sellers before you start sending them stolen money.

You've never even used Stripe have you?

breue |root |parent |previous [-]

he should becomes stripe's public defender/lawyer

codingdave |next |previous [-]

I have no knowledge specific to Stripe or your case, but do I know that the pattern you just described - a small 1 dollar payment followed by a large payment - is the exact pattern that criminals use to test stolen credit cards numbers. My bank will automatically reject anything following that pattern, put a hold on my card, and call me to confirm whether or not I have my card.

So yeah, if your business model calls for pattern matching with how stolen cards are used, that could very well be unacceptable risk to Stripe.

matheusmoreira |root |parent |next [-]

I don't get it... I've had plenty of actual corporations test my credit card in that exact manner.

PayPal for example literally turned this into second factor authentication mechanism: they charged me some random amount and demanded to know the value they charged me. Apparently this is proof that I have access to the associated bank account.

pstuart |root |parent |next |previous [-]

Out of idle curiosity, how might such a business such as the OP's be able to arrange payments to use Stripe without getting shut down?

alwa |root |parent |next [-]

Be upfront about the plan when you do the initial authorization. Stripe lets you signal a “set up a card on file” intent for this purpose, which doesn’t involve actually charging it $1.

IIRC it either provides or expects you to provide user-facing language like “you’re putting this card on file with this merchant, you know they’re going to charge it in the future according to their policies, right?”

https://docs.stripe.com/payments/cards/save-and-reuse

https://docs.stripe.com/payments/save-and-reuse

Or, like, send a fresh invoice for the $1500.

But charging a sale for $1 as a way to make sure the card is good is not the way. It sure used to be the way in the low-fi days of physical terminals, but not today.

Either way I imagine you might earn more benefit-of-the-doubt once you’ve established a track record of smooth transactions.

rtpg |root |parent |previous [-]

Don't charge $1 first? API-wise you can attach a card to a customer without charging it.

Maybe the $1500 thing still fails anyways but it won't look as much like fraud?

Or, y'know, just send the $1500 invoice after the fact and have that involve the client put in the card details there as a first shot. You _should_ (IIRC) be able to charge + capture the card in one go.

ShinyLeftPad |root |parent |next |previous [-]

Criminals? I think AWS (or something similarly large) used to hold a dollar to make sure the card works, it's a pattern that is used

anonymous908213 |root |parent [-]

Amazon does a small precharge on all of my grocery deliveries. This pattern is universal. I suppose it's easier for "engineers" to come up with pants-on-head idiotic solutions and special-case exemptions for large partners than it is to use their noggin and implement any kind of system capable of actually working.

anonymous908213 |root |parent |previous [-]

It's also the pattern that millions of businesses use. It's like pattern matching against transactions on days that end in "y". You certainly will capture all fraudulent transactions that way, but...

didgeoridoo |next |previous [-]

Yeah unfortunately this charge pattern could not have looked MORE like merchant fraud. The right approach would have been to use https://docs.stripe.com/payments/setup-intents and set it for off-session usage.

You still might have gotten a payment hold on the first transaction until someone in risk could take a peek at your site to make sure you had all the right disclosures in place, but you probably would have kept the account.

A_D_E_P_T |next |previous [-]

> 2. For people who've been through this: how would you structure per-appointment billing so it doesn't look unauthorized (an invoice with a link each time, an email confirmation before each charge, something else)?

Have you tried simply sending invoices via Stripe? Works for me, without a hitch. And it's pretty flexible; you can do a lot to modify terms, add notes, send email notices to multiple parties, etc.

If that won't work, there are payment processors who specialize in "high risk" accounts. Paykings come to mind. I've actually heard good things.

buckleyourshoe |next |previous [-]

I would be interested to hear about better alternatives that have functional support. We ran into problems with Google Cloud and were able to migrate to options with much better customer support. Are there payment providers like this available?

Aeseir |next |previous [-]

I'll be first to say that Stripe is a shit company and I cannot wait to see a competitor detroy them.

Now onto main problem.

Issue is the $1 followed by large payment.

A lot of banks will flag this as suspicious, in some cases block the payment, or even proceed with investigation.

There is nothing telling Stripe that this is a potentially legitimate payment so they blocked it.

The fact they are shit company and don't explain this to you is another issue.

brudgers |next |previous [-]

We're a small business that sells pre-booked appointments with homeowners to local contractors, billed per appointment that actually happens.

I imagine that's not a dissimilar transaction pattern to how escort services and similar businesses might try to use Stripe.

Obviously there's no easy way for Stripe to tell if you are actually doing what you say you are doing.

In addition, based on my having a more than passing familiarity with laws regulating construction contracting [1], I would not be surprised if there are jurisdictions where your service is in violation of the laws and regulations governing construction contracting.

Even if it is legal where you are, there's no obvious way for Stripe to know that's the only place you operate. And if you only operate locally, you can use a local bank to process credit cards...assuming you meet normal criteria -- if you don't meet normal criteria, it's reasonable for Stripe to decline your credit card processing business.

So my advice, if you want to operate locally work with a local banker, a local lawyer, and a local insurance agent. These might not scale, but scaling is only a problem once you have a going business. Good luck.

[1] The laws regarding construction contracting are an "is" I am not arguing that those laws are/aren't an "ought."

wewewedxfgdf |next |previous [-]

Sounds like Stripe is on the same road as Paypal.

1123581321 |next |previous [-]

Stripe stresses written authorization when you capture intent to pay.

hackernud3s |root |parent [-]

What? You mean have them write on paper and upload a photo of it?

|next |previous [-]

replwoacause |next |previous [-]

I'm so tired of these big companies giving poor customer support unless they get called out on social media.

Traubenfuchs |previous [-]

Hi, you are on the frontpage of hackernews and have reached our premium support.

The CEO or CTO of Stripe will be with you shortly.

lostlogin |root |parent [-]

Any comment on the other story here, from user breue?

weird-eye-issue |root |parent [-]

Yeah bud they'll be right on that.