DEV Community

Cover image for How Representment Works: What Happens When a Merchant Challenges a Chargeback
Eunice Explains
Eunice Explains

Posted on

How Representment Works: What Happens When a Merchant Challenges a Chargeback

#payments #fintech #architecture #beginners

A chargeback reaches the merchant.

But the merchant has evidence that the original transaction was legitimate.

So what happens next?

Does the merchant simply accept the financial loss?

Not necessarily.

In the previous edition of Systems Explained Simply, we looked at how chargebacks fit into the card-payment dispute flow.

Now we're following that transaction one step further.

This time, we're looking at the merchant-facing side of the dispute lifecycle.

That's where representment comes in.

First: What Is Representment?

In simple terms:

Representment is the process through which the merchant side challenges a chargeback by submitting evidence supporting the original transaction.

Conceptually, we've moved from this:

Cardholder
    │
    │ Raises dispute
    ▼
Issuing Bank
    │
    ▼
Card Network
    │
    ▼
Acquirer / Payment Provider
    │
    ▼
  Merchant
Enter fullscreen mode Exit fullscreen mode

to this:

  Merchant
    │
    │ Evidence / Response
    ▼
Acquirer / Payment Provider
    │
    ▼
Card Network
    │
    ▼
Issuing Side
Enter fullscreen mode Exit fullscreen mode

The exact flow and terminology depend on the network and dispute, but the important idea is:

The merchant isn't simply saying, "I disagree."

The merchant needs to respond to the specific reason for the dispute with relevant evidence.

And that's where things get interesting from a systems perspective.

A Chargeback Is Not Just a Chargeback

Suppose two ₦50,000 transactions are disputed.

They may have the same:

amount = 50000
status = CHARGEBACK
Enter fullscreen mode Exit fullscreen mode

But that doesn't mean they're the same type of dispute.

One customer might say:

"I didn't authorize this transaction."

Another might say:

"I paid, but the product never arrived."

Those claims require very different responses.

Conceptually:

Chargeback
    │
    ▼
Identify Dispute Reason
    │
    ├── Unauthorized Transaction
    │       ▼
    │   Relevant fraud/authentication evidence
    │
    ├── Goods Not Received
    │       ▼
    │   Relevant fulfilment/delivery evidence
    │
    └── Duplicate Processing
            ▼
        Relevant transaction records
Enter fullscreen mode Exit fullscreen mode

This is why reason codes matter.

Reason Codes Drive the Response

Card networks use reason codes or dispute categories to describe why a transaction is being challenged.

Those codes aren't just labels for reporting.

They help determine:

  • What the dispute is actually alleging
  • What rules apply
  • What evidence may be relevant
  • What deadlines apply
  • How the merchant should respond

For example, a dispute alleging fraud may require evidence very different from a dispute alleging that merchandise wasn't received.

So a merchant-facing dispute system shouldn't be designed around:

chargeback_received = true
Enter fullscreen mode Exit fullscreen mode

followed by:

send_generic_evidence()
Enter fullscreen mode Exit fullscreen mode

A better mental model is:

Chargeback Received
        │
        ▼
Identify Reason Code
        │
        ▼
Determine Requirements
        │
        ▼
Gather Relevant Evidence
        │
        ▼
Validate Response
        │
        ▼
Submit Representment
Enter fullscreen mode Exit fullscreen mode

The reason for the dispute should influence the evidence strategy.

What Evidence Might Matter?

Evidence depends on the dispute.

For a goods-not-received claim, useful information might include:

  • Delivery confirmation
  • Tracking information
  • Delivery address
  • Customer communication
  • Fulfilment records

For a duplicate-processing claim, the merchant may need transaction records demonstrating that the charges correspond to separate legitimate purchases.

For another dispute category, completely different information may be relevant.

The important engineering lesson isn't to memorize every possible evidence type.

It's this:

Evidence should be contextual.

A generic evidence packet for every chargeback is a poor model for a system dealing with multiple dispute categories.

Representment as a Workflow

From an engineering perspective, representment isn't simply a button labelled:

CHALLENGE CHARGEBACK
Enter fullscreen mode Exit fullscreen mode

It's a workflow with state.

A simplified model could look like:

CHARGEBACK_RECEIVED
        ↓
UNDER_REVIEW
        ↓
EVIDENCE_REQUIRED
        ↓
EVIDENCE_COLLECTED
        ↓
REPRESENTMENT_SUBMITTED
        ↓
AWAITING_OUTCOME
Enter fullscreen mode Exit fullscreen mode

And eventually:

   ┌───────────────┐
   │               │
   ▼               ▼
ACCEPTED         REJECTED
Enter fullscreen mode Exit fullscreen mode

Real implementations and network terminology vary, but modelling the process as a lifecycle helps us understand an important point:

A dispute evolves over time.

It isn't a single synchronous API request.

Deadlines Are Part of the System

There's another constraint payment engineers need to think about:

time.

Dispute processes operate within defined timeframes.

That means a merchant may have evidence proving the transaction was legitimate...

but still need to submit it within the applicable deadline.

From a system-design perspective, that introduces requirements around:

  • Timestamps
  • Due dates
  • Notifications
  • Escalations
  • Workflow queues
  • SLA monitoring

A dispute-management platform therefore needs to know not only:

WHAT happened?
Enter fullscreen mode Exit fullscreen mode

but also:

WHEN must the next action happen?
Enter fullscreen mode Exit fullscreen mode

Traceability Becomes Critical

Now think back to the original transaction.

It may have happened weeks earlier.

Yet the representment process may need information from that original payment.

So the system needs to connect:

Original Payment
      │
      ▼
   Dispute
      │
      ▼
  Chargeback
      │
      ▼
 Reason Code
      │
      ▼
   Evidence
      │
      ▼
Representment
Enter fullscreen mode Exit fullscreen mode

This is why identifiers and audit trails matter so much in payment architecture.

If those records are fragmented across multiple systems, assembling a reliable dispute response becomes much harder.

Representment Also Has Financial Consequences

Remember our earlier discussion about reconciliation?

A chargeback can create a financial adjustment against the merchant side.

If the merchant successfully challenges that chargeback, another financial event may need to be reflected.

Conceptually:

Original Payment        +₦50,000
Chargeback              -₦50,000
Successful Challenge    +₦50,000
Enter fullscreen mode Exit fullscreen mode

Again, the exact accounting treatment depends on the system and process.

But the architectural point remains:

Dispute events affect more than the dispute-management application.

They can affect:

  • Merchant balances
  • Settlement
  • Ledgers
  • Reconciliation
  • Reporting

So representment needs to integrate cleanly with the wider payment platform.

Chargeback vs Representment

The easiest way to separate them is:

Chargeback

The cardholder disputes a completed card transaction through the issuer, potentially creating a financial adjustment against the merchant side.

Representment

The merchant side responds to the chargeback with evidence supporting the original transaction.

So:

Payment
   ↓
Dispute
   ↓
Chargeback
   ↓
Reason Code
   ↓
Evidence
   ↓
Representment
Enter fullscreen mode Exit fullscreen mode

And this reveals something important about payment-system design:

The transaction record alone isn't enough.

You also need the history around the transaction.

Who challenged it?

Why?

When?

What evidence was provided?

What financial adjustments occurred?

What is its current dispute state?

What Should Engineers Take Away?

Representment highlights several useful design principles.

1. Model disputes as workflows, not booleans.

is_disputed = true tells you very little about where the case actually is.

2. Reason codes should influence system behaviour.

Different dispute reasons require different responses and evidence.

3. Evidence needs structure and traceability.

Documents and transaction data should remain connected to the dispute they support.

4. Time matters.

Deadlines, notifications and SLA tracking are part of the workflow.

5. Financial events need reconciliation.

Chargebacks and subsequent dispute outcomes can affect merchant balances and financial records.

6. Preserve the audit trail.

Weeks later, the system should still be able to reconstruct what happened from the original payment through the dispute lifecycle.

The Bigger Picture

Our payment system is no longer simply:

POST /payments
     ↓
  SUCCESS
Enter fullscreen mode Exit fullscreen mode

We've now followed:

Authorization
     ↓
  Clearing
     ↓
 Settlement
     ↓
   Payout
     ↓
Reconciliation
Enter fullscreen mode Exit fullscreen mode

And then the events that can happen later:

     Payment
        ↓
┌─────────────────┐
│ Refund          │
│ Reversal        │
│ Dispute         │
│ Chargeback      │
│ Representment   │
└─────────────────┘
Enter fullscreen mode Exit fullscreen mode

The further we go, the clearer something becomes:

A successful payment is a state in a much longer financial lifecycle.

And representment still isn't necessarily the end.

What happens if the cardholder side and merchant side still don't agree after the merchant responds?

That's where the dispute can move into later stages.

We'll continue from there in the next edition of Systems Explained Simply.

Systems Explained Simply is my series breaking down the infrastructure, workflows, and engineering concepts behind systems we interact with every day.

Eunice Explains

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.