(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.
We had the same issue (people testing stolen credit card numbers) on Stripe that was close to getting us shut off for a certain credit card company. We implemented a captcha and a tool to validate email addresses (emaillistverify) and it solved the problem.
We had the same issue because Marketing was using a stupid landing page SaaS tool to generate sales, it was connected directly to Stripe and we didn't have any control over it. We discovered the problem through Intercom, which notified us about a high volume of bounced emails (automatically sent after purchase). It was clear what was going on after discovering the same pattern.
To fix it, I had to proxy that unreliable SaaS software to implement CAPTCHAs and stronger bot detection. It was essentially a MITM-style proxy but for protection. It was fun to implement
TIL about emaillistverify. Their website always talks about „bulk email checking“, but I assume they also support „live checks“ through an API?
I assume you prevent users from signing up if the check fails?
Top nav of their site has an "API" link which goes to a page that says "ELV’s API keeps your email list clean. Notify website user about an invalid email address when they are filling out a form."
This is a very sad incident of carding attempts. You can sign up for FraudLabs Pro service and they have velocity check to prevent carding if it is from similiar browsers, IP or email addresses.
This is correct. We have seen this over the years in our ecommerce business. I suggest using threat levels, you are under attack so the threat level increases until they go away. When the threat level is high, you require an exact match AVS. You might have more agressive filtering at the IP level, real users generally won't be datacenter IPs. Pay attention to the ASN, sometimes you'll get an attack from a network that legit customers never use, so you can just block the whole network. Keep an eye on your logs, you'll notice patterns. The attack is likely coming from a single entity, if you make it difficult to abuse your service, then they will move on.
Can confirm doing charity collection that we often encountered this. Credit card processor said there was nothing we could do about the more sophisticated attacks that used a wide range of IPs. We basically stopped them by freezing everything if there was an unexpected traffic spike. Not perfect, but it worked and they stopped trying us.
Agreed. This is a situation where you need a dedicated security team to classify and mitigate this kind of attack while making sure the mitigations don't add too much friction to your real customers. It's not easy. It's also not really on your payment processor to be the first line of defense for this kind of fraud.
You'll need to find some way to fingerprint to classify users into risk buckets and then treat them differently based on the bucket: blackhole, high friction verification, and likely safe are three reasonable buckets.
Cloudflare has tools that can help identify bots, much of this can be offloaded onto them.
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:
It can't easily, Docker should not be naively treated as a security solution. It's very easy to misconfigure it:
- The Docker daemon runs as root: any user in the docker group effectively also has sudo (--privileged)
- Ports exposed by Docker punch through the firewall
- In general, you can break the security boundary towards root (not your user!) by mounting the wrong things, setting the wrong flags etc.
What Docker primarily gives you is a stupid (good!) solution for having a reproducible, re-settable environment.
But containers (read: magic isolated box) are not really a good tool to reason about security in Linux imo.
If you are a beginner, instead make sure you don't run services as the sudo-capable/root user as a first step.
Then, I would recommend you look into Systemd services: you can configure all the Linux sandboxing features Docker uses and more.
This composes well with Podman, which gives you a reproducible environment (drop-in replacement for Docker) but contained to an unprivileged user.
I agree with what you wrote, and add that you should make sure that your service's executables and scripts also should not be owned by the user they run as.
It's unfortunately very common to install, for example, a project as the "ubuntu" user and also run it as the "ubuntu" user. But this arrangement effectively turns any kind of file-overwrite vulnerability into a remote-execution vulnerability.
Owning executables as root:root, perms 0755, and running as a separate unprivileged user, is a standard approach.
> - Ports exposed by Docker punch through the firewall
I've been using ufw-docker [1] to force ufw and docker to cooperate. Without it, Docker ports do actually get exposed to to the Internet. As far as I can tell, it does its job correctly.
Is there another problem I am not aware of?
Yup that's trivially easy if you have permissions to use mknod and mount. (and if the file system namespace looks like it normally does all you need is mount.)
Docker is for organizing things for yourself, just like directories are. If you want actual isolation you have to take extra steps.
EDIT: and I feel like I should add those extra steps are exactly what most server software does automatically when it chroots itself. Again docker is really just for organizing things.
For those not intimate familiar with containers (docker/podman), can you link to a brief blog post that touches on this in detail for further reading? Much appreciated.
> Docker is for organizing things for yourself, just like directories are.
Services have the following dependencies: static data files; configuration files; executable code/binaries; library dependencies.
In days of yonder, you'd need to download/install all of that ^ on each machine where "service A" needs to run. Developers would run and test "service A" on ubuntu 18.04. But production servers had to run ubuntu 16.04 because "service X" that also runs on the same server needs a library that has not been ported to 18.04 yet.
But "service A" needs a library that was never available on 16.04. Welcome to dependency hell!
Containers bundle all of those dependencies into one object that can be downloaded directly onto the host server, ready for the "service A" process to execute. Now it doesn't matter if production servers are running 16.04. Everything "service A" needs is stored inside the container blob (including some minimal ubuntu 18.04 stuff).
the magic that lets this happen -- containers re-use the host server's OS kernel. Running a new ubuntu 18.04 container does not start a new OS kernel running. the process for your container is just 'firewalled' off from all other processes using cgroups [0]. containers re-use the host's kernel, start a cgroup'd process which starts your container's services and processes (the 18.04 'OS' services and your binary/code/executable).
short/simpler version: containers share the core of the underlying operating system on the host server.
> If you want actual isolation you have to take extra steps.
unfortunately, this means containers share the core of the underlying operating system on the host server.
containers not being isolated from the host server OS can present a security risk as you can escape from the container and "do bad things to host server". [1]
In cases where that is a problem you mostly have two choices:
* use VMs instead (a completely isolated OS instance is started for each service, cannot interact with the host OS at all -- this uses a lot more memory/cpu)
* use rootless containers [2] (container processes are launched under a specific user namespace rather than kernel namespace -- escaping the container means you only get access to the user namespace)
[1]: by default the docker daemon service and all the container processes it starts are running as root, which means escaping out of a container in a a default docker installation is as bad as giving someone root.
Containers allow separation of access rights, because you don't have to pwn only one program/service that is running on the host system to get physical access to it.
Containers have essentially 3 advantages:
- Restart the containers after they got pwned, takes less than a second to get your business up and running again.
- Separation of concerns: database, reverse proxy, and web service run in separate containers to spread the risk, meaning that an attacker now has to successfully exploit X of the containers to have the same kind of capabilities.
- Updates in containers are much easier to deploy than on host systems (or VPSes).
Sorta: yes the container is immutable and can be restarted, but when it does, it has the same privs and creds to phone up the same DB again or mount the same filesystem again. I'd argue touching the data is always the problem you're concerned about. If you can get an exec in that container you can own its data.
Do mean VMs? ISO is a file format, commonly used for VMs and other computers.
For VMs, they did take off and essentially the entire cloud ecosystem runs on mostly VMs behind the scenes for VPS and similar hosting.
It's true though at it seems more popular for developers to reach for containers when they need to think about deployments, particularly docker containers. But VMs are still widely in use and deployed today.
yyeaaah, i built a cloud. :) I love VMs. I'm a disciple of Alex Polvi. Lets call it an "Immutable Application VM" Stack. Each application service (or a logical group of application services) is packaged directly into an immutable VM image, and the orchestration manages these VMs directly. No separate container runtime or container orchestration layer on top of the VM. So you have an Immutable, Bootable System Image, but you would use kvm plus .iso plus orchestration tech. Basically, why does nobody built a cloud on the cloud lol??
(I helped build digitalocean from zero the pre-IPO, so I'm verrry rusty, this all might be nonsense/wrong think, and happy to be told as much! :))
Just thinking about this from a proxmox pov -- applying this advice, do you see an issue with then saying: take a copy of all "final" VMs, delete the VM and clone the copy?
And, either way, do you have a thought on whether you'd still prefer a docker approach?
I have some on-prem "private cloud"-style severs with proxmox, and just curious about thinking through this advice.
Not OP, but Im assuming its because of immutability of the containers where you can redeploy from a prebuilt image very quickly. There is nothing that says you cant do the same with servers / VMs however the deployment methodology for docker is a lot quicker (in most cases).
Edit: Im aware its not truly immutable (read only) but you can reset your environment very easy and patching also becomes easier.
Not parent, but see my sibling comment re: Docker. The issue is imo that Docker is very easy to misconfigure and gives you the wrong mental model of how security on Linux works.
On SSH password auth: its secure if you use a long, random, not reused elsewhere password for every user. But it is also very easy to not do these things. SSH certs are just more convenient imo.
Using docker does not help in this specific case - if the attackers came via ssh, they will have root access as before, and if they come in through the application, they still control your application inside the container and can make it serve what they want.
For ssh, the problem does not lie within password auth itself, but with weak passwords. A good password is more secure than a keypair on a machine whose files you can't keep private.
Docker is not really a security boundary (unless you use something like gVisor), so it's a bit of a red herring here.
The idea is to make your app immutable and store all state in the DB. Then, with every deployment, you throw away the VM running the old version of your app and replace it with a new VM running the new version. If the VM running the old app somehow got compromised, the new VM will (hopefully) not be compromised anymore. In this regard, this approach is less vulnerable than just reusing the old VM.
Im not op and I’m not sure they are using it for money laundering.
A money launderer can use a marketplace by creating a seller account and buying from himself. Since he’s the one buying he doesn’t need to deliver anything but he gets the money from a legit source. Usually he would use a payment method as close to money as possible so that it leaves less traces. But in OPs case, the amounts are low so he needs too many transactions to get something valuable. And because of the disputes, he’s (probably) not getting the money (?).
It could be card testing: the fraudster has a bunch of cards and doesn’t know which is valid or canceled. The best way to find out is to test in a real site. So he’ll test out each of them and the ones that go through are good to use elsewhere. The thing is that it would be better for him not to dispute the transactions so the OP would take much longer to find out about the scheme and shut it down. It’s better to use low amount transactions in this case so it doesn’t use too much of the credit available for him to defraud and probably doesn’t warn the card owner.
Another option is doing it just to hurt the OP marketplace. If you have too many disputes the brands can fine you and if you don’t solve the problem they can turn your account off. I’ve seen it happen when a competitor was trying to hurt the e-commerce. It’s a low move and rare but it happens.
One thing that might help is to analyze the sellers too. In a money laundering and even in the other settings, it could be part of the scheme. Are they new accounts? Are their volume exploding out of nowhere? Etc
> Since he’s the one buying he doesn’t need to deliver anything
This only works (in my mental model), when you produce the product you're selling in-house – like a digital product. But lots of "reselling" type businesses try to use this scheme as well. Like a restaurant might ring up more meals than they served, or less to not pay taxes. But, is this not easily spotted when the food import(?) cost doesn't match the revenue?
Maybe I just answered my own question, if the business is able to cook the books both ways, but it would also limit how much they're able to launder. Or is the import/export balance rarely/never checked?
That's why popular businesses for money laundering are car washes and nail salons. They're mostly cash based, and have very little in the way of inventory, so it's easy inflate your sales.
I'd think a video game arcade, especially one with laser tag, would be the best option.
Especially if you stick with quarters instead of using game cards like most modern arcades. Since quarters would be recycled anyways (Taken from the games and restocked into the quarter machine), it makes it easy to just deposit the cash you want to launder as if it had been fed into the quarter machine.
But a car wash uses water and a nail salon hires workers. Shouldn't take long to check that those numbers don't add up with what was sold at the end of a month.
Maybe. If you calim to wash a million cars but only wash a thousand that will be obvious, but 10 washes different is lost in the noise. Nail salons are easier because you can have the expensive personalized service that no real person buys but if someone investigates you will give it to them.
More likly the above are selling something illegal though. Pay for the expensive hand car wash but get drugs instead with a cheap automatic wash - nobody will know the difference.
For higher valued goods they use horses. A saddle can go for $30,000, so you buy some $1000 saddles and sell them for $30,000 and $29,000 worth of something else.
They will gladly send water down the drain if it threatens their enterprise. Besides, you have to be on the burner for huge crimes if law enforcement is going to care enough to audit water usage. Again, minor piece of circumstantial evidence in any case.
The gentleman who owns the nail salon in my Midwest suburbia strip mall drives a Lamborghini. One wonders about the immigration status and compensation structure of the nail techs.
Money only has meaning as a flow. Value moves from A to B. Forensic analysis can follow this chain quite a long way, which is a problem for people trying to hide illegal activity. They're always looking for ways to break that chain. If OP is correct and this attack allows you to covertly shift money around, that can break the chain and let the bad guys use the illegally obtained funds with legitimate services.
It might look something like:
1) get funds via illegal activity (dirty funds)
2) spends funds at an ecommerce site (dirty funds)
3) secure a paypal refund WHICH GOES TO ANOTHER ACCOUNT (clean funds)
The PayPal vulnerability allows the money to move from a dirty chain to a clean one.
I am aware of these types of botnets, how they work, and which companies are behind them. Hence the reason for adding my spam database to the initial comment, which focuses on exactly those, combined with the ebpf firewall module that analyzes and correlates repeated bad behaviors.
It's not a new technique btw, APT28/29 and others have been doing this for around 10 years now.
+1. As mentioned on the side, this will negatively impact your conversion rate. But you don't need to leave it on forever, either; you can use it to get some breathing room.
The attacker may lose interest or move on to more fruitful targets if they find themselves blocked even temporarily. This is the "don't need to be faster than the bear" dynamic of online fraud: there are infinite targets and you don't need to perfectly shut out an attacker to make the ROI unappealing for them.
My thoughts on the scenario:
1. Chargebacks are not just a financial problem. There is no amount of money you can pay to regain the trust of your sellers (as it's a marketplace) or to change terms with your payment providers.
2. If the emails come from the same domain, can you block the domain? There are lots of throwaway domains, but it's effort for the attacker to switch them, too.
3. CAPTCHAs are increasingly ineffective between captcha solving services and multi-modal AI. I've heard in a few recent attacks that hCaptcha does a little better than Turnstile or reCAPTCHA.
4. Shadowbanning is good for wasting your attacker's time, which is really important to kill their ROI. You'll need to get your false positive rate low though to not piss off your actual good customers.
5. Your scenario (no API, browser required, no bot activity expected) is a really good fit for properly implemented device fingerprinting.
I'm the PM for Fraud & Security at Stytch and we do have a Device Fingerprinting product. It's harder to trial than the open-source ones, but the advantage is that attackers can't inspect the implementation to evade it.
Would you be interested in talking more? I'm happy to walk through your current controls and see if it makes sense to test Device Fingerprinting, shoot me an email at (first letter of my username) + (last four letters of my username) @ stytch.com .
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.
I haven't worked with online payments for a few years, so take it for what it is, but I'd agree. PayPal is possibly the worst payment solution, for the stores. Their support sucks and is completely unhelpful, managing your account was at the time extremely complex, compared any other payment solution.
Our rule taking PayPal: Transfer EVERYTHING out of your PayPal account on a daily basis, do not let them hold your funds, they will block you from accessing it at some point. Minimize what they can touch.
Also don't all smaller amounts to be paid with PayPal. This prevents you from being abused as a source for verifying stolen accounts.
The only company I dealt with that came close to the same level of incompetency was Klarna. Klarna didn't at the time understand the concept of fraud, because they're Swedish and their system in Sweden MOSTLY prevented fraud at the time. Once people found away around that and Klarna expanded beyond Sweden, they gave up and attempted to stick the bill on us, despite their contracts clearly stated that they where responsible for collecting payments.
> Our rule taking PayPal: Transfer EVERYTHING out of your PayPal account on a daily basis, do not let them hold your funds, they will block you from accessing it at some point. Minimize what they can touch.
That only works until your business is successful. Once you reach enough transaction volume/dollars they will require you to float millions of dollars in your PayPal balance and not let you touch anything for 30-45 days after transactions.
If you can pass on a chunk of customers sure. I've canceled a purchase more than once at checkout when I saw there is no PayPal available, if the website was unknown or looked a little shady, and I didn't desperately need the item. There are people who don't buy at all if there's no PayPal just because it's less convenient.
This. Also, remember that from the consumer standpoint, PayPal was the first ever trusted payment processor that didn't pass your payment account info (bank, CC#, debit card info) along to the vendor. Granted, they passed along your email+shipping address. But the vendor would have had that info anyhow if you were purchasing some physical item from them.
So there's a large swath of the consumer population that views PayPal positively and will skip a purchase if there's no PayPal option.
Are there services that "guarantee" (or block) transactions for a fee?
In any case, this should be the primary responsibility of the payment service !! The fact it can so casually off load it to the merchants is just bizarre
Guaranteeing transactions would incentivize the provider to block transactions. There are many companies in the space, like sift.com, but they don’t guarantee.
3DS is not just 2FA, but it has an option to shift liability to the card issuer in case of card-stolen disputes. Our fraud has come to near 0 once we started 3DS enforcement. 1% of 3DS transactions don't lead to a liability shift, and in such cases, we flag those transactions and call the customer to get more forms of identification that they own the card.
With PayPal - beyond ownership of email address (which is already compromised), there's nothing else to validate against.
I'm not that commenter but my business also moved away from PayPal and is using Stripe + Sezzle for transaction processing. It has been about five years now without any issues at all.
Easy example is Stripe. You can enable 3DS, and you can listen for 'early_fraud_warning' events on a webhook to refund users & close accounts to avoid chargebacks and all the associated fees and reputation penalties.
Part of the problem is that not all countries have the same solutions, but credit/debit cards are an easy solution. In some countries that requires 2FA using a government issued ID. It's not 100% secure, people being people and doing stupid things, but it's better. If you're in the US, I don't know, it might not be better. If you can, ask your credit card processor to block cards that's not in the area you serve. E.g. we had huge success in blocking UK and US credit cards from our Scandinavian stores.
In Scandinavia there's also MobilePay, which is much much better, as it is also closely linked to real identities.
The problem with using credit/debit directly is that it requires the customer to trust you with their credit card number.
The nice thing about Paypal is I click the button and a window pops up that Firefox recognizes as coming from Paypal to autofill my login info, then Paypal confirms the payment info and gives the website just the payment info. With a credit card, even if you have a different payment processor with an icon next to it that says "secure", there's not actually any way for me to be sure at a glance that that isn't Stripe_Secure_Checkout_Confirmation.SVG and that you aren't just harvesting my credit card info, other than other contextual information on your website and your company's reputation as an actual company that does actual business in the real world.
Vipps and MobilePay merged, so it's the same product now. It's MobilePay in Denmark and Finland, and Vipps in Norway and Sweden... and apparently Poland.
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 merchanttechsupport@paypal.com — 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.
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.
I'm hot off fighting one of these bot nets. They automatically adapted and spread the calls over a ridiculous number of IPs and all had good JA4 fingerprints at Cloudflare (compromised or nurtured "users"). Gave us nothing to block. We started targeting high count JA4s and blocking those temporarily. This would usually cause them to stop automatically.
Very sophisticated LLM-enabled rented mafia bot net. They crafted attacks of various approaches as we turned up the heat.
In the end we refactored our entire authentication flow. We had a lot of Anon endpoints and ones that would validate card numbers etc from past misguided product and management decisions.
In the end we had to block a lot of legitimate traffic at times.
Reducing friction for users reduces friction for scaled bot attacks.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
Yes. I buy things all the time from smaller vendors that support PayPal, Amazon Pay, maybe google/apple, as well as a direct credit card entry. Actually, even many large vendors offer a selection of payment options; I pay Walmart and I think BestBuy with PayPal because it's got my card saved and I don't want to get up and grab my wallet. PayPal has big issues if you're a small seller, but as a purchaser it's convenient.
I don't think I've seen vendors offer a choice of two different merchant accounts, but some do have multiple merchant accounts and select one or the other at time of billing; sometimes you can tell because it shows up a little different on the bill depending on the path, or more often because they send an announcement about trouble with billing and mention that it only affects some customers because they have two accounts.
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.
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.
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 did the same thing with geo IP blocks + blocks of non-consumer IP ranges. I don't completely block the transaction - I just send them into a different workflow where we manually call them to run the transaction. This works fine for legitimate 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.
It's easy to say "don't use PayPal" but if you're going to say it, you need to do the hard part of suggesting a viable alternative for eCommerce that has as broad a reach and acceptance as PayPal. Stripe? Almost none of the outlets I do business with use it. Venmo? Same company as PayPal. Back to using credit card numbers? The more we spread those around online, the higher the chance they get stolen and used, probably in refund scams like the one OP describes.
People need an alternative with some degree of trust and most consumers, by my reckoning anyway, would prefer a single entity that is accepted everywhere. Right now, that's unfortunately PayPal.
Personally I've had way less issues with stripe, especially in terms of fraud detection.
Also not sure what and where business is but in Europe it's common to just use a proxy provider where credit card is just one of many options and you use a central gateway (similar to stripe)
You'd have to check your local options. At least one of my local banks offers something more advanced than PayPal. And there are several of these proxy providers in my country.
Edit:// if you just want low fee, fast and risk free transactions we all know there is only crypto
Yeah. It’s ridiculous how crypto gets so much hate here, yet there are constant, often heart wrenching posts about the failures and even near-malfeasance of payment processing systems. The paradoxical claims that crypto has no use case except fraud and crime, juxtaposed with the lamentation and gnashing of teeth over the misery of traditional payment systems is enough to provoke an existential examination of the senses.
I honestly think it must be mostly sour grapes, since by far, cash and other traditional payment methods facilitate the vast, vast majority of crime and fraud, and cryptocurrency is the only universally accessible, trustless, (nearly) costless, instant, global system for the transfer of value between two parties.
It is by far a better system, even with its flaws. Which is why, yes, many criminals use it, just as they use cash. Because it works.
I am also amazed by the resistance to change here as there is a system clearly more efficient and transparent. It's just a matter of time in my opinion.
BTW you can remove the (nearly) in "(nearly) costless", some solutions provide 0 fees and no inflation.
By more efficient you mean taking hours to settle? And no inflation as in Bitcoin level volatility and up?
I'd love an efficient and cheap option to move funds online - especially for micro payments too. But so far I haven't heard of any crypto option that actually stayed around long enough to prove these things.
Stablecoins on any number of low cost networks are fine for small payments (I haven’t lost anything, not even $0.01 in 10+years, vs tens of thousands in chargebacks, mostly fraudulent, for credit card processors).
I factor in 2.5% total costs for transaction frictions, historically that is a bit over 3x our actual average cost from payer to bank account, but it would easily cover the occasional loss of a day or two of sales in a catastrophe.
Pick a top 5 stablecoin that has a good reputation and at least 3 years, on a network with at least that, and settle your accounts daily, or whenever the accumulation represents a significant dent if lost.
The approximate aggregate risk-cost of major (top 10) stablecoins is somewhere south of .001% per day, and is better than the aggregate risk-cost of national fiat currencies, which unremarkably collapse or suffer catastrophic inflation and rebasing on a regular basis. There are frequently several undergoing this process at any given time.
> The approximate aggregate risk-cost of major (top 10) stablecoins is somewhere south of .001% per day, and is better than the aggregate risk-cost of national fiat currencies
This "stablecoin" garbage needs to die yesterday: a lot of people are going to lose their shirt when the first one blows up. Fixing exchange rates is folly, yet here we go again...
Why would I care if a stablecoin blows up? My payment cost allocation more than compensates for that possibility and my losses in a worst case scenario would be eclipsed to oblivion by the cost savings I have already realized.
My theoretical potential losses compared to the costs of the payment processsors I ditched, and the chargebacks we used to deal with.
International payment processing is quite expensive, both on a teansaction and on an administrative basis.
My worst case total risk exposure is approximately the same as the cost of 3 months of payment processing overhead, without counting fraudulent chargebacks and “we are going to freeze your account because we can” risks.
FWIW in the last 60 years I have lost way more money to fraud and theft dealing with banks and cash then I ever will using cryptocurrency. On a total, or a percentage basis. I see the risk profile, when properly managed, to be much, much lower using blockchain solutions.
> My worst case total risk exposure is approximately the same as the cost of 3 months of payment processing
Okay, yes: what you're describing is the actual utility of these things.
I think you underestimate how many people dealing in them are using them much less intelligently than you are.
They are being marketed in an extremely dishonest way, as a safe long term store of value. I regularly overhear normal people at my local bars talking about how they're "investing big in stablecoins" and it terrifies me.
>>This "government issued fiat currency" garbage needs to die yesterday: a lot of people are going to lose their shirt when the first one blows up.
What you are saying is a risk endemic to all fiat currencies, including stablecoins.
All symbolically represented forms of value quantization are subject to a failure of confidence. Cryptocurrencies are nothing new in this regard. All money is memetic in nature.
That’s one of the reason the stablecoins won’t be taking my assets? Idk what your point is but it doesn’t seem like you are debating from a point of rational examination.
Weird, people on the internet spewing BS? Who’d have thought?
Well, losing three months of revenue is going to really hurt when the stablecoin inevitably eats shit: hope you're prepared for that.
The risk is obviously lower because you aren't parking money there. I could certainly see how you might come out ahead in fees for certain international transactions.
But your original claim was that the aggregate risk-cost of dealing in stablecoins is lower than real currencies, and that is absolutely preposterous: you aren't accounting for all the risks.
Nobody claims that crypto doesn't have a use case. They claim that it has failed at its use case. You can't use it to buy things easily or safely. Buying a bunch of crypto on the internet and looking at a graph every day hoping the line goes up isn't useful.
Its use case is still fraud and crime: when laundering money or fencing stolen goods, you expect the process to be difficult, dangerous and to have to pay a large fee. Crypto is a clear improvement on older criminal methods. It's not an improvement on credit cards.
Plenty of digital places accepting crypto like Namecheap, Vultr, ..,
Plenty of companies where you can sell and receive whatever currency you prefer. More or less instantly in case of some. Yes also to my EUR/CHF bank account. For Switzerland that's $1000 per day (per service) without any deep verification.
Some banks even offering "instant transfer" where you get a debit card and just pay with the crypto on your account. Swissquote to name one with all proper banking requirements and barely any fees.
Also from the point of a seller that has seen many kind of weird disputed and scams I am happy to not have any of these issues with crypto. This is an very obvious improvement over credit cards.
Not saying the world is fine, but blaming crypto (the most transparent payment method ever) is way to simple and far from our financial reality
Even to the point that the cost of maintaining other payment systems was less cost effective than just dropping them and focusing on crypto only. FWIW we are not a “crypto” business, our focus is kinodynamics.
Our market is global and we are small from a payment perspective in this context, so our case may be a bit of an outlier, but our lived experience does directly contradict your claim.
I agree that speculation and crime is a problem, but the speculation market in global commerce and currency dwarfs crypto, así does the criminal usage of cash, so it’s disingenuously myopic to frame those as a crypto-centric issue.
The relative difficulties of regulation because of the decentralized nature of crypto does make it a hotbed for schemes that wouldn’t be practical under local regulations, but I have a hard time getting riled up about that when we have giant state sponsored gambling industries nearly worldwide.
If you were to compare the impact on criminal activity if you eliminated cash vs eliminating crypto, I think it’s easy to see that eliminating cash would be much more detrimental to criminal activity.
In all, the arguments being made are not at all based on a rational examination of verifiable ground truths. They are almost to a fault emotionally based arguments with a near hysterical pitch woven into them from the start.
It seems like some people fear crypto. I don’t know why, but they do. On some level, they fear the threat it poses to the devil they know, perhaps. Maybe that is why they react the way they do.
What's wrong with Trustly, Adyen and others among the ~40 alternatives we maintained integrations with at the casino operator I was working at almost ten years ago?
Haven't heard of them at all, that's what's wrong.
They may be great services, of course, being that I, a single consumer, am not a barometer for the success of a payment platform. But whoever they are, they're not being used by major retailers, distributors or manufacturers that I shop with both personally and professionally.
IIRC Ebay uses Adyen. I think Paypal uses Trustly in some significant markets.
I don't know why they didn't show up early in your research, as they are among the most well known and easy to find. Ingrid is lesser known and mostly active in e-commerce in the european markets.
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.
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'`.
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.
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.
I can promise you that's not a better solution. I witnessed a card testers smarter than Stripe tech and Stripe shutting down account that had literally 0% chargeback ratio and doing over $10MM in sales monthly. Still to them that was peanuts. They will help you initially and customer support is pretty fast at figuring things out, but in no shape of form will they say "gee, we see you are not the bad guy and someone else is doing that so your account is good to continue abusing our merchant accounts". They. Will. Shut. You. Down. Because they care about their rates of CB more than about your business. Just 2c, based on experience.
Agreed, but having dealth with both Paypal and Stripe in situations like this, I'd take Stripe over Paypal in a heartbeat. Paypal are some of the most evil bastards I've ever had the displeasure of "working" with.
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.
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.
In a perfect world with a fair market, yes they should consider entering and competing given they could probably do better. This isn't either.
One doesn't simply walk into mordor.
To enter this market, it requires that you first receive a national bank charter.
Post 2008 crisis, the laws have changed to eliminate competition from any new champion. There were many new requirements that can never be met over the long haul, and act as a ticking timebomb until it fails (through no fault of the person/group trying to start a bank.
At last read, the one that stuck out to me was it required a board of directors who could not receive payment or incentive related to the position, and where they would be personally liable for the majority of decision of the board.
No financial incentive, all the liability, and the decision is unmanageable in other people's hands. No one with a right mind will do that.
There's also the reasonability tests for success that need to be granted by the state or OCC as well. I hear these change all the time, and with the level of deficit spending these days and other fed shennanigan's its hard to find a reasonable person that will say any new contender will have a chance against a long-term state/fed fund/granted monopoly.
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.
Yep, and don't forget they will lock up any funds during that period, so I recommend you transfer them to your bank early and often. Money in your Paypal account is not your money.
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.
Each transaction will be unique, with a different device, different ASN, and different IP. If you find my post above, it links to an article which explains the whatfor and how this is going on.
(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.
We had the same issue (people testing stolen credit card numbers) on Stripe that was close to getting us shut off for a certain credit card company. We implemented a captcha and a tool to validate email addresses (emaillistverify) and it solved the problem.
We had the same issue because Marketing was using a stupid landing page SaaS tool to generate sales, it was connected directly to Stripe and we didn't have any control over it. We discovered the problem through Intercom, which notified us about a high volume of bounced emails (automatically sent after purchase). It was clear what was going on after discovering the same pattern.
To fix it, I had to proxy that unreliable SaaS software to implement CAPTCHAs and stronger bot detection. It was essentially a MITM-style proxy but for protection. It was fun to implement
TIL about emaillistverify. Their website always talks about „bulk email checking“, but I assume they also support „live checks“ through an API? I assume you prevent users from signing up if the check fails?
Top nav of their site has an "API" link which goes to a page that says "ELV’s API keeps your email list clean. Notify website user about an invalid email address when they are filling out a form."
So presumably yes
This is a very sad incident of carding attempts. You can sign up for FraudLabs Pro service and they have velocity check to prevent carding if it is from similiar browsers, IP or email addresses.
This is probably the best way to stop it from being automated. As well as a verified form of 2FA like a phone or email code.
This is correct. We have seen this over the years in our ecommerce business. I suggest using threat levels, you are under attack so the threat level increases until they go away. When the threat level is high, you require an exact match AVS. You might have more agressive filtering at the IP level, real users generally won't be datacenter IPs. Pay attention to the ASN, sometimes you'll get an attack from a network that legit customers never use, so you can just block the whole network. Keep an eye on your logs, you'll notice patterns. The attack is likely coming from a single entity, if you make it difficult to abuse your service, then they will move on.
Can confirm doing charity collection that we often encountered this. Credit card processor said there was nothing we could do about the more sophisticated attacks that used a wide range of IPs. We basically stopped them by freezing everything if there was an unexpected traffic spike. Not perfect, but it worked and they stopped trying us.
Agreed. This is a situation where you need a dedicated security team to classify and mitigate this kind of attack while making sure the mitigations don't add too much friction to your real customers. It's not easy. It's also not really on your payment processor to be the first line of defense for this kind of fraud.
You'll need to find some way to fingerprint to classify users into risk buckets and then treat them differently based on the bucket: blackhole, high friction verification, and likely safe are three reasonable buckets.
Cloudflare has tools that can help identify bots, much of this can be offloaded onto them.
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
Sorry for the noob question, but how can Docker help remediate the situation? I'm currently learning about DevOps.
It can't easily, Docker should not be naively treated as a security solution. It's very easy to misconfigure it:
- The Docker daemon runs as root: any user in the docker group effectively also has sudo (--privileged)
- Ports exposed by Docker punch through the firewall
- In general, you can break the security boundary towards root (not your user!) by mounting the wrong things, setting the wrong flags etc.
What Docker primarily gives you is a stupid (good!) solution for having a reproducible, re-settable environment. But containers (read: magic isolated box) are not really a good tool to reason about security in Linux imo.
If you are a beginner, instead make sure you don't run services as the sudo-capable/root user as a first step. Then, I would recommend you look into Systemd services: you can configure all the Linux sandboxing features Docker uses and more. This composes well with Podman, which gives you a reproducible environment (drop-in replacement for Docker) but contained to an unprivileged user.
I agree with what you wrote, and add that you should make sure that your service's executables and scripts also should not be owned by the user they run as.
It's unfortunately very common to install, for example, a project as the "ubuntu" user and also run it as the "ubuntu" user. But this arrangement effectively turns any kind of file-overwrite vulnerability into a remote-execution vulnerability.
Owning executables as root:root, perms 0755, and running as a separate unprivileged user, is a standard approach.
> - Ports exposed by Docker punch through the firewall
I've been using ufw-docker [1] to force ufw and docker to cooperate. Without it, Docker ports do actually get exposed to to the Internet. As far as I can tell, it does its job correctly. Is there another problem I am not aware of?
[1] https://github.com/chaifeng/ufw-docker
Docker keeps well behaved programs well behaved. You can escape in one line of shell.
How? Like if I have a Debian-Slim container running it's possible to "break-out" onto the host?
Yup that's trivially easy if you have permissions to use mknod and mount. (and if the file system namespace looks like it normally does all you need is mount.)
Docker is for organizing things for yourself, just like directories are. If you want actual isolation you have to take extra steps.
EDIT: and I feel like I should add those extra steps are exactly what most server software does automatically when it chroots itself. Again docker is really just for organizing things.
> Yup that's trivially easy if you have permissions to use mknod and mount.
Docker containers don't have mount permissions by default.
For those not intimate familiar with containers (docker/podman), can you link to a brief blog post that touches on this in detail for further reading? Much appreciated.
> Docker is for organizing things for yourself, just like directories are.
Services have the following dependencies: static data files; configuration files; executable code/binaries; library dependencies.
In days of yonder, you'd need to download/install all of that ^ on each machine where "service A" needs to run. Developers would run and test "service A" on ubuntu 18.04. But production servers had to run ubuntu 16.04 because "service X" that also runs on the same server needs a library that has not been ported to 18.04 yet.
But "service A" needs a library that was never available on 16.04. Welcome to dependency hell!
Containers bundle all of those dependencies into one object that can be downloaded directly onto the host server, ready for the "service A" process to execute. Now it doesn't matter if production servers are running 16.04. Everything "service A" needs is stored inside the container blob (including some minimal ubuntu 18.04 stuff).
the magic that lets this happen -- containers re-use the host server's OS kernel. Running a new ubuntu 18.04 container does not start a new OS kernel running. the process for your container is just 'firewalled' off from all other processes using cgroups [0]. containers re-use the host's kernel, start a cgroup'd process which starts your container's services and processes (the 18.04 'OS' services and your binary/code/executable).
short/simpler version: containers share the core of the underlying operating system on the host server.
> If you want actual isolation you have to take extra steps.
unfortunately, this means containers share the core of the underlying operating system on the host server.
containers not being isolated from the host server OS can present a security risk as you can escape from the container and "do bad things to host server". [1]
In cases where that is a problem you mostly have two choices:
* use VMs instead (a completely isolated OS instance is started for each service, cannot interact with the host OS at all -- this uses a lot more memory/cpu)
* use rootless containers [2] (container processes are launched under a specific user namespace rather than kernel namespace -- escaping the container means you only get access to the user namespace)
[0]: https://en.wikipedia.org/wiki/Cgroups
[1]: by default the docker daemon service and all the container processes it starts are running as root, which means escaping out of a container in a a default docker installation is as bad as giving someone root.
[2]: https://docs.docker.com/engine/security/rootless/
Containers allow separation of access rights, because you don't have to pwn only one program/service that is running on the host system to get physical access to it.
Containers have essentially 3 advantages:
- Restart the containers after they got pwned, takes less than a second to get your business up and running again.
- Separation of concerns: database, reverse proxy, and web service run in separate containers to spread the risk, meaning that an attacker now has to successfully exploit X of the containers to have the same kind of capabilities.
- Updates in containers are much easier to deploy than on host systems (or VPSes).
> Separation of concerns
Sorta: yes the container is immutable and can be restarted, but when it does, it has the same privs and creds to phone up the same DB again or mount the same filesystem again. I'd argue touching the data is always the problem you're concerned about. If you can get an exec in that container you can own its data.
Why do you think ISOs never really took off? I feel like they solve so many issues but only ever see folks reach for containers.
Do mean VMs? ISO is a file format, commonly used for VMs and other computers.
For VMs, they did take off and essentially the entire cloud ecosystem runs on mostly VMs behind the scenes for VPS and similar hosting.
It's true though at it seems more popular for developers to reach for containers when they need to think about deployments, particularly docker containers. But VMs are still widely in use and deployed today.
yyeaaah, i built a cloud. :) I love VMs. I'm a disciple of Alex Polvi. Lets call it an "Immutable Application VM" Stack. Each application service (or a logical group of application services) is packaged directly into an immutable VM image, and the orchestration manages these VMs directly. No separate container runtime or container orchestration layer on top of the VM. So you have an Immutable, Bootable System Image, but you would use kvm plus .iso plus orchestration tech. Basically, why does nobody built a cloud on the cloud lol??
(I helped build digitalocean from zero the pre-IPO, so I'm verrry rusty, this all might be nonsense/wrong think, and happy to be told as much! :))
Just thinking about this from a proxmox pov -- applying this advice, do you see an issue with then saying: take a copy of all "final" VMs, delete the VM and clone the copy?
And, either way, do you have a thought on whether you'd still prefer a docker approach?
I have some on-prem "private cloud"-style severs with proxmox, and just curious about thinking through this advice.
There's already unix permissions and regular namespaces. Docker is very hard to secure.
Not OP, but Im assuming its because of immutability of the containers where you can redeploy from a prebuilt image very quickly. There is nothing that says you cant do the same with servers / VMs however the deployment methodology for docker is a lot quicker (in most cases).
Edit: Im aware its not truly immutable (read only) but you can reset your environment very easy and patching also becomes easier.
It can't. Also there's nothing inherently wrong with ssh password auth.
You might want to back those statements up.
Not parent, but see my sibling comment re: Docker. The issue is imo that Docker is very easy to misconfigure and gives you the wrong mental model of how security on Linux works.
On SSH password auth: its secure if you use a long, random, not reused elsewhere password for every user. But it is also very easy to not do these things. SSH certs are just more convenient imo.
Using docker does not help in this specific case - if the attackers came via ssh, they will have root access as before, and if they come in through the application, they still control your application inside the container and can make it serve what they want.
For ssh, the problem does not lie within password auth itself, but with weak passwords. A good password is more secure than a keypair on a machine whose files you can't keep private.
Docker is not really a security boundary (unless you use something like gVisor), so it's a bit of a red herring here.
The idea is to make your app immutable and store all state in the DB. Then, with every deployment, you throw away the VM running the old version of your app and replace it with a new VM running the new version. If the VM running the old app somehow got compromised, the new VM will (hopefully) not be compromised anymore. In this regard, this approach is less vulnerable than just reusing the old VM.
This is not money laundering. Why would they dispute if it's ML?
Please explain the money laundering part here?
Im not op and I’m not sure they are using it for money laundering.
A money launderer can use a marketplace by creating a seller account and buying from himself. Since he’s the one buying he doesn’t need to deliver anything but he gets the money from a legit source. Usually he would use a payment method as close to money as possible so that it leaves less traces. But in OPs case, the amounts are low so he needs too many transactions to get something valuable. And because of the disputes, he’s (probably) not getting the money (?).
It could be card testing: the fraudster has a bunch of cards and doesn’t know which is valid or canceled. The best way to find out is to test in a real site. So he’ll test out each of them and the ones that go through are good to use elsewhere. The thing is that it would be better for him not to dispute the transactions so the OP would take much longer to find out about the scheme and shut it down. It’s better to use low amount transactions in this case so it doesn’t use too much of the credit available for him to defraud and probably doesn’t warn the card owner.
Another option is doing it just to hurt the OP marketplace. If you have too many disputes the brands can fine you and if you don’t solve the problem they can turn your account off. I’ve seen it happen when a competitor was trying to hurt the e-commerce. It’s a low move and rare but it happens.
One thing that might help is to analyze the sellers too. In a money laundering and even in the other settings, it could be part of the scheme. Are they new accounts? Are their volume exploding out of nowhere? Etc
> Since he’s the one buying he doesn’t need to deliver anything
This only works (in my mental model), when you produce the product you're selling in-house – like a digital product. But lots of "reselling" type businesses try to use this scheme as well. Like a restaurant might ring up more meals than they served, or less to not pay taxes. But, is this not easily spotted when the food import(?) cost doesn't match the revenue?
Maybe I just answered my own question, if the business is able to cook the books both ways, but it would also limit how much they're able to launder. Or is the import/export balance rarely/never checked?
That's why popular businesses for money laundering are car washes and nail salons. They're mostly cash based, and have very little in the way of inventory, so it's easy inflate your sales.
I'd think a video game arcade, especially one with laser tag, would be the best option.
Especially if you stick with quarters instead of using game cards like most modern arcades. Since quarters would be recycled anyways (Taken from the games and restocked into the quarter machine), it makes it easy to just deposit the cash you want to launder as if it had been fed into the quarter machine.
But a car wash uses water and a nail salon hires workers. Shouldn't take long to check that those numbers don't add up with what was sold at the end of a month.
Maybe. If you calim to wash a million cars but only wash a thousand that will be obvious, but 10 washes different is lost in the noise. Nail salons are easier because you can have the expensive personalized service that no real person buys but if someone investigates you will give it to them.
More likly the above are selling something illegal though. Pay for the expensive hand car wash but get drugs instead with a cheap automatic wash - nobody will know the difference.
For higher valued goods they use horses. A saddle can go for $30,000, so you buy some $1000 saddles and sell them for $30,000 and $29,000 worth of something else.
They will gladly send water down the drain if it threatens their enterprise. Besides, you have to be on the burner for huge crimes if law enforcement is going to care enough to audit water usage. Again, minor piece of circumstantial evidence in any case.
The gentleman who owns the nail salon in my Midwest suburbia strip mall drives a Lamborghini. One wonders about the immigration status and compensation structure of the nail techs.
Same here. Our nail salon often has a McLaren parked in front.
Money only has meaning as a flow. Value moves from A to B. Forensic analysis can follow this chain quite a long way, which is a problem for people trying to hide illegal activity. They're always looking for ways to break that chain. If OP is correct and this attack allows you to covertly shift money around, that can break the chain and let the bad guys use the illegally obtained funds with legitimate services.
It might look something like:
1) get funds via illegal activity (dirty funds) 2) spends funds at an ecommerce site (dirty funds) 3) secure a paypal refund WHICH GOES TO ANOTHER ACCOUNT (clean funds)
The PayPal vulnerability allows the money to move from a dirty chain to a clean one.
It wouldn't go to another account if you do a dispute, what are you talking about?
Yeah I work at a large US fintech and this isn't ML
>2) spends funds at an ecommerce site (dirty funds) 3) secure a paypal refund WHICH GOES TO ANOTHER ACCOUNT (clean funds)
How it breaks the chain?
Account1 buys for 10k USD, requests refund, receives it?
Even if it went for some reason to account2 then there is still the chain, but why would it go to other?
Unfortunately nowadays, blocking by ASN is not going to help you out much in solving this type of issue.
The reason for this is stealthy botnets.
For a brief rundown, I'd suggest this article.
https://jan.wildeboer.net/2025/04/Web-is-Broken-Botnet-Part-...
Web scraping is not the same as web scanning.
I am aware of these types of botnets, how they work, and which companies are behind them. Hence the reason for adding my spam database to the initial comment, which focuses on exactly those, combined with the ebpf firewall module that analyzes and correlates repeated bad behaviors.
It's not a new technique btw, APT28/29 and others have been doing this for around 10 years now.
You can configure your account to reject unverified buyers.
https://www.paypal.com/us/cshelp/article/what-are-payment-re...
+1. As mentioned on the side, this will negatively impact your conversion rate. But you don't need to leave it on forever, either; you can use it to get some breathing room.
The attacker may lose interest or move on to more fruitful targets if they find themselves blocked even temporarily. This is the "don't need to be faster than the bear" dynamic of online fraud: there are infinite targets and you don't need to perfectly shut out an attacker to make the ROI unappealing for them.
My thoughts on the scenario:
1. Chargebacks are not just a financial problem. There is no amount of money you can pay to regain the trust of your sellers (as it's a marketplace) or to change terms with your payment providers.
2. If the emails come from the same domain, can you block the domain? There are lots of throwaway domains, but it's effort for the attacker to switch them, too.
3. CAPTCHAs are increasingly ineffective between captcha solving services and multi-modal AI. I've heard in a few recent attacks that hCaptcha does a little better than Turnstile or reCAPTCHA.
4. Shadowbanning is good for wasting your attacker's time, which is really important to kill their ROI. You'll need to get your false positive rate low though to not piss off your actual good customers.
5. Your scenario (no API, browser required, no bot activity expected) is a really good fit for properly implemented device fingerprinting.
I'm the PM for Fraud & Security at Stytch and we do have a Device Fingerprinting product. It's harder to trial than the open-source ones, but the advantage is that attackers can't inspect the implementation to evade it.
Would you be interested in talking more? I'm happy to walk through your current controls and see if it makes sense to test Device Fingerprinting, shoot me an email at (first letter of my username) + (last four letters of my username) @ stytch.com .
Why is this not the top answer?
Some people want a high conversion rate, and before I flipped this on, something like ⅓ of my customers were unverified buyers.
How many fraudulent charges did you deal with?
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.
I haven't worked with online payments for a few years, so take it for what it is, but I'd agree. PayPal is possibly the worst payment solution, for the stores. Their support sucks and is completely unhelpful, managing your account was at the time extremely complex, compared any other payment solution.
Our rule taking PayPal: Transfer EVERYTHING out of your PayPal account on a daily basis, do not let them hold your funds, they will block you from accessing it at some point. Minimize what they can touch.
Also don't all smaller amounts to be paid with PayPal. This prevents you from being abused as a source for verifying stolen accounts.
The only company I dealt with that came close to the same level of incompetency was Klarna. Klarna didn't at the time understand the concept of fraud, because they're Swedish and their system in Sweden MOSTLY prevented fraud at the time. Once people found away around that and Klarna expanded beyond Sweden, they gave up and attempted to stick the bill on us, despite their contracts clearly stated that they where responsible for collecting payments.
The one reason I still use PayPal is because the 5% + 5¢ for micropayments is the best deal out there if you're billing $1 or $2 transactions.
I transfer all funds out on a daily basis.
> Our rule taking PayPal: Transfer EVERYTHING out of your PayPal account on a daily basis, do not let them hold your funds, they will block you from accessing it at some point. Minimize what they can touch.
That only works until your business is successful. Once you reach enough transaction volume/dollars they will require you to float millions of dollars in your PayPal balance and not let you touch anything for 30-45 days after transactions.
My immediate reaction reading the post was “don’t use PayPal”
Online marketplaces, multiparty sellers, credit card transactions, etc… are hard enough as it is
Don’t become dependent on a vendor who’s absolutely terrible to work with
If you can pass on a chunk of customers sure. I've canceled a purchase more than once at checkout when I saw there is no PayPal available, if the website was unknown or looked a little shady, and I didn't desperately need the item. There are people who don't buy at all if there's no PayPal just because it's less convenient.
This. Also, remember that from the consumer standpoint, PayPal was the first ever trusted payment processor that didn't pass your payment account info (bank, CC#, debit card info) along to the vendor. Granted, they passed along your email+shipping address. But the vendor would have had that info anyhow if you were purchasing some physical item from them.
So there's a large swath of the consumer population that views PayPal positively and will skip a purchase if there's no PayPal option.
Are there services that "guarantee" (or block) transactions for a fee?
In any case, this should be the primary responsibility of the payment service !! The fact it can so casually off load it to the merchants is just bizarre
Guaranteeing transactions would incentivize the provider to block transactions. There are many companies in the space, like sift.com, but they don’t guarantee.
> there’s no way to ascertain ownership of an account (like 3DS)
3DS is 2FA and PayPal most definitely has it, it's just that they protect the customer regardless of 2FA.
3DS is not just 2FA, but it has an option to shift liability to the card issuer in case of card-stolen disputes. Our fraud has come to near 0 once we started 3DS enforcement. 1% of 3DS transactions don't lead to a liability shift, and in such cases, we flag those transactions and call the customer to get more forms of identification that they own the card.
With PayPal - beyond ownership of email address (which is already compromised), there's nothing else to validate against.
What have you switched to that isn't PayPal and also doesn't have this issue?
I'm not that commenter but my business also moved away from PayPal and is using Stripe + Sezzle for transaction processing. It has been about five years now without any issues at all.
Easy example is Stripe. You can enable 3DS, and you can listen for 'early_fraud_warning' events on a webhook to refund users & close accounts to avoid chargebacks and all the associated fees and reputation penalties.
Part of the problem is that not all countries have the same solutions, but credit/debit cards are an easy solution. In some countries that requires 2FA using a government issued ID. It's not 100% secure, people being people and doing stupid things, but it's better. If you're in the US, I don't know, it might not be better. If you can, ask your credit card processor to block cards that's not in the area you serve. E.g. we had huge success in blocking UK and US credit cards from our Scandinavian stores.
In Scandinavia there's also MobilePay, which is much much better, as it is also closely linked to real identities.
The problem with using credit/debit directly is that it requires the customer to trust you with their credit card number.
The nice thing about Paypal is I click the button and a window pops up that Firefox recognizes as coming from Paypal to autofill my login info, then Paypal confirms the payment info and gives the website just the payment info. With a credit card, even if you have a different payment processor with an icon next to it that says "secure", there's not actually any way for me to be sure at a glance that that isn't Stripe_Secure_Checkout_Confirmation.SVG and that you aren't just harvesting my credit card info, other than other contextual information on your website and your company's reputation as an actual company that does actual business in the real world.
> In Scandinavia there's also MobilePay, which is much much better, as it is also closely linked to real identities.
Don't forget vipps, I think it also works in Poland now in addition to various nordic countries.
And in Sweden we have Swish
Vipps and MobilePay merged, so it's the same product now. It's MobilePay in Denmark and Finland, and Vipps in Norway and Sweden... and apparently Poland.
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 merchanttechsupport@paypal.com — 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.
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.
There are many companies selling access to ”residential proxies”.
Wouldnt a "service fee" resolve this? A non refundable amount to even transact
I'm hot off fighting one of these bot nets. They automatically adapted and spread the calls over a ridiculous number of IPs and all had good JA4 fingerprints at Cloudflare (compromised or nurtured "users"). Gave us nothing to block. We started targeting high count JA4s and blocking those temporarily. This would usually cause them to stop automatically.
Very sophisticated LLM-enabled rented mafia bot net. They crafted attacks of various approaches as we turned up the heat.
In the end we refactored our entire authentication flow. We had a lot of Anon endpoints and ones that would validate card numbers etc from past misguided product and management decisions.
In the end we had to block a lot of legitimate traffic at times.
Reducing friction for users reduces friction for scaled bot attacks.
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.
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.
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.
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.
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.
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.
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).
Accept payments from verified accounts only. That's like PayPal 101.
Why not block those 2 domains from signing up ?
They're popular enough that we'd penalize a substantial number of users.
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.
Let me guess, protonmail and tutanota?
Google Mail is also a very popular source of spam these days...
Could you add some additional check if that domain is used? (Possibly with browser fingerprinting, or other req fingerprinting)
Possibly something even that just wastes a little time and makes them know you're aware of the behaviour.
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.
Thanks, Nate. What's the best way to reach you?
You can reach me at nate@specprotected.com - happy to be helpful
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.
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.
Do western services ever offer two payment gateway options to the customer? Its common in India.
Yes. I buy things all the time from smaller vendors that support PayPal, Amazon Pay, maybe google/apple, as well as a direct credit card entry. Actually, even many large vendors offer a selection of payment options; I pay Walmart and I think BestBuy with PayPal because it's got my card saved and I don't want to get up and grab my wallet. PayPal has big issues if you're a small seller, but as a purchaser it's convenient.
I don't think I've seen vendors offer a choice of two different merchant accounts, but some do have multiple merchant accounts and select one or the other at time of billing; sometimes you can tell because it shows up a little different on the bill depending on the path, or more often because they send an announcement about trouble with billing and mention that it only affects some customers because they have two accounts.
Get in touch with me - ex PayPal fraud alum and can give you advice or get in touch with folks for you. Arthi@pinch.ai.
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)
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.
Or just a solver API like 2captcha.
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.
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.
I did the same thing with geo IP blocks + blocks of non-consumer IP ranges. I don't completely block the transaction - I just send them into a different workflow where we manually call them to run the transaction. This works fine for legitimate customers.
That bit about calling / contacting them is a great idea. We just blocked them!
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.
How big are you? When I was pushing $100K/mo through PayPal they gave me a personal account manager I could call anytime to resolve stuff like this.
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.
What's the best alternative?
It's easy to say "don't use PayPal" but if you're going to say it, you need to do the hard part of suggesting a viable alternative for eCommerce that has as broad a reach and acceptance as PayPal. Stripe? Almost none of the outlets I do business with use it. Venmo? Same company as PayPal. Back to using credit card numbers? The more we spread those around online, the higher the chance they get stolen and used, probably in refund scams like the one OP describes.
People need an alternative with some degree of trust and most consumers, by my reckoning anyway, would prefer a single entity that is accepted everywhere. Right now, that's unfortunately PayPal.
Personally I've had way less issues with stripe, especially in terms of fraud detection.
Also not sure what and where business is but in Europe it's common to just use a proxy provider where credit card is just one of many options and you use a central gateway (similar to stripe)
You'd have to check your local options. At least one of my local banks offers something more advanced than PayPal. And there are several of these proxy providers in my country.
Edit:// if you just want low fee, fast and risk free transactions we all know there is only crypto
Yeah. It’s ridiculous how crypto gets so much hate here, yet there are constant, often heart wrenching posts about the failures and even near-malfeasance of payment processing systems. The paradoxical claims that crypto has no use case except fraud and crime, juxtaposed with the lamentation and gnashing of teeth over the misery of traditional payment systems is enough to provoke an existential examination of the senses.
I honestly think it must be mostly sour grapes, since by far, cash and other traditional payment methods facilitate the vast, vast majority of crime and fraud, and cryptocurrency is the only universally accessible, trustless, (nearly) costless, instant, global system for the transfer of value between two parties.
It is by far a better system, even with its flaws. Which is why, yes, many criminals use it, just as they use cash. Because it works.
I am also amazed by the resistance to change here as there is a system clearly more efficient and transparent. It's just a matter of time in my opinion. BTW you can remove the (nearly) in "(nearly) costless", some solutions provide 0 fees and no inflation.
By more efficient you mean taking hours to settle? And no inflation as in Bitcoin level volatility and up?
I'd love an efficient and cheap option to move funds online - especially for micro payments too. But so far I haven't heard of any crypto option that actually stayed around long enough to prove these things.
Happy to be pointed in the right direction here.
Stablecoins on any number of low cost networks are fine for small payments (I haven’t lost anything, not even $0.01 in 10+years, vs tens of thousands in chargebacks, mostly fraudulent, for credit card processors).
I factor in 2.5% total costs for transaction frictions, historically that is a bit over 3x our actual average cost from payer to bank account, but it would easily cover the occasional loss of a day or two of sales in a catastrophe.
Pick a top 5 stablecoin that has a good reputation and at least 3 years, on a network with at least that, and settle your accounts daily, or whenever the accumulation represents a significant dent if lost.
The approximate aggregate risk-cost of major (top 10) stablecoins is somewhere south of .001% per day, and is better than the aggregate risk-cost of national fiat currencies, which unremarkably collapse or suffer catastrophic inflation and rebasing on a regular basis. There are frequently several undergoing this process at any given time.
> The approximate aggregate risk-cost of major (top 10) stablecoins is somewhere south of .001% per day, and is better than the aggregate risk-cost of national fiat currencies
This thinking is dangerous and stupid. Learn from history: https://en.m.wikipedia.org/wiki/Black_Wednesday
This "stablecoin" garbage needs to die yesterday: a lot of people are going to lose their shirt when the first one blows up. Fixing exchange rates is folly, yet here we go again...
Why would I care if a stablecoin blows up? My payment cost allocation more than compensates for that possibility and my losses in a worst case scenario would be eclipsed to oblivion by the cost savings I have already realized.
> my losses in a worst case scenario would be eclipsed to oblivion by the cost savings I have already realized.
Please elaborate :)
My theoretical potential losses compared to the costs of the payment processsors I ditched, and the chargebacks we used to deal with.
International payment processing is quite expensive, both on a teansaction and on an administrative basis.
My worst case total risk exposure is approximately the same as the cost of 3 months of payment processing overhead, without counting fraudulent chargebacks and “we are going to freeze your account because we can” risks.
FWIW in the last 60 years I have lost way more money to fraud and theft dealing with banks and cash then I ever will using cryptocurrency. On a total, or a percentage basis. I see the risk profile, when properly managed, to be much, much lower using blockchain solutions.
> My worst case total risk exposure is approximately the same as the cost of 3 months of payment processing
Okay, yes: what you're describing is the actual utility of these things.
I think you underestimate how many people dealing in them are using them much less intelligently than you are.
They are being marketed in an extremely dishonest way, as a safe long term store of value. I regularly overhear normal people at my local bars talking about how they're "investing big in stablecoins" and it terrifies me.
>>This "government issued fiat currency" garbage needs to die yesterday: a lot of people are going to lose their shirt when the first one blows up.
What you are saying is a risk endemic to all fiat currencies, including stablecoins.
All symbolically represented forms of value quantization are subject to a failure of confidence. Cryptocurrencies are nothing new in this regard. All money is memetic in nature.
That's like saying "base jumping isn't really more dangerous than flying commercial, after all we're all going to die anyway".
Fiat currencies have militaries. Your stablecoin doesn't.
That’s one of the reason the stablecoins won’t be taking my assets? Idk what your point is but it doesn’t seem like you are debating from a point of rational examination.
Weird, people on the internet spewing BS? Who’d have thought?
Well, losing three months of revenue is going to really hurt when the stablecoin inevitably eats shit: hope you're prepared for that.
The risk is obviously lower because you aren't parking money there. I could certainly see how you might come out ahead in fees for certain international transactions.
But your original claim was that the aggregate risk-cost of dealing in stablecoins is lower than real currencies, and that is absolutely preposterous: you aren't accounting for all the risks.
Nobody claims that crypto doesn't have a use case. They claim that it has failed at its use case. You can't use it to buy things easily or safely. Buying a bunch of crypto on the internet and looking at a graph every day hoping the line goes up isn't useful.
Its use case is still fraud and crime: when laundering money or fencing stolen goods, you expect the process to be difficult, dangerous and to have to pay a large fee. Crypto is a clear improvement on older criminal methods. It's not an improvement on credit cards.
Plenty of digital places accepting crypto like Namecheap, Vultr, ..,
Plenty of companies where you can sell and receive whatever currency you prefer. More or less instantly in case of some. Yes also to my EUR/CHF bank account. For Switzerland that's $1000 per day (per service) without any deep verification.
Some banks even offering "instant transfer" where you get a debit card and just pay with the crypto on your account. Swissquote to name one with all proper banking requirements and barely any fees.
Also from the point of a seller that has seen many kind of weird disputed and scams I am happy to not have any of these issues with crypto. This is an very obvious improvement over credit cards.
Not saying the world is fine, but blaming crypto (the most transparent payment method ever) is way to simple and far from our financial reality
Idk, my experience is that it works fine.
Even to the point that the cost of maintaining other payment systems was less cost effective than just dropping them and focusing on crypto only. FWIW we are not a “crypto” business, our focus is kinodynamics.
Our market is global and we are small from a payment perspective in this context, so our case may be a bit of an outlier, but our lived experience does directly contradict your claim.
I agree that speculation and crime is a problem, but the speculation market in global commerce and currency dwarfs crypto, así does the criminal usage of cash, so it’s disingenuously myopic to frame those as a crypto-centric issue.
The relative difficulties of regulation because of the decentralized nature of crypto does make it a hotbed for schemes that wouldn’t be practical under local regulations, but I have a hard time getting riled up about that when we have giant state sponsored gambling industries nearly worldwide.
If you were to compare the impact on criminal activity if you eliminated cash vs eliminating crypto, I think it’s easy to see that eliminating cash would be much more detrimental to criminal activity.
In all, the arguments being made are not at all based on a rational examination of verifiable ground truths. They are almost to a fault emotionally based arguments with a near hysterical pitch woven into them from the start.
It seems like some people fear crypto. I don’t know why, but they do. On some level, they fear the threat it poses to the devil they know, perhaps. Maybe that is why they react the way they do.
What's wrong with Trustly, Adyen and others among the ~40 alternatives we maintained integrations with at the casino operator I was working at almost ten years ago?
Haven't heard of them at all, that's what's wrong.
They may be great services, of course, being that I, a single consumer, am not a barometer for the success of a payment platform. But whoever they are, they're not being used by major retailers, distributors or manufacturers that I shop with both personally and professionally.
Adyen are everywhere for in-person payments where I live (Ireland).
Worldpay/Stripe seem to be the most common providers for ecommerce.
More generally, payments are painful so finding a good provider is very, very important.
IIRC Ebay uses Adyen. I think Paypal uses Trustly in some significant markets.
I don't know why they didn't show up early in your research, as they are among the most well known and easy to find. Ingrid is lesser known and mostly active in e-commerce in the european markets.
> Wait until they ban your account
Ban your account and prevent you from accessing any funds in that account.
I don't think you can manage payments between multiple users with most card processors?
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?
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.
Try running some of the IPs through a proxy detection API like https://ipinfo.io/products/proxy-vpn-detection-api or https://proxycheck.io/
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.
If the ips all belong to a single AS you could look at blocking just that traffic, or make a complaint to the AS.
You could also gather geolocation data from the ips and block commonalities.
What do the IP addresses belong to? As in, are they data center IPs, or residential addresses?
Consider blocking all of Tor IPs, known data center ranges and the likes.
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'`.
Yep or consider just blocking AS numbers of places people typically aren’t purchasing things from such as cheap VPS companies.
The user agents, can you post those?
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.
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 can promise you that's not a better solution. I witnessed a card testers smarter than Stripe tech and Stripe shutting down account that had literally 0% chargeback ratio and doing over $10MM in sales monthly. Still to them that was peanuts. They will help you initially and customer support is pretty fast at figuring things out, but in no shape of form will they say "gee, we see you are not the bad guy and someone else is doing that so your account is good to continue abusing our merchant accounts". They. Will. Shut. You. Down. Because they care about their rates of CB more than about your business. Just 2c, based on experience.
Agreed, but having dealth with both Paypal and Stripe in situations like this, I'd take Stripe over Paypal in a heartbeat. Paypal are some of the most evil bastards I've ever had the displeasure of "working" with.
This. Stripe is too big.
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
You are supposed to get a different ID in incognito.
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.
In a perfect world with a fair market, yes they should consider entering and competing given they could probably do better. This isn't either.
One doesn't simply walk into mordor.
To enter this market, it requires that you first receive a national bank charter.
Post 2008 crisis, the laws have changed to eliminate competition from any new champion. There were many new requirements that can never be met over the long haul, and act as a ticking timebomb until it fails (through no fault of the person/group trying to start a bank.
At last read, the one that stuck out to me was it required a board of directors who could not receive payment or incentive related to the position, and where they would be personally liable for the majority of decision of the board.
No financial incentive, all the liability, and the decision is unmanageable in other people's hands. No one with a right mind will do that.
There's also the reasonability tests for success that need to be granted by the state or OCC as well. I hear these change all the time, and with the level of deficit spending these days and other fed shennanigan's its hard to find a reasonable person that will say any new contender will have a chance against a long-term state/fed fund/granted monopoly.
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.
Yep, and don't forget they will lock up any funds during that period, so I recommend you transfer them to your bank early and often. Money in your Paypal account is not your money.
Is that still going on? I remember this killing businesses left and right early on (early 2000s).
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.
Unfortunately this won't help much.
Each transaction will be unique, with a different device, different ASN, and different IP. If you find my post above, it links to an article which explains the whatfor and how this is going on.