for developers and administrators
User Interface Reference
Resources (Directory Structure)
Zip and Country Codes
Supported Providers (Banks & Networks)
UniPay Codes & Code Mappings
Integrated 3rd Party Libraries
Diagrams and Documents
Chargeback Handling Guide v1.0
Added on: 09/12/13
Updated on: 03/07/18
Table of Contents
To understand the nature of
, it’s essential to analyze its lifecycle. There are three basic concepts associated with chargeback lifecycle:
Cycle – indicates current phase of
within its lifecycle
Status – indicates current status of the case within the cycle
Queue – indicates party responsible for the next action on the case
This guide will be useful for
s, chargeback managers and administrative users that deal with chargeback cases on a daily basis.
The first thing about chargebacks you should understand is chargeback's Cycle. There are several standard cycles:
Retrieval request – cases in this cycle represent requests from the issuer to the acquirer either for an original or legible copy of the transaction information document or for a substitute drafts; merchant has the option to refund transaction back to the customer or respond to the bank by supplying abovementioned information back to the processor. Note: If retrieval request remains unanswered as to allowed deadline, the chargeback will be automatically produced with no option to represent.
Chargeback – cases in this cycle represent first chargeback issued by credit card company; when the merchant receives the first chargeback, he/she has the option to accept the chargeback or dispute and represent it back to the bank; representment action requires submission of applicable information that proves the case. Note: Do respect the time frame to respond on time.
Representment – cases in this cycle are chargebacks that were disputed and represented.
Pre-arbitration – cases in this cycle were already once represented but didn’t satisfy the Issuer. The second round of review is conducted between the issuing bank and merchant without the involvement of the association; merchant has the option to accept the chargeback or dispute and request arbitration. Note: If representment is not satisfied, issuing bank proceeds to ‘pre-arbitration’ cycle; each card network uses its own notion of this cycle.
Arbitration – cases in this cycle represent chargebacks where arbitration was officially requested. Note: If merchant decides to request arbitration (go forward to ‘arbitration’ cycle), it’s important to consider involved risk. Arbitration is the last phase of the process; the decision is final. The losing party is responsible for arbitration
s starting from $400 (MasterCard can charge additional fees for every technical error associated with the case, which can be applied against either party, win or lose). Merchants requesting Arbitration implicitly accept to pay arbitration fees, if the final decision is not at their favor.
Status indicates current state of the chargeback within the cycle. Indicators of chargeback process progress are:
Pending – the party responsible for the case (queue) has not taken any action yet
Assumed – the party responsible for the case assumed liability for it
Outgoing – case awaits transition to the next cycle
for the case has been received and accepted
Error – temporary state due to processor generated error
Queue designates the party responsible for the case and the next action to be taken within the case. Types of queue are:
is responsible for the case and the next action
Network – Issuing bank is responsible for the case and the next action
Processor – Processor/Acquirer is responsible for the case and the next action
Note added – note was added to the
Case assigned – case was assigned to the chargeback management agent for further consideration
Response sent – necessary information was submitted in response to retrieval request
Representment sent – merchant represented chargeback case and passed his queue to the Issuer
Liability accepted – merchant accepted liability for the chargeback case
Non Merchant Activities:
Update received – update from the issuer or processor was received for the case
Case Handling Guidelines
When retrieval request is received, the following actions can be taken to handle the case: refund the transaction, respond to the retrieval request or dismiss the case.
Respond to the retrieval request
When retrieval request is received and merchant feels that the original charge was legitimate, he/she can respond to the case. Response is done by submitting supporting documentation that can provide sufficient evidence to prove legitimacy of the original transaction (copy of the signed agreement, copy of the purchase order).
Refund the transaction
When retrieval request is received and
is the desired way to handle the chargeback, there are two possible scenarios: the refund had already been issued by the time retrieval request was received or the refund had not been issued yet.
Refund issued: since transaction has already been refunded, the merchant only needs to respond to the case supplying refund’s reference number. There is no need to refund the transaction for the second time.
No Refund: the merchant needs to refund the transaction and, then, respond to the case supplying refund’s reference number.
Please note that retrieval request can arrive even after you’ve already issued the refund in either full or partial amount. This is a normal situation due to the overall mechanism of
Here is one typical example of how such situation happens. A cardholder calls the bank and asks to issue a chargeback. The bank asks whether cardholder contacted the
on this issue. The cardholder responds affirmatively, even though, in reality he/she had never done that. Consequently, the bank approves chargeback request, which is normally processed within 48 hours. However, after the call, the cardholder feels guilty and contacts the merchant; merchant accepts to do a
. But the cardholder never calls the bank back to cancel the chargeback request. This way, merchant will receive chargeback from the bank for the transaction in spite of doing the refund.
Dismiss the case
When retrieval request is received, however at the time of response it is discovered that a chargeback for the same transaction already exists, retrieval request case can be dismissed. By dismissing a retrieval request, a merchant simply chooses not to respond to it. The assumption is that the response is going to be made on the chargeback.
Such scenario can occur when retrieval request is issued; however, due to some reasons (cardholder’s request, etc.) a subsequent chargeback is issued and assigned a different case number. Consequently, merchant is going to have two different cases with different case numbers for a single transaction. In such situations, it’s recommended to dismiss the case in retrieval request cycle.
When chargeback is received, the following actions can be taken to handle the case: accept liability or represent the case.
If merchant feels that the request to refund money back is legitimate, there are two possible situations: merchant has already issued a
(refund issued) or merchant would like to issue refund (refund).
When chargeback is received and merchant feels that it is legitimate and accepts to return back the money, it’s simply sufficient to accept liability and leave the case at this point.
Representing the chargeback
When chargeback is received and merchant feel that initial transaction is legitimate, he/she has an option to represent a chargeback. Representment requires submitting supporting documentation that can provide sufficient evidence to prove that initial transaction was legitimate.
When chargeback is received and the
has been already issued, merchant has to represent the case by submitting prior refund’s reference number.
1. It's critical in handling of
s to supply all necessary information within the time frame set by the processor or the network (‘reply by date’ field can be of service to monitor time left for you to respond). Ensure that you always respond on time.
2. When you respond to a retrieval request or represent a chargeback, make sure that appropriate documentation is supplied and double check that documentation provides sufficient support.
3. When requesting an arbitration, make sure that you fully understand and are willing to accept to pay the arbitration fees in case ruling is not done in your favor.
4. Try to always respond on time to all retrieval requests, any unanswered retrieval request will result in non-disputable chargeback.
General Chargeback Lifecycle
Network Specific Cycle Variations
Visa can follow either Discover or MasterCard sequence
Time frame (in days) of chargeback cycles by card association
UniPay - Payment Gateway Software
All Logos and Trademarks used or mentioned on this page are copyrighted property of their respective owners and are used for display purposes only.