Split Funding Models

Traditionally, when merchants processed their transactions, the processor simply deducted processing fee and funded the merchant the rest. Presently, there is a growing need to split the part into several deposits. One of the main reasons for that is the emergence of online marketplaces.

From conceptual viewpoint, there are two ways to implement split funding mechanism. A company may need to implement one way or another, depending on its business model. Some business models, however, need to accommodate both ways at the same time in order to function effectively.

The purpose of this article is to inform the readers about the two types of split funding platforms, so that they could choose the more suitable platform type.

Customized split: split funding on the submitter’s end

The most common and simple type of split funding mechanism is as follows. When a transaction is processed, the submitter specifies, how the funds are to be split. Say, there are two or three recipients specified at the moment of transaction submission. Recipients are merchants or users, registered within the system, that are going to receive their shares of the total transaction amount.

In other words, the submitting system specifies particular splitting (fund distribution) rules on per-transaction basis.

This approach is more suitable when the distribution of funds depends on the specific context of the transaction, such as the number of affiliates involved, or the number of items purchased.

Example 1

A customer purchases a t-shirt for $25, and the submitting system determines that there is an affiliate, involved in the transaction, who should receive $5. Therefore, the system specifies that the total transaction amount is $25, of which $5 should go to the affiliate.

We should note that, when the next t-shirt is sold, the distribution of funds might, actually, be different.

Pre-defined distribution: split funding on the gateway’s end

Under the second model (the more complex one), the split funding rules are set up in advance in the system itself (on the payment gateway’s end). Some information on merchant services commission sharing is available here {link}.

The second model is more suitable when the distribution rules are the same from transaction to transaction.

Example 2

An online rent payment software vendor partners with some specific payment gateway. The gateway charges a convenience fee. For each transaction the rent payment software charges $4.50 from that convenience fee. The rules can be configured accordingly in the rent payment software and recorded on the gateway’s end.

Example 3

An online store sells t-shirts and hoodies online. T-shirts and hoodies are provided by two different vendor companies. For t-shirt sales the online store marks up 10%, while for sales of hoodies it marks up 8% of net transaction amounts. The rest (90% and 92%) of net transaction amounts, respectively, goes to the vendors. Consequently, after the respective distribution rules are setup, when a transaction happens, it will be sufficient to specify the vendor involved.

Split funding peculiarities

We should note, that in each split funding scenario it should be clear, who is responsible for the payment of fees. In most cases it is easier to make the account, under which the transaction is processed, responsible for the entirety of the fees. In other words, the entire fee is paid by the merchant and not split into parts. However, there might be scenarios, when the fee needs to be split between multiple parties.

Another issue to address is handling of void and refund transactions. As every sale transaction is eventually split into multiple ones, it is necessary to define, how the sub-transactions can be voided or refunded. The simplest option is to allow void/refund of the main transaction and, subsequently, void or refund all sub-transactions. However, more customized scenarios may also be required.


Your choice of split funding platform should depend on particular split funding needs of your business.
If splitting logic is complex and context-dependant, while the software integrator (customer) needs to have full control of the distribution rules, the first (customized split) model is preferable.
If splitting rules are more or less consistent from case to case, the second approach (pre-defined distribution) might be more appropriate.

Handling of Convenience Fees

If you want to implement convenience fees within your payment software system or payment gateway, this article is for you. In payment card industry context a convenience fee is a fee charged for card processing. It allows the merchant to pass the cost of card processing to the cardholder. Some more information on convenience fees can be found in our previous articles here and here.

The purpose of this article is to analyze the technical aspects of adding convenience fee handling functionality into a payment system.

Fundamentally, there are two approaches used for convenience fee implementation.

Convenience fee handling approaches

The first approach can be applied when merchant funding is handled by the payment gateway or PSP (i.e. by the system that processes the transaction). The second approach can be applied when funding is not handled by the system that processes the transaction (i.e. by the processor).

The main difference is that under the first approach convenience fees can be withheld at the time of funding, while under the second approach they can not, since the funding is handled elsewhere. Consequently, under the second approach, convenience fees have to be processed in a particular way at the time of processing.

Let us compare the two approaches based on a simple example.

Before describing the example, we should note, that in most cases a convenience fee is a surcharge, which is, generally, kept by the service provider that facilitates the payment (payment gateway, processor etc) (some part of that fee might be shared with the a reseller). The primary part of the transaction (100% of the original amount) is, naturally, deposited back to the merchant.


For example, if a $100 payment is made and $5 convenience fee is charged, the cardholder actually pays $105, of which $100 go to the merchant and $5 are withheld by the service provider. The surcharge includes the actual cost of transaction processing and an additional markup.

Under the first approach, the entire transaction (primary transaction amount and the convenience fee) can be processed as a single transaction using the same MID. At the time of funding the principal amount can be funded to the merchant and the convenience fee – withheld by the payment service provider (who facilitates the funding process and, therefore, can hold the funds).

Under the second approach, the PSP or payment gateway relies on some underlying processor to handle funding. In this situation if both the primary payment and the convenience fee are processed as a single transaction (as in the first case), all $105 will go directly to the merchant. Therefore, it is necessary to process two separate transactions ($100 payment and $5 convenience fee) using two different MIDs.

Peculiarities of the two approaches

First approach: MID and MCC

We should stress, that every MID is associated with a certain merchant category code (MCC) used for classification of products and services the merchant provides. Convenience fees are allowed to be processed only under certain MCCs (for instance, supermarkets are not allowed to charge convenience fees, while utility companies are).

Consequently, if you choose to implement the first of the two approaches, you need to use the MID (and the respective MCC) which allows you to charge convenience fees (sometimes a separate MID with a different MCC may be required to charge them).

Second approach: critical aspects

If you choose to implement the second approach, you need to think about several particular aspects.

  • When will convenience fee be charged? Will it be charged on successful payments only or on declines as well?
  • What should be done when a payment is not authorized because there are no funds on the card?
  • What should happen if the primary transaction succeeded but there are no sufficient funds to process convenience fee?
  • How to handle the situation when the primary transaction is voided or refunded back to the cardholder? Should convenience fee be refunded in such cases?
  • What descriptor should be used on the MID through which convenience fees are processed? How to ensure that the cardholder understands that it is related to the original payment?

These and similar questions must be addressed as part of your planning process.

Calculation of convenience fees

Calculation of convenience fee amount is another important aspect. Convenience fee is usually calculated in one of three ways.

  • It can be a fixed amount.
  • It can be a certain percentage of the principal transaction amount.
  • It can be a combination of the two.

It is desirable for the amount of convenience fee to be derived from the actual cost of transaction processing (include the actual cost plus bring some revenue). In order to achieve this, one of the several approaches can be used (similarly to transaction pricing strategies).

  • Unified “blended” rate. Same rate is used to calculate convenience fees for all transactions. However, handling of different cards may have different price, so some more sophisticated and flexible techniques might have to be used (allowing you to differentiate the fees, depending on card processing costs, instead of charging everyone maximal rates).
  • Buckets or tiers. Under tiered pricing, the fee can vary, depending on card type and transaction amount.
  • Customized logic. You can develop some customized logic, which will calculate interchange amounts based on card types and industries (e-commerce, retail etc), and define convenience fees based on interchange amounts. The technique is the most complicated one; however, it provides greater flexibility.


If you want to add convenience fee handling functionality to your payment system, you need to decide, how and when the amount of convenience fees are going to be calculated, as well as how and when they are going to be charged.

Migrating from One Processor to Another

Every now and then gateway processing relationships have to be re-evaluated. There are numerous reasons for that. Traditionally, a change of a processor for a PSP represented a new integration project for authorization and settlement, as well as moving of existing MIDs from the current processor to the new one.

In today’s world, as demands of merchants increase, the process looks a lot more complicated. In this article we are going to explain the particularities of the migration process, applied to the modern environment.

The aspects of migration

Just as before, migration of merchants is an important process. All merchants have to be moved to the new processor’s platform and configured.

A modern-time PSP, usually, has several integration points with a processor. Among them is the traditional authorization and settlement. However, many PSPs now offer batch processing – the ability to send files, and, consequently, account updater functionality, allowing for full update of information from issuers (which is, generally, required for recurring billing). This functionality requires additional integration efforts to be supported.

Many PSPs have to deal with on-boarding of numerous merchants on weekly basis and a lot of PSPs today have an integrated on-boarding mechanism, either through API, or through a merchant boarding file. Therefore, switching from one processor to another, potentially, implies changes in the merchant on-boarding mechanism.

Chargeback management has also evolved over time. It used to be a manual process. However, in today’s world, a lot of chargeback handling procedures are automated, and, again, payment facilitators may have existing integrations to retrieve chargebacks, as well as specific procedures around chargebacks disputes and uploads of supporting documentation. Switching to a new processor might mean changes in the existing integrations, or re-training of personnel, that is used to deal with chargeback disputing portal of the current processor.

Reconciliation procedures can also be a challenge, as they, generally, involve various kinds of settlement and fees reports, used for analysis of transactions processed, settled, and funded. Switching to a new processor might mean different reporting formats, or even lack of certain reports.

Loading and updating of BIN-files is another important component of modern-time migration process. More information on BIN-files can be found in our previous articles.

It is also important to understand that while you may get an enthusiastic support during the sales phase, when you go into technical integrations, you might face an extremely tedious and long process trying to put things in place and get them certified.


While change is an inevitable and necessary part of our life, and every now and then a PSP might need to change its major processing partner, this process should be approached with caution, and involve careful preparations. Depending on the size of a PSP, the process might take up to eight months, or even a year, so the PSP must set a reasonable time frame within these limits for the process to be completed. Before making the final decision on migration, a PSP should think about all of the listed aspects and decide how they are going to be organized in the new system. That is why using a standardized processing platform-gateway, which supports all of these aspects may be a reasonable choice. Usage of such standardized processing platform\gateway is extremely relevant for those, who haven’t started any integrations yet, because it will simplify potential further migrations.

Phishing Attack Prevention

In this article we’ve decided to readdress the security and fraud prevention issues. In particular, we are going to focus on a fraud technique, commonly referred to as phishing attacks. Phishing attacks are often used in payment processing context as a fraud technique, designed to capture a user’s logon information, which is needed to access the payment gateway or payment system, the user is working with.

You may have heard the term phishing already, but in this particular post we are going to describe the issue from payment gateway and payment system access perspective.

There are several reasons for phishing attacks.

  • Personal data theft. The phishing attack might be undertaken just to steal your personal data, or the personal data of your clients.
  • Payment data theft. The attack might be undertaken to steal your payment information (credit card numbers), or payment information of those customers processed through your accounts.

Even if the payment information is hidden, the individual logon of a user into a virtual terminal of a payment gateway might still be used by fraudsters for the so-called credit card milking (verification of stolen card numbers using this user’s merchant account).

How phishing attacks occur

Phishers usually replicate (make an exact copy of) the logon page of the system they are trying to attack and send you a letter with a link, that you are asked to follow. In the letter you are told that there is some urgent issue with the system, which requires you to follow the link and login. The visual appearance of the link, usually, corresponds to the actual login page of the service. However, once you click on it, you are redirected to an absolutely different page, looking exactly like the expected logon page. If you do not pay attention to the URL, you cannot notice the fact that you are not on the real logon page, and you may inadvertently enter your logon information, which would then be stolen.

How to prevent phishing attacks

There are several preventive techniques which can be used by payment system operators to protect their respective payment gateways against phishing. The two most common ones are two-factor authentication and security image usage. Both approaches are based on some additional authentication factor, added to username and password.

The two-factor authentication is based on usage of an additional value during logon. The value is generated by a software product, a hardware device (usually referred to as token) or by a smartphone. Generally, only the user has access to the software/hardware/smartphone, so even if the username and password are stolen by phishers, they still cannot access the logon page. You can find more detailed information on two-factor authorization in our respective article on Google authenticator.

The simpler approach is based on usage of a so-called security image. During the first logon, the user is asked to choose an image, which will be used as his personal security image. The logon dialogue webpage has to be modified accordingly, so that initially the user is required to input only the username, without the password. Once the username is input, it should be verified, if it is present in the database\system. If it is, an image is displayed. If the image coincides with the user’s security image, it indicates that the user can proceed with logon and input your password. Otherwise the user simply does not input the password, thus, making logon impossible, and preventing the potential phishing attack (as phishers do not know the security image to be displayed).


If personal data and payment information of your clients are major concerns for you, you should implement some phishing attack prevention technique in your logon mechanism.

Implementing Your Own Payment Terminal Solution

If you are a player in the retail space, thinking that your business needs support for payment terminals, or if you are considering different payment terminal solutions in search of the most suitable one, this article is for you.

The need for customized payment terminal solutions is gaining urgency in view of approaching introduction of EMV standards and requirements in the US, scheduled for the end of 2015.

In this article we are going to consider several solutions, available for payment gateways and payment service providers with respect to their EMV strategy.

In essence, a terminal is a mini-computer with its own OS, where a terminal application has to function. Payment gateway must integrate with this terminal application to support EMV properly.

Payment solution offered by the acquirer

The first and, seemingly, the simplest solution is using payment terminal application, offered by an acquirer.

Many present-day acquirers offer you some form of payment terminal solution, which some PSPs or gateways may consider using. Upon closer inspection, however, you realize that there are a couple of issues with that.

One of the issues is that most payment terminal solutions (applications) offered by acquirers are tied directly to their platforms. Particularly, because of the tight EMV regulations, they avoid sending transactions from the terminal to some third-party gateway, intermediary CRM, or software system, which would then forward them to the acquirer. This may present a problem, because they need to keep track of these transactions to accommodate the business model of a PSP/gateway. The problem with the solution is that these transactions become invisible to the third-party gateway providers within their systems.

Because of that, many gateways and PSPs choose to integrate their software system with a terminal in a way which they can fully control.

Integration with a terminal

Integrating with a terminal can be done at two levels. At a higher level a PSP/gateway can utilize an existing terminal application and integrate with it using integration SDKs. At a lower level a proprietary embedded application can be written and subsequently integrated into the overall payment processing ecosystem.

SDK-based integration

The advantage of the first solution is that the SDK-based integration, usually, is much quicker than development of an embedded terminal application. Major payment terminal manufacturers (such as Ingenico, VeriFone, and PAX) offer their own terminal applications, which can be used in various ways, and thus, it is possible for payment gateways to take advantage of these applications.

While this solution is the simpler of the two, it has its disadvantages:

  • The gateway will not always be able to customize the terminal application (its interface or logic). For instance, you might be unable to add non-payment-related functionality, such as quality survey, to the application, when you need it.
  • SDK-based integration method may not be conceptually suitable for your application. Traditionally, platforms that used terminals, were desktop applications (only desktop applications existed). That is why many terminal integration SDKs still rely on the so-called native code, such as Windows-compiled DLL library. This imposes the requirement on the application to be able to deal with the native code. While this is, generally, not a problem for a desktop application, it does present a challenge for a web-application, which operates from within a sandbox, and, usually, does not have security privileges to operate at such a low level.

Embedded solution

The advantage of an embedded solution is that you can customize everything, and the application can do whatever you choose for it to do. You can develop an SDK or integration API, that will work for you, or your customers in any way, that you find appropriate.

On the other hand, this solution has a price tag attached to it, and is associated with some challenges:

  • Writing your own terminal application requires your own specialized knowledge, and a special costly certification, that has to be competed with the respective vendor in order to acquire preliminary knowledge and access to SDKs, allowing to do embedded development.
  • Building and testing the application, definitely, takes time. Therefore, immediate integration with the payment gateway solution is impossible.

In the next post we will describe some specific methods of integration and implementation of various SDK, allowing you to incorporate the terminal application into some software solution or payment ecosystem.

EMV Certification in a Nutshell

The purpose of this article is to familiarize integrators with EMV processing, help merchants understand the process of EMV certification and estimate its cost.

The relevance of EMV certification

EMV stands for Europay, Mastercard and Visa, and denotes a worldwide transaction authentication standard. The standard is based on usage of integrated circuit cards, which increases the security of EMV card transactions in comparison to magnetic stripe cards. More information on EMV standards can be found here.

From January 1, 2005, merchants in EU area are held liable for all fraud resulting from transactions processed in the systems, which do not support EMV. In the US, EMV certification also became an extremely relevant issue after the associations declared that the liability will be placed on merchants at the end of 2015, i.e. if a person wants to make a purchase from a merchant, using the EMV card, but the merchant doesn’t have an EMV terminal, and the transaction ends up being part of fraudulent activity, it is the merchant who is going to be held financially responsible for the incident’s consequences.

Although many merchants can purchase EMV terminals from the acquirers and do not necessarily need to conduct the in-depth analysis of EMV certification process, gateways, payment facilitators, as well as companies, that maintain their own proprietary payments ecosystems, have to face the question of how to undergo EMV certification, i.e., how to add EMV support into feature sets of their products.

Let us move on and review the EMV certification process in greater detail.

EMV certification phases

Before starting an EMV certification, a company needs to make a decision about the three key components of the process:

  • Terminal(s) (hardware device) that will be used to read EMV cards. Some information on payment terminals can be found in our respective article
  • Payment gateway software or some form of software package that will deliver transactions to the acquirer
  • Acquirer(s), that will process the transactions

After these decisions are made, the company can proceed with the EMV certification, that is, generally, comprised of two sub-certification processes (phases): host integration and EMV certification.

Payment processing host integration

Generally, there are no certification fees involved in this phase, and the main cost is the cost of development of the integration code. It involves integration on the message level between your system and the acquirer. As part of this integration, a proper message format is implemented to enable a payment gateway to submit EMV fields to acquirer’s system in a format that it can “understand”. In a sense, the process is similar to classical integration, described in the respective article.

EMV certification

It is a process, in which an EMV terminal (a terminal, supporting EMV card processing) and a so-called EMV toolkit are used. Special test scripts, certified by the acquirer for every association, have to be executed with the help of the EMV toolkit. The results of execution of the test scripts are submitted to the acquirer to be considered for review. The acquirer forwards the results to the associations for their final approval.
Usually, EMV certification involves an administrative fee (charged by acquirers), ranging between $2,000 and $3,000 for every formal test script run. Re-certification process has to be initiated every time when a new hardware device, using a different EMV kernel is added to the previously certified EMV-processing pad.

For example if any VeriFone mx9 series device has been previously certified, any other device of a kind is automatically covered by that certification. But in order to use some Ingenico device, you would have to initiate another EMV certification (even if you are going to utilize the existing host integration and the same back end).
The most popular EMV toolkits include ICC and B2 toolkits. Particularly, these toolkits are quite popular among acquirers in the US.

Selecting a device

The list of all desired devices to be supported needs to be compiled in advance and included into the initial certification. While selecting the devices, one should understand that only terminals and readers, which have EMV level 1 and level 2 certified kernels, can be used.

An EMV toolkit works as both card reader and card writer: it both reads data from the chip and writes new data on it to be read during subsequent transactions.

Developing terminal application

As we’ve mentioned above, firstly, a business wanting to process EMV transactions, needs to select payment terminal, supporting EMV and certified by the acquirer.
Secondly, the integration needs to understand that most terminal manufacturers will not provide a stock payment processing application with the terminal. In this sense, a terminal is similar to a PC with just an operating system installed, without any applications. It is the integrator’s responsibility to procure (develop or license) a terminal payment application, compatible with the hardware and the operating systems of the models of the terminals that it wants to support.

There are various ways to simplify the development process: it can be outsourced, or some existing applications can be purchased; but, generally, it has to be accounted for in the budget for the project.

For deployment and management of the terminals, software updates, remote configuration management a separate software package is used, which is, generally, called, terminal management software.

This terminal application has to be able to utilize required peripheral devices, such as card readers, signature capture etc., and accommodate whatever types of transactions that are going to be required (credit cards, debit cards, gift cards, EBT, etc.).

Most large terminal manufacturers (such as VeryFone) maintain their own payment gateways. A business can purchase a terminal with the manufacturer’s application on it, which is, generally, “tied” to the manufacturer’s gateway. Therefore, if a business wants to connect such EMV terminal to a different gateway, it, generally, has to undertake some software development.

Selecting acquirers to partner with

A business, planning to integrate with several acquirers, needs to understand that each acquirer requires a separate EMV certification for each country, in which the business is going to process.

An average cost of EMV toolkit (which is used in every EMV certification) ranges from $10,000 to $30,000 per user license. That is why, when the acquirer is selected, it is advised to consider the models of the toolkit that the acquirer supports, so that potential cost savings can be realized by going with specific acquirers and toolkit vendors (by using a single toolkit for two or more certifications across different acquirers). And if you are already in possession of a certain toolkit, it never hurts to ask the acquirer explicitly, whether they would accept the tests using your version of the toolkit.


If you are a business considering the idea of going through EMV certification process, you need to select the devices you are going to use, payment gateway and acquirers you are going to partner with; also you need to decide how to get or develop terminal applications. And, of course, you need to carefully plan respective budgets.

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.

3 Cs for Payment Service Providers

The purpose of this article is to explain some essential components and mechanisms needed for a business to become a payment service provider.

With the increased use of electronic payments worldwide, there are more and more companies that are contemplating the idea of becoming payment service providers. However, many people, pondering the idea, lack the conceptual understanding of the essential components of the process that have to be implemented in order for these potential payment service providers to be able to operate.

There are three aspects to the formation of a payment service provider that can be called creation, conveyance and collection each dealing with various types of relationships, namely relationships with future clients (merchants), payment gateway provider(s) and an underwriting banks/processors.


The 1st group of relationships consists of the actual merchants and, in many cases, software vendors, through which the future payment service providers are going to service these merchants.

Basically, creation aspect of the process deals with the systems from which transactions originate. Some software products are necessary to originate transactions (for processing) or subscriptions (for recurring billing).

In case of a payment service provider servicing charities it might be as simple as just a web-site, a single page which will accept credit card donations and pass them on for processing. In the opposite “extreme” case, it can be as complicated and elaborate as an enterprise-scale POS or recurring billing software system.


The 2nd group of relationships involves either a gateway software provider, or a gateway services provider. A gateway software provider is a company that is going to supply gateway software product, while the gateway services company is going to provide the hosted offering for the gateway.

Conveyance of payments is conducted via a payment gateway through which payments are actually delivered from the originating system to the transaction processor.

Usually, PSPs will need to communicate with a multitude of payment processors and banks as well as with a multitude of the originators of the transactions (or, usually, the customers of the PSP – other software companies, POS vendors etc.). Consequently, there is a need a unified API and a unified approach that the originators could use to potentially communicate with a multitude of back-end processing systems.

That is where the need for a payment gateway software, or a payment gateway services provider (a.k.a. payment gateway) comes from.

In addition to gateway software provider, the potential future PSPs will also need to work out the PCI compliance strategy.


Lastly, the 3rd group of relationships will be banking relationships, i.e. banks willing to underwrite merchants and facilitate the process of subsequent merchant funding (settlement).

Collection of the payment is the phase during which the payment is actually processed and the merchant is funded. It requires a relationship with a bank.

Unless a PSP has direct relationships with card associations, it will need to rely on an existing account underwriter, usually a bank. While there are different arrangements around who takes/accepts the underwriting risk, some third party would be required to verify and approve the initial merchant application, and subsequently facilitate actual money transfers that follow settlement of authorized transactions.


While many people, who come from the small-business transaction-processing world tend to see the creation/conveyance/collection system as one complete piece (such as PayPal or Authorize.Net), in reality, there are 3 separate aspects involved, and any business wanting to become a PSP will need to search for solutions specific to each of these aspects.

Payment Gateway Solutions

In this article we are going to address several ways of implementation of payment gateway solutions available to merchants and payment service providers who process credit card and ACH transactions. As mentioned in the previous article, payment gateway solutions constitute one of the options a merchant can use for integration with a payment processor (payment service provider).

There are several specific payment gateway solutions available to merchants today.

Licensed payment gateway solution

A merchant licenses a gateway in binary form (nothing can be changed in the software code), or it licenses its source code (enhancements can be made if necessary). Licensed product is installed in the merchant’s own PCI-compliant environment.


  • full control of the whole payment gateway infrastructure
  • no per-transaction costs
  • out-of-the-box integrations with numerous payment processors and banks
  • licensed payment gateway environment is exclusively adapted to one merchant’s preferences


  • significant upfront licensing cost
  • need for PCI-compliant environment
  • ongoing hosting and maintenance costs

Generally, a licensed payment gateway solution is recommended for enterprise merchants and payment service providers that have an existing PCI-compliant environment as well as high transaction volumes, and require full control of their payment management process.

Hosted payment gateway solution

A merchant uses a gateway which is hosted by a third party.


  • no upfront license cost
  • no need for PCI-compliant environment
  • no ongoing maintenance and infrastructure costs


  • ongoing per-transaction per-merchant costs
  • low degree of control over the hosted environment in terms of downtime
  • shared environment might experience performance issues when multiple merchants are processing high transaction volumes simultaneously

While licensed option is a great solution for enterprise merchants, majority of merchants, especially smaller ones, tend to prefer the hosted payment gateway solution.

There are several common ways in which hosted payment gateway services are priced.

Hosted payment gateway pricing

Any hosted payment gateway solution involves various fees. If a merchant licenses a gateway, there is an upfront fee, but no subsequent fees, while hosted payment gateway solutions involves one of the two common pricing structures: volume-based pricing or subscription-based pricing.

Volume-based pricing involves per-transaction or per-MID fees (or both), which are charged for each transaction processed or for each MID issued to a merchant. The advantage of this approach is that if a merchant doesn’t process any transactions, it, generally, doesn’t pay anything.

Subscription-based pricing involves a fixed license fee (which is paid monthly) and a certain transaction cap. There is usually an extra cost associated with transactions processed over pre-defined caps. While the fee has to be paid both when transactions are processed and when they are not, if there is a large volume that a merchant regularly processes, the cost of each transaction is much lower than the one under per-transaction pricing model. Consequently, the approach is recommended to merchants who have certain transaction volumes processed on a regular basis.

Beside the above-mentioned advantage, subscription-based pricing, usually, gives large-size merchants access to some additional services (such as customized software development), which can be either included in the license subscription, or paid as an additional subscription. This provides access to trained development personnel capable of implementing additional features for a merchant or a payment service provider within the gateway on demand.


If a merchant chooses payment gateway as a preferable integration option, it must consider all advantages and disadvantages of each available payment gateway solution, keeping in mind processing volumes, specific needs and potential implementation costs.

Payment Processing Solutions

In this article we are going to look at several ways to implement a payment processing solution available to merchants and payment service providers who process credit card and ACH transactions.

On the importance of payment processing solutions

At some point many companies that process credit cards face the question of how to implement their connectivity with a credit card processor. There are various options these companies can choose from. Each of the payment processing solutions (direct acquirer integration, connector or payment gateway) has its strengths and weaknesses, so merchants and payment service providers must consider their particular needs before choosing the most suitable integration option. The following sections cover each of the possible solutions.

Direct acquirer integration

Direct acquirer (or processor) integration envisions implementation of the processor’s specification. The integration software code is written as part of the merchant’s application going directly into the payment processor’s system.

The advantages of this payment processing solution are as follows:

  • the merchant is communicating directly with the processor, and no intermediaries are involved; consequently the number of potential intermediary points of failure is lower
  • no additional costs are incurred by the merchant since no middleware technology is used
  • direct acquirer integration tends to perform better even on high transaction volumes

The disadvantages of direct acquirer integration are as follows:

  • the solution is one of the most difficult ones to implement, as integration specifications for platforms used by many payment processors are complex (often due to legacy technology that they rely on) and, consequently, much effort is required to implement the format
  • certification queues tend to be long and the time to open a project and get a specialist assigned can be quite extensive
  • because of the complexity of the specification, certification process requires multiple iterations (certification test executions), and each of them tends to take considerable amount of time

While direct acquirer (processor) integration provides merchants with the greatest control and flexibility and lowest long-term per-transaction cost, it is one of the most time-consuming approaches, carrying significant upfront cost in comparison to other options because of complexity of specifications and legacy technologies used by payment processors.


A connector represents a special software component that implements a payment processing specification and can be incorporated into a merchant’s application to simplify direct acquirer integrations.

While a merchant, using a connector component still has to go through certification with the payment processor, the implementation phase is significantly simplified.

Connectors can be of two types:

  • Software component – the component is integrated within the main application and is used to format messages.
  • Middleware – a piece of software installed separately from the merchant’s application. It receives incoming messages and converts them to the format of the underlying payment processor.

The advantages of connectors as a payment processing solution type are listed below:

  • connectors tend to reduce the development effort during the integration phase and can be used by wider range of software developers, not only by the most highly experienced ones
  • a connector eliminates the need for the integration code and subsequent maintenance
  • when new processing features become available, connector vendor takes care of support of these features

The disadvantages of connectors are as follows:

  • depending on the quality of the connector, performance problems might be experienced on high transaction volumes or in multi-threaded environment
  • it is difficult to introduce any types of tweaks or adjustments into connectors with no source code available, if necessary. Consequently, if something is wrong, no one but the vendor can fix the problem
  • upfront cost associated with licensing of the connector

For merchants that prefer upfront investment (as opposed to per-transaction gateway cost) and want to go with direct integration, eliminating intermediaries, connectors provide a good option to use, especially if their transaction volumes are not extremely high.

Payment gateway solution

A payment gateway is a solution similar to a middleware connector, incorporating various additional functions and supporting several different payment processors simultaneously. A payment gateway usually has an infrastructure to maintain merchant preferences and configuration settings associated with it.

The advantages of such payment processing solution as a payment gateway are as follows:

  • integration and certification processes are considerably simplified
  • additional features, such as host capture, are available
  • simplified PCI-compliance certification (payment gateways support pay-pages and other related solutions, thus, reducing merchant’s PCI scope); (more information on PCI compiance can be found here and here )
  • support of recurring payments

The disadvantages of payment gateways are listed below:

  • significant upfront fee / license cost or increased ongoing per-transaction cost
  • when hosted solution is used, a merchant has lower degree of control over the network environment of a payment gateway
  • merchant has low degree of control of the underlying logic of transaction processing

Despite the limitations of the payment gateway solution, it is the preferred choice of most merchants and payment service providers today.


Every merchant, processing credit cards, must make an informed choice from among payment processing solutions (integration options), depending on the merchant’s business size, overall transaction volume and specific business needs.

The next post will represent a detailed coverage of payment gateway solution types and payment gateway pricing structures.