Chargeback Handling Lifecycle

In this article we are going to address the concept of credit card chargebacks, focusing on chargeback’s lifecycle.

In essence, a chargeback is a dispute between a cardholder and a merchant over a certain amount of money, happening when the cardholder believes that the money has been charged illegitimately or by mistake (for products or services he or she did not purchase).

When it comes to credit card chargeback handling, every card association (Visa, MasterCard, Amex, and Discover) has its own chargeback lifecycle and its own rules for chargeback disputing. Particular flow depends on the specific association, but we will now try to provide a high-level chargeback lifecycle description, which you can use as a general guideline.

The cycle starts when a cardholder contacts a bank and requests one of two things. The customer can inquire about a particular transaction. In this case the bank is going to issues a retrieval request (sometimes referred to as inquiry) to the merchant, who produced the transaction. Otherwise, the customer can dispute a charge and request a refund. In this case a chargeback is issued.

Retrieval request and chargeback creation

In case of retrieval request or inquiry, the merchant has to respond to the cardholder’s request with appropriate information. If the cardholder is satisfied with the answer, the case is dismissed. Otherwise, he or she can insist on a chargeback. Moreover, if the customer’s request remains unanswered (ignored by the merchant), the inquiry is automatically converted into a chargeback, that a merchant cannot represent (dispute).

When a chargeback is issued, the disputed amount is automatically deducted from the merchant’s account.

If the merchant accepts liability, the case is closed and no further action takes place.


If a merchant decides to dispute the chargeback (submit a representment), he has to prepare all the necessary supporting documentation, such as the copy of the contract or product order, shipment confirmation, etc. The acquirer reviews all the submitted documents. If the acquirer considers, that the information provided by the merchant, is sufficient, the chargeback is reversed, and the merchant gets the chargeback amount back. After the money is returned to the merchant, the cardholder has the opportunity to decide on the next step.

Chargeback disputing rounds and arbitration

If the cardholder is satisfied with the information provided by the merchant as part of the representment, the chargeback is dismissed. Otherwise, the second round of chargeback disputing starts.

Different associations have different rules, limiting the number of chargeback disputing rounds. Consequently, further disputing rounds are conducted based on association-specific disputing policy. American Express, for example, has no limitations on the number of rounds of disputing between the cardholder and the merchant. Visa and MasterCard limit this number to one additional iteration, after which the case has to go into the arbitration.

In any case, at a certain stage, when the two sides cannot come to terms, the arbitration is requested. The arbitration is done by the association, the decision is final, and the losing party has to cover the arbitration fees, that, generally, start at $400 per case. Consequently, a chargeback below $300 rarely makes it to the arbitration stage.

Keep in mind, that debit networks do not have chargeback handling mechanisms, so transactions, processed through PIN-less debit networks are final and cannot be reversed.


We hope, that now that you have this information on chargeback lifecycle, you will be able to deal with chargebacks more efficiently.

Phishing Attack Prevention

In this article we’ve decided to readdress the security and fraud prevention issues. In particular, we are going to focus on a fraud technique, commonly referred to as phishing attacks. Phishing attacks are often used in payment processing context as a fraud technique, designed to capture a user’s logon information, which is needed to access the payment gateway or payment system, the user is working with.

You may have heard the term phishing already, but in this particular post we are going to describe the issue from payment gateway and payment system access perspective.

There are several reasons for phishing attacks.

  • Personal data theft. The phishing attack might be undertaken just to steal your personal data, or the personal data of your clients.
  • Payment data theft. The attack might be undertaken to steal your payment information (credit card numbers), or payment information of those customers processed through your accounts.

Even if the payment information is hidden, the individual logon of a user into a virtual terminal of a payment gateway might still be used by fraudsters for the so-called credit card milking (verification of stolen card numbers using this user’s merchant account).

How phishing attacks occur

Phishers usually replicate (make an exact copy of) the logon page of the system they are trying to attack and send you a letter with a link, that you are asked to follow. In the letter you are told that there is some urgent issue with the system, which requires you to follow the link and login. The visual appearance of the link, usually, corresponds to the actual login page of the service. However, once you click on it, you are redirected to an absolutely different page, looking exactly like the expected logon page. If you do not pay attention to the URL, you cannot notice the fact that you are not on the real logon page, and you may inadvertently enter your logon information, which would then be stolen.

How to prevent phishing attacks

There are several preventive techniques which can be used by payment system operators to protect their respective payment gateways against phishing. The two most common ones are two-factor authentication and security image usage. Both approaches are based on some additional authentication factor, added to username and password.

The two-factor authentication is based on usage of an additional value during logon. The value is generated by a software product, a hardware device (usually referred to as token) or by a smartphone. Generally, only the user has access to the software/hardware/smartphone, so even if the username and password are stolen by phishers, they still cannot access the logon page. You can find more detailed information on two-factor authorization in our respective article on Google authenticator.

The simpler approach is based on usage of a so-called security image. During the first logon, the user is asked to choose an image, which will be used as his personal security image. The logon dialogue webpage has to be modified accordingly, so that initially the user is required to input only the username, without the password. Once the username is input, it should be verified, if it is present in the database\system. If it is, an image is displayed. If the image coincides with the user’s security image, it indicates that the user can proceed with logon and input your password. Otherwise the user simply does not input the password, thus, making logon impossible, and preventing the potential phishing attack (as phishers do not know the security image to be displayed).


If personal data and payment information of your clients are major concerns for you, you should implement some phishing attack prevention technique in your logon mechanism.