Every payments team in this industry knows the shape of it. A deposit lands, the client trades, the balance goes to zero, and six weeks later the acquirer forwards a dispute. The cardholder is the real cardholder. The device is the same device. The claim is that the transaction was unauthorised, or that the service was never provided.
The card networks call this first party misuse. Everyone else calls it friendly fraud, which is a poor name for something that costs the merchant the deposit, a dispute fee and a mark against a ratio that can eventually end the merchant account. It is separate from criminal card fraud and it needs a different defence.
The pattern behind the reason code
Disputes arrive under a reason code, and the code tells you which argument the issuer has accepted. Two families matter here. The fraud family says the cardholder did not authorise the transaction. The service family says the cardholder authorised it but did not receive what was promised, or the merchant refused a refund that was due.
In trading, the service codes are the harder ones. A client who says "I never got what I paid for" is describing an intangible product that has no tracking number and no delivery signature. The general mechanics of the dispute cycle are covered in chargebacks explained. What is specific to this sector is the motive: the dispute almost always follows a loss, which means the timing sits at the end of the account life rather than at the start.
A subset is not malicious at all. A shared card in a household, an unrecognised billing descriptor, a client who genuinely forgot a deposit made under a different brand name. Those cases are solved by information rather than by argument, and they are the cheapest ones to prevent.
Why an intangible service is hard to defend
Physical merchants win representments with a courier record. A trading firm has no equivalent, so the evidence has to be assembled from the account itself. The good news is that a trading account produces more usable evidence than almost any other online product, provided the system was built to keep it.
What the issuer will accept, broadly: proof the cardholder is the account holder, proof the terms were accepted at a specific time, proof the funds were credited and used, and proof the client was in contact after the deposit. A login trail with IP addresses and device fingerprints, a timestamped acceptance of the client agreement, the identity documents collected during onboarding, the full trade history and any support conversation. Screenshots are weak. Exported logs with timestamps are strong.
Evidence that does not exist at the time of the deposit cannot be created later. The representment pack is decided by the design of your onboarding and logging, not by how well the compliance officer writes. If your platform does not store authentication timestamps and IP history, you will lose cases you should win.
What actually stops a dispute before it starts
Three interventions do most of the work, and none of them are clever.
The billing descriptor is first. If the client sees an unfamiliar entity name and a foreign city on a statement, the odds of a "do not recognise" call rise sharply. The descriptor should carry a recognisable brand name and, where the field allows, a support contact. Second is the confirmation email, sent within seconds, naming the amount, the currency, the exact descriptor that will appear and the way to reach support. Third is 3D Secure, which produces an authentication record and, for the fraud reason codes, shifts liability to the issuer. It does nothing for the service codes, so treat it as narrowing the surface rather than closing it.
After those, the highest value change is usually operational: answer withdrawal requests faster. A large share of service-code disputes are filed by clients who asked for their money, waited, got a template reply and went to the bank instead. That is a queue problem dressed up as a fraud problem. The same logic runs through payment fraud prevention generally, where response time is a control in its own right.
Building the representment pack
Assemble it as a fixed template so nobody improvises under a deadline. Cover letter stating the facts in plain language and naming the reason code being answered. Transaction record with authorisation and authentication data. Identity verification result and the document reference. Timestamped acceptance of terms, with the version of the terms that was live that day. Account activity from credit to the disputed period. Support correspondence. Refund policy as published on the site on the transaction date.
Write the cover letter for a person with two minutes and no context. The winning argument is normally one sentence: this cardholder authenticated on this date, accepted these terms, used the balance in this way, and contacted us here. Everything else is exhibits. The refund policy you published matters more than the one you intended, so check that the archived version says what you think it says.
When to fight, and when to pay and move on
Not every case is worth defending. Representment costs staff time and a fee win or lose. Where the evidence is thin, the faster resolution is a refund, because dispute ratios are measured against thresholds and an account that crosses them can end up in a monitoring programme with additional costs, or in the market for a new high risk merchant account, which is a materially worse commercial position than the deposit you were arguing about.
Run it as a portfolio. Track win rate by reason code and by processor, and defend the categories where you actually win. Refund the rest early, before the case escalates. Firms that do this well end up with a smaller dispute count and a higher win rate at the same time, because the population they fight is the population where the record supports them.
"Most disputes we see are not people trying to steal. They are people who lost money, got a slow reply from support, and found a faster button at their bank. Fix the reply time and half the problem goes away."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Friendly fraud is a dispute filed by the genuine cardholder against a transaction they authorised, usually after the trading balance is gone.
- Strong customer authentication answers the fraud reason codes but leaves the service codes untouched, so it is a partial defence only.
- A representment is won by evidence captured at signup and deposit time: identity results, terms acceptance timestamps, login trails and trade history.
- Clear billing descriptors, instant confirmation emails and fast withdrawal handling prevent more disputes than any argument written afterwards.
Frequently Asked Questions
What is friendly fraud in a trading context?
It is a card dispute raised by the genuine cardholder against a transaction they actually authorised. In trading it usually follows a loss: the client funded an account, traded the balance away, and then told their bank the payment was unauthorised or the service was never delivered. The card was not stolen and the transaction was not fraudulent, which is why the industry also calls it first party misuse.
Does 3D Secure stop friendly fraud?
It stops most of the unauthorised category by shifting liability for that reason code to the issuer, and it produces an authentication record that is hard to argue with. It does not stop disputes filed under service related reason codes, because those do not claim the cardholder was absent. Strong authentication narrows the attack surface rather than closing it.
Is it worth fighting every dispute?
No. Representment costs staff time and a fee whether you win or lose, and some cases are unwinnable because the evidence was never collected. The practical rule is to defend where you hold authentication data, a signed agreement and platform activity logs, and to refund quickly where you do not, since disputes count towards ratio thresholds that can put an entire merchant account at risk.