Dealing With Multiple International Payment Platforms

Introduction

Present-day globalization tendencies push more and more businesses to process payments in multiple geographical zones.

Particularly, such companies include businesses, which start offering their products online internationally, and franchises, which enter international markets.

The purpose of this article is to outline the problems faced by these companies and try to provide structured step-by-step strategy that they could follow.

Problem

Let us say, there is a company, which wants to solve the problem of multi-currency and international transaction processing for itself or for its clients.

Context

The task of entering an international market can be addressed at one of the three “complexity levels”.

  • Level 1: A company wants to process its own transactions (product sales) in different countries.
  • Level 2: A franchisor wants to operate in different countries, but in each country at most one processing partner is sufficient (a franchisor can impose all franchisees to use a single processor).
  • Level 3: A software vendor company wants to service many clients in different geographic zones using several processing options (support more than one platform or acquiring bank in each country).

Strategy in brief

The crucial issues you will definitely have to deal with (if you want to expand your operations to multiple geographical locations) include:

  • Finding a solution for operations with several currencies
  • Prioritization of regions
  • Prioritization of typical transaction types handled by your payment ecosystem
  • Organization of underwriting and on-boarding processes in new geographies
    • Strategy in detail

      In order to organize the process properly, first of all, you have to study the overall situation and then – answer some fundamental questions.

      • Is it going to be possible to settle transactions in one single currency, or settlement currency must always be the same as authorization currency? If a company wants to charge its customers in a local currency and settle the funds from international sales in a single bank account, it can partner with a single acquirer, that supports dynamic currency conversion. If it plans to settle transactions in the local currency, then a local relationship with a specific bank will be required. In the second case a more complicated payment ecosystem will have to be built.
      • What are the high-priority and low-priority regions? What the actual transaction volume is going to be? Evaluation of transaction volumes is necessary for pricing negotiations and related issues. Establishment of the relationship with a payment processor and implementation of the required technical integration is never a simple process. It takes plenty of time, and it becomes even more difficult at the international scale, especially when several projects are under way. Most likely, you will have to proceed in the sequential manner, which is why it is important to prioritize.
      • What are the transaction types you need to process? Are you going to deal only with online card-not-present transactions? Is card-present transaction support required? Will you need EMV support and respective payment terminals? Usually, it is much easier to find a card-not-present solution, because various local regulations exist for use of the chip cards in a particular region. In some cases region-specific specifications are necessary for you to be able to accept cards in the retail environment. The additional challenge is that in some countries it is not possible to certify your existing EMV solution, and you may be required to use whatever is available on the local market. Some of these available solutions might not fit into your existing payment ecosystem.
      • Which banks will handle the underwriting process, and how merchant accounts are going to be issued? How are you going to integrate with these banks? What is the specific connection mechanism? These questions are extremely relevant for many countries. However, in some countries (say, in North America) there are payment gateways, which work with several processors or acquiring banks, and are able to facilitate your relationship with any one of them. On the international arena, the options might be more limited, because some regions have only few acquiring banks, and some gateways might be limited to work with only specific acquiring partners.

      As we can see, all business details (including corruption as well as local regulations and legislative barriers, which might result in cost increases) must be discussed and considered in advance.

      You must find the gateway, providing the best solution in each specific country in view of the listed questions.

      Finally, you will get a list of countries, banks and payment platforms you will have to partner with. After that you will have to analyze the available gateways and check, which of them have either all or most of the necessary bank connections.

      Example

      Let us consider a case when some “optimal” solution is found. Say, there is a gateway, which supports 3 of the 5 necessary bank connections, but is unable to add the missing 2 and all the subsequent ones (or the payment gateway provider is reluctant, because the cost of new connections is too high). This is just the case when you have to consider creating your own payment ecosystem (for some companies this might be the overall goal).

      Next you have to define, in which countries you will have to start from scratch, and in which countries you have some clients (merchants) already using the system. Keep in mind, that in any case if you are going to expand your operations, a strategy will be needed for on-boarding of new merchants.

      Existing clients

      Example

      A franchising company is a vendor of software for fitness centers. It doesn’t have any integrated solutions within the country. Franchisees have to establish a relationship and purchase standalone terminals from it. Every transaction, made at POS, is processed using the standalone terminal, and then – keyed into the main system of record, provided by the franchisor. The franchisor decides that the solution based on usage of standalone terminals is a bit complicated and it is better to offer integrated payment processing functionality. In this case the franchisor has to migrate the already existing merchant accounts.

      In such a situation, you have to analyze, how to migrate these clients from their existing solutions to the company’s main product. Beside that, you need a strategy for the new underwriting process (get new merchant accounts for the already existing merchants and check if processing costs are going to increase). Finally, you have to define, which technical solutions are needed (in terms of additional integrations) in order to allow merchants to be able to send transactions for processing.

      New clients

      If you have no clients (yet) in some region, you have to work out operations for on-boarding process in each particular country.

      Conclusion

      If you are planning to enter foreign markets, handle new currencies, and process transactions internationally, you need to set up priorities and develop a step-by-step expansion strategy.

Legacy System Replacement

Introduction

A lot of already-established companies are still using solutions, based on legacy software that was developed using mainframe systems. Many of these companies want to switch to newer solutions from archaic older ones. However, the process presents certain difficulties.

Problem

A company is using a legacy system, which performs all the critical payment handling functions for the company. The system is strategically important, because all company’s business operations revolve around it. The company needs an efficient way to migrate to the new solution.

Context

While it often seems obvious that an old system needs to be replaced with a new one, the actual implementation of the new system is a very challenging process. Let us suppose, there is a legacy system, used by some organization. The legacy system has many integrations with banks and other entities. Also, many front-end systems (such as POS and CRM systems) are connected to the legacy system. A lot of data of various kinds (merchant data, transaction data, etc.) is stored in the system. Certain rules, implemented in the legacy system, are not always trivial or obvious. People, who implemented them, might no longer be working with the company. At the same time, the system is used by the whole company and many vital operations rely on it.

Strategy in brief

As we can see from the previous section, the main question is how to migrate all the integrations, business logic, and data to the new system. Keep in mind that some new logic and business processes might have to be added to the new system during the migration.

The main issues to be addressed in the context of transition from the legacy system to the new one are:

  • PCI compliance
  • Integrations with processors
  • Integrations with front-end systems
  • Personnel training
  • Data migration

In the next section we are going to describe the steps, addressing each of these issues one by one.

Strategy in detail

In fact, there are several options a legacy system user can follow. We are going to use the example of one of our clients, which faced the problem of legacy system replacement and successfully managed to solve it.

Environment preparation

The first thing you should do is prepare PCI environment and install the respective software into this environment. If hosted environment is used, then all the respective hardware and software has to be provisioned into the cloud platform.

Optimization of integrations with processors

You should decide, which integrations have to be implemented to enable real-time and batch processing of transactions, account updater, chargeback handling, and merchant on-boarding. Possibly, you have to sunset some of the existing integrations, if the number of merchants using these integrations is relatively small. These merchants will have to be migrated (transferred) to the new platform, terminated, or temporarily retained on the existing platform.

In other words,

  • transaction volumes have to be analyzed,
  • based on this analysis, the key platforms for future integrations should be selected,
  • the future of the existing integrations with low-transaction-volume platforms should be decided. You should decide whether the migration is worth the effort, as certification of each new integration is a time- and labor-consuming procedure (see, for example, article on EMV certification for details).

Analysis of integrated systems

You should conduct the analysis of all the front-end systems, integrated into the existing payment gateway, and decide, whether these integrations are relevant for the new product.
Front-end systems include POS systems, CRM systems, web-sites and online services, that process payments through them, any mobile terminal solutions, or any other systems, that submit transactions into the legacy system for processing.

Just like in the case of merchants and processors, the options are: to migrate the systems, to leave them temporarily integrated with the old platform, or to phase them out (as legacy products used by a very small number of clients).

Once the inventory of the integrated systems is taken, and the decision is made as to which of them must be re-connected with the new system, the most appropriate re-integration strategy must be worked out.

Fundamentally, there are two ways to accomplish this.

  • Integrate the new system with the new payment processing system using the new system’s standard (native) API. This implies changes made in the front-end system and may not be appropriate for cases when the front-end system can no longer be modified.
  • For cases when it is not desirable to change the front-end system, an emulator of the legacy system’s API can be implemented in the new system. This way the news system will be able to accept transactional information from the front-end systems in legacy format that was used before.

Analysis of the business processes

The next important thing to do is analysis of all the business processes (and how they are performed) with the operations team. The business processes include merchant on-boarding, reviewing of files, settlements, funding, reconciliation of deposits, and others. Equivalents to these processes should be found within the new gateway. Gaps should be identified and plans should be worked out for implementation of the respective new logic. Sometimes, the logic might be already in place, but additional training materials are required, in order for the team to be able to use them for reference while working with the new system.

Development of data migration strategies

The next step to take is to decide, how the data is going to be migrated. The relevant data, usually, includes

  • Merchant settings (MIDs, settlement times, etc.)
  • Tokens (payment information, which might be used in future)
  • Recurring billing schedules (payment plans)
  • Transactional activity (statements, transactions)

You should define the ways of handling each of these data types.

Merchant settings, generally, have to be migrated. Migration is, usually, done through API or file formats of the existing gateway. It is preferable for the mechanism to allow you to transfer the merchants from one platform to another one by one. If transition goes flawlessly for one or two merchants, other merchants can be moved as well. Ideally, you should devise an approach, allowing you to add new merchants to the new system, and, at some point, import all of the existing merchants into it. Keep in mind, that the information of a merchant might get changed before it goes live on a new system and some manual adjustments after the import process might be necessary.

Tokenization data requires special attention. Tokenization data is not always readily available. Sometimes the tokens are stored by the processor and extraction of the data has to be ordered in advance. A special process might be required for conversion of tokenization data from one vault to another (re-tokenization). The tokens will have to be updated with the already existing systems. If tokens cannot be updated, you need to devise a strategy for token mapping with the new values in the existing gateway. As you are dealing with tokenization, PCI compliance issues will also have to be addressed.

Recurring billing data has to be addressed separately, because billing history and balances might be required for future analysis.

As for transaction data, in most cases there is no need to migrate it (although, sometimes, when recurring billing is involved, migration is necessary). If necessary, the respective reporting documents with transaction data can be found in the old database. If the data has to be transferred, a separate strategy is needed for the transfer. If the API is available, transaction data transfer can be performed through the API, if not – migration should be done at the database level.

Preparation for PCI audit

If PCI compliance remains the responsibility of the company, originally owning the legacy system, it needs to prepare all the documentation, necessary for the future PCI audit. It is easier to record all of the procedures at the initial development phase and analyze all of the PCI consequences at that time.

Conclusion

Before replacing your legacy system with a new one, you should gather the information on the transition process and devise a clear system replacement strategy.

Intro: Business Solution Upgrading Challenges

Having worked with different companies in the merchant services industry, we realized that there are certain factors, which are crucial for success or failure of projects, associated with large payment systems.

We decided to write a series of articles, in which we are going to outline the aforementioned crucial factors, present the most typical problems in payment industry, and explain how these problems can be resolved using modern technologies (such as UniPay gateway payment platform, which can become a basis of some particular solution).

A project is, usually, associated with a situation when a new payment-handling component (payment system) is added to an already existing business solution (by a software user or software vendor). Either the component is added to perform new functions, or it replaces an old component in order to perform its functions more efficiently. The business solution may be some system, servicing, for example, a network of stores or fitness centers. The new component may be developed either by the internal team of the company, which uses the business solution (the network of supermarkets or fitness centers), or by some external software vendor.

Strategic planning challenges of business solution upgrading

In most cases the projects are very complex, because without respective experience it is difficult to work out a winning strategy, which allows the company to take all the issues into consideration.

Lack of information

One of the reasons for strategic planning problems is the lack of necessary information, because salespeople, who negotiate the implementation of the new component into the existing solution (sometimes called business development people) are often unable to understand all the technical details during the initial phase of the process. Misunderstanding often works both ways: representatives of the software vendor are often unable to explain these details to the customer, while representatives of the customer (company, business network) are unable to ask proper questions. Consequently, when it comes to implementation of the technical details in question, unexpected problems emerge.

Logistical gaps

Another reason for strategic planning problems is thelack of appropriate logistics. They say project implementation involves a lot of moving parts that need to be put together. Without particular experience with certifications, PCI compliance, deployment of enterprise clusters, or other specific issues, it is very difficult to work out a general timeline, list the necessary resources and their amounts, define the future linking points, etc.

In order for a project to be successful it is necessary to clarify all the details during the initial phase. Beside that, it is necessary to plan all logistical aspects (which systems are going to be involved, how they are going to communicate, where they are going to be deployed, who is going to provide technical support for them, etc.).

While the company, that wants to implement some new component, usually, understands the importance of these two steps, sometimes it does not know, which particular questions it should ask the software vendor in order to get a complete picture of the task. As a result, a project is often launched with one set of parameters (budget, timeframes), while in the process of its implementation new details emerge, requiring budget increase and deadline extension, and in the end the whole project may turn out to be a failure.

The purpose of our series of use cases is to present several “templates”. In each article we will outline the initial problem, list the key issues, which have to be considered and clarified, and present a draft plan of action, featuring the steps, which need to be taken in order to make your project more successful.