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.