Split Funding and Adaptive Payments

In this article we are going to discuss the concept of split funding and address one of the existing examples of its implementation – PayPal adaptive payments.

Traditionally, in merchant services during payment processing the simple residual revenue sharing model was used. In this model, the cost of transaction processing (processing fee) was collected from the merchant. Part of this amount could be paid to a channel partner in the form of commission. Usually, the funds were distributed between up to 3 parties. Merchants would get their net processed. Merchant fee was retained by the processor or merchant service provider, and part of that fee was paid to Visa / MasterCard as well as to the underlying processor for the actual processing of the transaction. In some cases the part retained by the MSP was additionally split in between the MSP and some sales partner or ISO that helped to set up the account. Some information on merchant services commissions sharing can be found in one of our previous articles.

When the market developed, a set of new requirements to implementation of funds distribution mechanism emerged in the industry. The requirements were produced by new use cases and scenarios, in which the funds needed to be distributed to more parties.

Let us look at the three use cases, illustrating the more sophisticated remittance approach.

Convenience fee

The first use case is the case when convenience fee is used, and one or more third parties need to be paid percentages out of this convenience fee.


A person pays a rent of $1,000, and a payment processing company adds a 3% ($30) convenience fee. The merchant (property owner) expects to get his $1,000. Consequently, a logic is needed, allowing the processor to retain $30 from the total amount of $1,030. The convenience fee may include merchant fees only (in this case the whole $30 will be retained to cover the future merchant fees for transaction processing). Besides merchant fees, the convenience fee may include some additional commission. For instance, $4.99 per payment might be charged by the web payment portal provider on each payment processed. Therefore, the payment portal provider will expect to get $4.99 out of each 3% convenience fee.

Convenience fee / tax / reserve

In this scenario, every transaction amount is automatically split into several parts, due to particular business-related reasons, such as the need to keep taxes and reserves on separate bank accounts.


Let us assume that a $1000 transaction is processed, and we have an 8% tax rate, while a 3% convenience fee is added. Additionally, there is a business need to surcharge an 8% tax and hold 10% of net proceeds as a reserve. It is mandated that tax and reserve amounts must be stored in dedicated bank accounts. Given the explained conditions, the gross transaction amount will be $1,110, which will need to be split accordingly:
$30 – convenience fee;
$80 – tax;
$100 – reserve;
$900 – net remitted to merchant.

Many vendors

In this scenario we have an online retailer is reselling products or services of one or more vendors. The retailer uses a simple pricing model, charging fixed percentage above its wholesale cost.


An online bookstore works with three publishing houses. It has a 10% margin arrangement with the first publishing house, and 5% margin arrangement with the second and third publishing houses, while the remaining amount (90% or 95%, respectively) is remitted to the vendor.
Let us say, an online order for three books with a total amount of $100 is placed. Each book comes from a separate publishing house. The first book costs $50, the second – $20, the third – $30. The total amount of $100 should be split accordingly:
$45 – amount remitted to the first publishing house;
$19 – amount remitted to the second publishing house;
$28.5 – amount remitted to the third publishing house;
$5+$1+$1.5=$7.5 – amount collected by the bookstore.

Adaptive payments

The company that was the quickest to respond to the needs of the market was PayPal with the introduction of their adaptive payments system. As it stands right now, it is designed, primarily, to take care of the last use case.

In essence, adaptive payments allow you to get the payment and automatically distribute part of this payment (such as the abovementioned commission) to one or more PayPal users, according to some rule, embedded in the remittance logic.


Realizing the need for new residual revenue sharing mechanisms on the market, more and more gateways incorporate split funding logic into their remittance engines. If you need this new functionality, ask your payment service provider, if they have it available.

Peculiarities of host EMV integrations

Every day the number of companies, working on EMV integrations, increases. There are several common misconceptions, that people have when starting integration, so we’ve decided to a closer look at the integration process and address some of those.

Briefly speaking, in order to go through the integration process successfully, one needs a terminal with a terminal application, which is going to be integrated with a gateway, while the gateway, in its turn, is integrated with a processor.

We’ve already written articles about EMV standards and technologies, as well as their advantages. In this particular article we are going to focus on some details, particularly related to EMV integrations. The article is targeted at payment gateway developers, who need to add EMV capability. We shall look at the changes, which need to be introduced into payment gateway logic in order for the gateway to be able to support EMV.

Support of EMV-specific fields in the request

In order for a gateway to support EMV (exchange EMV information), it needs to support fields, which are specific for EMV data processing. These fields are grouped into two key sets. One set of fields is the tag data read from the chip (usually sent as a single field). Another set includes information about general terminal capabilities, particularly, its EMV capabilities, as well as the entry mode, that was used when transaction was processed. Mostly processors will be asking whether a transaction was processed using integrated circuit (ICC), or it was a fallback using swipe, or a fallback using manual entry. These fields are also used for contact-less processing.

One of the EMV tags (9F26 – Application Cryptogram) must include the Authorization Request Cryptogram, which is responsible for the integrity of all of the other fields in the request message.

Support for updates in the response

It is important to understand that the issuer can return a configuration script which needs to be passed back to the card for a subsequent update. Therefore, the gateway will need to accommodate this value in its response field.

One of the mandatory EMV tags in the response (Issuer Authentication Data – Tag 91) must include a special Authorization Response Cryptogram (ARPC), which guarantees the integrity of the response message in general.

In some cases the receipt is printed by the POS, and not by the terminal. For the cases when the POS system prints the receipt itself, in order to make the functioning of the POS system more transparent, you need to make the access to the fields printed on the receipt as easy for developers as possible in the face of the future EMV integration, particularly through adding specialized fields to the response message.

Mandatory fields on the receipt

EMV has requirements that certain fields must be printed on the receipt. There are several requirements for approved and for declined transactions, as well as for offline transactions. Commonly, mandatory fields to be printed on receipts are:

  • application name (for example, application preferred name (Tag 9F12) should be printed if possible)
  • application PAN (last four digits of card number; Tag – 5A)
  • card entry mode (such as chip / contact-less / keyed / swipe, including fallback if used)
  • transaction total (for example, the receipt total line must reflect the transaction Amount (Tag 9F02) and identify the currency used to process the transaction)
  • cardholder verification (for example, “Verified by PIN”)
  • authorization mode (for example, “online” vs “offline”)
  • EMV tag data (for example, tag 4F for Application Identifier, 95 – for Terminal Verification Results, 9F10 – for Issuer Application Data, 9B – for Transaction Status Indicator, 8A – for Application Response Code)

Partly, these values are taken from request fields, and partly – from response fields.


EMV-certification is a long road. If you choose to walk it, you’d better be well prepared. Consequently, it is better to think carefully in advance about all the peculiarities of EMV integration implementation and all respective changes of your payment gateway API.