Mobile Payment Processing Techniques

There is no doubt, that the role of mobile devices in our lives is rapidly gaining importance. Nowadays mobile devices and payment applications installed on them are often used for handling of online purchases. In this article we are going to address the ways of making and accepting payments through mobile devices. We will discuss the ways in which mobile payments can be processed and the types of payments that can be made with mobile devices.
The main problem of payment application usage is how to deal with PCI compliance in each particular case. We are going to consider several conceptual approaches, which allow people and entities to accept payments, and, at the same time, reduce their PCI exposure.
Conceptual approaches to mobile payment processing are as follows.

Mobile payment processing through In-App payments

The first and most widely available approach is the so-called In-App payment. It is used by the most popular online stores, selling apps, such as App Store, Google Play, and others. They offer payment APIs, allowing to accept payments from the user of a given mobile app. In case of In-App payments, PCI exposure is completely avoided, as cardholder data is handled by the apps marketplace.

Mobile payment processing through a payment page

The second approach is usage of a classical web-page (payment page), which is accessed by an app that needs to collect the payment on a mobile device. In this case the payment page is located on the payment server of the payment service provider, which handles transaction processing for the app marketplace. This allows the app that needs to collect the payment to remain out of PCI scope.

Mobile payment processing through integration with the PSP

The third approach is to perform the integration of your mobile app with the external API of the payment service provider.
In this case you have to be careful not to increase your PCI exposure level.
If you choose to integrate your app with the payment system of your PSP, there are several ways you can follow.

  • You can use a payment application, provided by the gateway, and control its operation through so-called inter-app communication.
  • You can use the SDK/API, provided by the payment gateway.

Depending on your PCI strategy, you can choose one of the listed options.
In both cases it is better to consult QSA regarding your PCI status. However, if you do not have a QSA and plan to do a self-assessment questionnaire, then inter-app communication is the safer option.
The advantage of the inter-app communication is that your application code is completely separated from the payment application that actually processes the payment.
The disadvantage of inter-app communication is that you have to operate two payment applications instead of one.

How to process payments

Within the mobile environment both card-present and card-not-present transactions can be processed.
To process card-present transactions you can use some external device. Traditionally, conventional card-readers were used. However, nowadays, many other solutions emerged, which allow you to accept EMV cards and input PIN. Some of these modern devices are operated through Bluetooth technology. So, you can choose a device to integrate with, if you need to process some particular types of cards and transactions.
For card-not-present transactions two options can be used.

  • One option is to input card data manually, using the on-screen keyboard of the mobile device.
  • Another option is to use special external libraries, such as They allow you not to input card data manually, but instead just take a photo of your card using the camera on your mobile device. Cardholder name and card number are extracted from the card photo using image recognition algorithms. As we see, in this case, a traditional card-not-present transaction is performed, however the cardholder does not have to input card number manually.


There are different approaches, which you can utilize for mobile payment processing. Your choice will depend on your technical/functional needs and on transaction pricing offering of a specific PSP (for instance, in-app communication is quite expensive in comparison to classical payment gateway integration).

Getting out of PCI scope


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.


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.


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?


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.


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.

Legacy System Replacement


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.


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.


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.


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.

The challenges of mobile EMV solutions

The purpose of this article is to familiarize the readers with the challenges of implementation of mobile EMV solutions. The article is primarily targeted at software companies, which are looking for effective approaches to integration of card-present solutions into their mobile applications. The article might also be of interest to payment gateway providers, trying to solve the problem of mobile EMV solutions for their clients.

Lately a lot of new mobile POS systems emerged, which were based on various kinds of card readers for smart phones and other mobile devices. For example, Square Readers represented one of the first available solutions, which allowed merchants to turn their cell phones into mobile POS systems.

We should stress, that the first mobile payment card readers scanned the data in an unencrypted format. In order to manipulate the reader, a native app has to be installed on the mobile device (i.e., the card reader cannot be controlled by a web-application from the web page). Consequently, a mobile card reader, that “touches” the unencrypted card data and communicates it to the mobile device, puts the whole mobile POS system within the PCI scope.

In order to better protect cardholder data and get the POS app out of PCI scope, several solutions are available. However, when EMV is involved, some of the solutions work better than the others.

Similarly to payment terminal solutions, mobile card-present solutions can be conceptually divided into three groups: integrated solutions, standalone solutions, and semi-integrated solutions. Let us address these solution types one by one.

Fully integrated solutions: EMV certification required

In pre-EMV world most companies used encrypted card readers, which encrypted card data at the moment of swipe and, thus, got the app out of PCI scope. If you apply the same methodology with EMV, there still remains a problem with EMV regulations.

The mobile POS app needs to be integrated with the payment gateway or payment processor, which is going to handle the payments. At the same time, it needs to be integrated with the EMV reader, which is going to scan the card data. If you integrate with the EMV reader, you have to go through EMV certification (using the EMV toolkit), because in this case, transaction path will go through the mobile application. Consequently, the mobile application is included into the EMV path, and it has to be re-certified every time when some change is introduced either by the gateway or by you (the POS app developer), as required by EMV regulations.

You also have to remember, that, in order to do initial certification, you have to understand the EMV certification process, buy an EMV toolkit, pay the developers, and spend a lot of time and money to complete the task. The whole EMV certification process might take three to six months.

In order to get the POS system out of the scope of EMV regulations, and, at the same time, protect the integrity of both EMV card and EMV kernel of the POS app, you can use either a standalone solution, or a semi-integrated one.

Standalone mobile EMV solutions

This solution implies the use a separate, “isolated” application for handling of payments (EMV payments included). For example, a software package, obtained from the payment gateway provider, can be installed on the merchant’s mobile device. This package is capable of performing basic payment operations. This solution is equivalent to a standalone payment terminal. The point is that the software package provided by the payment gateway is independent from the mobile POS system or app, and, at the same time, it is already EMV certified by the payment gateway.

In order to accept a payment, the merchant switches to the EMV-certified payment app, provided by the gateway, completes the payment, and then switches back to the POS app (mobile POS system), provided by the software vendor, to confirm this payment.

As we see, the POS app remains out of the EMV path.

Semi-integrated mobile EMV solutions

Another EMV mobile solution is a semi-integrated one. It is more flexible and provides somewhat greater control of the business logic than the standalone solution. However, this solution is more complicated, than the standalone one, because in order to implement its particular architecture, you need to get approvals from processors and associations.

In case of semi-integrated solution, you have to create an independent, autonomous component. SDK of this component should give your mobile POS system the opportunity to control the overall flow of business logic, but does not allow any interaction with the EMV kernel, or any control over payment processing workflow. The component itself is responsible for the transmission of the data to the payment gateway. It is also EMV certified on its own as embeddable solution. Therefore, other software packages that integrate this component into themselves, can rely on its EMV payment processing functionality, but remain out of EMV path (and out of PCI scope).

This solution is, in some way, a “gray area”. It imposes particular requirements on the architecture of the component. Architectural solution, allowing the component to keep the software package, that integrates with it, out of EMV regulations scope, will depend on the particular processor that you work with.


When you consider implementing your own mobile EMV solution, you need to keep in mind the needs of your existing (and, possibly, potential) customer base. Will you be able to get away with the standalone solution? Will it be better for you to offer your clients an integrated solution? If you want to go with a semi-integrated solution, be sure to approve your overall design with the EMV certification team of the underlying processor, before you embark on the actual implementation.

EMV payment terminal cloud demystified

In our previous articles we mentioned embedded payment terminal solutions, however the concept of payment terminal cloud is still an innovative one. The purpose of this article is to describe a new conceptual approach for embedded solutions, a technology called NIO (non-blocking input/output or non-blocking i/o). The technology allows to create a kind of a payment terminal cloud, that can be manipulated.

The majority of traditional non-embedded solutions, and many embedded solutions as well, are based on the assumption that the POS communicates directly with the terminal (i.e. sends all the messages directly to the terminal).

As we explained in the respective article this communication can be organized through a serial/USB port, or through the local IP of the terminal (using Ethernet cable). However, with the emergence and development of NIO technology, it became possible to use an alternative approach, where the POS does not actually have to ever communicate directly to the terminal.

The concept is very similar to many chat programs. When two people want to chat with each other, their chat client software (remote clients) subscribes to the centralized chat server. When the first person types a message, it is sent to the server and delivered to the chat client of the second person, subscribed to receive messages. The response is delivered back to the first person in the same way.

A similar mechanism can be used to control the work of a terminal. Particularly, a terminal, when initialized, can open a channel for communication with the server and keep it open (persistent connection), so that it can receive any notifications, which are addressed to it. On the other hand, a POS system can also get connected to the server and send commands to the terminal, which is already connected to this server. When multiple terminals get connected to the server in the way described above, a so-called “terminal cloud” is formed. Many terminals are maintaining connection with the server. Once the POS gets connected to the cloud, it can send messages to any connected terminal through the channel, maintained by this terminal.

Formerly, the solution was hard to implement, especially for large number of terminals, as support of multiple persistent TCP connections required too many resources. Presently, NIO technology, which can be built into a terminal and initialized on a server, allows this server to support thousands of open connections without requiring significant resources from the server.

The advantage of the approach is that it allows for usage of the same integration concept for card present and card-not-present transactions. In both cases a POS system sends messages to the server (or payment gateway) in the same way, while in traditional systems card-present and card-not-present transactions represent two different data flows (card-present transactions are, traditionally, handled through integration with the terminal, while card-not-present ones are sent to the gateway).

Another advantage concerns simplification in terms of PCI compliance. The terminal communicates with the gateway, and thus, POS remains completely out of scope, because it neither touches card data, nor communicates directly with the terminal.


If you are a provider of a web-application, or a mobile application, which needs to manage terminals without any local footprint (.dll libraries), or if you use OS, for which there are no available terminal adapters of terminal integration libraries, you need to search for a terminal solution, which is based on payment terminal cloud approach.
If you are a developer of payment terminal solutions, you can utilize payment terminal cloud concept. It makes your solution more promising, as it becomes acceptable for a broader spectrum of potential customers.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic

PA-DSS Certification

All developers of payment applications, at some point in the life of products face the challenge of PA-DSS certification process. In this article we are going to look at this process a little bit more in detail.

PA-DSS is an officially adopted data security standard to be followed by developers of payment applications, that are installed in the PCI environment. The difference between PA-DSS compliance and PCI compliance is that PCI certification is a mandatory procedure for a card network or an organization intended to ensure that the network\organization is following all the necessary requirements, while PA-DSS certification is particularly targeted at payment software developers and vendors. PA-DSS certification of a payment application developer company indicates a high level of compliance with the necessary rules of respective software products’ development.

More information on PCI and PA-DSS requirements can be found here and here, respectively.

Let us now look at the key elements of PA-DSS certification, and list the documents, which a software vendor should have available in order to go through certification process successfully.

PA-DSS certification phases

Generally, to conduct PA-DSS certification, a software vendor contracts a certified PA-DSS assessor, such as Coalfire, SecurityMetrics, Trustwave among others.

The key steps within PA-DSS audit are as follows:

  • Gap analysis. The process begins by software vendor filling out some form of questionnaire, allowing the assessor company to understand, which “weak points” or “gaps” will need to be addressed in the process of audit. The gaps in this context mean absence of some processes or procedures, required by PCI standard.
  • Product installation in the PA-DSS compliant lab. The product is installed in the lab environment, where it is to be tested for compliance.
  • Documentation analysis. At this stage installation documentation and diagrams are analyzed.
  • Product testing. The product is tested in all environments (operating systems) that are or will be used for its operation at clients’ sites.
  • Remediation. During this period any identified issued, that violate compliance, are addressed.
  • Final certification. After the remediation stage, when all the gaps are eliminated, the product is subject to final certification.

Documents, necessary for PA-DSS certification

If you are a software vendor, going through PA-DSS audit, we recommend you to prepare several important documents in advance, so that you could have them handy at the time of your final certification. This will simplify your PA-DSS audit process significantly.

The documents are as follows:

  • Implementation guide. This document describes the steps that must be followed in order for your application installations to comply with Payment Application – Data Security Standards (PA-DSS). The information in this document is based on PCI Security Standards Council Payment Application – Data Security Standards program. Product installation guide is one of the sections of the implementation guide. It includes the necessary PCI information on how to install and maintain the product correctly.
  • Software development life-cycle (SDLC) description. This should define the phases of define the phases of the software development cycle, paying special attention to software code review procedures, associated with PA-DSS requirements.
  • PA-DSS SDLC requirements list. This is an additional document with specific requirements to SDLC, concerning development processes, development environment, and development of the specific application. The document is a framework of the information needed to fill in your existing SDLC process with the requirements for PA-DSS. You can view it as a checklist to make sure, that each requirement is in your SDLC, and if not, add it to the appropriate location.
  • Description of training procedures for developers. The document must specify the frequency of PCI and PA-DSS compliance trainings and include the list of training materials used.
  • Description of support and troubleshooting policies. This document describes the procedures used to support and maintain the product. It should be clear from the document that cardholder data will not be compromised during product maintenance procedures (no card numbers will be accidentally stored etc).
  • Installation guide for resellers. If resellers are involved in product installation (if the product is installed by some third-party reseller and not by the software vendor company), the guide must provide instructions on how the reseller should install the product in a compliant.


PA-DSS certification is a rather complicated procedure to go through. However, if you are a payment application software vendor, PA-DSS certification provides you with additional security guaranties. Beside that, it allows your company to organize your development team and structure the development process in a more efficient way. And, finally, the status of a PA-DSS certified software vendor, definitely, strengthens your business reputation.

4 Cs of Recurring Billing

The purpose of this article is to explain the key mechanisms a business must put in place to implement a coherent recurring billing solution. While in one of our previous articles we described the 3 Cs (creation, conveyance and collections) from a general transaction processing perspective, in this post we are going to focus on recurring billing processing and define 4 Cs of a recurring billing solution.

Each of the Cs reflects a certain aspect of recurring payment processing.


As we mentioned in the article on 3 Cs, creation of payments is associated with a system, from which these payments originate. The key elements around the creation phase of a recurring billing solution are:

  • Subscription Types. Subscription types reflect various service and product options offered by the merchant.
  • Payment Plans. Payment plans reflect specific payment arrangements (frequency of payments’ recurrence etc)
  • Payment Methods. Payment methods include electronic form of payment to be used in recurring billing process
  • Payment Page Security. This aspect incorporates means for capturing and secure processing of cardholder data. Detailed information on payment pages can be found in the respective article.


It has been mentioned that compliance is a critical issue in recurring billing context, as recurring billing requires cardholder data to be stored somewhere in order for subscription-based business to be able to access it at regular intervals, when the actual billing takes place. Detailed information on PCI compliance requirements can be found in the respective article. The items to consider in the context of compliance are:

  • Card Data Storage (who is going to store cardholder data and how it will be stored). Cardholder data storage options are described in the respective article of our blog
  • Tokenization. One of the most common solutions for PCI compliance is tokenization. As we described in our respective post, tokenization is a flexible mechanism allowing companies to reduce their PCI scope or even get out of it completely, while still being able to process recurring transactions. The company must decide, how to implement tokenization in order to make PCI audit as smooth as possible
  • Data Ownership. The inherent problem of tokenization is the ownership of cardholder data. Ownership (and, particularly, change of ownership) of cardholder data is a tricky matter, especially, when it comes to third-party tokenization. If the company uses tokenization services, provided by some external entity, and wants to switch to another tokenization services provider, the original provider might claim the ownership of cardholder data and refuse to handle it to the new provider. In order to avoid situations like this one, data ownership and related matters must be taken care of and agreed upon in advance


As we mentioned in the article on 3 Cs conveyance of payments concerns relationship with payment gateways through which transactions will be submitted to the processor. Conveyance of payments calls for implementation of the following important aspects and relationships in the recurring billing system:

  • Soft Descriptors. Implementation of soft or dynamic descriptors is an important issue, particularly in recurring billing context. The soft descriptors allow customers who have multiple subscriptions (or those who subscribed to a service a month ago) to recall which particular subscription they are charged for, when the statement arrives. Soft descriptors are also an essential feature to be implemented by companies, using aggregation model, as they include the descriptions of the aggregator, the merchant, and the transaction itself. In all described cases implementation of soft descriptors allow companies to avoid chargebacks, erroneously issued by customers
  • PSPs, Acquirers. The company needs to decide, who is going to underwrite its own merchant account or merchant accounts of other businesses that it will be servicing. Respective relationships with PSPs and acquirers must be established, taking into consideration not only pricing, but also the need for different currencies and overall feature set.
  • Gateways. If a company decides to use a payment gateway, it needs to carefully consider the choice of a particular payment gateway solution (hosted, licensed or in-house), which is most suitable for the company’s business model.
  • Direct-to-Processor. Usage of hosted gateways is undesirable when a direct-to-processor integration is necessary. In this case the company needs to find some licensable payment gateway software that can be used to simplify the integration process
  • Hybrid. If the company needs a combination of gateway and direct-to-processor integrations, it also has to implement the optimal (in terms of value-for-money) combination of the respective approaches


Collections of payments calls for implementation of the following items:

  • Reconciliation. Even in the most basic processing scenarios (for example, a gateway for credit cards and a bank for ACH) the entire process of reconciliation (matching of what was processed to what was received as a deposit from the processor) needs to be thought through. The company should implement the most flexible and transparent reconciliation mechanism
  • Decline Management. Decline handling is of particular importance for recurring billing, because if transaction declines, future recurring billings may not be possible. At the same time, contacting cardholder all the time is an expensive process. Some type of retrying\recycling\rebilling mechanism should be defined and implemented beforehand to minimize interactions with the customer.
  • Credit Card Updater. A typical reason for a decline is outdated credit card information (expired card). A common solution to this problem is implementation of credit card updater functionality (described in the respective article on decline recycling) as part of the decline recycling process
  • Customer Communication. No matter how good your decline recycling mechanism might be, some contact with the customer is still unavoidable. Therefore, it is essential to think through the customer communication process and the rules that the agents will follow as they call upon customers trying to collect declined transactions
  • Dunning Management. In some cases communication with a customer proves to be ineffective and debt has to be collected in some other way, be it through additional calls or e-mails, or via some third-party collections company. Some companies might prefer to drop the account and terminate the service while others may engage the services of a third-party collections company to still collect the debt. It is advisable to define collections strategy before getting the actual subscribers. In our respective article collections process is described in greater detail
  • Charge Back Management. In order to preserve its good reputation and avoid getting into the Terminated Merchant File (TMF), any company must keep the number of chargebacks issued by its customers at the minimum. In some cases even detailed soft (dynamic) descriptors are insufficient. Therefore, the company needs specific mechanisms to obtain chargeback information as soon as it is available, as well as to have a process to respond to inquiries and dispute chargebacks (these matters are addressed in the respective article).


In order to implement recurring billing it is not sufficient for a company to just find some recurring payment platform, which will regularly charge certain amounts from the clients. All aspects regarding creation, compliance, conveyance, and collections, must be taken care of in advance. Consequently, all technical features must be analyzed, appropriate business relationships (for underwriting etc.) should be established, and all processes around decline recycling and payment collection should be defined.

Hosted, Licensed and In-house Payment Gateway Solutions

With the advance of electronic payment industry and online payments in the world, and with the increase of online payments’ percentage in the total number of payments, more and more companies are redefining their online payment processing strategies.

In order to become a payment service provider, a business needs to consider three aspects of the payment processing sometimes referred to as creation, conveyance and collection (this is the subject of our previous article).

When a business has established relationships with customers and banks, the question becomes – what particular payment gateway solution should be implemented?

The purpose of this article is to review the available payment gateway solution options as well as analyze advantages and disadvantages of each one of them.

While we previously published an article that reviewed payment gateway solutions on higher level, this time we are going to take a more in-depth look, adding another option to the “mix”. The three options we are looking at are:

  • Hosted gateway solution (“Hosted solution”)
  • Development of a payment gateway software system using internal resources (“In-house yourself”)
  • Licensing of a payment gateway software product from a third party (“Licensed solution”)

Hosted payment gateway solution

Under this option a merchant utilizes a third-party payment processing gateway, the gateway software product is hosted within the data-centers owned by the gateway service provider; per-transaction fees (and, usually, some monthly fees) are charged to the merchant.

The advantages of a hosted solution are:

  • Absence of significant upfront cost involved
  • No need for PCI-compliant infrastructure
  • Out-of-the-box high availability support
  • Overall ease of operation

The disadvantages of a hosted solution are:

  • Per-transaction and, potentially, monthly subscription fees that are felt sharply as volumes grow
  • Limited control over the processing environment
  • Lack of control over the feature-set and inability to add new features quickly
  • Potentially high cost of adding new features
  • Inability to keep specialized knowledge (such as solutions for your business-specific needs) in-house (as it becomes the property of the “host”)

For these reasons many people decide to have there own in-house solution. Here there are two options available. Solution can either can be built by an internal team (from scratch), or it can be licensed.

Self-developed payment gateway solution

The idea of a self-developed (in-house) solution is that the entire gateway software product, as well as the hosted environment is designed, built and maintained by the internal team.

The advantages of a “do-it-yourself” solution are:

  • Tailored system architecture. The system, from its “point of conception” is going to be built around the business model specific to you, and, therefore, is going to accommodate your various business needs
  • Uniqueness. The system is going to be unique to you (nobody else is going to have it, so specialized knowledge can be kept in-house as a “know-how”; features, functionality and APIs remain yours exclusively)
  • Full control over the development cycle and overall payment eco-system

The disadvantages of a “do-it-yourself” solution are:

  • A need for a group of specialized developers. Development of this type of systems, due to their complexity, requires a group of people with highly-specialized knowledge of payment processing and architectures of payment systems, as well as development skills.
  • Long initial development cycle. Depending on the complexity of the software that has to be written, it can take from 1 month (in extremely basic scenario) to 2-3 years (in case of an enterprise-level system). One to five full-time developers with specialized knowledge (see above) will have to be engaged during that period.
  • Complexity of cost forecasting. Modern payment gateways, generally, provide a multitude of features around integration APIs, on-boarding, integrations, reporting, terminal support etc. The overall scope of works is quite significant. Therefore, it might be difficult to forecast the actual cost from the very beginning, as development efforts tend to extend beyond initially allocated limits.
  • De-concentration of efforts. Quite often companies requiring payment gateways also develop and maintain their own core software product, so if payment system development is undertaken internally, some part of the internal development team has to be dedicated to payment processing as opposed to core product functionality.
  • Complexity of operations. All aspects of development and deployment have to be considered and closely monitored (core functionality, general architecture, technologies to use, high-availability deployment (clustered configuration, fail-over configuration), card storage solutions, PCI compliance)

For those that find themselves in a situation where they can’t wait to get an internal development team or they don’t want to get involved in complex development process, licensed solution can be a more suitable option.

Also, in many cases companies in need of payment processing are purely financial services companies, and for them software development services is simply an “alien” type of activity.

Licensed payment gateway solution

In a licensed solution payment gateway software is licensed from a third-party software development company, which deploys and maintains the product to a PCI environment owned by the licensee. The environment can be cloud-based servers or the licensee’s internal data center.

The advantages of licensed solution are:

  • Out-of-the-box functionality. A ready-to-use solution available on Day 1 with pre-defined set of functions. The product is already developed, and most of the aspects are already thought through (APIs already defined, general architecture is designed, there are integrations available out of the box, the approach for PCI audit is already defined, and high-availability deployment configurations are already provided). Beside that, licensed offering, usually, comes from a software company which provides professional services, including customized development. Consequently, you don’t need an internal development team, while you still benefit from the contributions that are made by other people because of the overall development of the product
  • Availability of development resources. Under licensed solution your own development team can concentrate on your core product, while payment processing related works can be outsourced.
  • Fixed initial cost. The initial cost is not only fixed, but also, generally, lower, than the cost of building equivalent functionality in-house.
  • Benefit of collective contribution. The product is based on feedback from multiple companies using the solution, therefore, if some feature becomes popular, it might get implemented in the product without the explicit investment of the licensee (paid by someone else)

The disadvantages of a licensed solution are:

  • Reliance on a “third party”. Choosing a third-party product you assume the software providers to be there for you when you need them. If the product is sunset, you are no longer getting any product updates or might not even be able to use the product
  • Excessive feature set. The product might come with numerous features that are not necessarily needed, and, because of that, it might be difficult to use
  • Inability to leave the know-how in-house. Like in case of a hosted solution, if you have something highly specialized “for yourself”, you’re obliged to share it with the external development team (licensor)
  • Potential inconsistency with the business model used. Some features might be conceptually incompatible with the current business model your company is using, and you are not necessarily in the position to change them


For those, whose budgets are limited, hosted solution is a preferable option. Those, who already use a hosted solution, may consider the option of switching to a licensed one, but in this case they need to choose from among commercial open-source products, as these reduce some risks, because the source code is available for purchase.

PCI Compliance Levels

The purpose of this article is to familiarize different merchant services industry players with the four levels of PCI compliance, and briefly describe some solutions available for level 4 merchants (the most common category), allowing them to go through PCI certification procedure as smoothly as possible.

As we mentioned in one of the previous articles, any business dealing with cardholder data in some way, has to meet PCI compliance requirements and go through some sort of PCI audit procedure. Depending on volumes of transactions processed (including online transactions) a business is classified as belonging to one of the four PCI compliance levels. Beside processed transaction volumes, a company’s PCI compliance level also depends on predominant card entry mode the company utilizes. There are several card entry modes (determining card industry types), but in terms of PCI compliance levels card entry modes (or card industries) can be divided into two basic categories: e-commerce and other transactions.

Let us briefly review the levels of PCI compliance (as they are defined by Visa), moving from 4 to 1.

How PCI compliance levels are defined

A level 4 merchant is a business processing less than 20 thousand Visa e-commerce transactions a year, or any merchant processing less than a million Visa transactions a year, regardless of card entry mode.
A level 3 merchant is a business processing between 20 thousand and one million Visa e-commerce transactions a year.
A level 2 merchant is a business processing between 1 and 6 million Visa e-commerce transactions a year.
A level 1 merchant is a business processing more than 6 million Visa e-commerce transactions a year, or a business, considered a level 1 merchant by Visa association itself (based on cardholder data security and risk related considerations).
The complexity of PCI compliance certification and PCI audit for a given business are determined according to the level this business belongs to.

PCI compliance-related solutions

In order to meet PCI compliance requirements, merchants, belonging to PCI compliance levels 1,2 and 3 can utilize various solutions (such as tokenization, profiling and others), enabling them to store credit card data and manage cardholder data flow in the most effective way.

Many online businesses, web-sites, and small size merchants, fall into level 4 category, and often look for the most suitable solutions for PCI certification. In this post we focus on this (most common) type of merchants – level 4 merchants, which, according to some sources, handle about one third of the total volume of credit card transactions processed.

In order to meet PCI requirements, level 4 merchants have to fill out the so-called SAQ (self-assessment questionnaire). The type of a SAQ (ranging from A to D) that a given merchant has to fill out, depends on this merchant’s validation type. Basically, the validation type depends on how the merchant handles cardholder data (and whether the merchant stores it or not). More information on merchant validation types can be found here.

Level 4 merchants often utilize the services of other companies (level 1 service providers acting as PSPs in this case) to process credit cards. Particularly, they often rely on payment pages and tokenization services of the PSPs. In most cases the PSP itself would have a special mechanism for level 4 merchants, simplifying the process of filling out the SAQ significantly.

For example, most companies, performing PCI audit (such as Trustwave, Security metrics, CoalFire) have special software packages (or web-based offerings) designed to help level 1 providers that use them for PCI audits to simplify the completion of the self-assessment questionnaires for their level 4 customers.

Basically, an SAQ is a simple *.pdf document. PCI audit companies create special web-portals for level 4 merchants. An authorized level 4 merchant can enter such a portal, submit its SAQ, and identify its payment service provider. After that the fields related to the PSP are auto-filled. These can be the fields denoting particular features (which level 4 merchants might not even be aware of), provided by the PSP itself and not by level 4 merchants from the PSP’s portfolio.

The described arrangement (solution) greatly simplifies the process of PCI compliance certification for both PSPs and their level 4 clients, as well as for PCI auditors themselves.


Before starting to worry about PCI compliance, a level 4 merchant should reach out to its PSP and enquire about the respective automated solution, that the PSP might already have in pace.