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.

Conclusion

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.

Merchant Services Commissions Sharing

The purpose of this article is to familiarize the key players of merchant services industry with the important approaches to merchant services commissions distribution (a.k.a. merchant services revenue sharing) and respective vital features which need to be implemented in the payment systems to accommodate these concepts.

Introduction

Merchant services industry is organized in such a way that credit card transaction processing often involves multiple resellers (ISOs, payment service providers, sales agents), basically, entities, assisting other actors and making commissions on transaction processing.

Traditionally resellers were represented by independent sales organizations, which assisted businesses in getting and using their merchant accounts. In recent years more and more software companies, which develop products that include credit card processing features, found themselves playing the role of merchant services resellers (as users of these software products required merchant accounts for credit card transaction processing). Particularly, among such products are POS software, restaurant software, fitness center software, daycare center software and other software packages which rely on recurring revenue.

Merchant Services Commissions

Any transaction processing cost consists of base costs (interchange fees and assessments) and markups, and only markups are negotiable. In an article on transaction pricing and processing costs more information on this subject can be found. Most commonly, merchant services commission constitutes a portion of the markup that is paid to reseller to facilitate the relationship. In other words, if a reseller brought a merchant who is charged 3% markup over the processing cost, the reseller might get 1% of the processing cost as commission.

One of the problems always faced by a reseller of any type is the issue of collecting the commission in the most efficient way; ideally, this task needs to be implemented within a payment system.

Approaches to merchant services commission distribution

There are two common approaches to arrange efficient merchant services commission distributiion between multiple intermediate parties: buy-rate and revenue sharing.

  • In case of buy-rate, a PSP can set its transaction processing rate (buy-rate) at 3.5%. Consequently, the reseller can mark it up and offer the service at 5% and collect 1.5% residual revenue on every transaction processed. Say, for a $100 transaction processed the merchant would keep $95, $3.5 would go to the PSP, and $1.5 would go to the reseller.
  • In case of revenue sharing a PSP prices each deal as it sees fit, and certain percentage of the total markup collected is shared with respective reseller. For example, a PSP might collect a $5 fee on a $100 transaction processed, subtract the processing cost of $1.5, and give 50% of the rest ($1.75) to the reseller.

In the recent years, software companies functioning as resellers found that collecting their SAS-offering fees and merchant services fees as a combined merchant services charge was the more efficient way that made reconciliation easier for the merchants. Consequently, more and more people and businesses are searching for payment systems capable of providing respective functionality.

In order to improve the understanding of the features needed to accommodate various types of revenue sharing strategies, let us look at the example below.

Example

There is a billing company SuperBill which processes credit cards. It has an agreement with a software company ezDesign Software developing CRM systems for web-designers. Each web-designer (ezDesign Software client) is set up a merchant, because it needs to charge its customers for web-sites and design services.

When transactions are processed, every web-designer needs to get all the funds he or she is entitled to, but at the same time a certain amount (representing the cost of transaction processing services and the price of software usage) must be retained by the billing company (the basic mechanism can be found in our article on merchant fees). SuperBill needs to pay a certain percentage of this amount to the ezDesign Software it is partnering with.

For example, let’s assume, processing costs is 4%. Let us further assume that the software company wants to charge 1% for its services, i.e. the total is 5%. When a designer charges $100 from a certain web-site, he gets $95 deposited to his account, $5 is withheld by SuperBill and $1 out of the $5 is sent to the ezDesign Software.

Conclusion

When you are selecting a payment system to partner with, you need to analyze the mechanisms of residual revenue distribution included in this system and ensure that the sharing model that you need is supported and the reconciliation process is not going to be too complicated.

Payment Gateways: Introduction

Modern market environment constantly calls for new solutions in the area of credit card processing.

For many merchants in today’s market it is extremely important to make the right decisions concerning merchant accounts, merchant services and merchant relationships. Unfortunately, many merchants are stuck with the misconception that when it comes to merchant services the only thing that matters, the only determining factor while making a decision, is the price. Or, to put it simply “whoever offers a better deal in terms of costs is going to be the preferred choice”. While the cost actually is the most important aspect, it is far from being the only one.

Feeling the need for informing the key players of merchant services industry about various aspects of credit card processing, we’ve decided to publish a mini-series of posts intended to help individuals and organizations facing the task of credit card processor\payment gateway selection. Each of these posts will be dedicated to some specific aspect to be considered while selecting a payment gateway.

The series is addressed to the two groups of entities we are going to refer to as merchants and resellers. Merchant’s and reseller’s viewpoints will provide the two key payment gateway selection perspectives. In order to ensure clear understanding of our terminology, it is appropriate to start by defining these two terms.

Payment gateway selection perspectives: merchants and resellers

A merchant is a business that needs to process transactions for itself. Let us consider a health club as an example of a merchant. The reason for choosing a health club as the most illustrative example among potential ones is because a health club has multiple uses for credit cards.

A health club needs to process transactions (a retail “card-present” transaction) at the point of sale (for instance, a member buys a protein shake). On the other hand, any decent health club has a web-site where customers can also make payments and buy things online – so here’s where e-commerce comes into play. And, finally, sometimes club representatives might contact their clients by phone to collect past dues – that is another example of card-not present transaction, beside online payments. As we can see, a health club usually conducts transactions involving several so-called industry types, both card-present and card-not-present (retail, e-commerce, direct marketing, mobile and others).

Alongside merchants, there is an emerging group of entities (people or organizations) functioning as intermediaries between merchants and processors. Here we are going to call this group resellers. Resellers help merchants to get their merchant accounts or contribute to processing of the transactions in some other way. Examples of resellers include software companies, ISOs and, potentially, franchise owners.

Since a health club is chosen as a merchant example, a fitness software company should provide a suitable example of a reseller to refer to. Most club management software packages today have credit card processing as their component. People using the club management software automatically become prospects for the sale of merchant services. This provides the software company with an opportunity to partake in residual revenue. It becomes the link to connect the club with the processor\payment gateway (in technical terms) or the ISO\underwriter (in business terms).

Now that the play-field is defined, it’s time to move to analysis of specific features to be considered during payment gateway selection. The next installment is going to cover the processing costs.