How GDPR Impacts Chargeback Handling in the EU
How GDPR impacts chargeback handling in the EU comes down to one fact. GDPR sets three conditions on using customer data to fight a chargeback, and it never bans the practice outright. At Chargeback.io, we've run alert data across EU merchant transactions every day.
This exact data question comes up at signup, before any dispute does:
- A lawful basis for using the data at all
- Only the data this dispute needs, and nothing more
- A deletion date once the data stops being useful
The second one traps the most merchants, because sending extra evidence feels like the safe move. Get all three right and compliance never slows a dispute response.
Key takeaways
- Use customer data in disputes when a lawful basis covers it
- Match every evidence field to the reason code being contested
- Redact unrelated fields instead of dropping useful documents
- Set retention to 540 days when delivery runs slow
- Fines reach 20 million euros or 4% of worldwide turnover
- Alert signup shares transaction identifiers, so it needs a lawful basis
How does GDPR affect chargeback handling?
GDPR limits which personal data you can put in a dispute response, asks for a lawful basis to use it, and caps how long you keep it. The rules cover how companies handle data on people in the EU.
GDPR fines reach 20 million euros or 4% of worldwide yearly turnover. Whichever figure is higher applies. Those caps are for serious, repeated breaches. One mishandled case file sits nowhere near them. The real exposure is a regulator asking how you decide what goes into every dispute response.
A dispute response is data processing, and that catches merchants out. You pull a billing address, an IP from checkout, a device ID, and the order history into a case file. That's personal data, used for a purpose, so every GDPR rule applies.
One misreading costs more than any of the rules. Some merchants strip customer data out of their responses to stay safe. They send thinner evidence and lose cases they should win. GDPR limits how you use the data while still expecting you to make your case.
What GDPR requires of a payment processor
Dispute work runs on one of two lawful bases, either performing the contract or your legitimate interest in stopping fraud. Contract performance covers the data you need to fill and service the sale.
Legitimate interest covers the data you use to catch or contest fraud. Recital 47 says processing "strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned."
Read that recital carefully, because it grants less than merchants assume. Recitals explain the regulation rather than binding like its articles. Fraud prevention gives you a strong argument instead of an exemption, and "strictly necessary" is the phrase doing the work.
If a regulator or a customer challenges you, you have to show the data was needed. Record the basis and the fields you used on each case file while you build it. A note written months later carries far less weight.
A customer's own rights can override legitimate interest.
Two of those rights bite during a live dispute. A customer can object to the processing, or ask you to erase their data. Neither request forces you to drop a case. GDPR lets you keep data you need to defend a legal claim, and a chargeback response qualifies.
Answer the request, then keep only the evidence the dispute needs.
What you can and can't include in compelling evidence
Checkout and fulfillment data is lawful to send because you collected it for the sale. Marketing profiles and broker data came from another purpose, so they are not. That first group covers what a dispute response is built from:
- Billing address entered at checkout and its match to the card
- IP address and device fingerprint captured during the order
- Delivery or download confirmation for the purchase
- Order and shipping history for the same customer
- Prior undisputed purchases on the same card
GDPR applies a purpose test here. Data you gathered to complete and secure a sale can defend that same sale later. A typical packet asks you to gather nothing new, so a compliant response and a strong one are usually the same file.
Enrichment is where merchants cross a real line. A marketing profile, a data broker append, or ad-targeting scores all came from a different purpose. The sale's lawful basis won't cover that material, and pulling it in needs a fresh basis.
Reaching for extra evidence is exactly when it happens.
How much customer data is too much for one dispute?
Include a field only when it answers the point the cardholder is contesting, because GDPR asks for the minimum that settles the claim. The reason code tells you what that point is, and it changes what counts as necessary.
A customer who says the order never arrived makes delivery evidence relevant. Send tracking, carrier confirmation, and the delivery address.
A customer who says they never authorized the purchase shifts the question to identity. Send the IP, the device fingerprint, and the AVS and CVV results instead. Send the delivery packet on a fraud claim and you add personal data without answering what was asked.
Over-sending usually looks like one of three habits:
- Attaching a full account export when one transaction is disputed
- Including a complete order history rather than the relevant prior orders
- Forwarding entire support threads that cover unrelated issues
Redaction resolves the tension between sending too much and sending too little. You can submit a document with the unrelated fields masked, which keeps the evidence intact. Black out other customers' details on a shared shipping manifest, and mask unrelated line items on an invoice.
Network templates sometimes ask for a field you consider disproportionate. Supply the narrower evidence that answers the same question, and note why in the response. An issuer weighs whether your evidence rebuts the claim rather than whether you filled every box.
How long you can keep dispute records
GDPR tells you to delete data once it stops being useful. A dispute can arrive long after the sale, so retention has to cover the whole filing period. Those two rules only clash if you read "necessary" too narrowly. Article 5(1)(e) says data may be kept "no longer than is necessary" for its purpose.
Name the purpose accurately and the clash mostly goes away. A sale record exists to defend that sale for as long as someone can dispute it. Read that way, retention follows the network rules.
Visa's longest filing window reaches 540 days on late-delivery disputes. There the clock runs 120 days from the expected delivery date. Most disputes use the shorter 120-day window from the sale itself, so what you sell decides which figure applies:
Set your window from that table, then record which network rule you based it on. Article 5(2) says you must "be able to demonstrate compliance". In practice that means a schedule naming the data type, the window, and the rule behind it.
Filing windows shift by dispute type, which our chargeback filing time limits breakdown maps out.
Where retention policies actually break
Systems enforce retention, and a written policy changes nothing until the settings match it. The deletion clock usually sits in three places at once. Check your payment processor, your order-management system, and your CRM.
A 540-day policy fails the moment one of them still runs a 12-month default.
Say a customer disputes an order 14 months after it shipped. A policy that wiped the evidence at 12 months leaves you no delivery proof and no IP match. That evidence is gone for good, and no processor can reissue it.
One more option closes the gap. Deleting the customer record and keeping the evidence bundle are separate actions. Strip the full profile and keep the fields a dispute needs. You meet the storage limit and can still answer.
Does GDPR change how you share data with an alert provider?
Signing up for a chargeback alert service is itself data processing, because you send personal data to a third party. GDPR counts that as processing however little you share. Signup runs on a short list of identifiers, so providers need the billing descriptor, the BIN, and either the CAID or ARNs.
The lawful basis works the same way it does for evidence. You're reusing sale data to protect the sale it came from, so signup needs no separate consent flow.
You stay the data controller here, because you decide why the data is used. The provider follows your instructions, which makes it your processor and puts the relationship inside Article 28.
Ethoca and Verifi run the alert networks for Mastercard and Visa. Ethoca chargeback alerts cover the Mastercard side.
Verifi covers Visa through RDR and CDRN, which differ in how the dispute gets resolved.
The basis covers matching identifiers only. Sending a provider more than the matching needs takes its own lawful basis and a processing agreement.
Our alerts run on exactly that identifier set, so you can compare alert coverage without handing over anything more.
What to check in a provider agreement
Ask what a provider takes in before you sign up, because the answer should be a short list of identifiers. Then read their processing agreement for the Article 28 terms:
- What the processing is for and how long it runs
- That they act only on your written instructions
- That their staff are bound to confidentiality
- How they appoint and vet sub-processors
- Whether your data is deleted or returned when you leave
That last term matters most, because the identifiers you shared should not outlive the contract. Providers built for this market hand you a signed agreement at signup. Treat a missing one as a warning about the rest of their data handling.
Sorting the data question early frees you to fix the upstream causes. Getting chargeback prevention right does more for your dispute rate than winning any single case.
The same goes for PCI DSS compliance, which governs how you store the card data these disputes run on.
FAQ
Does GDPR apply to US merchants selling to the EU?
Yes. GDPR follows whose data you handle rather than where you are based, so EU customers bring you into scope.
Do these rules cover my UK sales too?
Yes, under a separate regime. The UK copied GDPR into its own law as the UK GDPR, and the duties stay much the same.
Can I get deleted evidence back from my processor?
Rarely, and never in full. Processors keep sale records on their own schedules, but delivery proof and device data sit in your systems and go for good.
