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.

Payment Gateways II: Support for Recurring Billing

The purpose of this article is to familiarize the key merchant services industry players with the concept of recurring billing as an advanced feature to be considered during payment gateway selection. If this is the first time you are reading “Payment Gateways II” series, please, start with the Introduction as it will improve your understanding of the current post.

Recently subscription-based payment model has become very popular. The model is predominantly used by membership-centric organizations, such as health clubs, tanning salons, etc. Even traditionally retail industries are implementing the elements of subscription payments into their business practices. For instance, online stores selling such products as water filters, vitamin supplements, skin care products are offering their customers to purchase these products regularly on subscription basis. Because of increased importance of subscription-based business model, recurring billing becomes an essential part of modern payment processing systems, such as payment gateways.

Recurring billing paradigms

When it comes to recurring billing (also known as subscription billing or recurring payment processing) there are two major paradigms, which can be called committed billing and uncommitted billing.
Uncommitted recurring billing would be an on-line subscription, which carries no minimum time commitment and requires no special handling in case of delinquency (usually the service or subscription simply get discontinued). For example, monthly subscription at eFax or premium membership at linked-in.
An example of committed recurring billing would be a term gym membership or a cell phone contract. In both of these examples, if a payment is missed and an account becomes delinquent, a collection attempt is made to reinstate the account and collect any past due. Simply deactivating the service is not an option in such cases.

An important issue arising in connection with recurring billing is cardholder data storage. If a merchant is storing actual payment card data (for recurring billing), it must go through costly PCI compliance certification procedures. Tokenization and profiling provide solutions allowing merchants to reduce their PCI scope or completely get out of it. For more information on tokenization and profiling see here and here.

Another component of recurring billing to be mentioned is decline recovery, as declines tend to happen more frequently when customers are charged on recurring basis. That is why subscription-based businesses should integrate with payment gateways offering decline recovery mechanisms.

Let consider an example of tanning salon to gain better insight into the needs of a business using subscription-based model.

Example

A tanning salon used to offer exclusively annual or semi-annual memberships to its customers, because it lacked the necessary technology to implement monthly payment process. This made attracting new customers more difficult for the salon, as long-term membership required significant upfront payment to join. Now, by going with a payment processor that offers recurring billing, the salon can offer flexible monthly payment plans, making its membership more affordable. At the same time, presence of decline recovery tools makes it easier for the salon to manage decline recycling and ensure that the revenue is not affected by going with monthly billing vs annual billing.

Conclusion

Depending on the type of recurring billing that a merchant needs (committed vs uncommitted), it might want to look for a payment gateway that accommodates that specific feature set. If the business requires committed recurring billing model, it needs to verify, what decline recovery techniques and collection tools are going to be available within the payment gateway it is using.
If repeat purchases are important for a business, then it is critical to find out in advance, whether the processor\payment gateway it deals with offers some form of tokenization.

Out next post will cover credit card BINs and card intelligence.

Payment Concepts: Payment Card Data Storage

This article is the second one in a mini-series describing recommendations to be considered by merchants interested in attaining PCI compliance. In this installment we are going to look into the reasons behind payment card data storage and possible solutions that make PCI audit more simple.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

Reasons behind payment card data storage

There are several reasons for payment card data storage:

  • for reporting purposes and to look up previous transactions
  • for issuing of refunds
  • for repeat purchases and recurring billing

Let’s take a closer look at each of them.

Payment card data storage for reporting and transaction lookup

The question to consider here in terms of payment card data storage is whether it is really necessary to store credit card numbers for future transaction lookup.

If a business is storing the info for reporting purposes without actually doing anything with the card number, it can just store a part of that number (for some merchants it might be sufficient to store just the last 4 digits, solely for identification purposes).

For lookup purposes by full account number merchants can use one-sided hash (information on hashing algorithms can be found here. A common way is to use SHA-256 hashing function with multiple iterations and salt to ensure that the data is hacker-proof.

The hash value is unique, the number of iterations is difficult to guess, and the salt is difficult to crack. Even if the hashing algorithm was determined, the number of iterations established, and the salt guessed, it would still take a considerable amount of time to decode card numbers using brute force approach.

Generally, storage of the last 4 digits and one-sided hash is considered acceptable, but the final “verdict” will depend on your specific auditor.

Payment card data storage for issuing of refunds and transaction settlement

In some cases, merchants would process credit card transactions and store payment card data in order to be able to issue a refund (return money) on the card if the cardholder returns merchandise. Sometimes, certain processors will require full credit card information to settle transactions at the end of the day.

In both cases (refund and settlement) merchants need to consult with the current payment gateway or payment processor to see if there is an alternative option to return money or to perform settlement.

If a merchant needs to return money to a customer, many present-day processors and gateways support refund operation using reference number. When the original sale transaction is processed, a reference number is returned back to the merchant. Subsequently, it is possible to issue a refund passing only the reference number back to the processor, and effectively returning money for that transaction without supplying the original credit card number.

Those, experiencing the problem around settlement (usually, associated with terminal capture) should consult their current payment gateway and see if there is a host settlement (capture) option available that would eliminate the need for sending credit card information at settlement time.

Payment card data storage for repeat purchases and recurring billing

The most common payment card data storage solution for repeat purchases and recurring billing is tokenization. Instead of getting and storing the credit card number, businesses, wishing to have support for repeat purchases and recurring billing, are getting a token from a PCI-compliant tokenization provider. Thus, they can store a token instead of the card number, and reuse it in subsequent transactions\purchases, while reducing their PCI scope.

The concept of tokenization and respective options available to merchants for effective payment card data storage and PCI scope reduction will be covered in the next post.