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