When a retailer cannot prove authorisation, the dispute shifts in the customer’s favour and the merchant loses leverage in representment. The organisation may still have a legitimate sale, but without evidence of verified identity, card association, and live authentication, it cannot reliably refute an unauthorized transaction or stolen card claim. That leaves the claim exposed to reversal.
Why proof of authorisation decides the dispute
Card disputes are not resolved by the merchant’s belief that a sale was genuine. They are resolved by whether the retailer can produce persuasive evidence that the person presenting the card or payment method was entitled to do so, and that the transaction was authenticated in a way the card scheme recognises. Without that record, the merchant’s position weakens quickly.
The practical issue is evidentiary, not commercial. A retailer may have delivered goods or services in good faith, but if it cannot show cardholder verification, risk signals, and transaction authentication evidence, it has little basis to challenge a claim that the payment was unauthorized.
That is why cardholder verification, transaction authentication, and auditability matter as a control set, not as optional extras. The record has to be strong enough to survive representment, because a “valid sale” that cannot be proven usually behaves like a lost dispute.
What merchants usually have to prove
In practice, the strongest defence is a chain of evidence that ties the transaction to the cardholder or an authorised payment action. That may include the authentication step used at checkout, the card association rules that applied, order and delivery evidence, device or session evidence, and any logs showing the payment was accepted under the expected workflow.
If the retailer only has a receipt but no trustworthy authentication trail, the dispute is harder to defend. If it can show that the transaction followed the required authorisation path, the merchant has a materially better chance of keeping the sale. The point is not that every payment needs the same proof, but that the proof must match the claim being contested.
A useful way to think about this is to retain audit-ready evidence of who or what approved the transaction, when it happened, and what authentication was present at the time. For payment environments, the relevant baseline is anchored by PCI DSS v4.0, which reinforces the need for strong access control, logging, and protection of payment-related evidence.
Risk and Threat Considerations
When authorisation evidence is missing, the merchant is exposed to reversal even if the sale itself was legitimate. The main risk is not just losing one dispute, but creating a repeatable gap where stolen cards, account compromise, or weak checkout controls can be used and then denied with little resistance.
Failure mechanism: The retailer cannot produce a defensible record that links the transaction to verified cardholder authorisation, so the issuer or scheme treats the claim as unresolved in the customer’s favour.
Impact: The merchant absorbs the financial loss, fees, and operational burden of the dispute, and repeated failures can indicate broader weaknesses in payment authentication, evidence retention, or fraud control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
PCI DSS v4.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | Req. 10 — Log and Monitor All Access to System Components and Cardholder Data | Dispute defence depends on transaction logs and evidence retention for payment activity. |
| Req. 7 — Restrict Access to Cardholder Data by Business Need to Know | Authorised payment handling relies on limiting who can act on payment data and systems. | |
| Req. 8 — Identify Users and Authenticate Access to System Components | The question turns on proving authentication and authorisation behind the transaction. | |
| Recommendation — Retain and review transaction logs that can support or refute disputed card payments. Limit payment-system access to authorised roles and processes only. Authenticate access to payment systems and preserve the evidence of that authentication. | ||
Practitioner Guidance
What to verify: Make sure your dispute file can answer three questions cleanly: who authorised the payment, how that authorisation was authenticated, and what supporting evidence remains available at challenge time. If any one of those is missing, treat the transaction as weakly defendable even if the order was fulfilled.
Decision rule: If you cannot show a scheme-acceptable authentication trail, prioritise evidence capture, log preservation, and checkout control review before assuming the issue is only a customer service dispute. That usually reveals whether the gap is in identity proof, payment workflow, or record retention.
Practitioner takeaway: In card disputes, proof is the control. Retailers win by preserving a clear authorisation trail, not by relying on the presumed legitimacy of the sale.
Related resources from NHI Mgmt Group
- What happens when an organisation is in scope for NIS2 but cannot prove its security controls are effective?
- What happens when a financial institution cannot prove DORA readiness during an audit or regulatory inquiry?
- What happens when software manufacturers cannot prove they handled vulnerabilities and AI-generated code with sufficient controls?
- What happens when a valid authorised transaction later turns out to be fraudulent under the new Amex CID policy?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
