From ISO to Payment Facilitator


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.


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


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.


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.


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.


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.


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.

Handling of Convenience Fees

If you want to implement convenience fees within your payment software system or payment gateway, this article is for you. In payment card industry context a convenience fee is a fee charged for card processing. It allows the merchant to pass the cost of card processing to the cardholder. Some more information on convenience fees can be found in our previous articles here and here.

The purpose of this article is to analyze the technical aspects of adding convenience fee handling functionality into a payment system.

Fundamentally, there are two approaches used for convenience fee implementation.

Convenience fee handling approaches

The first approach can be applied when merchant funding is handled by the payment gateway or PSP (i.e. by the system that processes the transaction). The second approach can be applied when funding is not handled by the system that processes the transaction (i.e. by the processor).

The main difference is that under the first approach convenience fees can be withheld at the time of funding, while under the second approach they can not, since the funding is handled elsewhere. Consequently, under the second approach, convenience fees have to be processed in a particular way at the time of processing.

Let us compare the two approaches based on a simple example.

Before describing the example, we should note, that in most cases a convenience fee is a surcharge, which is, generally, kept by the service provider that facilitates the payment (payment gateway, processor etc) (some part of that fee might be shared with the a reseller). The primary part of the transaction (100% of the original amount) is, naturally, deposited back to the merchant.


For example, if a $100 payment is made and $5 convenience fee is charged, the cardholder actually pays $105, of which $100 go to the merchant and $5 are withheld by the service provider. The surcharge includes the actual cost of transaction processing and an additional markup.

Under the first approach, the entire transaction (primary transaction amount and the convenience fee) can be processed as a single transaction using the same MID. At the time of funding the principal amount can be funded to the merchant and the convenience fee – withheld by the payment service provider (who facilitates the funding process and, therefore, can hold the funds).

Under the second approach, the PSP or payment gateway relies on some underlying processor to handle funding. In this situation if both the primary payment and the convenience fee are processed as a single transaction (as in the first case), all $105 will go directly to the merchant. Therefore, it is necessary to process two separate transactions ($100 payment and $5 convenience fee) using two different MIDs.

Peculiarities of the two approaches

First approach: MID and MCC

We should stress, that every MID is associated with a certain merchant category code (MCC) used for classification of products and services the merchant provides. Convenience fees are allowed to be processed only under certain MCCs (for instance, supermarkets are not allowed to charge convenience fees, while utility companies are).

Consequently, if you choose to implement the first of the two approaches, you need to use the MID (and the respective MCC) which allows you to charge convenience fees (sometimes a separate MID with a different MCC may be required to charge them).

Second approach: critical aspects

If you choose to implement the second approach, you need to think about several particular aspects.

  • When will convenience fee be charged? Will it be charged on successful payments only or on declines as well?
  • What should be done when a payment is not authorized because there are no funds on the card?
  • What should happen if the primary transaction succeeded but there are no sufficient funds to process convenience fee?
  • How to handle the situation when the primary transaction is voided or refunded back to the cardholder? Should convenience fee be refunded in such cases?
  • What descriptor should be used on the MID through which convenience fees are processed? How to ensure that the cardholder understands that it is related to the original payment?

These and similar questions must be addressed as part of your planning process.

Calculation of convenience fees

Calculation of convenience fee amount is another important aspect. Convenience fee is usually calculated in one of three ways.

  • It can be a fixed amount.
  • It can be a certain percentage of the principal transaction amount.
  • It can be a combination of the two.

It is desirable for the amount of convenience fee to be derived from the actual cost of transaction processing (include the actual cost plus bring some revenue). In order to achieve this, one of the several approaches can be used (similarly to transaction pricing strategies).

  • Unified “blended” rate. Same rate is used to calculate convenience fees for all transactions. However, handling of different cards may have different price, so some more sophisticated and flexible techniques might have to be used (allowing you to differentiate the fees, depending on card processing costs, instead of charging everyone maximal rates).
  • Buckets or tiers. Under tiered pricing, the fee can vary, depending on card type and transaction amount.
  • Customized logic. You can develop some customized logic, which will calculate interchange amounts based on card types and industries (e-commerce, retail etc), and define convenience fees based on interchange amounts. The technique is the most complicated one; however, it provides greater flexibility.


If you want to add convenience fee handling functionality to your payment system, you need to decide, how and when the amount of convenience fees are going to be calculated, as well as how and when they are going to be charged.

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.


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.


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.


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.