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.
Recommended to you
