While card processing integrations have been an integral part of acquiring business for many years, and most acquirers have the respective documentation available, modern PSPs require additional integrations to handle chargeback delivery and chargeback disputing.
The purpose of the article is to provide you as a merchant or a payment facilitator with a deeper knowledge of chargeback handling process, so that you could take care of all the issues concerning chargebacks while discussing your integration with the payment processor (depending on the approach the processor offers).
The two important aspects of chargeback handling are chargeback delivery and chargeback disputing.
Chargeback delivery mechanisms
It should be kept in mind that initially, when the concept of chargeback came into being, volumes of processed transactions and the scale of credit card fraud were much lower than they are today. Consequently, as of now there are three conceptual approaches to chargeback delivery, which were historically introduced one after another. Let us list them in chronological order.
- Regular mail and fax. Traditionally, chargebacks used to be delivered via regular mail as printed reports. At some point processors started to send chargebacks by fax.
- E-mail. After regular mail and fax, the practice of delivery via e-mail emerged. Chargeback information was either delivered as an attachment, or embedded in the body of the e-mail. Usually, one e-mail was sent per chargeback.
- Data files. As the process became more complicated, printed reports and ordinary e-mails became really impractical, because the number of chargebacks and retrieval requests dramatically increased (proportionally to the total number of transactions). Consequently, the next step undertaken by processors was to export chargeback reports from their system. This method is still used by many processors today. A data file is generated and either pushed to the merchant’s FTP server, or provided for download by the merchant. The file, usually, contains the information about the chargeback, necessary to identify the original transaction and take subsequent action to dispute the chargeback or otherwise.
- API. Some processors developed APIs allowing to load chargebacks or receive a notification (callback) when a chargeback occurs. The advantage of API is that it provides somewhat better control for the merchant on how delivery of the chargeback occurs.
Chargeback disputing mechanisms
Sometimes, after a chargeback is received, the merchant may want to dispute it. Just like in case of delivery, there are several approaches used for chargeback disputing as well.
- Fax. Fax is still one of the most popular options. Supporting documentation, as well as the explanation of the original charge is faxed to a number, provided by the processor.
- E-mail. The same information can be sent as an e-mail attachment. Obviously, both cases assume some human involvement. Even though the initial disputing e-mail can be originated by the system, that processed transactions, supplying the supporting documentation automatically, in some of the cases there can be a reply from the processor (for example, if some information is missing). That reply cannot really be automatically handled.
- Data file combined with fax or e-mail. Some acquirers/processors prefer merchants to send a text file with charge information and then fax or e-mail supporting documentation. The mechanism is slightly better than the previous one, because the information exchange is organized through the file, while the documents are submitted using more or less appropriate medium.
- Disputing portal. Many present-day processors started to create special disputing portals, allowing merchants to login, upload supporting documentation and explain the reason for dispute within the portal. The same portal can be used for chargeback delivery, as, beside chargeback disputing, the merchants, who login to the portal, can check if any new chargeback have occurred.
- Disputing API. The portal-based approach works perfectly well with merchants, but payment facilitators and PSPs find it problematic to use. The reason is that login information for each merchant must be maintained, and merchants can interact with the processor “behind the PSP”. As a result, it becomes very difficult for the PayFac, or the PSP to manage the whole process. That is why some of the processors, which are targeting PSP markets started offering chargeback disputing APIs. Uploading of the documentation and disputing of the chargebacks in such cases can be done using a SOAP- or REST-based API. The API makes the process a lot more fluid, convenient, and flexible for a software or PSP company that is trying to offer an integrated chargeback disputing solution for its customers.
Conclusion
Depending on your needs and purposes, you should try partnering with the processor, offering you the most convenient chargeback delivery and chargeback disputing mechanisms in the context of your business model.
Recommended to you
