The purpose of this article is to cover chargeback handling as an advanced feature to be considered by merchants and resellers when selecting a payment gateway\credit card processor.
If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.
To learn about chargeback concept and why chargebacks are important, check the respective article on our web-site. Chargebacks represent problems for both merchants and resellers because of financial liability with them. A crucial point to be kept in mind is that if chargeback rate of some business exceeds 1 %, this business gets on the Terminated Merchant File and its merchant account is shut down.
Merchant perspective
While chargebacks are unavoidable, the goal of any business is to handle chargebacks properly whenever they appear. That means: find out about potential chargeback as soon as possible (retrieval), contact the customer, respond to retrieval and try to resolve the issue, prevent the chargeback from getting enforced and having financial impact.
When dealing with a processor\payment gateway it is important to understand:
- how chargebacks are going to be delivered to the merchant (chargeback delivery mechanism),
- what information is going to be present in a chargeback (chargeback identification method),
- how the chargeback disputing mechanism will work.
These three aspects are addressed below.
Chargeback delivery mechanisms
In terms of chargeback information delivery from a processor to a merchant the two common options are: over e-mail (fax) and as a report (through API).
In case of e-mail or fax delivery, for every chargeback that occurs, a merchant is going to receive an e-mail or fax with the chargeback details. The report/API option offers delivery of chargebacks in electronic format (for example, as a delimited file), which can then be either used for manual processing or imported into merchant’s system of record.
For larger businesses with high transaction volumes an importable report/API would definitely be a more preferred option.
Chargeback identification methods
There are two approaches the processors might use to identify a chargeback. Based on the approach they use, merchants will receive slightly different information about a chargeback.
One of the ways is to use the unique identifier of the original transaction which is included in the chargeback case. However, some of the legacy platforms are incapable of doing this, and instead they send the merchant the date, the amount and the last four digits of the card number. While this option is acceptable on some smaller transaction volume, it will be a labor-intensive task for those who process a lot and want to handle chargebacks. Consequently, whenever possible, the preference should be given to processors capable of including unique ID of the original transaction in the chargeback information.
Chargeback disputing mechanisms
In terms of disputing (merchant-processor interaction) there are two ways of handling chargebacks (providing supporting documentation against the chargeback claim). One is through e-mail or fax, and the other – by using automated customer relationship management system (CRM) API.
While still predominant in the industry, the first option might be inefficient, as it involves a lot of manual work. The second option is going to help a business automate the process, but it may require resources to put it in place.
Consequently, if a merchant needs to handle a small number of chargebacks, it can go with the manual process. However if a merchant wants the chargeback handling to be an efficient automated mechanism, the preference might lie with processors who use some formal API for chargebacks disputing.
To illustrate the common issue with chargebacks, let us consider the example of a health club.
Example
Conclusion
Depending on transaction volumes, merchants must select processors/payment gateways capable of providing the most suitable options in terms of chargeback delivery, identification and disputing. A merchant dealing with larger transaction volume would prefer to partner with a payment gateway/processor whose chargeback handling mechanism is fully automated and implemented in a formal API.
Reseller perspective
The issue with chargebacks affects all resellers in one way or another (as chargebacks tend to be viewed negatively by acquirers), but it is particularly vital for payment service providers (PSP), participating in the underwriting process and bearing financial responsibility for the merchants in their portfolio. In such cases if a merchant is incapable of covering the chargebacks, PSP might be responsible for refunding the money back to customers. Therefore, it is of paramount importance for any PSP to be aware of all of the chargebacks as soon as they occur, as this awareness gives them the opportunity to react and, potentially, resolve the issue with the merchant before it is too late (the merchant is out of business).
Example
If a PSP usually has a multitude of merchants in its portfolio, it is virtually impossible for this PSP to resolve chargeback issues with all of them “manually”.
Conclusion
If a reseller business is bearing financial responsibility for chargebacks issued by customers of its sub-merchants, it is better for this reseller to use API in order to control the process across entire portfolio and get the information as quickly as it arrives.
In the subsequent posts we are going to move on to more advanced features, targeted at enterprise merchants, wholesale resellers, ISOs and PSPs.
Recommended to you
