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.
Pasted my written advice to this founder here, to be helpful to the community as a whole. These are all free/cheap things you can do when you're early on and being picked on by the baddies:
- *Track anonymous user sessions*, even if you delete all anonymous sessions every 24 hours to prevent data accumulation, this will do wonders when it comes to tracking a user on their "approach" to your payment experience. It should be cheap-as-free to log some of these events so you can identify different populations of users based on how many "typical" events they skipped.
With this, you are looking for users that skipped essential or common steps.
- *Get some sort of free device fingerprinting tool in place at or before your payments experience.*
[https://github.com/thumbmarkjs/thumbmarkjs](https://github.com/thumbmarkjs/thumbmarkjs) ← this is a MIT fork of Fingerprint.js after they changed their license. It's a great starting point, and while these can be blocked or manipulated, it does a TON to raise the bar on would-be attackers.
With this, you are looking for users with the same device hitting your payments experience over and over, and people who are blocking this script from running.
- *Some IP reputation vendors have a free tier API (e.g. IPQualityScore)* that might be helpful at the volumes you are working with, just be sure to cache lookups so you aren't making a bunch of API calls to get the reputation of the same IP over and over.
With this, you are looking for IPs that either have a poor reputation or are classified as VPNs/Residential IP Proxies/Cloud Proxies.
- *Lastly, keep a running rate for your payment failure ratio over the last 20 + 60 minutes.*
This lets you put logic in place that automatically puts more strict controls in place if your payment acceptance rate dips below 90% and transactions are above a certain minimum threshold - this should let you sleep a little easier knowing that your mitigations automatically shift to "battlestations" if an attack goes off while you are sleeping or out with your family.
*Being clear:* cookies, device fingerprints, and IPs are pretty easily manipulated by a motivated attacker - checking behavior across all three at the same time significantly raises the bar for a would-be attacker.
This should keep you out of the hottest water until you get to a size & scale of attack pressure where you might want to consider using my startup's platform to proactively classify and honeypot malicious user behavior.
Yeah, the UA is pretty consistent but very generic. It reads as a desktop browser.
We did not look up the AS number. Can you describe that we'd be looking for there? Based on how the address was changing, I assume they're using Tor or some kind of VPN that will obfuscate IP so I didn't spend much time looking at them.
You can't trust those services 100% but you can use them to turn up the level of turnstile/captcha/verification on those clients.
I'm somewhat concerned that you don't know what you'd be looking for (or to verify Tor) if you're running an ecommerce platform, fraud is an almost certain outcome for any store and merchant providers (Paypal, Stripe, Adyen, etc) want zero to do with helping you solve that (even if you're only embedding their Javascript!)
I work for IPinfo. If the OP sends me a list of problematic IP addresses, we would be happy to look into them and send back the parent IP ranges. This way, they can block them on the firewall or through a simple IP-based blocklist.
Check if the client sends the "Accept" and/or "Accept-Language" header. Or check if the order of request headers matches what would be expected from that generic User Agent. You'd be surprised how often they fail to send "Accept-Language", while every "normal" browser does.
You can look up the AS and other info, like detected proxies or VPNs, using the form on https://iplocate.io/what-is-my-ip (disclaimer: I've run this service since 2017).
If they come from a consistent AS, you can block the AS. If they're using a proxy or VPN, you could try blocking those. If you don't expect to get traffic from hosting providers, you can block where `asn.type == 'hosting'`.
Does the email address has a pattern? I faced similar registration attack, but the email address had pattern, I blocked them in code but gave a success response and the attack went away.
Yes, we added Turnstile to checkout and they were able to get past it. We assume it's either because Turnstile sometimes uses a pure-JS approach (no interaction) or they're using an AI to drive the browser and it was able to figure it out.
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.