Ask HN: Startup getting spammed with PayPal disputes, what should we do?
177 comments
·June 4, 2025patio11
(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.
Nicholas_C
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.
vdfs
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
alex_suzuki
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?
jffry
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
topak3000
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.
treebeard901
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.
jacob019
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.
ozmodiar
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.
colechristensen
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.
cookiengineer
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:
JamesAdir
Sorry for the noob question, but how can Docker help remediate the situation? I'm currently learning about DevOps.
danbreuer
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.
fugue88
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.
smnc
> - 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?
msgodel
Docker keeps well behaved programs well behaved. You can escape in one line of shell.
cookiengineer
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).
imglorp
> 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.
mjburgess
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.
guappa
There's already unix permissions and regular namespaces. Docker is very hard to secure.
calgoo
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.
ahoka
It can't. Also there's nothing inherently wrong with ssh password auth.
dmos62
You might want to back those statements up.
whyever
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.
m00x
This is not money laundering. Why would they dispute if it's ML?
baobabKoodaa
Please explain the money laundering part here?
miltava
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
addandsubtract
> 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?
pbronez
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.
KomoD
It wouldn't go to another account if you do a dispute, what are you talking about?
high_na_euv
>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?
trod1234
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-...
cookiengineer
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.
tyingq
You can configure your account to reject unverified buyers.
https://www.paypal.com/us/cshelp/article/what-are-payment-re...
bobbiechen
+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 .
_alternator_
Why is this not the top answer?
trollbridge
Some people want a high conversion rate, and before I flipped this on, something like ⅓ of my customers were unverified buyers.
azemetre
How many fraudulent charges did you deal with?
Foofoobar12345
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.
mrweasel
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.
trollbridge
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.
busterarm
> 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.
maxclark
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
iforgotpassword
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.
domoregood
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.
algo_trader
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
abxyz
Guaranteeing transactions would incentivize the provider to block transactions. There are many companies in the space, like sift.com, but they don’t guarantee.
halpow
> 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.
Foofoobar12345
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.
sky2224
What have you switched to that isn't PayPal and also doesn't have this issue?
A_D_E_P_T
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.
_QrE
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.
mrweasel
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.
BobaFloutist
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.
tyfon
> 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.
abxyz
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.
imdavidsantiago
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.
noodlesUK
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.
dabinat
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.
jpalomaki
There are many companies selling access to ”residential proxies”.
ikekkdcjkfke
Wouldnt a "service fee" resolve this? A non refundable amount to even transact
datavirtue
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.
Beijinger
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.
aga98mtl
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.
bzmrgonz
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.
trollbridge
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.
Longtime user posting from a new account out of an abundance of caution.
I founded an e-commerce marketplace startup. We use PayPal's Multiparty APIs (PayPal Commerce Platform) for checkout. For the 10 days, someone has been bombarding us with purchases that they later dispute. There's consistent pattern to it:
* They use an email address that has no footprint online, always from the same two domains * They use an unverified PayPal account to pay * They pay a low amount, not always the same, in a narrow range for a digital item * All of the charges were disputed within a few hours
They're not doing this through our API. The purchase process requires a browser because of the way our payment form is configured. There's an amount of variation to each purchase that tells us they're automating a browser. Logs indicate that they're changing IP each time. The events come in bursts and seem to be spaced to avoid automated detection.
We added the typical mitigations to our network stack and code. A few are still slipping through. Logs indicate a high amount of bot traffic.
PayPal does not seem equipped to deal with this. Their support is always extremely slow, relies on canned responses, and to date has a very limited understanding of how their own Multiparty APIs work. Their phone support people will not talk with me, they see no indication that my PayPal account is affiliated with these purchases in any way. They want each of our sellers to contact them independently, which we know will result in disparate cases that don't tell the complete story or offer any assistance.
Has anyone encountered anything like this before? We're struggling to find the motive or intended outcome by the attacker(s). We're a small company with a niche audience, we've never had a conflict with anyone that got serious enough that we'd expect them to come after us like this.
Any thoughts and recommendations would be greatly appreciated. We feel like we are on our own here and are unsure of how to handle it.