Payment Gateway Cloud

In our previous article we described collaborative payment processing, based on payment gateway cloud concept. Although payment gateway cloud concept is a new one, it incorporates the results of a long evolution of payment technologies. This evolution was spurred and directed by the needs of merchants and other payment processing industry users. In order to understand it better, we are going to analyze it in comparison to a similar evolution process, which took place in web hosting industry.

Shared hosting – Payment gateway

Small online businesses and bloggers often face the need to create and maintain their own web-sites. To save money, they use a classical shared hosting, where they create their web-sites, alongside thousands of other hosting users. A similar need in payment services industry is faced by startup merchants and (again) small-size businesses. An equivalent to shared hosting in payment systems world is integration with a payment gateway. Startup merchants use the services of such companies as Authorize.Net, Stripe etc.

Virtual private server – Hosted or white-label payment gateway

With time users of a shared hosting face its limitations resulting from throughput constraints, viruses, problems with server, caused by other people, unavailability of support personnel, etc. For some businesses these problems are tolerable, while others choose to go to the next evolutionary phase, which is the virtual private server (VPS), giving them greater control over their environment and less of impact from the actions of others. An equivalent from the payment processing world is a hosted payment gateway solution, where a payment gateway instance is allocated for a specific merchant or a group of merchants.

Often VPS-based solution is also better for web-design companies with many sites and clients because it provides them with greater control over the process. In the merchant services world web-design agencies have their analogues: payment service providers and payment facilitators. PSPs and PayFacs often search for dedicated hosted payment gateway instances, commonly known as white-label payment gateways.

Dedicated server / Licensed payment gateway

While virtual private servers do guarantee significant efficiency improvement, they have their own flaws, because physical hardware is shared among several virtual machines or appliances. As a result, new limitations become evident, particularly, in cases, when high availability and fault tolerance are required. In such cases, large business users switch from VPS to dedicated servers. In payment processing world the equivalent of a dedicated server is an on-premise license of a payment gateway and deployment of the gateway in the company’s own PCI-compliant environment.

Dedicated servers solve most of the problems of web-design agencies, large online businesses etc., but support of such systems is a very complex task. Similarly, in the payment processing world, to support a licensed payment gateway solution, one has to face new issues related to server hardware, PCI compliance, etc.

We should mention a particular problem, specific to payment technologies, that doesn’t exist in the web-site hosting world. We are talking about implementation of payment integrations (with banks, processors, gateways). From technical viewpoint, integration between a gateway and a bank should not take more than a month. However, in practice, as a result of human factor, lack of organization, bureaucracy related to certification agent assignment, and instability of test servers, the process may take 8 to 12 months. If you are not familiar with integration process, you can read about it here.

Payment gateway cloud

Until recently there was no solution, allowing businesses with on-premise gateway deployments (particularly PSPs and PayFacs) to reduce the costs associated with new integrations. However, a new technology (implemented by such companies as United Thinkers) does allow your business to solve this problem.

The idea of payment gateway cloud technology is that an existing payment ecosystem can implement protocols (for transaction processing, chargeback disputing, and merchant provisioning), that are supported by the cloud within itself. If these functions are implemented, the payment ecosystem becomes capable of communicating with any other ecosystem, also connected to the cloud, where these protocols are implemented as well. As a result, any node of the payment gateway cloud can use the local integrations, implemented by any other node of the cloud.


If you face regular problems with integrations and the need for more back ends, but do not have the time and funds to invest in respective development efforts, you can consider exploring a UniPay-backed payment gateway cloud technology.

On the Way to Collaborative Payment Processing

Many businesses go through an evolutionary cycle as they grow. They usually start as small companies with very basic needs. Then at some point, as their processing needs become more sophisticated, they tend to outgrow the payment processing platform, chosen at the very beginning. In this article we are going to follow through a typical evolutionary path of such a company, see, which challenges it experiences, which traditional solutions can be used, and what new collaborative payment processing technology can offer.

Our story starts in a small warehouse. A group of people decides to open a book-selling business and launch a web-site, through which they are going to sell books.

Classical third-party payment gateway service

Having neither previous transaction processing volume nor PCI infrastructure, the company chooses the simplest route: to partner with an existing payment gateway, that can connect it to one or more processors that it needs.

As time goes by, the book-selling business expands rapidly, its revenue grows. It gets recurring orders from schools and universities. It starts opening stands and kiosks at book fairs, in airports and other places. Consequently, the need for card-present EMV solution as well as recurring billing solution arises. New payment processing logic is required. Beside that, the company is expanding to other geographies. Support for more currencies is needed.

The current gateway cannot accommodate all of these needs. The company starts thinking of integrations with several gateways. However, these gateways solve similar problems in different ways and cater to different market segments. The gateway, used for US dollars, has robust recurring billing, while the gateway used for Euros has an excellent on-boarding system. And still, there is no common denominator and the bookselling business has to compensate all the differences using its own development team, and, beside that, implement integrations with multiple payment processing back ends.

Gradually, the bookselling company reaches a decision to invest in its own infrastructure and develop some in-house payment gateway that would be used as a centralized system of record.
The managers start to analyze the problem of in-house payment platform development and list related costs and tasks, such as: logic to be developed, integrations, needed for payment processing, implementation of recurring billing functions and reconciliation processes. At the same time, they realize the additional costs of a new data center, PCI audit procedures, tokenization appliances and other operation costs. The company understands that the problem is too complicated to try to solve it with internal resources only.

As a result, the management decides, that the payment ecosystem should be based on some existing open-source payment technology.

Open-source payment gateway solution

The bookselling company licenses and implements an open-source payment technology (adding the missing functionality in-house) and its growth continues. Now it has its own infrastructure, which it fully controls.

With time, however, the company starts facing new problems. First, it has to redo all the necessary certifications and implement new integrations. These integrations start taking too much time to complete. Second, supporting card-present solutions in different geographical locations is not an easy task, so it poses additional challenges. Third, as the company’s core product begins to mature, the management decides to expand their operations to Europe (in addition to North America, where the business is already solidified), and understands that they need to include marketplace offering, allowing participating stores to use the company’s merchant services.

It seems like an endless cycle of growing needs, product updates and constant re-certifications. The solution comes in the form of collaborative payment processing.

The essence of collaborative payment processing

While a payment gateway can connect to a bank or a processor, it can also connect to another instance of itself, running elsewhere (in another ecosystem). Therefore, two payment ecosystems, that use the same payment processing platform as foundation, can connect to each other, forming a cloud.

While the bookselling company expands to Europe, it finds out that there is a payment service provider that uses the same open source payment processing technology. This technology has a cloud capability, allowing the two instances to get connected and, automatically, provision accounts and set them up for processing, as well as process transactions through each other.

The company signs a contract with its European partner (PSP), which allows it to underwrite merchants using the integrations of the PSP. At the same time, collection of merchant and transaction data (as well as other data) is performed using the existing in-house technology, built by the original business. As a result, without the need for any additional integrations, the bookselling company immediately gains access to all of the processing capabilities of their partner in Europe.

After some time, as the company expands further, a similar collaborative payment processing mechanism is replicated in Australia. The three companies (headquartered in the US, Europe, and Australia) form a three-sided partnership, allowing them to benefit from each other’s processing functionality.


Each individual case of a company’s growth is unique, and you should be looking for solutions that work best for you. However, the example, described above, is very typical of what we have observed within the industry. If you feel that this scenario resembles your business and would like to learn more about the concept of collaborative payment processing, we will be glad to provide additional information at UniPay Gateway.

In the next article we are going to describe the concept of payment gateway cloud in greater detail.

Credit Card Processing for Startups

Online commerce, electronic payments, and credit card processing have become fundamental aspects of today’s economy. As a result, almost all startup companies need to decide, how they are going to process payments for themselves or on behalf of their clients.

People often tend to ask questions like: “What are the best payment processors?” (sometimes “What are the best online payment processors?”), “What is the best payment processor for accepting micropayments?”, “What is the best processor for honest pricing?”, “With regards to fees, what is the best payment processing service for a SaaS company with a low monthly price ($5 per user per month)?”, “What is the best Payment gateway for Java which can only validate cards without posting any charge on the card?”, “What’s the best payment gateway for an online factoring invoices marketplace?” etc. In fact, there are no universal answers to these questions, as the situation is a bit more complex and context-dependant. In our article we are going to explain why, and provide some guidelines, which startup businesses can follow to find optimal solutions for themselves.

As we wrote in “Payment Gateways” series, when you are choosing a potential solution to implement, before you look at credit card processing costs, associated with a particular gateway, you need to understand, whether it supports all the functionality you need.

Let us list the fundamental questions, which are relevant for you as a startup company.

Fundamental questions regarding credit card processing

  • Do you need to process payments for yourself only, or do you need to process payments on behalf of your clients (i.e. do you need to function as a payment facilitator)?
  • Do you need only card-not-present (CNP) solution for online recurring payments, or is card-present solution (EMV) also necessary?
  • Do you need to support multiple currencies or not?

In many cases before thinking about your pricing options, you need to verify, whether the listed functions are supported, and whether the gateway supports your MCC code. Beside that, if you are trying to get a merchant account abroad, you need to check, whether you can get it with the gateway you are planning to partner with.

For example, if you are an Indian merchant, trying to get a merchant account in the US, you need to check, that you have all the necessary documents to be underwritten in the US. In the very least you must have a tax ID in the US.

Then (as we’ve mentioned), you need to verify the MCC code and check, if the logic you need is available within the gateway.

As a result of this analysis, it may turn out, that your choice of payment gateways/processors can be reduced to one or two payment platforms.

Reality check

Before addressing a particular payment gateway or processor, you can also perform a “reality check”. Keep in mind that a processor’s revenue amounts approximately to 1% of your processing volume. So, if your processing volume is $ 5000, the processor gets $50. For such a modest reward processors will not offer you complex or customized solutions.

True, Stripe and PayPal may seem to be costly solutions for your business. However, if your processing volume is not very high yet, they may be the only solutions available in your case, because they have a well-developed infrastructure, allowing them to work with the so-called micro-merchants. Larger processing companies may not have such an infrastructure.

Card-present solution

If you need a card-present solution, it is important to analyze the technology you are planning to implement, the upcoming integration, and the cost of devices you are going to use. You should also verify, whether you have all the necessary EMV certifications.

PayFac model

If you need to function as a payment facilitator and issue merchant accounts, then you should pay attention to merchant onboarding and underwriting rules, adopted by your potential processing partner. You should also check, whether your potential partner has some API in place, which allows to simplify onboarding of new merchants.

Availability of starting capital

Being a startup, you may have the funds, allowing you to rent a payment platform for your business needs. If you have both money and time, you can even develop a processing platform using your in-house development team. Finally, you can license an existing white-label payment gateway solution, as we explained in our previous articles.

In these latter cases you can expect lower processing costs, but you will have to pay for support of the necessary infrastructure.


If you have neither the starting capital, nor processing volume, you should not try to find the “cheapest” credit card processing solution, because you are getting what you pay for. If the profit the processor gets from your transactions is low, you are going to be treated accordingly.

In these cases it might be more secure to pay slightly higher processing fees, but partner with a company, which offers robust technologies and has no funding delays. If you save 25 cents on a transaction, but then find that your account is suddenly frozen or closed, it is not a preferable option.

Is it Time to Switch to a New Payment Gateway Solution?

As merchant services industry is rapidly moving forward, new payment gateway solutions are emerging. These new solutions often offer new functionality. They are more flexible and capable of satisfying the new needs of merchants and resellers/ISO/Payment Facilitators.

The purpose of this article is to outline the main signs, indicating, that it might be appropriate for you to switch your current payment gateway solution to a new one. While some of these signs are relevant for all merchant services industry players, others apply to specific groups, such as merchants or intermediary entities (ISO and payment facilitators).

Let us review some of the signs, indicating that it is time to search for an alternative payment processing platform.

  • Processing costs and fees – your cost of processing is too high and the processing fees are being re-adjusted even though your volume has significantly grown. You may have started with small processing volumes, but now your volumes are much higher, so your current transaction processing cost is significant, because the fees you are paying are the same as before. If you are not able to re-negotiate transaction pricing with your current processor, then you should look for alternatives.
  • Funding delays – it takes too much time to get the funds you are entitled to. The funds are arbitrarily frozen and delayed, while you have a good processing history, there are no problems associated with your account and no particular reasons for suspicion and funding delays. If you are unable to resolve the issue with your current processing partner (i.e., your processor cannot provide a suitable solution), then, perhaps, it is time to look for a new one.
  • Lack of multi-currency support – you need to accept payments in multiple currencies, but your current payment platform does not support multi-currency payment processing. While you can use a different payment platform to handle additional currencies, it might also make sense to find an alternative payment gateway solution that will handle everything with one interface (from one entry point).
  • Lack of the necessary features – when you have started, your processor had a satisfying feature set, but since you started using the existing solution, your needs have changed. Now there are certain features, that you need, that are not available within your current payment processing platform. For example, traditionally, you worked with e-commerce transactions, but now you would like to handle card-present payments as well. You need to work with payment terminals and offer new solutions to your customers, but your payment gateway provider is unable to support the new technology. Or, perhaps, you would like to enroll in 3D secure program, in order to improve transaction security, but your provider does not support the respective features.
  • Reporting issues – reporting is not customizable enough. I.e., the reports are not presentable in the format that you need. There are no ways to export raw data in a format, allowing you to manipulate it. Some of the data, you would like to be able to see, such as details of processing costs is not available, etc. Perhaps, as a result of unclear reporting procedures, you experience problems while trying to reconcile your deposits properly.
  • Integration inconvenience – it is possible, that the technology, offered by your payment service provider, is not the most modern (up-to-date) one. While you managed the initial integration, supporting it imposes unnecessary costs on you. You might consider looking for an easier and more natural solution.
  • Limited branding functionality – you would like to present payment processing interface to your customers under your own brand. However, your current payment platform does not allow you to do that. As a result, lack of required branding functions limits your marketing capability and hampers your relationships with your customer base.
  • Merchant onboarding problems – as we have explained in our previous article, merchant onboarding problems are extremely relevant for payment facilitators and ISOs. More and more systems today offer real-time merchant onboarding and provisioning, which is a critical feature. It becomes one of the driving factors of competitive advantage in the merchant services industry. You may be used to submitting paperwork manually and waiting for a couple of days for the MIDs do get issued. However, your customers are demanding a more streamlined process. If your current payment gateway solution is unable to accommodate it, you may consider some additional or alternative options.


If some of the listed issues resonate with the pinpoints, that you have with your current payment processor, perhaps, you should consider some changes to the existing payment gateway solution, or even switching to a new one.

How to Streamline Merchant Onboarding and Provisioning

This article is primarily targeted at payment facilitators and payment aggregators. As we wrote in our previous articles, in order to process online payments, an entity must obtain a merchant account. This process involves two aspects: underwriting (sometimes also called MID provisioning) and onboarding. In this article we are going to describe, how to facilitate the process in today’s payment gateways, and explain, how payment facilitators can simplify merchant underwriting procedures.

Traditional merchant onboarding

Traditionally, merchant onboarding process was performed manually. Any potential merchant had to complete a paper form and prepare some documents, which were submitted to the underwriter (underwriting bank). If underwriting was successful, the underwriter sent back a MID, which was then configured within a payment gateway.

Some payment systems went beyond manual process. They offered future merchants to complete their merchant application forms online. After the form was reviewed by the underwriter, a so-called “download sheet” (“tier sheet”, “VAR sheet”) was returned to the merchant by e-mail. The sheet contained the merchant ID as well as other parameters needed to configure the payment gateway for processing.

The described onboarding procedure is not very efficient. The key drawbacks are as follows.

  • Data from paper forms has to be manually input into the computer system. This requires considerable effort of many physical operators.
  • The process is time-consuming. In many cases when the process is handled on paper, the process would take several days. Online forms, in some instances simplify the process, but it could still take 24 hours or more to get the MID set up.
  • When the MID is set up, the payment gateway still has to be configured manually.

On top of that, any part of the process, that involves human participation, increases the possibility of human errors, causing further delays and pushing the moment when the merchant can start transaction processing even further away in time.

Improved merchant onboarding practices

More and more software companies, that include credit card processing as part of their product offering, such as POS systems and restaurant systems, are trying to keep up with the requirements of today’s market. Consequently, they want to provide merchants with an opportunity to get their MIDs and start processing right at the moment when the merchant signs up for the core product.

In order to achieve this, several things have to be accomplished. In fact, accomplishing even some of these items will allow underwriters to streamline merchant onboarding process.

The most fundamental component of merchant onboarding streamlining/automation is the opportunity to submit the data to the underwriter online. There are two approaches, commonly used for this end.

  • API or file-based approach. Some underwriters have either API- or file-based process, allowing merchants to send their data online, and underwriters – to verify this data and issue MIDs instantaneously. However, file-based process might still take up to 24 hours.
  • Blocks of MIDs. Some underwriters are able to issue blocks of pre-allocated live MIDs (not yet assigned to any particular merchants). Underwriters allow aggregators and payment facilitators to use these MID blocks only for merchants with certain pre-approved MCC codes, i.e., merchants, selling a certain type of products or services (say, restaurants). These merchants can start processing right away, under condition that the PayFac provides the information on every merchant, that got the new MID assigned, to the underwriter within 24 or 48 hours from the moment the merchant starts processing.

If at least one of the listed approaches is implemented, merchant underwriting process can be almost completely automated.

The next thing to automate is the acquisition of merchant data. This can be accomplished through implementation of an API or an online merchant application form, which an applicant can complete to provide required data.

After the acquisition of merchant data you have to integrate with the acquirer, so that the data, input into the form by the applicant, could be automatically submitted to the acquirer through API or in a file (according to the first approach described above). The acquirer will then issue a MID, which can be used for processing and is automatically configured within the gateway.

If merchant data is not sent to the acquirer in real time, but the acquirer provided a pool of pre-approved MIDs (according to the second approach described above), the MID will be taken from this pool. The next day (within 24 hours) a separate process will include the new merchant into the report on active MIDs, sent to the acquirer. However, the merchant will be able to process transactions during these 24 hours as well.

We should stress, that pre-allocated MIDs are mostly suitable for payment facilitator model, when all the sub-merchant funds are deposited to a main payment facilitator account and it is the responsibility of the PayFac to re-distribute the funds. Otherwise, if the deposit accounts need to be different (there is no PayFac between the merchants and the acquirer), the acquirer will, most likely, expect to receive deposit information before the MID becomes active.


Our recommendation to software companies is to pay attention at merchant provisioning and onboarding mechanisms, used by given payment service provider or payment facilitator, before deciding whether to partner with it or not.

Our recommendation to PSPs is to form partnerships with those acquirers, that can either provide a real-time MID provisioning API or pre-allocate MIDs for immediate merchant activation.

Split Funding Challenges

The purpose of this article is to address some challenges, associated with implementation of split funding. First, we are going to review a common approach, used by today’s companies, and then – suggest an alternative one, which you might find more appropriate for your particular needs.

In our previous articles we wrote about development of online marketplaces and the need for split funding logic in online marketplace models. In spite of increasing demand for split funding functionality, some payment service providers decide to refrain from development of the respective logic, because they do not want to face some common challenges, related to split funding. One of the most common problems is handling of chargebacks and refunds of payments, which were split when the purchase was made. Let us describe the traditional approach to chargeback and refund handling under split funding model.

PSP-centric split funding model

A split payment involves at least two business entities: a merchant and at least one affiliate (as described in the article on online marketplaces). Consequently, when a payment is made, the main transaction is processed by the merchant and part of the payment amount goes to the affiliate.

For example, if a $100 transaction is processed, the merchant gets $80, and the affiliate receives $20.

The challenges arise when a chargeback or refund of the transaction is necessary.

From the standpoint of the payment system the most natural thing to do is to collect $80 from the merchant and $20 from the affiliate, and return $100 to the cardholder. If both the merchant and the affiliate have sufficient funds on their accounts, the approach works fine. However, if the affiliate does not have sufficient funds on the account at the moment of the chargeback, the situation becomes more complicated. While the $20 debt can be recorded as payable by the affiliate, it is not immediately clear, who should give the money back to the cardholder, and when. In the case of chargeback, the burden can be put on the payment service provider.

Moreover, it is unclear, how the PSP can collect the debt from the affiliate, because in contrast to merchants, affiliates do not take part in transaction processing. All transactions are processed through merchants while affiliates just get their share. As long as this mechanism works, there is no need for affiliates to go through formal underwriting process and submit their details to the PSP. But when an affiliate has a debt, it becomes problematic for the PSP to collect it, because the PSP may not have all the necessary information.

As we can see, under the traditional model, the PSP faces considerable risk.

Another potential problem is that the primary merchant may, for some reason, owe money to the PSP (unpaid fees, chargebacks, etc.).

For example, the primary merchant owes $90 to the PSP. A payment of $100 comes in. $20 should go to the affiliate. Under the traditional distribution logic, $20 immediately go to the affiliate, while $80 go to the merchant only to be later collected by the PSP (leaving the merchant with $10 outstanding balance). However, this distribution scenario is not preferable for the PSP, since in the end the PSP continues to hold the debt (while preferring to shift it to the merchant).

The question is: how can the PSP improve the situation to protect itself from the listed risks?

Merchant-centric split funding model

In the previous scenario the merchant and the affiliate were considered equal players. This resulted in considerable risks for the PSP.

However, if we consider transaction split funding and transaction processing as two separate consecutive processes, then the situation can be improved (in terms of risks for the PSP and complexity).

In the first of the previously described examples, when $100 comes in, $80 goes to the merchant and $20 goes to the affiliate, just like under the PSP-centered model.

Now let us return to the chargeback\refund case. Instead of trying to collect respective shares of chargeback amount from the merchant and the affiliate(s), the PSP should collect the total chargeback amount from the primary merchant. If the affiliate does not have the necessary amount, it will be recorded as outstanding balance and be taken into account in further mutual payments. As we can see, the PSP will not have to assume the financial liability.

Finally, if $100 are processed by the merchant, the first thing it should do is pay off any outstanding balance to the PSP. If the affiliate is entitled to $20, but the merchant owes $90 to the PSP, then the PSP should get its $90, first and foremost. The remaining $10 should go to the affiliate, while another $10 should be considered as outstanding balance, owed by the merchant to the affiliate. This outstanding balance should be taken into account during future payments made between the merchant and the affiliate.

The main advantage of the merchant-centric model is that the transaction processing mechanism remains a classical one. The merchant processes transactions in the ordinary way. After that, on remittance phase, the merchant can transfer respective amount shares to the affiliates. If the merchant (or an affiliate) does not have the necessary amount available, it should be recorded on the balance as a future payable, owed by the merchant to respective affiliates (or the other way round). This system makes the clearing of payments between the merchant and its partners (affiliates) much more transparent.

Remittance issue in split funding

It is important to keep track of inter-merchant payments at two levels, corresponding to the two basic phases of transaction processing: settlement level and remittance\funding level.

Once a transaction is processed (settlement level), all the amounts, which the parties are entitled to should be recorded. However, as the actual funds become available to the primary merchant only at later period, it is necessary to record all the balances at the moment of remittance as well.
Remittance is a separate level, i.e. a sub-phase of the whole process, signifying the availability of the actual funds on the account.

Otherwise, the merchant may face the situation when the funds are available only from “gross” (settlement), but not from “net” (remittance) perspective. In such a situation it might be unable to pay the respective shares to its partners.


As we can see, PSP-centric model does have its issues and challenges, and it can lead to a conclusion that it is unprofitable and risky to support split funding. The merchant-centric approach is more difficult to implement. However, it is closer to the traditional merchant services model. It also provides a reasonably elegant resolution for the most common split funding problems.

Credit Card Processing in Restaurant Industry

The purpose of this article is to discuss the peculiarities of credit card processing in the industries, where tips are widely used (restaurant industry is a vivid example). Originally, tips were given in cash, or added to the receipt as tip adjustments. Nowadays, EMV liability shift brings forward the need for new functionality, which has already been quite relevant for the industry for some time. So why not use the situation as an opportunity to expand the functionality even further?

Restaurant industry

Traditionally, restaurant industry was considered a card-present one, just like retail industry. However (especially in the US) it has some peculiar features, related to tips. In many countries service cost is included into the price of the purchased product, but in the USA it is added separately, so when a transaction is processed, the need for tip adjustment arises.

From traditional way to easier tip adjustment

A traditional solution, commonly used in the pre-EMV world, was as follows. After the customer got the bill, he presented the credit card (with magnetic stripe), the transaction was authorized, and the receipt was brought to the customer. On the receipt the customer could specify the tip amount, which was then input into the system. Tip adjustment was done “on top of” the authorization, i.e. the authorization amount was increased, and settlement was performed on a higher amount, which included the tip.

In case of an EMV card, as long as “chip-and-signature” approach is used, the process can, essentially, remain the same. However, if “chip-and-PIN” approach is used, you need to devise an alternative way of its implementation. The reason is as follows. The customer will have to physically interact with the payment terminal (either at the table or at the counter) to input PIN. Before EMV, a debit card could be processed like a credit one, but after the EMV liability shift, some solution for “chip-and-PIN” case is absolutely necessary. Moreover, as the customer will have to interact with the terminal, the new solution can also allow the customer to select the tip amount right on the terminal screen. In this case the customer will no longer have to sign the receipt and specify the tip amount on it.

The new features

Tip amount selection prior to authorization

If you are a merchant, working in an industry, which involves tips (such as restaurants, hair salons, shuttle and taxi services), and selecting a terminal solution, you need to take into consideration such issues as tip adjustment and PIN input.

If you are a developer, devising a card-present POS system for an industry, involving tips, you need to decide in advance, how the customer is going to select the tip amount while making a payment.

We should stress, that in card-present situation the customer will have to touch the terminal and deal with a specific payment application. Consequently, it is logical to implement tip selection mechanism within this application. This will simplify the process in the eyes of the customer (the need for tip adjustment as a separate operation will disappear).

For instance, a payment terminal itself can suggest options for tip amounts (5/10/15/20 %) to the customer. Once the customer selects the tip amount, it will be instantly added to the main amount and authorized. In this case there is no need to perform or even implement the tip adjustment functionality. Sometimes tip adjustment does not succeed, so if tip amount can be input into the device prior to authorization, this risk (even the possibility) is eliminated.

As we can see, developers of software for industries, involving tips, definitely, should envision the possibility of tip amount selection on the terminal screen. We would recommend offering the customer to select one of the pre-calculated tip amounts (such as, again, 10, 15, 20, or 25 %) or key in the amount of tip manually (‘other’ option).

Support for selection of multiple tip recipients

Another issue you should consider if you develop special logic for handling tips is that a tip can have several recipients. For example, in beauty salons tips can have several different recipients. Consequently, while developing POS software for beauty salons, you can keep this in mind.


If you are a merchant in search of a new solution, you can try to find a solution, not only allowing your customers to specify tip amounts on a payment terminal, but also split these amounts among different recipients.

If you are a software vendor, developing POS software for an industry, involving tips, you should add the respective flexible tip-handling functionality (tip adjustment, automated tip amount selection, and tips with multiple recipients) to attract more merchants to your software products.

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).

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.

Online Marketplace Model

With the success of eBay, Uber, AirBnB, and other similar online marketplaces, the concept of an online marketplace is rapidly entering new industries. As a result many modern software companies are providing online marketplace software for these different industries. Consequently, the problem of payment handling in marketplace-type systems becomes more and more relevant.

What an online marketplace is

Online marketplace is a platform, allowing its users to exchange products and services, which is provided and supported by a third-party entity. Examples include eBay and AirBnB.
Plenty of different companies develop software for online marketplaces. However, the need for effective organization and support of complex payment processes at online marketplaces maintains its relevance.

The difference between an online marketplace and a conventional business

The main marketplace-specific problem is as follows. During a traditional transaction, when a customer pays a merchant for a purchase, the merchant receives the money with a small processing fee withheld. The fee is retained by the processor (the company that processed the payment).
In an online marketplace two conceptually new components were added to the above-mentioned simple transaction processing mechanism.

The first one is as follows. In an online marketplace situation there is an additional party involved that needs to be paid for the service vended. So, when the merchant is paid, a fee has to be withheld (as in the conventional model). However, it needs to cover not only the cost of processing, but the cost of the service of the marketplace. Let us use examples to illustrate the difference.

Example 1

John purchases a T-shirt for $20 in a store and pays with his credit card. The store receives $19, while $1 is withheld by the bank that handles credit card processing for the store.

Example 2

John buys a $20 T-shirt at an online marketplace. The merchant receives $18.50. $1 goes to the bank that processed the transaction, as in Example 1. However, $0.50 from the transaction needs to go to the marketplace owner.
While it is possible for the marketplace to collect its fee as a monthly subscription, or as a separate (second) transaction, it is preferable to be able to withhold just one fee from the main transaction, and then – split it among any other parties, such as affiliates, that are involved.

Moreover, the marketplace owner is not the only new player in comparison to a conventional business.
Another important thing to consider, when dealing with marketplaces, is the affiliates. We are talking about third-party blogs and web-sites, which handle the promotion of different products (ads, which we see in blogs, leading to online marketplaces like Amazon and eBay, provide vivid examples of such promotions). Say, a blogger writes about different cleaning products and detergents. She writes about unique cleaning products, and references a link to the web-site (online marketplace), where these products can be purchased. It is expected, that the blogger is going to receive some small commission of every purchase that is made through the link from her blog.

Example 3

John smears his newly-bought T-shirt, goes online and finds the blog, providing some useful information on where effective detergents can be purchased. He clicks on the link in the blog and purchases the detergent at the online marketplace. Now, beside the fees, the bank and the marketplace owner are entitled to, the blogger should also get her small share of the transaction amount.

As we can see, the traditional transaction processing model does not fully meet the needs of an online marketplace. Online marketplaces have a need for split funding, i.e, they require the ability to split an original transaction into multiple sub-components (smaller payments), that can be distributed among different parties, such as affiliates.


If you want to build your business in accordance to the online marketplace model, you need to select the right payment processing partner, who, potentially, is capable of providing flexible split funding functionality. Although you can go with a traditional processor and build the split funding logic yourself, you are likely to experience many challenges, and still the process might not be transparent enough. Consequently, it might be better and more profitable for you to partner with a payment platform, which already supports split payment functionality. It might also be useful for you to check, if a payment facilitator model is the right one for you.
In the next article we are going to address two basic split funding models.