From ISO to Payment Facilitator

Introduction

Recently the term “payment facilitator” has gained popularity. The role of payment facilitators at the merchant services market has grown significantly. The concept of a payment facilitator is actively promoted in the merchant services industry. Consequently, more and more companies consider the idea of assuming the role of payment facilitators.

Problem

A business, selling merchant accounts, is currently functioning as ISO, but wants to become a payment facilitator.

Context

An ISO, generally, relies on other entities in many aspects of its activity. If a business needs to get a merchant account (purchase it from an ISO), the ISO needs to address some other entity (usually, the payment processor) to handle this issue.
Traditionally, the model functioned as follows. ISOs and software companies, which performed the role of ISOs for their clients, referred their clients to the processors and helped sell the accounts, relying on external gateway. Underwriting and funding was handled by the processors. With time, as the number of clients increased, they realized that the model was not very effective. As a result, payment card associations suggested the concept of payment facilitators, which provided these new entities with greater control over the processes of MID issuing, merchant funding etc.
ISOs have various reasons for becoming payment facilitators.
As we’ve mentioned in one of our articles, a payment facilitator actively participates in sub-merchant funding, and each of its sub-merchants is funded under a separate MID. In view of these functions, to become a payment facilitator, an entity needs to perform several important steps and answer some critical questions.

Strategy

Finding a processing partner

If you are an ISO, you already have a certain number of merchant accounts to support.

  • Are you going to become a payment facilitator with your current payment processor, or find a new processing partner? In either case, as mentioned in the respective article, you will have to sign a separate agreement with your processing partner, and go through the payment facilitator underwriting process.
  • If you are switching to a new payment processor, what is the plan for migration of your merchants? Will all the existing merchants from your portfolio be able to go through underwriting process with the new payment processor? If not, what is the “plan B” for those merchants, which are unable to do that? Some tips on migration to a new processor can be found here.

Pricing strategy and underwriting

If you are going to change our processing partner, you need to carefully study the following two issues:

  • What are the underwriting requirements of the given processor? Which documents and guarantees are required? What are the requirements for merchant services reserves? Remember, that before being able to underwrite your sub-merchants, you need to go through underwriting procedure with the payment processor yourself.
  • What transaction pricing model is offered by your potential processing partner? More information on transaction pricing models can be found in our previous articles, such as this one.

Technical aspects

You need to address several technical aspects. Mostly, these concern the peculiarities of new integration(s).

  • What types of payment cards and transactions do you need to support?
  • How will the new merchants be set up? How will the new MIDs be issued? What is the merchant underwriting mechanism you are going to use? If merchant information changes over time, how will those changes be delivered? In other words, what is the strategy for merchant on-boarding and provisioning?
  • Who will implement KYC (know your customer) logic, verification procedures? Is it going to be the processor or your own development team?
  • How will sub-merchant funding, remittance, statement generation, and reporting be organized?
  • Do you need card-present solutions (which, naturally, call for usage of physical payment terminals)? Which terminals are you going to use? Which processor(s) is(are) going to support particular solutions (card-present and card-not-present, or some others)? If several processors are going to be involved, then merchant on-boarding, funding, and chargeback handling procedures have to be worked out for each of the processors. If you need to process only card-not-present transactions, do you need to handle recurring payments and batch transaction processing? How are you going to handle these tasks? What is your solution for merchant information updating (account updater functionality)?
  • Are you going to handle most of the abovementioned processes manually? If yes, you need to develop training materials for your personnel. Otherwise (if the processes are going to be automated), you need to launch the respective development projects in order to implement the necessary logic.

PCI compliance and fraud protection

What is your status in terms of PCI compliance? What fraud protection mechanisms are available? In order to ensure the security of all the processes, you need to go through appropriate PCI audit as a prospective payment facilitator, and implement the best fraud protection tools you can find.

Conclusion

Becoming a payment facilitator, you are getting more control of merchant funding and underwriting processes, but you are also assuming greater risks and responsibilities. Your transition strategy must include all the aspects, needed to ensure smooth handling of the whole life-cycle of your sub-merchants.

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.

What is payment aggregation?

What is payment aggregation?

Payment aggregation is a processing arrangement when a large business (called the aggregator) is processing transactions on behalf of many smaller businesses belonging to its portfolio.

How can payment aggregation be practically implemented?

Payment aggregation can be implemented in one of the two ways.
In case of so-called straight aggregation, the aggregator (payment service provider) gets underwritten by credit card payment processor and processes transactions of all of its sub-merchants using the same merchant ID (MID).
In case of sub-merchant aggregation (sub-merchant funding) the aggregator processes transactions of the smaller businesses under different MIDs, remits the funds to sub-merchants and withholds the fees but still bears financial responsibility for all the accounts.
Due to increased possibility of fraud with the straight aggregation model, sub-merchant aggregation is a preferred way to organize processing.
In respective articles you can find some more detailed information on payment aggregation model and sub-merchant funding.

Who can benefit from payment aggregation?

One of the categories of merchant services industry players, frequently using payment aggregation, includes software and service companies, customers of which need to accept payments from their respective customers. Payment aggregation model allows software providers to function as payment service providers using either payment processor integration or some white label payment gateway offering, which they use under their own brands.

What are the risks associated with payment aggregation?

In these types of arrangements the payment aggregator usually gets the preferred processing rate from the underlying payment processor or bank. In return, it, generally, assumes the risk (financial liability) for its entire portfolio. Consequently, aggregator becomes responsible for any transaction fraud or chargeback associated with its sub-merchants.

Sub-merchant Funding

The purpose of this article is to familiarize different merchant services industry players (merchants, resellers and payment service providers) with the concept of sub-merchant funding and associated features required from a payment gateway.

Introduction

The concept of sub-merchant funding becomes relevant when some company is functioning as a reseller (payment service provider, aggregator) of merchant services to other companies. Sub-merchants are, thus, merchants that processes transactions with assistance from a reseller (aggregator, PSP), who is playing the role of an intermediary.

In contrast to merchant funding, where the funds are transferred immediately to merchants, under sub-merchant funding the funds are transferred to sub-merchants from a certain payment service provider’s (or reseller’s) portfolio, while the aggregator gets its revenue portion.

The overall goal of the entire sub-merchant funding mechanism is to get the funds for transactions that a merchant processed to that merchant as quickly as possible.

There are two ways in which sub-merchant funding can be organized; each of these ways has its own advantages and disadvantages.

Sub-merchant Funding Models

Direct Sub-merchant Funding

Under the first model the processor transfers the funds directly to sub-merchants. Merchant services fees in this case are withheld by the processor and part of the fee amount is transferred to the PSP (see article on {residual revenue sharing}).

The advantages of this approach are:

  • sub-merchants get their money faster, as no additional banking transfers are required to move the funds to the PSP and then to sub-merchants
  • fewer bank accounts are involved, so reconciliation becomes easier for sub-merchants

The disadvantages of this approach are:

  • PSP is fully reliant on the processor to do the funding accurately and to service its customers (sub-merchants) well. If quality of this service is not satisfactory for sub-merchants, the reputation of the PSP can tremendously suffer
  • sub-merchants are directly exposed to the processor, so there is a chance that the processor company might try to seize them from the PSP
  • the approach is efficient only in cases when all transaction types needed by a given merchant can be handled by the processor within sub-merchant funding process. For example, if a merchant processes ACH and Amex, but the processor can only handle Visa and MasterCard, and, consequently, the PSP is required to take care of Amex and ACH transactions, the entire approach loses its meaning

Sub-merchant Funding through the PSP

Under the second model the funds are transferred to the PSP, and the PSP transfers them to each of its sub-merchants taking care of fees and funding of its respective sub-merchants on its own.

The advantages of this approach are:

  • Greater independence and more control of the process (funding schedules, merchant statements etc.) for the PSP
  • PSP gets more privacy in portfolio management, and, consequently, greater control over pricing. As a result, it has more potential bargaining power with the processor, since the processor has a lot less visibility into pricing of the sub-merchants

The disadvantages of this approach are:

  • PSP must have some type of software system to take care of sub-merchant funding and merchant statements
  • In cases when the processor funds to the PSP net processed (with fees deducted) versus gross processed transactions, or when reserves (see respective article for details) are withheld, reconciliation process can become rather complicated

Conclusion

If you are a PSP having the necessary technology and expertise to handle sub-merchant funding, it is better to perform it on your own, as it gives you greater control of the process and, probably, guarantees a more profitable arrangement for you. On the other hand, if you do not have skills and/or staff to handle reconciliation, it might be better to go with processors that can offer sub-merchant funding on their platforms.

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.