A payment can be successfully authorized, cleared, and settled...
and still become a problem days or weeks later.
The merchant may already have received value.
The transaction may be marked as successful across the payment stack.
Then the cardholder says:
"I didn't make this transaction."
At this point, we're no longer dealing only with payment processing.
We're dealing with dispute management.
Let's look at where a chargeback fits into the card payment lifecycle and what happens between the systems involved.
First: where does a chargeback happen?
A simplified successful card payment looks something like this:
Cardholder
│
▼
Issuing Bank
│
▼
Card Network
│
▼
Acquirer / Payment Provider
│
▼
Merchant
The exact architecture varies, but the important point is that multiple parties participate in getting a card transaction from the customer to the merchant.
A chargeback begins after a cardholder disputes a transaction through their issuer.
Now the direction of communication changes.
Cardholder
│
│ Raises dispute
▼
Issuing Bank
│
│ Dispute / Chargeback
▼
Card Network
│
▼
Acquirer / Payment Provider
│
▼
Merchant
This is one reason chargebacks shouldn't simply be thought of as "refunds."
They are part of a formal card-payment dispute process.
The actors involved
Before looking at the flow, let's identify the major participants.
Cardholder
The person whose card was used for the transaction.
They may dispute a payment for reasons such as an unrecognized transaction, duplicate billing, goods or services not received, or another eligible dispute reason.
Issuer
The financial institution that issued the customer's card.
The cardholder normally raises the dispute with the issuer.
Card network
The network provides rules and infrastructure that allow the dispute to move between the issuing and acquiring sides.
Acquirer / Payment Provider
The acquiring side processes payments for the merchant and communicates relevant dispute information to the merchant.
Merchant
The business that accepted the original payment.
Depending on the dispute, the merchant may accept the chargeback or provide evidence supporting the original transaction.
What happens when a dispute is raised?
Suppose a cardholder notices a ₦50,000 transaction they don't recognize.
They contact their issuing bank.
From a systems perspective, we now have an interesting situation.
The original transaction might already look like this:
authorization_status = APPROVED
clearing_status = COMPLETED
settlement_status = SETTLED
But now another state exists:
dispute_status = OPEN
The original payment hasn't magically disappeared.
Instead, a new process has started around that transaction.
That's an important distinction when designing or understanding payment systems.
Step 1: Identify the original transaction
The dispute needs to be associated with the correct payment.
That means transaction identifiers become extremely important.
A payment platform may need information such as:
- Transaction reference
- Amount
- Transaction date
- Merchant information
- Card/payment reference
- Processing identifiers
Without reliable identifiers, matching a dispute back to the original transaction becomes much harder.
This is one reason traceability matters so much in financial systems.
Step 2: Record the dispute reason
Not every chargeback exists for the same reason.
For example:
Transaction A → Cardholder says transaction was unauthorized
Transaction B → Customer says goods were never received
Transaction C → Customer says they were charged twice
These are different scenarios.
The dispute reason determines what information is relevant and how the case proceeds under the applicable card-network rules.
So a dispute-management system needs more than:
disputed = true
It needs to understand why the transaction is being disputed.
Step 3: Move the dispute through the payment chain
The issuer processes the cardholder's dispute.
The dispute information can then move through the relevant card-network process toward the acquiring side.
Eventually, the merchant or its payment provider may receive information about the disputed transaction.
Notice something important here:
This isn't necessarily a synchronous request.
The customer isn't waiting at a checkout screen while all of this happens.
Chargeback processing can involve events occurring across different systems and at different times.
From an engineering perspective, you're dealing with an asynchronous workflow.
Step 4: Handle the financial impact
If the dispute progresses to a chargeback, there can be a financial adjustment associated with the original transaction.
Conceptually:
Original payment
Cardholder ───────────────► Merchant
₦50,000
Chargeback financial flow
Cardholder ◄─────────────── Merchant side
₦50,000
That diagram is deliberately simplified.
In reality, the movement occurs through the financial institutions and payment rails involved rather than through a direct transfer between the merchant and cardholder.
But it helps illustrate the direction of the financial effect.
Step 5: Keep the systems reconciled
Now something else becomes important.
Remember our previous Systems Explained Simply article on reconciliation?
Chargebacks create additional financial events that also need to be accounted for.
A system may need to distinguish between:
Original Sale +₦50,000
Chargeback -₦50,000
--------------------------------
Net Effect ₦0
If one system records the original transaction but another records both the transaction and the chargeback, the totals won't agree.
So dispute processing doesn't exist in isolation.
It affects ledgering, settlement, reconciliation, reporting, and merchant balances.
This is where the different parts of payment architecture start connecting.
Why transaction state matters
A common mistake when thinking about payments is assuming a transaction has only two states:
SUCCESS
FAILED
Real payment systems are more complicated.
A transaction can successfully complete its original lifecycle and later become associated with other events.
For example:
AUTHORIZED
↓
CLEARED
↓
SETTLED
↓
PAID OUT
↓
DISPUTED
↓
CHARGEBACK
The exact states and terminology depend on the system, but the principle is important:
"Successful" doesn't always mean "nothing else can happen to this transaction."
Financial systems often need to preserve the original event while recording subsequent events against it.
Refund vs Reversal vs Chargeback
These three processes can look similar from the customer's bank account because money may return.
Architecturally, they're different.
Refund
The original payment completed and the merchant intentionally initiates a return of funds.
Payment → Completed → Merchant initiates refund
Reversal
The original transaction should not complete normally, so its financial effect is cancelled or unwound.
Payment → Problem → Reversal
Chargeback
The original payment completed, but the cardholder later disputes it through the issuer.
Payment → Completed → Dispute → Chargeback
The destination may look similar.
The triggering event is completely different.
What should engineers take away from this?
Chargebacks reveal several important characteristics of payment-system design.
Payments are asynchronous.
Events can happen long after the checkout request has finished.
Transaction identifiers matter.
You need reliable ways to correlate disputes and financial adjustments with the original transaction.
State needs to be explicit.
A transaction being successfully settled doesn't prevent later dispute events.
Auditability matters.
When money is disputed, systems need enough history to explain what happened.
Reconciliation doesn't stop at settlement.
Refunds, reversals, chargebacks, and other adjustments also need to be reflected correctly across financial records.
And perhaps most importantly:
A payment isn't just an API request.
It's a lifecycle.
Putting it together
Our payment architecture is starting to look much bigger than:
POST /payments
↓
SUCCESS
A more realistic mental model is:
Authorization
↓
Clearing
↓
Settlement
↓
Payout
↓
┌───────────────┐
│ Later Events │
├───────────────┤
│ Refund │
│ Reversal │
│ Dispute │
│ Chargeback │
└───────────────┘
↓
Reconciliation
And that brings us to the next interesting question.
What happens when the cardholder raises a chargeback...
but the merchant has evidence that the original transaction was legitimate?
The chargeback isn't necessarily the end of the workflow.
The merchant side may be able to challenge it.
That's where representment comes in.
We'll explore that next in 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
