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.

PSPs, Payment Facilitators, and Aggregators

Depending on particular region of the world, the terms payment service provider (PSP), payment facilitator, and payment aggregator can denote different concepts and have slightly different meanings, i.e. one and the same type of entity can be called in a different way. However, globally, the three different concepts do exist, no matter how you might call them.

The purpose of this article is to explain the difference between the three crucial concepts, defining the three types of important merchant services industry players. Let us now provide a more detailed explanation of the differences.

Payment Service Providers

A payment service provider (PSP) is an organization, which provides individual merchant accounts to its merchants (i.e. provides traditional merchant services). Such a company works with a group of merchants, however it, generally, does not participate in the process of merchant funding.

A PSP facilitates merchant underwriting and payment processing, but merchant funding is, generally, done directly by the acquirer. Subsequently, a payment service provider can derive certain residual revenue only from the processing fees collected by the acquirer.

Payment Facilitators and Aggregators

A payment facilitator is similar to a PSP, but in contrast to a PSP, a payment facilitator does fund the merchants directly. However, the entities which conduct sub-merchant funding can be further subdivided into two groups.

The first group includes classical payment facilitators. In this case each business (merchant) is treated as a sub-merchant of the payment facilitator. This means that there is a separate MID, that is issued for each merchant involved in processing.

The second group includes the so-called aggregators. In case of an aggregator the same MID is used for every sub-merchant.

Examples

An example of a payment service provider is any independent sales organization (ISO). ISOs and resellers of merchant services can serve as examples of merchant service providers. Almost every bank nowadays has a department dealing with merchant services.A restaurant software (gym software, club management software, or any POS software) company is an example of a classical payment facilitator. Each restaurant using the software can get the merchant account through the POS development company. In this case the payment facilitator (being the software and financial services company) is going to review the account, collect the proper information from the customer and register it as a sub-merchant in their payment facilitator’s portfolio.

Another example includes such companies as lodging services (for instance, Airbnb) or marketplaces. A person renting accommodation through Airbnb does not have his own MID. A general aggregate MID is used for the whole service. The aggregator funds the apartment owners, and ensures that appropriate payments are deposited to respective apartment owners’ accounts.

One of the principal differences between payment facilitators and aggregators is the size of businesses (merchants) the two types of entities are dealing with. Payment facilitator model is suitable and effective in cases when the sub-merchant in question is a medium- or large-size business. Classical payment aggregator model is more suitable when the merchant in question is either an individual or a small business. Consequently, sub-merchants of classical aggregators must follow certain constraints of maximal processing volumes. When transaction volumes of a merchant become larger, this merchant can be obliged to have its own MID, or even become an independent business.

Conclusion

As the need for payment service providers and payment facilitators grows, you may consider becoming one. It is important to identify the specific model that you want to follow and ensure that you have necessary banking relationships, procedures, and software to handle the needs of the respective market segment.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic.

3 Companies, that Need Open Source Payment Gateways

The purpose of this article is to familiarize various merchant services industry players with the benefits of an open source payment gateway.

During the last several years more and more open source software products emerged.
One of the reasons of rapidly growing popularity of open source software products is their collective development, where each company using the software benefits from any development that any other party introduces. Consequently, the concept of open source software development became particularly prevalent among the companies that developed programming tools and libraries; however, it was also adopted by business software providers, such as shopping cart and POS software vendors etc.

Payment gateways, on the other hand, traditionally, were commercial closed-source products. Source code represented strategic value for payment gateway operators. Payment gateway software was, originally, developed by the company, which operated the payment gateway. Payment gateway operators did not sell the software code to other parties and left all the implementation know-how to themselves as a trade secret. Now, however, we are witnessing the emergence of companies, which offer payment gateways as licensable platforms (technological commodities); they do not host them themselves, but rather license them for others to host and use. As a result, the open source concept became especially popular in such cases, because usage of open source in technical products of such kind is a convenient and practical option.

Who might need open source payment gateways?

Many people think that payment gateway software is needed only by companies that accept credit card payments. In reality, companies that facilitate payment processing or process transactions on behalf of others would also greatly benefit from open source payment gateways.

Here are the three types of companies that might benefit the most from payment ecosystems, built on top of open source technologies:

  • Payment facilitators (or payment service providers), i.e. entities, that process large transaction volumes, but do that through some third-party processor (acquirer))
  • Mainframe platform users, i.e. legacy system users
  • Software and service companies, integrated with multiple payment systems and gateways (such as Authorize.net, PayPal, Stripe, Square, etc.) (check the article on various types of payment processing solutions here)

Let us now look at each of these three groups of companies in greater detail.

Open source payment gateways for PSPs

Payment service providers, traditionally, relied on several payment gateways, because the combination of these gateways could offer a broad scope of functionality, and wider access to acquirers. As a consequence of that, they had to define their operational procedures around multiple unrelated payment systems.

Open source payment gateway architecture could function as a universal, unifying and flexible solution in such cases. On one hand, the open source payment platform could be used as an intermediary system that all additional gateways would be integrated with. In this case, it would function as a single point of record and, potentially, single point of integration for customers of a PSP. On the other hand, such an open source platform with the ability to implement direct connections into acquirers could serve as a replacement for other legacy gateways the PSP uses.

Example

A payment facilitator partners with FirstData and Vantiv to process transactions in the US and Canada, and with another couple of gateways to support Australian and European processing. Due to the nature of its business, it has to deal with four different gateways. The payment facilitator could integrate these four gateways into a single open source gateway, which he could then adopt as a single system of record and which all of its customers would integrate with. Consequently, as more connections are needed, they could be added at the back end, without affecting the existing front-end integrations.

Open source payment gateways for legacy system users

Legacy systems are mainframe-based software packages. Initially they were written 30 to 40 years ago using languages such as Fortran, Cobol or RPG. They are still widely used in financial and banking sectors and many of the billing companies rely on those.

A legacy system was usually developed to satisfy the needs of a particular company, which used it. Today, such a company might need to replace the outdated (but still working) system with a new one, because it becomes too complicated to maintain the existing legacy system. However, it is really problematic to find an alternative system, so perfectly fitting into the business model of the company. And it is equally difficult for the company to develop a replacement system using its internal team from scratch.

In this situation, an open source payment gateway is a viable solution, because, it already has all of the foundational logic implemented (so no significant upfront development is required). At the same time, its open nature allows the company, that uses it, to introduce any changes that it needs to make it fit better into its business model.

Example

A billing company using mainframe could choose to build its new payment ecosystem using an existing open source payment platform. Normally, the migration process can be broken up into phases. The initial rollout could rely on the existing functionality with minor modifications. Within each phase various changes in logic could be introduced, gradually adjusting the entire system to the needs of the company.

Open source payment gateways for software companies

There are many software companies today, that have implemented support for various payment gateways within their products. Examples of such products include event reservation systems, shopping carts, POS systems, restaurant software etc. These companies, traditionally, wanted to distance themselves from payment processing and concentrate exclusively on domain-specific functionality. At the same time, they wanted to support the widest number of payment gateways and processors available.

As the number of supported gateways increased, it became more and more difficult to maintain all the connections by the internal development team. Relying on third parties for development of the necessary plug-ins is not always the best option. Since such integrations are, generally, tightly coupled with the main application code, changes to the application can cause malfunctioning of pre-written integrations, especially, those delivered by third parties.

Consequently, such companies could benefit from an open source payment platform by delegating all of the payment processing logic and management of the payment connections to the external payment system, and by maintaining a single unified integration with that system from the core product.

This way any changes in the core product will, probably, have minimal effect upon the existing integrations, and all new integrations can be developed in a unified fashion, taking advantage of the open source nature of the payment platform.

Example

A classical example is a shopping cart vendor, trying to support as many payment gateways as possible, in order to reach the broadest spectrum of potential clients. Still, some clients have integrations with some payment systems, which are not currently supported. Usage of open source technology as the foundation of the payment ecosystem gives such a vendor an opportunity to implement the logic for the integration that it needs without any changes in the core product. This alleviates pressure from the shopping cart vendor when it comes to implementation of new integrations.

Conclusions

If your company in the course of running its business has to deal with multiple payment gateways or payment processors with a need for a unified entry point, you would, likely, benefit from an open source payment gateway technology, and we encourage you to research that topic more.

What is a payment service provider?

What is a payment service provider or PSP?

A payment service provider (or PSP) is a company facilitating different types of payment processing for other companies, usually through its own payment system.

What is the difference between a payment service provider and a merchant services provider?

Some people use the two terms (PSP and MSP) interchangeably. All payment service providers are, in fact, merchant service providers as well. However, in case of payment service providers, payment aggregation model is often used. When merchant accounts are issued by merchant services providers, they are issued in the name of the underlying merchant that goes through the underwriting process with the acquirer the MSP works with (the acquirer can be a merchant services provider as well).
In contrast to merchant services provider, a payment service provider is often an aggregator in relation to merchants in its portfolio. Services of payment service providers are more popular in industries, where it is more difficult for merchants to get merchant accounts directly (high-risk).

How can an entity become a payment service provider?

There are two things that a company needs to become a PSP: its own infrastructure and banking\acquirer relationships. Basically, the company will need its own payment gateway solution, a PCI-compliant hosting and integrations with banks and acquirers. More detailed information on how to become a payment service provider can be found in respective article in our blog.

What is the role of payment service providers in merchant services industry?

Payment service providers allow merchants they are servicing to avoid the bureaucracy of large financial institutions (acquirers, banks and processors), gain access to better technology and customer service and save on integration-related efforts.