Representment
Representment is the process by which a merchant contests a chargeback by re-presenting the transaction to the issuer with evidence that the charge was legitimate.
When a cardholder disputes a charge and the issuing bank files a chargeback, the merchant’s money is pulled back provisionally. Representment is the merchant’s rebuttal: the transaction is literally “re-presented” to the issuer, this time accompanied by an evidence package arguing the charge was valid, and the issuer decides who keeps the money.
Winning representments is mostly a records problem. The evidence that persuades issuers is specific: the authorization record with its approval code, AVS and CVV match results, 3-D Secure authentication outcome, proof of delivery or service, the customer’s signature or device data, refund policy disclosure, and any prior undisputed purchases from the same cardholder. Each card network prescribes its own format, deadlines run short (often 20–45 days depending on network and stage), and a package that misses the format or the deadline loses by default regardless of the merits.
That’s why the practical question when evaluating dispute tooling is where the evidence lives. If the dispute system and the processing system are separate, someone reassembles the case by hand from exports. When they share a ledger, the case file largely builds itself: the authorization data, verification results, and customer history are already attached to the disputed transaction.
Representment also isn’t always the right move: below a certain amount, the chargeback fee plus the labor exceeds the recovery, which is why mature programs pair representment with pre-dispute resolution and set thresholds for when to fight, refund, or accept. QorCommerce Disputes handles both paths: auto-resolution through Verifi and Ethoca, and representment packages assembled from the platform ledger, drafted as a managed service for merchants who want chargebacks handled entirely.
In the docs: Responding to disputes ↗