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.

Representment

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.

Conclusion

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

Implementing Your Own Payment Terminal Solution

If you are a player in the retail space, thinking that your business needs support for payment terminals, or if you are considering different payment terminal solutions in search of the most suitable one, this article is for you.

The need for customized payment terminal solutions is gaining urgency in view of approaching introduction of EMV standards and requirements in the US, scheduled for the end of 2015.

In this article we are going to consider several solutions, available for payment gateways and payment service providers with respect to their EMV strategy.

In essence, a terminal is a mini-computer with its own OS, where a terminal application has to function. Payment gateway must integrate with this terminal application to support EMV properly.

Payment solution offered by the acquirer

The first and, seemingly, the simplest solution is using payment terminal application, offered by an acquirer.

Many present-day acquirers offer you some form of payment terminal solution, which some PSPs or gateways may consider using. Upon closer inspection, however, you realize that there are a couple of issues with that.

One of the issues is that most payment terminal solutions (applications) offered by acquirers are tied directly to their platforms. Particularly, because of the tight EMV regulations, they avoid sending transactions from the terminal to some third-party gateway, intermediary CRM, or software system, which would then forward them to the acquirer. This may present a problem, because they need to keep track of these transactions to accommodate the business model of a PSP/gateway. The problem with the solution is that these transactions become invisible to the third-party gateway providers within their systems.

Because of that, many gateways and PSPs choose to integrate their software system with a terminal in a way which they can fully control.

Integration with a terminal

Integrating with a terminal can be done at two levels. At a higher level a PSP/gateway can utilize an existing terminal application and integrate with it using integration SDKs. At a lower level a proprietary embedded application can be written and subsequently integrated into the overall payment processing ecosystem.

SDK-based integration

The advantage of the first solution is that the SDK-based integration, usually, is much quicker than development of an embedded terminal application. Major payment terminal manufacturers (such as Ingenico, VeriFone, and PAX) offer their own terminal applications, which can be used in various ways, and thus, it is possible for payment gateways to take advantage of these applications.

While this solution is the simpler of the two, it has its disadvantages:

  • The gateway will not always be able to customize the terminal application (its interface or logic). For instance, you might be unable to add non-payment-related functionality, such as quality survey, to the application, when you need it.
  • SDK-based integration method may not be conceptually suitable for your application. Traditionally, platforms that used terminals, were desktop applications (only desktop applications existed). That is why many terminal integration SDKs still rely on the so-called native code, such as Windows-compiled DLL library. This imposes the requirement on the application to be able to deal with the native code. While this is, generally, not a problem for a desktop application, it does present a challenge for a web-application, which operates from within a sandbox, and, usually, does not have security privileges to operate at such a low level.

Embedded solution

The advantage of an embedded solution is that you can customize everything, and the application can do whatever you choose for it to do. You can develop an SDK or integration API, that will work for you, or your customers in any way, that you find appropriate.

On the other hand, this solution has a price tag attached to it, and is associated with some challenges:

  • Writing your own terminal application requires your own specialized knowledge, and a special costly certification, that has to be competed with the respective vendor in order to acquire preliminary knowledge and access to SDKs, allowing to do embedded development.
  • Building and testing the application, definitely, takes time. Therefore, immediate integration with the payment gateway solution is impossible.

In the next post we will describe some specific methods of integration and implementation of various SDK, allowing you to incorporate the terminal application into some software solution or payment ecosystem.

Payment Facilitators’ Role in Merchant Services

In this article we are going to focus on an important category of merchant services industry players, called payment facilitators. We are going to explain the history of their emergence in the industry and list the challenges they face at the present-day market.

Before payment facilitators

Traditionally, merchant services market dealt with the following types of intermediary entities (players) who helped merchants get and manage their merchant accounts:

  • Aggregators
  • Third-party processors
  • ISOs

Aggregators, as a rule, helped to solve the problems of micro-merchants or merchants having trouble with getting their own merchant accounts, particularly for recurring billing, bill payment and other transactions of similar kinds.

Third-party processors were often represented by payment gateways, which, generally, worked in collaboration with ISOs in order to simplify transaction processing for merchants (especially when legacy processing platforms were involved).

A traditional ISO played the role of a sales agent (intermediary). ISOs helped merchants to prepare documentation for processor’s underwriting departments, but, generally, did not participate in the underwriting process, merchant on-boarding, and subsequent merchant funding/remittance.

Over time, the so-called super-ISOs emerged. These were larger ISOs, which had greater involvement in the underwriting process, but, generally, tried to stay clear of any risk.

Recently the role of ISOs as one of the key merchant services industry players (an intermediary selling merchant service accounts) has become less important than before. The most likely reasons include:

  • market consolidation
  • the need for a consolidated business and technology offering
  • the challenges of acquirers around management of underwriting, on-boarding and fraud monitoring for many small-size merchants.

As online payments gained popularity, merchant services industry evolved, and many new small and medium-sized merchants emerged on the market. With the emergence of such multitude of small-sized merchants (as well as merchants with some particular business needs) it became more difficult for acquirers to handle underwriting and merchant management.

Consequently, several important trends became prominent in the merchant services industry, and the need for the so-called payment facilitators became apparent.

Emergence of payment facilitators

Acquirers found it difficult to work with smaller-size merchants, because, from underwriting, processing, on-boarding, and funding perspectives, administrative effort required to service a merchant is the same across all merchant sizes. Same administrative procedures are needed to service a micro-merchant and a merchant processing millions of transactions, although server load and transaction volumes, surely, differ. As a result, the practice of working with the so-called payment facilitators became more popular and frequent.

From ISOs to payment facilitators

In a sense, a payment facilitator can be defined as a product of ISO’s evolution. In contrast to pure ISOs, payment facilitators do perform merchant underwriting themselves, and, thus, free the acquirer (underwriter) from the need to perform administrative procedures, necessary for merchant account approval. In some cases, the also facilitate funding of their sub-merchants. Consequently, a payment facilitator goes through the so-called underwriting process for payment facilitators in order to provide the insight to the acquirer about the procedures, which are going to be used for merchant screening and merchant underwriting-related decisions.

In exchange for cheaper access to transaction processing (emerging from the opportunity to purchase services from the acquirer “wholesale”, and, thus, pay less), payment facilitators take the underwriting-related risks, handle initial underwriting, merchant funding, and general support of merchants from their portfolios (customer service). Lower transaction processing costs provide the basis of payment facilitators’ profit margins.

Software companies as payment facilitators

Many software companies, which initially worked through such payment gateways as Authorize.net or Stripe, realized that they were losing a considerable share of revenue because they paid to third parties for merchant and gateway services, which they were capable of providing themselves. At the same time, plenty of these software companies had considerable experience and histories of working with merchants who used their services (such as software development for fitness centers, tanning salons, restaurants, supermarkets etc).

It became obvious to these companies that they could also act as payment facilitators, because at some point in payment processing cycle all transactions had to go through their software products, and they had control over transaction processing.

Aggregators as payment facilitators

Many aggregators switched to the described model, where payment facilitators represented the intermediary link between them and the merchants, according to provisions of the new legal regulations. Another numerous group of aggregators decided to perform the role of payment facilitators themselves, because this step made them more compliant with the most recent regulations, imposed by the associations, and also formalized their screening process, thereby, reducing the possibility of potential fraud.

Now that we’ve reviewed the process of payment facilitators’ emergence, and listed the key entities performing the role of payment facilitators, let us look at what it takes to become one. While it seems like a cool idea for many companies, in fact, it is a challenging process, and it is important to account for all the aspects of this process.

Becoming a payment facilitator

In order to become a payment facilitator, a company needs to take care of several important aspects:

  • Some form of a contract with the acquirer (processor, underwriter). To sign a contract, the company needs to present some proof of its financial viability, including all the necessary legal documentation, such as financial statements, all the necessary insurances etc.
  • Some CRM system allowing to manage prospective merchants.
  • A mechanism for merchant background verification. These include credit history check, background checks by LexisNexis, TransUnion, or similar companies.
  • Some software or payment gateway solution, needed to physically process transactions. Payment gateway software must be integrated (have established relationship) with the respective processor (acquirer).
  • Appropriate PCI certifications. PCI audit allows the candidate to obtain all the necessary PCI-compliance-related documentation.
  • Selection of a merchant funding strategy. Merchant funding can be performed either through the acquirer, or the necessary functionality must be implemented in the company’s own platform.
  • A set of consumer fraud and merchant fraud prevention instruments. Typically, these instruments are embedded in the company’s own platform. Some articles on our blog provide descriptions of consumer and merchant
    fraud prevention mechanisms, as well as merchant services reserves.

Conclusion

Ideally, a prospective payment facilitator needs a unified platform capable of managing the whole lifecycle of the merchant and the merchant’s transactions.

EMV Certification in a Nutshell

The purpose of this article is to familiarize integrators with EMV processing, help merchants understand the process of EMV certification and estimate its cost.

The relevance of EMV certification

EMV stands for Europay, Mastercard and Visa, and denotes a worldwide transaction authentication standard. The standard is based on usage of integrated circuit cards, which increases the security of EMV card transactions in comparison to magnetic stripe cards. More information on EMV standards can be found here.

From January 1, 2005, merchants in EU area are held liable for all fraud resulting from transactions processed in the systems, which do not support EMV. In the US, EMV certification also became an extremely relevant issue after the associations declared that the liability will be placed on merchants at the end of 2015, i.e. if a person wants to make a purchase from a merchant, using the EMV card, but the merchant doesn’t have an EMV terminal, and the transaction ends up being part of fraudulent activity, it is the merchant who is going to be held financially responsible for the incident’s consequences.

Although many merchants can purchase EMV terminals from the acquirers and do not necessarily need to conduct the in-depth analysis of EMV certification process, gateways, payment facilitators, as well as companies, that maintain their own proprietary payments ecosystems, have to face the question of how to undergo EMV certification, i.e., how to add EMV support into feature sets of their products.

Let us move on and review the EMV certification process in greater detail.

EMV certification phases

Before starting an EMV certification, a company needs to make a decision about the three key components of the process:

  • Terminal(s) (hardware device) that will be used to read EMV cards. Some information on payment terminals can be found in our respective article
  • Payment gateway software or some form of software package that will deliver transactions to the acquirer
  • Acquirer(s), that will process the transactions

After these decisions are made, the company can proceed with the EMV certification, that is, generally, comprised of two sub-certification processes (phases): host integration and EMV certification.

Payment processing host integration

Generally, there are no certification fees involved in this phase, and the main cost is the cost of development of the integration code. It involves integration on the message level between your system and the acquirer. As part of this integration, a proper message format is implemented to enable a payment gateway to submit EMV fields to acquirer’s system in a format that it can “understand”. In a sense, the process is similar to classical integration, described in the respective article.

EMV certification

It is a process, in which an EMV terminal (a terminal, supporting EMV card processing) and a so-called EMV toolkit are used. Special test scripts, certified by the acquirer for every association, have to be executed with the help of the EMV toolkit. The results of execution of the test scripts are submitted to the acquirer to be considered for review. The acquirer forwards the results to the associations for their final approval.
Usually, EMV certification involves an administrative fee (charged by acquirers), ranging between $2,000 and $3,000 for every formal test script run. Re-certification process has to be initiated every time when a new hardware device, using a different EMV kernel is added to the previously certified EMV-processing pad.

For example if any VeriFone mx9 series device has been previously certified, any other device of a kind is automatically covered by that certification. But in order to use some Ingenico device, you would have to initiate another EMV certification (even if you are going to utilize the existing host integration and the same back end).
The most popular EMV toolkits include ICC and B2 toolkits. Particularly, these toolkits are quite popular among acquirers in the US.

Selecting a device

The list of all desired devices to be supported needs to be compiled in advance and included into the initial certification. While selecting the devices, one should understand that only terminals and readers, which have EMV level 1 and level 2 certified kernels, can be used.

An EMV toolkit works as both card reader and card writer: it both reads data from the chip and writes new data on it to be read during subsequent transactions.

Developing terminal application

As we’ve mentioned above, firstly, a business wanting to process EMV transactions, needs to select payment terminal, supporting EMV and certified by the acquirer.
Secondly, the integration needs to understand that most terminal manufacturers will not provide a stock payment processing application with the terminal. In this sense, a terminal is similar to a PC with just an operating system installed, without any applications. It is the integrator’s responsibility to procure (develop or license) a terminal payment application, compatible with the hardware and the operating systems of the models of the terminals that it wants to support.

There are various ways to simplify the development process: it can be outsourced, or some existing applications can be purchased; but, generally, it has to be accounted for in the budget for the project.

For deployment and management of the terminals, software updates, remote configuration management a separate software package is used, which is, generally, called, terminal management software.

This terminal application has to be able to utilize required peripheral devices, such as card readers, signature capture etc., and accommodate whatever types of transactions that are going to be required (credit cards, debit cards, gift cards, EBT, etc.).

Most large terminal manufacturers (such as VeryFone) maintain their own payment gateways. A business can purchase a terminal with the manufacturer’s application on it, which is, generally, “tied” to the manufacturer’s gateway. Therefore, if a business wants to connect such EMV terminal to a different gateway, it, generally, has to undertake some software development.

Selecting acquirers to partner with

A business, planning to integrate with several acquirers, needs to understand that each acquirer requires a separate EMV certification for each country, in which the business is going to process.

An average cost of EMV toolkit (which is used in every EMV certification) ranges from $10,000 to $30,000 per user license. That is why, when the acquirer is selected, it is advised to consider the models of the toolkit that the acquirer supports, so that potential cost savings can be realized by going with specific acquirers and toolkit vendors (by using a single toolkit for two or more certifications across different acquirers). And if you are already in possession of a certain toolkit, it never hurts to ask the acquirer explicitly, whether they would accept the tests using your version of the toolkit.

Conclusion

If you are a business considering the idea of going through EMV certification process, you need to select the devices you are going to use, payment gateway and acquirers you are going to partner with; also you need to decide how to get or develop terminal applications. And, of course, you need to carefully plan respective budgets.