Split Funding Models

Traditionally, when merchants processed their transactions, the processor simply deducted processing fee and funded the merchant the rest. Presently, there is a growing need to split the part into several deposits. One of the main reasons for that is the emergence of online marketplaces.

From conceptual viewpoint, there are two ways to implement split funding mechanism. A company may need to implement one way or another, depending on its business model. Some business models, however, need to accommodate both ways at the same time in order to function effectively.

The purpose of this article is to inform the readers about the two types of split funding platforms, so that they could choose the more suitable platform type.

Customized split: split funding on the submitter’s end

The most common and simple type of split funding mechanism is as follows. When a transaction is processed, the submitter specifies, how the funds are to be split. Say, there are two or three recipients specified at the moment of transaction submission. Recipients are merchants or users, registered within the system, that are going to receive their shares of the total transaction amount.

In other words, the submitting system specifies particular splitting (fund distribution) rules on per-transaction basis.

This approach is more suitable when the distribution of funds depends on the specific context of the transaction, such as the number of affiliates involved, or the number of items purchased.

Example 1

A customer purchases a t-shirt for $25, and the submitting system determines that there is an affiliate, involved in the transaction, who should receive $5. Therefore, the system specifies that the total transaction amount is $25, of which $5 should go to the affiliate.

We should note that, when the next t-shirt is sold, the distribution of funds might, actually, be different.

Pre-defined distribution: split funding on the gateway’s end

Under the second model (the more complex one), the split funding rules are set up in advance in the system itself (on the payment gateway’s end). Some information on merchant services commission sharing is available here {link}.

The second model is more suitable when the distribution rules are the same from transaction to transaction.

Example 2

An online rent payment software vendor partners with some specific payment gateway. The gateway charges a convenience fee. For each transaction the rent payment software charges $4.50 from that convenience fee. The rules can be configured accordingly in the rent payment software and recorded on the gateway’s end.

Example 3

An online store sells t-shirts and hoodies online. T-shirts and hoodies are provided by two different vendor companies. For t-shirt sales the online store marks up 10%, while for sales of hoodies it marks up 8% of net transaction amounts. The rest (90% and 92%) of net transaction amounts, respectively, goes to the vendors. Consequently, after the respective distribution rules are setup, when a transaction happens, it will be sufficient to specify the vendor involved.

Split funding peculiarities

We should note, that in each split funding scenario it should be clear, who is responsible for the payment of fees. In most cases it is easier to make the account, under which the transaction is processed, responsible for the entirety of the fees. In other words, the entire fee is paid by the merchant and not split into parts. However, there might be scenarios, when the fee needs to be split between multiple parties.

Another issue to address is handling of void and refund transactions. As every sale transaction is eventually split into multiple ones, it is necessary to define, how the sub-transactions can be voided or refunded. The simplest option is to allow void/refund of the main transaction and, subsequently, void or refund all sub-transactions. However, more customized scenarios may also be required.

Conclusion

Your choice of split funding platform should depend on particular split funding needs of your business.
If splitting logic is complex and context-dependant, while the software integrator (customer) needs to have full control of the distribution rules, the first (customized split) model is preferable.
If splitting rules are more or less consistent from case to case, the second approach (pre-defined distribution) might be more appropriate.

Online Marketplace Model

With the success of eBay, Uber, AirBnB, and other similar online marketplaces, the concept of an online marketplace is rapidly entering new industries. As a result many modern software companies are providing online marketplace software for these different industries. Consequently, the problem of payment handling in marketplace-type systems becomes more and more relevant.

What an online marketplace is

Online marketplace is a platform, allowing its users to exchange products and services, which is provided and supported by a third-party entity. Examples include eBay and AirBnB.
Plenty of different companies develop software for online marketplaces. However, the need for effective organization and support of complex payment processes at online marketplaces maintains its relevance.

The difference between an online marketplace and a conventional business

The main marketplace-specific problem is as follows. During a traditional transaction, when a customer pays a merchant for a purchase, the merchant receives the money with a small processing fee withheld. The fee is retained by the processor (the company that processed the payment).
In an online marketplace two conceptually new components were added to the above-mentioned simple transaction processing mechanism.

The first one is as follows. In an online marketplace situation there is an additional party involved that needs to be paid for the service vended. So, when the merchant is paid, a fee has to be withheld (as in the conventional model). However, it needs to cover not only the cost of processing, but the cost of the service of the marketplace. Let us use examples to illustrate the difference.

Example 1

John purchases a T-shirt for $20 in a store and pays with his credit card. The store receives $19, while $1 is withheld by the bank that handles credit card processing for the store.

Example 2

John buys a $20 T-shirt at an online marketplace. The merchant receives $18.50. $1 goes to the bank that processed the transaction, as in Example 1. However, $0.50 from the transaction needs to go to the marketplace owner.
While it is possible for the marketplace to collect its fee as a monthly subscription, or as a separate (second) transaction, it is preferable to be able to withhold just one fee from the main transaction, and then – split it among any other parties, such as affiliates, that are involved.

Moreover, the marketplace owner is not the only new player in comparison to a conventional business.
Another important thing to consider, when dealing with marketplaces, is the affiliates. We are talking about third-party blogs and web-sites, which handle the promotion of different products (ads, which we see in blogs, leading to online marketplaces like Amazon and eBay, provide vivid examples of such promotions). Say, a blogger writes about different cleaning products and detergents. She writes about unique cleaning products, and references a link to the web-site (online marketplace), where these products can be purchased. It is expected, that the blogger is going to receive some small commission of every purchase that is made through the link from her blog.

Example 3

John smears his newly-bought T-shirt, goes online and finds the blog, providing some useful information on where effective detergents can be purchased. He clicks on the link in the blog and purchases the detergent at the online marketplace. Now, beside the fees, the bank and the marketplace owner are entitled to, the blogger should also get her small share of the transaction amount.

As we can see, the traditional transaction processing model does not fully meet the needs of an online marketplace. Online marketplaces have a need for split funding, i.e, they require the ability to split an original transaction into multiple sub-components (smaller payments), that can be distributed among different parties, such as affiliates.

Conclusion

If you want to build your business in accordance to the online marketplace model, you need to select the right payment processing partner, who, potentially, is capable of providing flexible split funding functionality. Although you can go with a traditional processor and build the split funding logic yourself, you are likely to experience many challenges, and still the process might not be transparent enough. Consequently, it might be better and more profitable for you to partner with a payment platform, which already supports split payment functionality. It might also be useful for you to check, if a payment facilitator model is the right one for you.
In the next article we are going to address two basic split funding models.

EMV Compliance: How to Become EMV Compliant

Nowadays, more and more merchants are becoming concerned with the problem of EMV standard implementation. These merchants are looking for the most suitable EMV solutions. The purpose of this particular article is to provide some guidelines, which will allow merchants to solve EMV compliance related problems.

The concept of EMV compliance is relevant for merchants, whose facilities are equipped with devices, needed for accepting of EMV payment cards. Depending on the size of a merchant (its transaction volume), its operations model, and industry type, several approaches can be used by the merchant to become EMV compliant.

Your EMV compliance implementation strategy will depend on particular payment terminal solutions, used by your business. Conceptually, there are three scenarios a merchant can follow to become EMV compliant.

EMV compliance for different merchant types

In this section we are going to consider several merchant types, starting from simpler ones, and moving on to more complicated models. Specific steps to be taken by the merchant on the way to EMV compliance will depend on the type of payment terminal solution this merchant uses.

Standalone terminal solution case

Let us consider a merchant business (say, a retail shop), which uses either no terminals, or a standalone terminal solution, provided by the MSP. The terminal is used as a standalone device, which accepts payments, and is not integrated with the POS system. After a payment is accepted by the terminal, it should be registered in the main POS system that is used as a primary system of record.

Consequently, the current solution can, potentially, be replaced by any similar standalone terminal of the same class, which supports EMV standard. So, in order to become EMV compliant, such a merchant should address its current MSP, and verify what EMV options are available (the simplest strategy for the merchant). If the current provider cannot offer any EMV options, the merchant can address other MSPs, which offer similar pricing conditions.

Integrated terminal solution case

Let us now consider the case, when the merchant (say, a large network) already uses some payment terminal solution, provided by the MSP, and the merchant’s POS system is already integrated with the existing payment terminal solution.

In this case it would be desirable for the merchant to resolve the issue of EMV compliance with its current MSP. However, if it is not possible, then the merchant has to search for an alternative solution, taking into account all the intricacies of potential new integration.

As the process of implementation of a new terminal solution involves integration of POS system with payment terminal(s), the merchant should devise the integration strategy in advance. As we wrote previously, the strategy involves several critical issues, such as:

  • Hardware to be used
  • Functions it should perform
  • Terminal fulfillment mechanism
  • Payment types to be handled
  • Required terminal solution types

A detailed description of EMV terminal solution implementation strategy is provided in the respective use case.

Proprietary terminal solution case

The third case concerns a merchant, which developed its own payment terminal software using its own development team. In contrast to the merchants, described in the first and second subsections, this merchant cannot use any other solutions from any MSPs, because it has its own application, supported by its own designated personnel. This application has to be certified by the merchant with the current processor.

In order to keep using its current terminal application, the business (merchant) needs to go through EMV certification process. As part of the EMV certification, the merchant will, most probably, have to perform the following steps:

  • address its current processor
  • buy the respective product
  • perform integration at server level
  • add the respective logic to the payment terminals
  • purchase EMV certification toolkit
  • go through EMV certification process, as described in the respective article

Conclusion

In order to achieve EMV compliance, you need to decide, which type of merchant your business belongs to. This will allow you to define the scale and the main phases of the process of becoming EMV compliant. If you follow all the necessary steps carefully, EMV compliance will open an opportunity for gaining new benefits.