Almost everything written about PayPal chargebacks assumes you ship boxes. Keep tracking numbers, ship only to the confirmed address, let Seller Protection absorb the rest. If you sell software, a subscription, a download, or an API key, none of that applies to you, and the parts of PayPal's policy that do apply are narrower than the marketing copy suggests.
This is the map for the intangible seller: which of PayPal's three escalation paths you are on, what each costs, what Seller Protection does for something that never had a tracking number, what evidence an issuer reads, and why the buyer who just cost you $35 will probably try again next month under a different email.
PayPal dispute vs chargeback: find out which one you have
PayPal splits what a card network treats as one process into three, and the subject line of the email tells you which one landed.
A dispute is opened by the buyer in PayPal's Resolution Center. PayPal's developer documentation gives the buyer 180 days from the payment date to open one, and gives the two of you 20 days to sort it out between yourselves. Nobody at PayPal is deciding anything yet. Money is held, no fee has been charged, and a refund at this stage closes the case.
A claim is a dispute that either side escalated. Now PayPal is the decision-maker, applying its own Purchase Protection rules. PayPal's own explainer says you have 10 days to respond or the claim closes in the buyer's favour, and a typical claim resolves in about 30 days.
A chargeback never touches the Resolution Center on the way in. The buyer called their card issuer, the issuer filed under Visa or Mastercard rules, and PayPal, as the merchant of record for that card transaction, is relaying it to you. PayPal states plainly that the decision is made by the card issuer and PayPal does not decide the outcome. The same page puts the timeline at roughly 30 days for PayPal to contest and up to 75 days for the issuer's final answer.
A fourth path, the bank reversal, is what you see when the buyer paid from a linked bank account and their bank pulled the money back. It behaves like a chargeback with even less recourse.
The distinction matters because you are writing for a different reader in each case. A claim is read by a PayPal agent who can see the buyer's account history. A chargeback is read by an issuer analyst who has never heard of your product and is checking your evidence against a reason code. Write the same response to both and one of them will fail.
What a PayPal chargeback fee costs even when you win
There are two fees with different names, and they apply to different payment types.
For payments made through a buyer's PayPal account or PayPal guest checkout, PayPal charges a Dispute Fee when the buyer files a claim, a card chargeback, or a bank reversal. The US merchant fees page lists the Standard Dispute Fee at $15.00 and the High Volume Dispute Fee at $30.00. You land in the high-volume tier when, per PayPal's help article, your dispute rate is 1.5% or more and you had more than 100 sales transactions in the previous three full months. That rate counts only item-not-received and not-as-described claims, so a wave of unauthorized-transaction chargebacks will not push you into the tier by itself.
For card payments that did not go through a PayPal account or guest checkout, meaning you use PayPal as a direct card processor, the same page lists a separate Chargeback Fee of $20.00.
The waivers are narrower than they look. PayPal's dispute-rate article says that if you appeal and win, the disputed amount and the Standard Dispute Fee are reimbursed, but the High Volume fee is not, because it is priced off your rate rather than the case. The Standard fee is also not charged for disputes resolved before escalation, for claims under twice the fee amount, for unauthorized-transaction reports filed directly with PayPal, and for transactions PayPal judges eligible under Seller Protection. Missing from that list: an unauthorized-transaction chargeback filed with the issuer, on a sale that is not Seller Protection eligible, that you lose. That is the most common shape for a software seller.
On the Hacker News thread about a $10 SaaS payment that cost its owner $43.95, skwee357 summed up the experience across processors: "The first thing I learned, you pay the chargeback fee no matter what." On PayPal that is slightly too pessimistic for the Standard fee and exactly right for the High Volume one.
Seller Protection for things that don't ship
Seller Protection covers two claim types: Unauthorized Transaction and Item Not Received. That is the whole list. PayPal's chargeback help page says that if a transaction qualifies, PayPal covers the chargeback amount and waives the fee, which is the outcome every seller wants and the reason so many assume they are covered.
Significantly Not As Described is not covered, under any circumstances, for any product type. For a digital seller this is the exclusion that matters, because "the software didn't work" and "I didn't get what I paid for" are both filed as not-as-described. The only path through a SNAD claim is to win it on evidence.
For intangible goods, the Seller Protection Program terms add two conditions. First, PayPal must have marked the specific transaction as eligible on the Transaction Details page, or told you in writing that your category is eligible. If the word "Eligible" does not appear on that transaction, you are not covered, no matter what you sold or how well you documented it. Check this before you spend an afternoon assembling evidence.
Second, you need proof of delivery, and PayPal defines it differently for things that were never in a box. Its help article says that for intangibles, compelling evidence includes a system of record showing the date the item was sent and that it was either electronically sent to the recipient, including the recipient's address such as email or IP, or received or accessed by the recipient. Read that as a spec for your database. For every order you need the provisioning timestamp, the email it went to, the IP that first logged in, and the first access to the paid feature.
Most small software businesses log the payment and nothing else. That is the gap.
Evidence that moves an issuer
A PayPal claim and a card chargeback want different things from you, because different people are reading.
For a claim, the PayPal agent already has the buyer's account history, login IPs, and device. Your job is to connect your delivery record to that account: the payer email, the transaction ID, the timestamp you provisioned access, and your own record of the buyer using the product afterward. Keep it to what PayPal can cross-check against its own data.
For a chargeback, the issuer analyst has the cardholder's statement and your submission, and that is all. PayPal's Braintree documentation, which uses the card networks' evidence categories, lists what counts for digital goods: proof of digital goods downloaded from your website or app, the user's IP address, the customer's username, and service usage times and dates. Lead with usage that post-dates the purchase. The cardholder's claim is that they never authorized it, and continued use of the paid feature from the same device is the closest you will get to contradicting that.
Be honest with yourself about what a login log proves. On the same thread, jasonlotito put the issuer's view bluntly: "You need evidence that the card holder authorized the payment. I promise you, nothing you submitted proves that." If the account was created with a stolen PayPal login, the usage you are showing belongs to the thief, and the issuer will read it that way. Usage evidence wins friendly-fraud cases, where the real cardholder used the product and later claimed they didn't. It rarely wins stolen-credential cases, so decide which one you are looking at before you respond.
Leave out anything that is not a fact about this transaction. Your terms of service, your refund policy, and a paragraph about how unfair chargebacks are do not move an analyst working through a queue. A screenshot of a single database row with a timestamp does.
Why refunding after the case is opened doesn't help
The most repeated advice on every forum is to refund the moment you see a case. It is correct for exactly one of the three paths and harmful for the other two.
During the dispute stage, a refund resolves the case, and disputes resolved directly between buyer and seller and not escalated to a claim carry no fee. If you were going to refund anyway, do it here, before the buyer escalates.
Once a claim is open, PayPal is adjudicating and the fee is assessed unless you win. Once a chargeback is open, the issuer has already debited PayPal and PayPal has already debited you. A refund at that point is a second, separate movement of money. Braintree's documentation says it without hedging: you could lose double the amount of the original transaction if you refund a transaction that is also charged back. The refund cannot be reversed, and the chargeback continues on its own track.
So: refund before a case exists or during the dispute stage, never after a claim or chargeback is filed. If you already refunded and a chargeback arrives anyway, submit the refund record as your evidence. It is the one situation where a refund helps you win rather than doubling your loss.
The repeat offender behind most of your chargebacks
Tally a year of PayPal cases for a software product and they do not spread evenly across your customers. They cluster into two kinds of buyer.
The first pays with a stolen PayPal account. Someone else's credentials, someone else's linked card, a purchase that looks ordinary until the real owner sees the statement and files an unauthorized-transaction claim. You cannot win these on usage evidence, because the usage is the thief's. Your only defence is Seller Protection eligibility, which for intangibles means the transaction was marked eligible and you logged delivery properly. If either is missing, you eat the sale and often the fee.
The second is the friendly fraudster: a real person, their own account, who used the product and then told their issuer they didn't recognise the charge. These are winnable, but they are also the ones who come back. They know a not-as-described claim on a $12 subscription is rarely fought, and they know a new email address gets them a fresh account. The chargeback fraud post covers why a buyer with one successful dispute behind them is your highest-risk customer for the next one.
On the same Hacker News thread, evermike described what most sellers can do after the fact: "As a merchant, in theory you can block that customer from making future payments. But probably only their specific card or email." That is the whole problem. On a PayPal wallet payment you usually do not see a card at all, and the email is the cheapest identity on earth to replace.
How to prevent PayPal chargebacks at signup and checkout
The Resolution Center is the wrong place to reduce PayPal chargebacks, because by the time a case exists the cost is mostly sunk. The fee is assessed, the hours are spent, and the buyer has confirmed that it worked. The leverage is earlier, at the two moments where you decide whether to accept this person at all.
Start by fixing the logging gap from the Seller Protection section, since it is free and it is the precondition for everything else. Every provisioned order should have a row you can hand to an analyst: PayPal transaction ID, payer email, the account it was applied to, the timestamp, and the IP and device of the first paid-feature use.
Then link the loss back to the account that produced it, and to every other account that shares something with it. A chargeback is a confirmed label on a specific email, a specific device, and often a specific phone number, and any new signup that shares one of those keys is the same buyer. With PayPal wallet payments you rarely have a card fingerprint to match on, so the device fingerprint and the email do the work. A returning offender changes their email every time and their browser almost never.
Velocity per device matters more than velocity per IP here. Shared egress, VPNs, and mobile carriers make per-IP counts noisy enough that acting on them alone produces false positives. Three signups from one device in a day is worth acting on regardless of what IP they came from.
This is what Portreeve does for this problem. One call at signup or checkout_attempt returns allow, review, or block in under 100 ms, and the identity graph links accounts across hashed email, device fingerprint, and phone, so a buyer who charged you back last month and returns under a new email is already attached to the cluster you convicted. When a PayPal case lands, you report a chargeback outcome on the original event through the Feedback API and the loss teaches the graph. review never blocks the buyer, so you can flag aggressively and reserve block for the cluster you have already lost money to. The handling verdicts reference covers wiring a review queue so a flagged signup proceeds while you look, and the device fingerprinting guide explains what a browser token can and cannot tell you.
"Just stop accepting PayPal" is the other common advice, and it fails for the same reason "refund instantly" does. The buyer with a stolen PayPal account also has a stolen card, and the friendly fraudster who disputed a PayPal charge will dispute a Stripe charge with the same issuer. Dropping a payment method changes which fee schedule you read. It does not change who is on the other side of the checkout form.
If you want to try this on your own signup and checkout flow, the free tier screens 1,000 events a month with no card required. Create an account and send your first verdict in test mode before anything touches live traffic.