Ask HN: Startup getting spammed with PayPal disputes, what should we do?

(I worked at a different processing company, which I am not speaking for.)

We're struggling to find the motive or intended outcome by the attacker(s).

The highest likelihood for me is that they're doing card/credential testing. They have either stolen or purchased a large number of stolen credentials. Those credentials are worth more individually if they are known to function. They can use any business on the Internet which sells anything and would tell someone "Sorry, can't sell you that because I couldn't charge your account/card/etc. Do you have another one?" to quickly winnow their set of credentials into a pile of ones which haven't been canceled yet and another pile. Another variation of this attack is their list is "literally just enumerate all the cards possible in a range and try to sift down to the cards that actually exist."

After sifting through to find the more valuable cards, they sell this onto another attacker at higher price of the mixed-working-and-not-working cards, or they pass it to their colleague who will attempt to hit the cards/creds for actual money.

Digital items are useful because people selling them have high margins and have lower defenses against fraud as a result. Cheap things, especially cheap things where they can pick their price, are useful because it is less likely to trigger the attention of the card holder or their bank. (This is one reason charities get abused very frequently, because they will often happily accept a $1 or lower donation, even one which is worth less than their lowest possible payment processing cost.) The bad guys don't want to be noticed because the real theft is in the future, by them or (more likely) by someone they sell this newly-more-valuable card information onto.

This hit the company I used to run back in the day, also on Paypal, and was quite frustrating. I solved it by adding a few heuristics to catch and giving a user matching those heuristics the product for free, with the usual message they got in case of a successful sale. This quickly spoils your website for the purpose they're trying to use it for, and the professional engineering team employed to abuse you experiences thirty seconds of confusion and regret before moving to the next site on their list. Back in the day, the bad guys were extremely bad at causing their browser instance to even try to look like a normal user in terms of e.g. pattern of data access prior to attempting to buy a thing.

Hope some of that is useful. Best of luck and skill. You can eventually pierce through to Paypal's attention here and they may have options available contingent on you being under card/credential testing attack, or they might not. I was not successful in doing so back in the day prior to solving the problem for myself.

Would also recommend building monitoring so you know this is happening in the future before the disputes roll in. Note that those disputes might be from them or from the legitimate users depending on exactly what credentials they have stolen, and in the case they are from legitimate users, you may not have caught all of the fraudulent charges yet. (Mentioning because you said "all of the charges" were disputed.) If I were you I'd try to cast a wider net and pre-emptively refund or review things in the wider net, both because the right thing to do and also because you may be able to head off more disputes later as e.g. people get their monthly statements.

This is a money laundering scheme where they are trying out how far they can go per domain.

It's also a bug in the paypal API that they're abusing, where the SDK doesn't differ between example.com and www.example.com. If webshops like yours get exploited and used for money laundering, they will mix transactions from those two subdomains, while leaving the www.example.com domain as it is. The support people at paypal are dumb enough to not take care about each case, and usually they mix transactions later also via other social media services that have microtransactions (e.g. tiktok or snapchat streams where you can gift away items).

The way paypal support's workflow works is that they have to nanually identify each and every transaction separately, meaning a human will be busy for weeks on end. Not kidding you. That's how the scammers keep winning with schemes like this. Usually there's also no way to escalate this, not even for business customers, at paypal, due to how their support offices are structured organizationally.

As a mitigation I'd recommend to block ASNs that are known hosters that do this, and double check your webshop version for known vulnerabilities and fixes.

If you don't use docker already, start to virtualize your webshop software now. I can't stress how important this is. Also double check any users and passwords you are using for the services, and the rest of the filesystem for indicators on the VPS. Disable SSH passwords and use only SSH key authentication on the VPS in case this hasn't been done already.

I'm writing this because usually this kind of scheme starts to happen after the server got pwned already, and after e.g. the ssh password bruteforce scanner was successful or after the web exploit / persistence exploit was successful.

If you need a starting point to block those botnet affiliated networks, I started both a firewall and scam database project that does exactly this:

[1] https://github.com/cookiengineer/antispam

[2] https://github.com/tholian-network/firewall

You can configure your account to reject unverified buyers.

https://www.paypal.com/us/cshelp/article/what-are-payment-re...

They are probably testing stolen/hacked PayPal accounts. Probably doing a dispute to ensure the owners don’t suspect anything is going wrong, until they use it for bigger transactions. Unfortunately with PayPal there’s no way to ascertain ownership of an account (like 3DS).

This used to happen to us, eventually after haggling with PayPay support for over a year on who should bear the cost, we just shut down PayPal payments. Don’t have anything better to offer, sorry.

Assume that the transactions are coming from humans, it is often cheaper to instruct humans than it is to automate when there’s an expectation that you will try to mitigate the malicious behavior.

Be willing to temporarily suspend your services in order to prevent the malicious behavior. Do the manual work to allow genuine customers to keep using your service, e.g: require manual account approval. You need to treat every one of these chargeback transactions as a risk to your businesses ability to operate, each that you allow to happen increases the risk of permanent damage to your business.

Reach out to your account manager at PayPal, this is not something that should be going via frontline support. You need to be talking to a person who knows and is responsible for your account. If you don’t have one, get one. If you can’t get one, look for anti payment fraud businesses that work with PayPal, they may be able to get a direct line to PayPal on your behalf.

For the future, if you’re dependent upon a service provider you should always have someone you can reach out to directly. If a provider isn’t willing to offer that, find a different provider. Financial services especially are very risk averse and will jettison your account if they get even a whiff of something untoward, whether you tried to prevent it or not. The cost of recovering from that will dwarf the cost of any drastic mitigation you take now. Losing your PayPal account is worse than turning off purchases for a few days.

Sounds like automated chargeback abuse, maybe for card testing or just to exploit your payment/dispute setup. We’ve dealt with similar stuff.

A few things that helped us: – Browser fingerprinting (FingerprintJS or even basic user agent + behavior tracking) – Logging full headers + TLS fingerprints — IPs rotate, but some other patterns leak through – Introduce small friction in the payment flow (e.g. lightweight CAPTCHA or JS challenge) – Look at timing patterns — automation tends to work in strict intervals

PayPal support is notoriously slow for anything that’s not cookie-cutter. Try emailing [email protected] — they’ve been more useful in escalated cases.

This kind of thing is more common than you’d think, especially for platforms selling digital goods.

I think I have a simple solution for you. Those who use contabo will understand this. So Contabo has recently started to announce their charges to paypal. the email reads, 'you have opted for automatic charges and your paypal will be charged $x.xx in 10 days. This is a brilliant move in my opinion and quite trivial to implement. You give the customer ample time to investigate any errors and/or challenge or change settings/cancel. I think most companies don't like to make "cancel process" too accessible but that's no way to treat customers man.

Some of the other commenters here have reasonable mitigations. One word of advice - PayPal is ruthless about banning merchant accounts that it deems risky. You’d best sort this out quickly or have plans to be able to rapidly switch to another PSP. Even if your business doesn’t get banned, the multiparty vendors (or whatever the appropriate term is) might get hit.

I had a similar thing happen recently. Some of the IP addresses were proxy / datacenters but many of them weren’t, which made me think it might be a botnet. And the UAs were generic, so there wasn’t anything easily-bannable.

I added fingerprinting and rate-limiting and the problem seems to have gone away. They’re trying to test a large number of accounts / credit card numbers so the best strategy is to slow them down to the point where it’s no longer worth it for them at scale.

This sounded interesting, provided here in the thread: You can configure your account to reject unverified buyers.

Besides this: You can not build a long term business that relies on PayPal [or Amazon.]

I would also try to attack the domains. Some strongly worded emails from a lawyer, report fraud at ICANN for the two domains.

You could take these type of orders as "pending" then require a SMS code to access the final payment page. Adding an extra step like this might discourage the attacker if their goal is not attacking you specifically. They will move on to another easier target.

I operate a small not-for-profit site that has a (very inexpensive) subscription. To avoid this, I do a few things:

- We have a no-questions-asked unlimited refund policy.

- I don't tolerate unverified PayPal buyer purchases. However, if someone tries to buy with one, I activate the subscription, and then contact the buyer via the e-mail/phone number they signed up with, confirm they're a real person, and then send them a PayPal invoice.

- Only subscriptions can be purchased.

- We've configured the flow when using PayPal to not tell the user if a transaction is declined to the maximum extent possible. I.e., the subscription still gets activated and then we call the user to arrange other payment options.

I’ve had similar PayPal chargeback issues before, where bots were testing stolen credit cards. We added CAPTCHA to the payment form and monitored suspicious IP addresses, which helped stop many of these attacks.

We also started temporarily holding PayPal funds until we could manually verify transactions, preventing a lot of small test chargebacks.

Finally, contacting PayPal's Merchant Services team really helped us reduce fraud significantly.

Beside all the helpful comments: If this is a serious problem for your business, invest in Cloudflare or other professional bot-protection. They do fingerprinting and similar stuff.

Also, if you implement your own methods, do shadow-banning of bots that you identified. These attacks will stop if the time and effort the malicious actor has to invest outweigh the benefits, so the more time and effort you let them waste, the better. A good example are unsolvable and ridiculously captchas. That is obviously a double-edged sword - you need a good way of whitelisting known good actors, so the effect of false-positives on your customers is minimized.

No easy solution other than implementing your own customer identity verification as payment prerequisite. Some platforms allow to do it, however end user experience has a lot of friction. User will get additional pop up with a bank login, where they enter/MFA through and select bank accounts to verify their card against.

Open Banking is the long term solution here. There are countries with relatively advanced legislation on that manner, so depending where you operate you might have full flow in the background through banks API (the only thing you need to capture is end user email for account/ID verification).

Do you have any competitors in your area of business? I’ve heard of people doing this to wipe out a new entrant. Every chargeback costs you money and you eventually will get blocked from taking payments.

Accept payments from verified accounts only. That's like PayPal 101.

Why not block those 2 domains from signing up ?

My startup defends companies from exactly this. (www.specprotected.com)

Happy to give guidance to a fellow startup - I know you're unlikely in a position to be able to pay for a solution.

Digital goods, donations, ticketing, any sort of marketplace -- it doesn't matter your size, just having a merchant account they can transact against is enough motive for them.

https://visitorquery.com - my startup. I'm curious if they use proxies or not. Datacenter or residential, my service can detect them. You have a free plan which should allow you to have a better understanding of your traffic, at least from this perspective. Shenanigans with payment gateways usually involve proxies so I'm almost certain you can use it to detect > block the abusers before they reach the checkout page.

Have you considered implementing velocity limits and requiring phone verification for new accounts? We faced similar issues and found that slowing down rapid fire purchases + requiring SMS verification eliminated 90% of the fraudulent attempts. PayPal's dispute resolution is def painful… but these preventive measures helped us avoid most disputes.

Solutions include TLS fingerprinting, browser fingerprinting, behavioral scoring, IP reputation, captcha/crypto challenge...

If you are on a premium CDN, they are probably equipped and can provide security consulting. If not, you may want to switch vendor or buy a separated bot detection solution.

These Cloudflare WAF rules (not my creation) should help mitigate some of the threat by blocking TOR traffic, blocking bots and blocking datacenter IPs (eg bots running on a VPS). The rules are granular so you can tweak them when you start to identify the traffic sources of the bad actors.

You'll probably need to block entire ASNs. I assume most of your legitimate customers aren't using VPNs or eg DigitalOcean droplets to access your site.

https://webagencyhero.com/cloudflare-waf-rules-v3/

In addition, you should start looking for alternatives to PayPal in case they decide to drop you.

I wish people would stop using paypal. they work ok (in my case, 20 years) until one day they dont and you find yourself locked out of your account and no one can help you.

Is Turnstile an option to try to dissuade the bot traffic?

https://www.cloudflare.com/application-services/products/tur...

(no affiliation)

I created https://truesign.ai specifically for this use case.

It detects bots, fake emails and proxies -- analyzing the network in realtime, no blocklists or IP reputation.

It's free during beta.

Get in touch with me - ex PayPal fraud alum and can give you advice or get in touch with folks for you. [email protected].

We had a similar issue and rate limiting + IP blocking did the trick. You don’t have to solve the problem completely; just make yourself a less desirable target than your competitors.

I’d love to hear what you end up doing.

If there is any way to avoid Paypal, and still continue your business viably, this would be my recommendation.

Paypal is not a company that exists for its customers.

What would happen if you ignored it? That's the basis for figuring out next steps.

It sounded from what you wrote that it will not affect your relationship with PayPal, because they are asking your sellers to contact them individually, and it's distributed across all of your sellers, so it won't affect their relationships either? Did I read that wrong?

Thank you, everyone. I want to start by saying how reassuring all of these comments, feedback, and support are. We've spent the past few days feeling very alone in this situation, unsure of why it was happening and whether our approach of adding friction really was the best option. We had a brief period where we wondered if we were being singled out by competitor! Knowing that this is just a thing that happens, especially with PayPal, is reassuring and helps ground us.

I can't respond to every comment right now because we're actively dealing with it. There were more attempts this morning. Some quick replies to some of the frequent comments:

* We're on a paid Cloudflare plan. We upgraded to the ~$2500 after this started and added a lot of filtering rules and interactive challenges to some key pages. Because purchases are either browser automation or humans, this has only been somewhat effective at filtering out bad traffic.

* IP checks show a mix of proxy/VPN and not. Blocking at the IP or ASN level won't get us very far.

* PayPal's Marketplace "platform" (it's a few APIs) processes orders through each of our sellers' accounts. As a result, we can't prevent purchases from unverified accounts because that has to be done by each seller.

* Moving off of PayPal isn't possible. For a marketplace platform in the US, the only other real option is Stripe Connect, but our domain has a lot of micro-transactions and Stripe's $2 per month per active user is a nonstarter. We experimented with Stripe and users (esp casual sellers) found their onboarding so intimidating that we lost signups. We would love other options, we have great concerns about PayPal as a longterm partner.

* Blocking the domains the purchases come from is not an option. They are recognizable names used by more legitimate users than illegitimate. We are adding extra scrutiny to these checkouts but we think it's possible they'll change tactics if they know we're onto that.

* Thank you for the fingerprint suggestions. We are going to try Fingerprint Pro.

* We've been gradually increasing friction via automated challenges and blocklists. We will increase this with more invasive Captchas, especially when aspects of the sale match criteria.

* We built an "Under Attack" mode that we can enable to completely disable key areas. We are prepared to temporarily shut down all sales if need be.

* We blocked prepaid credit cards from signing up for our subscriptions. This is a separate vector and we've had a few people try this over the past year. There was at least one person who did both the PayPal fraud and a signup scam + AI content. This should cut that off.

Again, thank you to everyone for the advice. We're monitoring this post closely.

Not the easiest solution but I would suggest not using PayPal. Much more issues there than just using credit card, and as you noticed nobody there to care.

Wait until they ban your account and there again is nobody to talk to.

Not sure how paypal works but can you enable 3DS for this?

do you have the user agent string of their browser?

did you look up the AS number of the IP addresses they're using?

This is not a technical matter. This is a legal matter. Sue the party as John Doe/Janes for business interference and fraud, and get records from PayPal, their ISP/phone provider, etc in discovery.

Also, have your attorney send a polite letter to Paypal's legal department.

I'd place good money on this being a competitor trying to sink your merchant account by racking up a lot of fraudulent transactions.

Cloudflare bot protections and enhanced WAF rate limiting rules. Go.

Should be some settings on PayPal to refuse payments from new accounts. Or switch to Stripe which has much better "anti fraud" mechanisms in place.

switch to stripe? ditch paypal altogether?

I just tried fingerprintjs. Got different IDs on the same browser in normal & incognito mode. Doesn't seem like any help at all.

Known issue apparently: https://github.com/fingerprintjs/fingerprintjs/issues/1088

As others have suggested, implement a captcha if you aren’t already. Implement Fingerprint.js and see if you can spot some patterns you can create firewall or application rules to block. Finally, not optimal but migrate off PayPal.

I mean this sincerely:

Your company should pivot into competing with PayPal. You've identified profound deficiencies in how they operate, know what type of services customers value, and have motive: someone is attacking your business and PayPal can't even comprehend that there is a problem, let alone protect you from it.

More than that, there are vast swaths of people that have horrendous horror stories about dealing with PayPal, having their accounts shutdown without explanation, being abused in the same or similar ways, and a wide variety of other concerns. There is a market for it. You just need to consider what made you go with PayPal Multiparty over whatever competition exists.

>We're struggling to find the motive or intended outcome by the attacker(s).

Unless you plan to sue, determining motive probably doesn't matter a whole lot. We could guess at different reasons, and even if we figured out a good one, it wouldn't change what is happening, just why it's happening. That's not much of a meaningful change.

PayPal terrifies me; I would move off of their platform ASAP, or at least be ready to when they inevitably pull the "lock your account pending an investigation" move that kills so many new companies.

[dead]

[dead]

[dead]

[dead]

[flagged]

You could implement FingerprintJS [1] or even implement email or phone verification before allowing purchases for unverified PayPal accounts or implement some transaction frequencies per IP address. With FingerprintJS, it can basically create a unique ID per user and mitigate the behavior you are seeing and block them or add in additional countermeasures like 2FA.