(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.