From Batch to Retail Payment Processing

Introduction

The landscape of modern payment services market is rapidly changing. More and more well established companies, using legacy software, face the problem of expansion of their existing offerings to accommodate the newer needs of the market. One of transition-related issues is the addition of retail functionality to an existing recurring-billing-oriented payment system.

Problem

A well established business, which traditionally functioned as payment aggregator, has recently become a payment facilitator. Its main function is aggregation and facilitation of recurring payments in some industry (membership dues, insurance, installment payments, utility bills etc). Now the company faces the necessity to add a card-present EMV solution to its business offering.

Context

The problem is most relevant to billing companies, which sell their software products to front-end users. Many of such billing software vendors traditionally focused only on card-not-present transactions. They used to function as recurring payment aggregators for a long time, but (under pressure from associations) switch to payment facilitator model. We should remind, that such a transition also allows these companies to get greater control of merchant underwriting process.
On the other hand, under pressure from their customers, they have to add retail component as well as e-commerce processing to their (initially recurring-payment-oriented) payment system.

The pressure from the customers has the following reasons.

Many customers of such companies are brick-and-mortar businesses, which emerged long before online operations became possible. (Recently founded businesses, in contrast to brick-and-mortar ones, operate mostly online and, consequently, do not need any retail components). Some other businesses, representing the clientele of recurring payment aggregators, follow “mixed” operation modes.

Examples

A fitness center receives membership dues as recurring online payments, but sells physical merchandise, such as apparel, foods, drinks, and supplements, at a physical facility. Another example is an insurance company, which collects recurring payments, but wants to be able to collect past due payments and pre-payments in retail environment or online.

In order to be able to accept card-present/EMV payments, some of subscription-based businesses resort to third-party solutions, such as usage of standalone payment terminals. For handling of online payments these businesses can use PayPal or Authorize.net services on an individual basis. However, we should stress, that reconciliation process becomes more complex, as you, potentially, have to reconcile payments handled by multiple systems.

Another issue, faced by recurring billing companies, concerns handling of non-recurring payments. All the payments, made using a standalone terminal (past due payments or pre-payments, for example), have to be, then, manually input into the primary system of record, used for management of recurring payments.

Consequently, in order to ensure greater convenience and flexibility of operations for its customers, the aggregator/payment facilitator has to add both retail and e-commerce processing functionality.

Addition of a retail component, in fact, calls for implementation of real-time processing functionality. As EMV has recently become an official standard for retail payment processing, in a situation like the one just described, implementation of EMV solution becomes a top priority.

In order for your retail payment processing implementation project to be a success, you can use the following strategy, which includes several important steps, and which poses some challenging questions to be answered.

Strategy in brief

You need to understand both business and technological sides of the problem.

Business-related questions are as follows.

  • How are merchant accounts going to be issued? Who will be underwriting them?
  • Which processing system is going to be used?
  • What is the integration cost and how much time will the integration take?
  • What’s going to be the by-rate charged by processor for retail payment processing and what rate will be charged for the merchants?
  • How will funding be handled?
  • How will merchants acquire the necessary equipment? Who will they buy payment terminals from? Is fulfillment center relationship needed? How the terminals are going to be priced (full price/discounts/subsidies)?
  • Which card brands are you going to handle and in which countries?

Technology-related questions are as follows.

  • How you are going to implement a payment terminal solution and go through EMV certification, if necessary?
  • Which architectural changes need to be introduced into the existing system, initially developed exclusively for handling of recurring payments, in order to enable it to support real-time payments?
  • Are you going to use standalone terminals, or do you need to integrate with some POS systems?
  • Will you need only standard terminals or mobile terminals as well?

Strategy in detail

Here (in greater detail) are some important strategic issues to address.

Who will provide merchant accounts for retail payment processing?

Can you stay with your current processor? If your current processor supports different payment modes, such as e-commerce and EMV, can you use them for both recurring and retail payments? If yes, can you provide retail (real-time processing) services as a payment facilitator (the model you are already successfully using for batch processing), or do you need to switch to a different model (say, a retail ISO) to provide retail services? As we explained in our previous articles, under retail ISO model, you will simply resell merchant accounts, while merchant on-boarding and funding will be handled by the processor. If you stick to the payment facilitator model, you will have to handle merchant on-boarding and funding.

If your current processor is CNP-only, should you try to establish a new retail relationship? I.e., should you try to get merchant accounts for retail from a different processor? Does it make sense to move your entire business (both card present and CNP) to the processor that offers all the functionality you need, a better price, and, possibly, some additional services (such as robust merchant on-boarding, chargeback handling, and cross-brand account updater mechanisms)?

How are you going to technologically implement the integration?

Real-time and batch integrations are conceptually different processes. Consequently, no matter, whether you switch to a new processor or stay with the current one, real-rime integration is needed anyway. Moreover, if you need to use EMV payment terminals or mobile devices, you also need to select an appropriate EMV solution. As we mentioned in our previous use case, you have to study hardware options, supported by your specific processors, and, if you want to use your own customized terminal solution, you have to keep in mind fulfillment-related issues.

During the integration, you can either develop the software using your own development team, or use some third-party software product.

How are you going to handle non-recurring payments?

Your existing recurring billing system is, most probably, not adapted for handling of one-time payments. If, conceptually (and architecturally) the system was not intended for support of one-time payments, then addition of non-recurring payment functionality is quite a challenge.

Even if you have the logic to handle one-time cash or check payments, this logic might be too rudimentary to accommodate real-time credit card or ACH processing. Moreover, this functionality is, probably, not fit for handling of complex transaction lifecycles.

Conclusion

Addition of a retail payment processing component to your recurring-payment-centered system can be a major challenge, given all of the items that you have to consider. However, you can consider this challenge as an opportunity to switch to a more standardized and robust payment management platform (such as UniPay Gateway), that will not only solve the current problem, but also improve the overall quality and the capabilities of your existing payment ecosystem.

From ISO to Payment Facilitator

Introduction

Recently the term “payment facilitator” has gained popularity. The role of payment facilitators at the merchant services market has grown significantly. The concept of a payment facilitator is actively promoted in the merchant services industry. Consequently, more and more companies consider the idea of assuming the role of payment facilitators.

Problem

A business, selling merchant accounts, is currently functioning as ISO, but wants to become a payment facilitator.

Context

An ISO, generally, relies on other entities in many aspects of its activity. If a business needs to get a merchant account (purchase it from an ISO), the ISO needs to address some other entity (usually, the payment processor) to handle this issue.
Traditionally, the model functioned as follows. ISOs and software companies, which performed the role of ISOs for their clients, referred their clients to the processors and helped sell the accounts, relying on external gateway. Underwriting and funding was handled by the processors. With time, as the number of clients increased, they realized that the model was not very effective. As a result, payment card associations suggested the concept of payment facilitators, which provided these new entities with greater control over the processes of MID issuing, merchant funding etc.
ISOs have various reasons for becoming payment facilitators.
As we’ve mentioned in one of our articles, a payment facilitator actively participates in sub-merchant funding, and each of its sub-merchants is funded under a separate MID. In view of these functions, to become a payment facilitator, an entity needs to perform several important steps and answer some critical questions.

Strategy

Finding a processing partner

If you are an ISO, you already have a certain number of merchant accounts to support.

  • Are you going to become a payment facilitator with your current payment processor, or find a new processing partner? In either case, as mentioned in the respective article, you will have to sign a separate agreement with your processing partner, and go through the payment facilitator underwriting process.
  • If you are switching to a new payment processor, what is the plan for migration of your merchants? Will all the existing merchants from your portfolio be able to go through underwriting process with the new payment processor? If not, what is the “plan B” for those merchants, which are unable to do that? Some tips on migration to a new processor can be found here.

Pricing strategy and underwriting

If you are going to change our processing partner, you need to carefully study the following two issues:

  • What are the underwriting requirements of the given processor? Which documents and guarantees are required? What are the requirements for merchant services reserves? Remember, that before being able to underwrite your sub-merchants, you need to go through underwriting procedure with the payment processor yourself.
  • What transaction pricing model is offered by your potential processing partner? More information on transaction pricing models can be found in our previous articles, such as this one.

Technical aspects

You need to address several technical aspects. Mostly, these concern the peculiarities of new integration(s).

  • What types of payment cards and transactions do you need to support?
  • How will the new merchants be set up? How will the new MIDs be issued? What is the merchant underwriting mechanism you are going to use? If merchant information changes over time, how will those changes be delivered? In other words, what is the strategy for merchant on-boarding and provisioning?
  • Who will implement KYC (know your customer) logic, verification procedures? Is it going to be the processor or your own development team?
  • How will sub-merchant funding, remittance, statement generation, and reporting be organized?
  • Do you need card-present solutions (which, naturally, call for usage of physical payment terminals)? Which terminals are you going to use? Which processor(s) is(are) going to support particular solutions (card-present and card-not-present, or some others)? If several processors are going to be involved, then merchant on-boarding, funding, and chargeback handling procedures have to be worked out for each of the processors. If you need to process only card-not-present transactions, do you need to handle recurring payments and batch transaction processing? How are you going to handle these tasks? What is your solution for merchant information updating (account updater functionality)?
  • Are you going to handle most of the abovementioned processes manually? If yes, you need to develop training materials for your personnel. Otherwise (if the processes are going to be automated), you need to launch the respective development projects in order to implement the necessary logic.

PCI compliance and fraud protection

What is your status in terms of PCI compliance? What fraud protection mechanisms are available? In order to ensure the security of all the processes, you need to go through appropriate PCI audit as a prospective payment facilitator, and implement the best fraud protection tools you can find.

Conclusion

Becoming a payment facilitator, you are getting more control of merchant funding and underwriting processes, but you are also assuming greater risks and responsibilities. Your transition strategy must include all the aspects, needed to ensure smooth handling of the whole life-cycle of your sub-merchants.

Implementation of EMV Payment Terminal Solution

Introduction

Many companies at the modern merchant services market are looking for an optimal card-present solution to implement. Some of these companies are expanding or re-organizing their activities (a step, which often leads to the need to choose and implement a payment terminal solution). Others are newcomers, which want to accept both card-present and card-not-present payments.

Problem

A company is looking for a universal card-present solution to implement. Either it can be a new solution, which is to replace an old one, or it can be the first card-present solution to be implemented by the company.

Context

The problem is relevant for several categories of businesses:

  • existing companies which already have a card-present solution in place, but want to replace it with a better one (possibly, in response to EMV liability shift)
  • existing companies, which previously dealt only with card-not-present transactions
  • startups that require card-present solutions
  • Strategy

    In order to implement a card present solution in the most reasonable and adequate way, your company needs to take the following important aspects into account.

    What hardware should be used in the new payment terminal solution? Which payment terminals are to be used? What functions should they be capable of performing?

    In order to answer these questions, you should analyze your business situation, the needs of the merchants you are going to service, as well as the price these merchants are willing to pay for the new terminals.

    For example, you might need the cheapest monochrome screen terminals or high-end 7-inch touch-screen ones with the most advanced functionality for your particular case.

    Keep in mind, that payment terminal market is an oligopoly, i.e., it includes only few large vendors, so your choice may be limited. Beside that, most companies’ offers may be quite similar.

    Do you need mobile solutions?

    Some companies offer solutions for both payment terminals and mobile POS systems. Maybe, it might be advantageous for you to deal with such a universal vendor, rather than to involve different vendors for different kinds of solutions.

    Which payment types do you need to handle?

    Do you need EMV contact and EMV contactless payments or are you going to deal only with encrypted swipe payments?

    Do you need standalone or integrated payment terminal solutions?

    Remember, that a payment terminal is just a hardware unit and different kinds of software can be installed on it. While terminal manufacturers (such as Ingenico and VeriFone) offer their own terminal applications, alternative payment terminal solutions are also available from third parties. Such third-party software products may be more suitable for your particular situation, than the software, developed by the terminal vendors themselves (for which you need to pay separately anyway).

    Depending on the type of payment terminal solution that you need (standalone or integrated), you need to evaluate the available software options according to the following three criteria:

    • Quality of user interface. I.e. how the software looks, works, and performs its intended functions inside the terminal (button sizes and colors, supported languages etc.).
    • Ability of the terminal application to communicate with the payment gateway. Some vendors offer terminal applications which are “strategically tied” only to their partner gateways. The question is, thus, whether the terminal application, that you are going to use, is already (or can be) connected to the payment system you need to interact with. You should also avoid situations when in order to deal with different processors you have to use different types of payment terminals and terminal applications, as the process may become too complicated to manage. In other words, your terminal application must be able to smoothly communicate with all back-end payment systems you need.
    • Ease of integration of a payment terminal with the POS system. Many companies still offer legacy integration strategies, which require either installation of DLL libraries or Windows service on the workstation. Both these solutions present deployment challenges, especially, for web-based applications. Beside legacy strategies there are other available options, such as cloud solutions (offered, for instance, by UniPay Gateway).

    As you can see, your choice of a particular terminal solution will not depend so much on the physical hardware and its price, as on the availability of your preferred terminal application on particular terminal models, or on support of a particular payment gateway by the terminal application you want to choose. For example, if your bank or payment gateway tells you that you can only use Ingenico, it makes no difference if you find Verifone more suitable for your business.

    Fulfillment strategies

    One of the most important aspects to consider is payment terminal fulfillment. I.e., who will be loading the new terminals and shipping them to your merchants. There are several options possible.

    You can buy a batch of (say, a 1000) terminals from a vendor or manufacturer, and then use an internal team to inject the respective keys and terminal applications into them as they are shipped to merchants (in smaller quantities). This process requires a whole infrastructure. Although this option is plausible for some companies, most businesses choose to delegate terminal fulfillment to special entities. Consequently, you can partner with a fulfillment center that will install software applications on the terminals, service the terminals, and handle terminal replacement.

    When choosing a fulfillment center, you should consider the following issues:

    • what it costs to buy a new terminal or replace an existing one; what the shipping rates are
    • which software applications (custom software packages) can be loaded
    • which terminal models it supports
    • with which processors it has agreements for PIN key injection (as it needs to be able to inject respective encryption keys), and in which countries
    • if you need some particular terminal application to be installed on your terminals, you should check with the fulfillment center, if it is able to install this application for you.

    When you find a fulfillment center, which is suitable for you in terms of pricing and servicing conditions, and a terminal application, which supports the payment gateway you are (or are going to be) partnering with, your choice of payment terminal solutions may become very limited.

    Example

    You have done a market research and realized that your options include Ingenico iSC 250/480 or VeriFone MX 915/925. However, in order for your terminals to be able to interact with your payment gateway, you need a special terminal application. Only two fulfillment centers are able to install this particular application, and only one of them deals with the three processors, whose keys you need to inject. This fulfillment center supports only Ingenico terminals. In this situation there is no point in some in-depth analysis of specifications and price offerings of VeriFone, as Ingenico turns out to be your only choice.

    EMV certification (if necessary)

    If you need to support EMV standard and keep using your own payment platform, you will need to integrate your terminal solution into an existing payment ecosystem (i.e. integrate your terminals with an existing gateway). This means that you need to go through EMV certification process.

    Remember, that each EMV kernel, installed on devices, which you are using within your solution, must be separately EMV-certified. Consequently, in order to simplify EMV certification process, you need to minimize the number of EMV-kernels on your devices (including EMV-kernels provided by one and the same manufacturer/vendor).

    Example

    A company wants to work with a certain number of models of terminals and mobile devices. Some mobile devices are using the EMV kernel which is used by payment terminals, while other mobile devices are using a different EMV kernel. (For instance, Ingenico uses both its own mobile solutions and solutions, developed by ROAMpay before its acquisition by Ingenico). In this case the company has to certify two EMV kernels, i.e. go through two certifications.

    In order to minimize the number of EMV kernels and, thus, reduce time and cost of EMV certification process, you need to verify, whether all the devices you are going to use, are made by the same manufacturer, and whether one and the same EMV kernel is installed on all the models of these devices.

    Conclusion

    Many newcomers in the merchant services industry erroneously think that selection of a card present solution starts with the analysis of available hardware options. Selection of hardware, in fact, may be the last phase of the process. You should, definitely, know the names of the key hardware brands. However, a decision, based only on hardware specifications, may result in a costly error. The key factors to be considered first and foremost often include terminal application compatibility, support of the necessary gateway integrations, number of necessary EMV certifications (if they are needed), and preferable fulfillment strategies

Getting out of PCI scope

Introduction

More and more companies nowadays accept credit card payments. Payment card industry is regulated by Payment Card Industry Security Standards Council, which has specific security requirements. According to these requirements, each company, dealing with card data, has to go through regular PCI audit, which is quite a costly procedure. That is why many companies are trying to find the answer to the question: how can a business accept payment cards, but remain out of PCI scope.

Problem

The general problem is to move the existing payment system, which is presently in PCI scope, out of it. At the same time, the system has to be able to perform its functions as before.

Context

While some companies cannot avoid PCI audit, because their payment systems are too large, a number of merchants and software companies are technically able to reorganize their infrastructure in such a way, which would allow them to either get out of PCI scope completely, or reduce their “exposure level” and PCI audit costs.

From conceptual viewpoint the problem has several complexity levels.

  • Level 1: Card present vs card not present. If only CNP transactions are involved, it is much easier to reduce exposure level.
  • Level 2: Number of front-end systems.
    If only one front-end system (for instance, a POS system) is involved, the process becomes much more transparent. If there are many front-end systems, a solution must be found for each of them.
  • Level 3: Which kinds of applications are involved?In some cases web applications might be easier to remove out of PCI scope, than desktop applications. If you are dealing with a legacy system which uses obsolete technologies and has limited functionality (or, maybe, the developers who created the system are no longer with the company), the task becomes even more complex.
  • Level 4: Are recurring payments involved? If the answer is “yes”, then there is a need to store cardholder data, and the matter of exposure reduction gets trickier.
  • Level 5: Are all the merchants using different payment systems? Say, if you are a software company, the users of your software can either partner with the same PSPs, or have different independent (individual) processing solutions. So, is payment processing
    unified for all users of your platform, or do they have customized processing solutions associated with local banks or processors?

Strategy

In order to optimize your business infrastructure and successfully get your company out of PCI scope, or at least, reduce your exposure level, you need to perform the following important steps.

  • Consult the PCI auditor. Whatever strategy you have in mind, discuss it with the PCI auditor before implementation. Then compile all the necessary documents to start the process.
  • Decide, which of the components of your payment ecosystem have to be phased out. In the simplest case the system consists of a single software package. However, in many cases, it can include several packages, different terminal solutions, etc, and these components and solutions have to be prioritized.
  • Decide, if (similarly to the previous step) you need to sunset your integrations with some processors and migrate merchants to other processing platforms in order to unify and simplify the process.
  • Decide, whether you need to unify payment processing across your customers. Do you, potentially, need to reduce the number of supported processors and simplify the overall infrastructure, in order to make it more transparent.
  • Decide, whether you need to store cardholder data. If your company uses terminal capture, then you have to send the file with card numbers to your processor on a regular basis. Consequently, you have to store card numbers within your system. However, if you switch to host capture, card numbers no longer have to be stored in the system and sent to the processor.
  • Analyze the following two basic issues in the context of exposure level reduction: card flow and card storage (if necessary). Card flow can be handled in two ways: either using payment pages (mostly for CNP solutions), or (for card present solutions) using P2PE on card readers or payment terminals. For card storage a classical solution is tokenization of card data.
  • Verify, whether CNP, card present, and recurring billing solutions are supported by each of the PSPs your system works with. We should remind that if recurring billing is involved, you or your partner PSPs have to store and, consequently, tokenize card numbers. If some of the PSPs do not support all the necessary services (or if it is more relevant to work with some unified processor-agnostic service and eliminate the necessity to support different tokens), then you should consider partnering with some independent (processor-agnostic) tokenization services. Some information on migration from one processor to another can be found here.
  • Plan the integration works which have to be done for implementation of the new infrastructure. These may include integrations with tokenization services, P2PE service providers, and other entities.
  • Plan cardholder data migration process. If actual card numbers are stored within your system, or if your current tokenization solution is only partial, you need to decide, how and when card numbers will be migrated.

Conclusion

Even if you understand that you are unable to get your system out of PCI scope completely and all you need is to simplify the process of cardholder data handling, you might consider using some standardized open-source payment technology (such as UniPay Gateway), which is capable of performing all the necessary functions, within the existing payment ecosystem. This step will allow you to unify many internal processes and, thus, simplify PCI audit procedure.

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.