What Makes It a Paying Business

14 January 2015 | By INSART Team

By Vasiliy Soloshchuk, Maxim Oliynyk, & Vyacheslav Z. Tibilashvili

What One Should Know Prior to Making an Investment in a Payment System Development Project

Developing a payment system has been so much in vogue of late that most anyone looking to put their hard-earned bucks to good use has either embarked on this budding trend already, or is putting on their thinking cap in contemplation of others’ success.

The idea is so trite, the related solutions are so rife, and the market is so huge, that stepping into any kind of pitfalls doesn’t just seem to be part of the plan.

Alas, for those venturing into such a project with just a smattering of the business, the whole thing may not look so rosy in due course, and may even take on a more macabre hue toward the end of their business undertaking.

From our experience with several projects in this business domain, business entrepreneurs who invest in such projects, typically, have no clear idea about what the system must do in order to meet the needs of their target audience.

Also, what we normally come across is the total absence of any idea about some of the underlying technicalities that may hamper a project when implemented improperly.

We’ll try to equip those looking to develop a payment system with the basic knowledge of what we believe to be the more insidious issues that can translate in big-time problems, including financial losses, after the system’s launch. Our tips may also be of interest to those entrepreneurs, who consider buying into an already functioning payment system project, or one that has been under development for some time now.

1. Ensure Your System’s High Availability

By definition, virtually any payment system is a system that must allow for its infinite expansion, while also being able to support a large and constantly growing number of users. The system must allow for easy and reliable data replication and backup.

Technically, this can be achieved only by building a cluster solution that consists of several nodes. This approach also ensures a high processing power of the system.

2. Data Consistency

In a payment system, any transaction may trigger an avalanche of related recalculations. Technically, it is tremendously difficult, if not impossible, to implement a mechanism to perform the myriads of the required recalculations. Nevertheless, it is exactly this erroneous approach that may well be taken by a less experienced and less far-sighted development team.

In order to prevent this happening, you should make sure that the Technical Specification of your system-to-be include a special node to align all of your transactional data at set intervals.

3. Integration Issues

Ensuring a good integration ability of your system is key for both its functioning, and the well-being of your future payment business. Yet this is just another point where a less experienced service provider may get you in trouble after the system goes live.

Make sure the Applied Program Interface (API) for your system is developed using an advanced protocol, for example, Restful.

We also recommend that the technical specification include developing built-in plug-ins (for example, Os Commerce ones) in order to ensure the application’s easy and seamless integration with external systems.

4. Security-Related Issues

Security is vital for any payment business. Despite this being much of a platitude, your service provider may not be fully familiar with all existing security concepts, and the more up-to-date means of ensuring a system’s security because it is an entirely separate field of expertise.

Moreover, it is even more likely that the average provider of custom software is incapable of sufficiently securing a payment system if the security requirements for it are relatively high. At the same time, the issue of problem security is closely associated with a system’s user friendliness and its cost of ownership.

However, in the majority of cases, the multi-factor approach to a payment system’s security is a must. This means that the system’s security must be based on a combination of two, or all of the following factors:

  • Knowledge of one or more facts
  • Ownership of a specific object
  • Bio-metric factors

Since biometric authentication systems are rather costly to maintain, and capable of raising the system’s overall security level relatively insignificantly, they are not taken into consideration, and what should be paid attention to is two-factor authentication.

Usually, the most optimal solution that can ensure a rather high level of security is based on a sufficiently complex password, and a code that that is generated each time a user wants to enter the system. This code is sent to the user’s physical device (token).

It is also essential that you make sure that the security requirements section of the project’s technical specification includes the following functionality:

  1. A Web application firewall
  2. Password-based authentication
  3. User Account-level authentication:      

o   Environment-based intellectual identification.

If the user’s environment (their operational system, browser, location, language, and more) is different from the one used during their registration, or, correspondingly, from the environment used during the user’s latest entry into the system, the user may be requested to enter some additional information. For example, they can be requested to enter a one-time password that is sent to their mobile number via SMS.  

o   IP-based authentication.

o   An HSM module that allows storing sensitive data in an encrypted form.  

In addition to reducing the load on the central server during encryption and decryption, implementing such a module would also ensure reliable storage of the encryption keys.

Please note, that your service provider must be capable of implementing the above functionality.

Importantly, the system must be compliant with the PCI-DCC standard, imposed by major payment providers.

A payment system must provide functionality for user verification during users’ registration in the system. This can be a combination of several types of validation. In our opinion, it is best to implement a combination of black list-based validation, and ID-based verification with a capability that allows submitting a user’s photo with their open ID. The photo scans must automatically be validated using the IDChecker service.

It is also necessary to implement validation against any required government-issued black lists, for example, those issued by the Office of Foreign Assets Control (OFAC) of the U.S. Department of Treasury (this service is provided by rdc.com).

  • Fraud Detection Functionality

It is an absolute must that your solution include filtering functionality.

For example, we believe it to be absolutely indispensable to implement several filters, that, when triggered, necessitate manual processing of the corresponding transaction. These filters can include:

o   The geography from which the payment originates. This is the primary filter which is an absolute must.

We also recommend that the following filters be considered:

o   The maximum transaction amount

o   The maximum product amount, or number of units 

  • Secure Integration with External Payment Systems and Human Factor-Related Risks

Your payment system’s interaction with other payment systems is where it is bound to be tested for vulnerabilities. Unfortunately, these tests may well turn out to be extremely detrimental to your budget unless you see to it in advance that some preparations are made to avert the possible unwanted scenarios.

We’ll try to outline some of the spots in your system that may well start oozing dough when implemented by a less experienced development team and given the right circumstances.

One of the more common payment system scams is associated with an incomplete verification of transaction-related parameters during a transactional exchange between two systems.

In plain talk, one of the two systems is flimflammed into giving out an amount of money during a money transfer from another system. The crook generates a payment in system A, but doesn’t complete the payment generation procedure. After this, he manually creates another payment statement using a POST-request (a simple HTML form), emulating the statement generated in system A. In doing so, the crook uses the ID and some other parameters of the payment statement in system A. However, the amount of the manually created payment is much smaller than that of the original payment statement created in system A.

The manually created payment with a smaller amount is then sent to system B. As the payment IDs of the two payment statements coincide, the money is paid into the crook’s account in system A. The discrepancy between the two payment amounts constitutes the crook’s profit.

Please note, that this kind of fraud can be committed using some other payment parameters too. For instance, the same trick can be pulled off by fraudsters by indicating a different, normally, much cheaper currency in the manually created payment statement.

Another, similar type of spurious parameter-based payment scam consists in forging the notification sent from system A to system B.

Unfortunately, threats your system can be faced with may not always originate from the outside. Any payment system also involves the human factor, and, whenever the system is not protected well enough, this creates plentiful opportunities for unscrupulous employees, who can, for instance, create a good positive balance in an account of their liking.

How to stave off the possible assaults on your property, business, and business reputation?

In order to protect your system against the spurious parameter-based types of fraud, you must see to it that during the transactional exchange of your system with external systems your system validates all the parameters of all the incoming payment-related instructions and notifications.

Human factor-related risks can be curbed through external data validation, performed at regular intervals. To implement this, a separate recalculation module should best be developed to recalculate the transactional data, and signal the discrepancies that have arisen.

It is also possible to prevent in-house fraud by automatically hashing the currency and amount in created payment statements, so that whenever an attempt is made to modify these parameters, the system checks the new parameter values with those previously enciphered, and blocks the user ‘s account. Another good option would be using an electronic signature for each transaction.


Prior to engaging in what can become your golden business opportunity, it is only prudent that you check if the vision of the stakeholders you are banking on is in sync with that of industry experts. It is also obvious, that most of the potential problems one can encounter as an investor are associated with system security, and it may be mission-critical for a payment system startup to find employees, or choose a technology partner with corresponding expertise and experience.

© 2014 INSART


The views, opinions, and examples expressed and quoted in this article do not constitute any call for action. These views, opinions, and examples are provided solely for information purposes, and interested readers should also be reliant on other competent opinions. The article does not constitute an all-round set of instructions. Illegal use of payment systems’ technical vulnerabilities results in severe criminal penalties.