It can be difficult to sort through the wide variety of processes, procedures, and terminology that exist within the world of payments. One particularly frequent source of confusion is the relationship between chargebacks and retrieval requests—made all the more confusing due to retrieval requests sometimes being called “soft chargebacks”. This article will sort out these two payment processes that are similar but different, distinct but sometimes interrelated.
As defined in our Payments Glossary, a chargeback is “a mechanism for returning payment to a customer after a disputed credit or debit card charge. Unlike a refund, a chargeback does not involve the direct communication of customer and merchant but, rather, involves communications between their respective banks (issuer and acquirer).”
A retrieval request is a procedure whereby a cardholder or issuing bank obtains information about a particular transaction from a merchant. In many ways, it is like the first step in the chargeback process—hence, its occasional alternative appellation as a “soft chargeback”. In some cases it is essentially an indication that a chargeback is forthcoming. But this is not always the case and, as with most payment procedures, the connection between retrieval requests and chargebacks varies from one card brand to the next.
In recent years, Visa and Mastercard have deemphasized retrieval requests, no longer mandating them as the first step in filing a chargeback. This has unsurprisingly come in conjunction with the development of multiple products that serve to alert merchants to incoming chargebacks and provide opportunities to settle disputes before they become chargebacks. However, those brands have not entirely eliminated retrieval requests and other card brands, such as American Express and Discover Card, still include retrieval requests as an integral part of their payment dispute processes.
The nominal and underlying causes of retrieval requests are very similar to the causes of chargebacks. Usually an issuer files a retrieval request if the cardholder contacts them to let them know that there is some issue with a transaction.
This could include the usual causes associated with friendly fraud such as the cardholder not remembering making a purchase, not recognizing the transaction as being for the correct amount, or finding some other issue with the transaction details. These sorts of issues could also come as the result of family fraud, unclear billing descriptors, simple forgetfulness, or other benign issues. This particular variety of retrieval request should be easy to resolve.
Retrieval requests could also originate from a cardholder’s attempt to commit chargeback fraud. These requests may be more acrimonious but proper recordkeeping can be very beneficial to the merchant. It is also entirely possible that a retrieval request could result from an incidence of true fraud. If this is the case, it is likely that the merchant will need to issue a refund.
Sometimes issuers file a retrieval request without any input from the cardholder. These usually result from technical issues with the transaction, such as illegible receipts or sales slips. Again, organized records of every transaction should help merchants resolve these sorts of retrieval requests.
The “soft chargeback” moniker comes from the fact that a retrieval request resembles the initial stages of a chargeback, albeit without the consequences for the merchant’s chargeback ratio. It can also serve as a de facto chargeback alert. If the merchant and acquirer fail to satisfactorily resolve the acquirer’s request, it is likely that the acquirer will file a chargeback, with all the entailing consequences.
Timeliness is an important aspect of a retrieval request response. Usually acquirers give issuers and merchants fewer than 20 days to resolve the issue. Some acquirers may set a deadline of as few as 10 days. This contrasts with the relatively long deadlines that issuers allow for cardholders to file retrieval requests—sometimes reaching as long as 18 months after the initial transaction.
From a merchant’s perspective, the ideal result of a retrieval request is the issuer dropping any objections and allowing the transaction to stand. However, that is not going to be possible in every instance. In situations where such a resolution seems unlikely, merchants would be well served to proactively issue refunds rather than face chargebacks, which carry additional consequences beyond lost revenue.
The worst possible retrieval request result for a merchant would be a failure to respond at all. This almost assuredly results in a chargeback being filed, likely with a reason code of “requested item not received”. This reason code precludes any chargeback reversal rights, requiring the merchant to simply accept the chargeback.