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.

Handling Merchant Fees

In the previous article we touched upon the topic of merchant funding, which is particularly important for payment service providers. This article is also targeted at PSPs, also known as third-party processors or payment facilitators. In the article we are going to address such important aspects of merchant funding (remittance) as withholding of merchant fees.

As mentioned in the previous article, one of the challenges faced by PSPs in connection with remittance and funding processes is that, regardless of the pricing structure, it is desirable to keep the process of withholding of fees as clean and as transparent as possible.

One of the crucial questions to be addressed in the context of merchant funding is “how” and “when” to take out merchant fees.

How to take out merchant fees?

Deducting fees from subsequent remittance

One way is to take the fees out of the subsequent remittance. For instance, if at some point a merchant owes $100 in fees and has just processed $1000 worth of transactions that merchant will be funded $900 instead of full $1000.

The advantage of this approach is that it is easier to spot\detect the situation when a merchant has no funds to cover the fees.

The disadvantage of the approach is that if a merchant discontinues processing, or if a merchant’s processing volume drops, there may not be enough money to cover the fees already accrued.

Withdrawal of merchant fees as a separate transaction

The second approach involves issuing a withdrawal (usually, as an ACH transaction) either from the same deposit account, or from a separate bank account that was designated by the merchant for withholding of the fees.

The disadvantage of the approach is that this type of withdrawal may result in ACH returns, which might be difficult to track, and, thus, it becomes more problematic to see the outstanding balance of the merchant (in contrast to the first approach).

Under the first approach the actual balance of the merchant is always clear, while under the second approach there is always a risk of arrival of ACH return up to 60 days from the day when fees where taken from the merchant.

When to take out merchant fees?

As mentioned above, another important question to be considered by a PSP is “when” to take out fees. As in case of “how”, there are two options.

Withholding of merchant fees at the time of a deposit

One approach is to take out merchant fees at the time of the deposit.

This approach is often used in conjunction with the on-demand remittance model (when funds are disbursed fixed number of days after transaction processing – see the previous article for details). If a PSP is funding transactions and taking out merchant fees right away, it can have fees deducted taken from the remittance. Such combination is quite a common one.

Example

On Monday a merchant processes a $1000 worth of transactions. If the fees are withheld at the time of the deposit then, and remittance is done based on response date with a two-day delay period, then on Wednesday the merchant gets this sum minus (for instance) $50 of fees ($950).

The advantage of the approach is that the PSP has higher chances of collecting the fees.
The disadvantage of the approach is that it makes daily reconciliation more complicated for the merchant. For instance, if a merchant processed $1000, it will not get the full $1000 (as fees are taken out), so the described approach makes it really difficult for merchants to reconcile, as they always have to consider the fees.

Withholding of merchant fees based on time cycle

Another approach is to take out money at the end of a processing cycle, which is, generally, a calendar month.

Example

If a merchant processes a $1000 worth of transactions on Monday, it gets the full amount on Wednesday and $50 of fees are taken out at the end of the month.

This second approach is often used in combination with withdrawal of merchant fees as a separate transaction discussed above.

The advantage of the approach is that this approach makes reconciliation easier for merchants, as they only have to reconcile the fees part at the end of the month.
The disadvantage of this approach is that it requires the PSP to potentially float its own funds, if PSP is funded net of fees by the underlying processor. Another disadvantage for the PSP is that at the time it attempts to collect the fees, the funds may not be in the account.

In the next article we are going to address the handling of transactions that occur outside the normal processing cycle, namely, ACH returns and chargebacks.

Merchant Funding for PSPs

This article is, primarily, addressed to payment service providers, also known as third-party processors or payment facilitators. Its goal is to familiarize PSPs with the concept of merchant funding (remittance) and challenges associated with it.

One of the issues faced by payment service providers is that of organizing the remittance process in the most efficient and competitive way. The remittance process is the process of sending money back to merchants for transactions they processed. The process of remittance is very closely related to merchant funding process.

There are several challenges faced by PSPs in connection with remittance and funding processes.

  • In many cases it is only possible to send the money after the payment service provider has been funded by the underlying processor.
  • Reconciliation process for a payment service provider and for a merchant, receiving the money, needs to be as simple as possible.
  • Regardless of the pricing structure, it is desirable to keep the process as clean and transparent as possible.

To satisfy the listed criteria, PSPs can choose from among several merchant funding models, incorporating different remittance mechanisms and fee withholding strategies.

Merchant remittance can be organized in several ways.

Cycle-based remittance

The simplest way to fund merchants is based on a time cycle which usually is a calendar month. Under this approach the money is sent once or twice a month (commonly on the1st and the 15th). Each remittance covers all transactions processed from the previous remittance up until now.

The advantage of this approach is that reconciliation (by merchants) tends to be simple and only has to be done once or twice a month.
The disadvantage of this approach is that if the remittance happens on the 1st and the 15th and the merchant processes considerable volume of transactions, for instance, on the 3rd, the money is not available to the merchant for the next twelve days.

The cycle-based approach is more common when some form of follow-up/collections process is performed as an add-on service to the straight processing.

”On-demand” remittance

Under the so-called “on-demand” approach, money is sent to the merchant fixed (agreed upon) number of days (usually, one or two) after the original transaction was processed.

For example, transaction processed on Monday gets funded on Wednesday.

The advantage of the “on-demand” approach is that money is available to the merchant sooner.
The disadvantage of the approach is that the reconciliation becomes more complicated, especially, if a merchant is processing transactions every day, as funding from one day can overlap with funding from another.

There are two ways in which the “on-demand” approach can be implemented.

Remittance based on transactions’ funding date

When this approach is used the funding of a transaction happens after a fixed time period counted off of the date when the transaction is funded by the underlying processor. (The funding date in this case is the date when the PSP actually gets the money from the processor.)

The advantage of remittance based on the funding date is that PSPs don’t have to float any money themselves.
The disadvantage of the approach is that it might become extremely complicated when funding is performed by different institutions (banks, processors of different types) with different time schedules. However, if all underlying funding happens on the same schedule, using this approach is not a problem.

For example, if funding period equals to two business days, transaction processed on Monday will be funded by the processor on Wednesday, and the merchant will receive the funds on Friday.

Funding-date-based approach is, technically, recommended for situations when all of the funds are received by PSPs with the same time delay.

Remittance based on transactions’ response date

When this approach is used, the funding for a transaction happens after a fixed time period counted off of the response date of the transaction. (Response date is the date when the response to the transaction (approval/decline) is received from the underlying processor, and, thus, it is known whether the transaction got approved or declined.)

For example, if funding period equals to two business days, transaction processed on Monday will be funded on Wednesday, regardless of when the PSP receives the funds from the processor.

For PSPs who have multiple underlying funding institutions, which operate on different schedules, the solution is to fund all transactions based on response date. This does make reconciliation more complicated for the payment service provider and potentially requires floating of funds, but it simplifies reconciliation for the merchant (as all of the funds are consolidated into a single deposit) and gives the payment service provider a very important competitive advantage.

Example

A merchant submits a file containing ACH, Visa/MasterCard and Amex transactions. Let us assume that ACH transactions are funded back to PSP the next day, Visa and MasterCard transactions – two days after and Amex – four days after the submission (which is not uncommon in the industry today). For example, the file is processed on Monday. On Tuesday ACH transactions will be funded back to the PSP. On Wednesday the PSP receives the funds for Visa/MasterCard transactions, and on Friday Amex transactions get funded.If funding (remittance to the merchant) is based on response date with a two-day delay period, then on Wednesday the merchant will get all the funds for the transactions processed on Monday, but the PSP will have to float the funds for Amex transactions.

If transactions are funded based on the date of their funding by the underlying processor (with the same two-day delay period), then the merchant will get the money for ACH transactions on Thursday, for Visa and MasterCard transactions – on Friday, and for Amex – next Tuesday. While under this model the PSP never has to float its own funds (send them to the merchant), the reconciliation for the merchant is rather complex, especially if processing happens daily.

In the next article we will continue developing the topic of merchant funding (remittance) process for PSPs. Particularly the article will cover the process of handling merchant fees.

Payment Gateways II: Credit Card Payment Aggregation

The purpose of this article is to familiarize the key merchant services industry players (particularly, large-size merchants, wholesale resellers and PSPs) with payment aggregation as an advanced feature to be considered during payment gateway selection. If this is the first time you are reading “Payment Gateways II” series, please, start with the Introduction as it will improve your understanding of the current post.

Payment aggregation concept

Payment aggregation as a concept exists in two aspects covered below.

Straight aggregation

Historically payment aggregation was used to give payment processing capabilities to those businesses, which wouldn’t be able to go through merchant services underwriting otherwise. A central company (PSP) would get underwritten, have its own agreement with a processor and use the same MID to process (aggregate) payments of its smaller customers that wouldn’t go through individual underwriting and have their individual merchant accounts. The PSP would process all their payments and aggregate them through the central account, remit respective funds withdrawing its own fees.
Over time the credit card companies insisted on discontinuing this practice for the most part, as it was used for covering various illegal operations, such as drug sales, money laundering etc. As a consequence, the concept of a sub-merchant was introduced.

Sub-merchant funding

Under this concept each merchant goes through some form of underwriting, but the entire financial liability and risk is on the PSP and its entire portfolio. Instead of using one single MID for all merchants, each merchant is assigned its own MID, but this MID is linked to the portfolio of the PSP. Usually the PSP portfolio has much better processing rates than any member of the portfolio could have gotten on its own. PSP takes care of funding of merchant fees and statements.

Let us look at particular functions and important features of payment aggregation model to be considered during payment selection.

Important aspects of payment aggregation model

Support for aggregation and remittance is an important enterprise feature, primarily targeted at PSPs. To facilitate efficient, transparent and flexible functioning of the payment aggregation model, resellers need to be able to perform a wide range of tasks. Particularly, a reseller, using payment aggregation model, needs to be able to do the following:

  • allow it to easily set up a merchant
  • process transactions on behalf of its multiple customers\sub-merchants
  • manage their accounts
  • use merchant-specific pricing
  • remit processing revenue back to merchants
  • withdraw merchant fees (transparently for the merchant)
  • generate statements (at the end of the month or on per-deposit basis)
  • share residual revenue with channel partners

To simplify each of these tasks, resellers need special tools. But not all processors/payment gateways are able to provide all the necessary tools to resellers. For instance, some are only able to back out their own fees, and some can not accommodate per merchant pricing.

In addition to the issues mentioned, several other considerations should be made. To learn about respective issues that PSPs should bear mind, please, consult the resources covering PCI compliance and credit card chargebacks on our web-site.

To illustrate the importance of payment aggregation support, let us consider a practical example.

Example

A PSP is offered a deal with a processor, allowing transaction processing at very good rates. At the same time the deal envisions full responsibility for underwriting, merchant statements, merchant fees etc, so the PSP needs the technology to execute remittances, generate merchant statements and take out the fees. Consequently, cooperation with a payment gateway supporting respective functionality allows the PSP to accept the offered contract with the payment processor without any additional efforts targeted at support of the aforementioned functions.

Conclusion

If a PSP is using a cost plus pricing model, with a variable pricing for each merchant, and, potentially, variable commission structure, it definitely needs a software platform capable of accommodating these features.