The Challenges of Chargeback Disputing and Delivery

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.


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.

Payment Terminal Fulfillment Process

In our previous articles we addressed different types of payment terminal solutions. If you decide to utilize an embedded terminal solution, then one of the key questions you have to address is how to implement fulfillment of the terminals, which is going to involve proper key injection into the brand-new (or factory-unlocked) terminals, and how to do the initial software load.

The classical arrangement of fulfillment process is as follows. A contract is signed with a reseller of payment terminals. The reseller (fulfillment company) is going install the necessary applications, inject encryption keys, and ship the terminals to the merchants. Some fulfillment companies also can do servicing of the terminals, as well as provide support and take inbound customer calls.

When you select a payment terminal fulfillment partner, it is important to keep several points in mind. First, your partner should be capable of installing the applications you need, including the ones you’ve developed yourself. Second, your partner needs to be able to inject the keys for the processors you need (in those countries you need to be processing). This second aspect is particularly important when you are working with multiple acquirers and in multiple countries.

When you think through your payment terminal fulfillment mechanism, we highly recommend you to map out the following processes (and how they will occur).

  • Initial order. How is the payment terminal order going to be captured from a merchant? Who will capture the order (you or fulfillment center)? If it is you, how is it going to be placed in the fulfillment center? (The merchants can place the order on your web-site, so that you will forward the order to a fulfillment centre, or they can directly address the fulfillment centre themselves). How will the appropriate terminals be set up within your gateway and/or terminal management system (TMS)?
  • Modification of orders. A merchant ordered three terminals of a certain model and then decided that he needed an extra terminal. Or, maybe, he decided that one of the terminals had to be of a different model. Appropriate procedures must be developed for the cases, when an order has not been sent for fulfillment yet, as well as for the cases when the order has already been submitted for fulfillment (or even has been shipped).
  • Cancellation of orders. Procedures, similar to the abovementioned order modification scenarios must be developed.
  • Return of terminals. A terminal can have some defects, or a merchant can terminate his partnership with a respective payment service provider. In both cases, the terminal has to be returned. Respective procedures for return or exchange of the terminals must be implemented. A re-stocking strategy must also be in place, as the returned terminals (previously rented by some merchant) might be re-purposed elsewhere.
  • Maintenance issues. If merchants experience technical problems with a terminal, there needs to be a service they can contact. Respective support procedures should be thought through.
  • Stock shortages. You should also consider your strategy for potential stock shortages. The two most common approaches are as follows. First, you can pre-purchase terminals of certain models in advance. For example, you may purchase 500 terminals from a fulfillment center, and when only 50 of them are left in stock, you automatically order the next 500. Second, you can sign agreements with several fulfillment centers and maintain some stock with each.


If you are a provider of embedded terminal solutions, you need to pay particular attention to your payment terminal fulfillment process, and make sure that it is tailored for your needs or needs of your merchants, and those of your embedded solution.