How to Streamline Merchant Onboarding and Provisioning

This article is primarily targeted at payment facilitators and payment aggregators. As we wrote in our previous articles, in order to process online payments, an entity must obtain a merchant account. This process involves two aspects: underwriting (sometimes also called MID provisioning) and onboarding. In this article we are going to describe, how to facilitate the process in today’s payment gateways, and explain, how payment facilitators can simplify merchant underwriting procedures.

Traditional merchant onboarding

Traditionally, merchant onboarding process was performed manually. Any potential merchant had to complete a paper form and prepare some documents, which were submitted to the underwriter (underwriting bank). If underwriting was successful, the underwriter sent back a MID, which was then configured within a payment gateway.

Some payment systems went beyond manual process. They offered future merchants to complete their merchant application forms online. After the form was reviewed by the underwriter, a so-called “download sheet” (“tier sheet”, “VAR sheet”) was returned to the merchant by e-mail. The sheet contained the merchant ID as well as other parameters needed to configure the payment gateway for processing.

The described onboarding procedure is not very efficient. The key drawbacks are as follows.

  • Data from paper forms has to be manually input into the computer system. This requires considerable effort of many physical operators.
  • The process is time-consuming. In many cases when the process is handled on paper, the process would take several days. Online forms, in some instances simplify the process, but it could still take 24 hours or more to get the MID set up.
  • When the MID is set up, the payment gateway still has to be configured manually.

On top of that, any part of the process, that involves human participation, increases the possibility of human errors, causing further delays and pushing the moment when the merchant can start transaction processing even further away in time.

Improved merchant onboarding practices

More and more software companies, that include credit card processing as part of their product offering, such as POS systems and restaurant systems, are trying to keep up with the requirements of today’s market. Consequently, they want to provide merchants with an opportunity to get their MIDs and start processing right at the moment when the merchant signs up for the core product.

In order to achieve this, several things have to be accomplished. In fact, accomplishing even some of these items will allow underwriters to streamline merchant onboarding process.

The most fundamental component of merchant onboarding streamlining/automation is the opportunity to submit the data to the underwriter online. There are two approaches, commonly used for this end.

  • API or file-based approach. Some underwriters have either API- or file-based process, allowing merchants to send their data online, and underwriters – to verify this data and issue MIDs instantaneously. However, file-based process might still take up to 24 hours.
  • Blocks of MIDs. Some underwriters are able to issue blocks of pre-allocated live MIDs (not yet assigned to any particular merchants). Underwriters allow aggregators and payment facilitators to use these MID blocks only for merchants with certain pre-approved MCC codes, i.e., merchants, selling a certain type of products or services (say, restaurants). These merchants can start processing right away, under condition that the PayFac provides the information on every merchant, that got the new MID assigned, to the underwriter within 24 or 48 hours from the moment the merchant starts processing.

If at least one of the listed approaches is implemented, merchant underwriting process can be almost completely automated.

The next thing to automate is the acquisition of merchant data. This can be accomplished through implementation of an API or an online merchant application form, which an applicant can complete to provide required data.

After the acquisition of merchant data you have to integrate with the acquirer, so that the data, input into the form by the applicant, could be automatically submitted to the acquirer through API or in a file (according to the first approach described above). The acquirer will then issue a MID, which can be used for processing and is automatically configured within the gateway.

If merchant data is not sent to the acquirer in real time, but the acquirer provided a pool of pre-approved MIDs (according to the second approach described above), the MID will be taken from this pool. The next day (within 24 hours) a separate process will include the new merchant into the report on active MIDs, sent to the acquirer. However, the merchant will be able to process transactions during these 24 hours as well.

We should stress, that pre-allocated MIDs are mostly suitable for payment facilitator model, when all the sub-merchant funds are deposited to a main payment facilitator account and it is the responsibility of the PayFac to re-distribute the funds. Otherwise, if the deposit accounts need to be different (there is no PayFac between the merchants and the acquirer), the acquirer will, most likely, expect to receive deposit information before the MID becomes active.


Our recommendation to software companies is to pay attention at merchant provisioning and onboarding mechanisms, used by given payment service provider or payment facilitator, before deciding whether to partner with it or not.

Our recommendation to PSPs is to form partnerships with those acquirers, that can either provide a real-time MID provisioning API or pre-allocate MIDs for immediate merchant activation.

Payment Gateway Monitoring

This installment continues a mini-series of articles, dedicated to the insights of payment gateway development. We continue to review different aspects, allowing to improve the efficiency of a payment gateway performance and the overall quality of its service.

Payment processing in today’s world has become a necessary service for increasing numbers of emerging online businesses. One of the critical payment gateway quality factors is availability of the gateway 24/7.

However, issues occur from time to time, and the best thing you can do is to be aware of these issues as early as possible to be able to take action swiftly, minimizing potential downtime.

There are two strategies that we recommend when it comes to potential issue detection.

Internal audit of payment gateways

The first mechanism is the internal audit mechanism (self-diagnosing system). This mechanism is “responsible” for detecting any functional problems or errors within the system. Detection of errors can be performed in one of two ways: either through analysis for errors of logs, generated by different components of the system (in special log files or database tables), or through active health checks of various services (this can be accomplished by executing a kind of ping operation on every particular service to verify that it is functioning without errors). If any problems or errors are detected, the internal audit subsystem can notify the administrators about them (using e-mail alerts, SMS etc).

Transaction velocity tracking in payment gateways

In some situations a problem may occur not within the system, but either somewhere along communication channels or on the customer’s end. Instead of pushing the responsibility to other entities, most payment gateway systems try to resolve or at least detect the reason of such a problem. Consequently, a need for a special detection mechanism arises. The mechanism has to detect the situations when transaction flow from a particular client is interrupted, or changes its typical behavioral pattern.

The approach used for detection of such situations is called “transaction velocity tracking”. The idea is to monitor transaction volumes usually received from a particular client during a certain period of time.


About a hundred transactions are usually processed through a particular MID within a 30-minute interval, but at some point this number suddenly falls below that level. Respective notifications are sent to administrators. Naturally, some of the notifications will be “false alarms”, however, close monitoring of incoming transaction volumes allows to detect serious malfunctions on the merchant’s end (POS system or e-commerce web-site).

Before you develop specific velocity tracking mechanism, you should define which criteria you are going to use to track the transaction volumes, i.e. how you are going to quantify them. While tracking by MID can seem the most obvious approach, sometimes it is not the best one. In many cases instead of tracking specific MIDs it might be more relevant to track specific integrations. Say, if a gateway is integrated with ten different POS systems, it might be appropriate to track each of them as opposed to their individual merchants.

MID-level tracking is more relevant for desktop applications and individual payment terminals. However if you are dealing with a web-application with a centralized server, which uses the same credentials for processing transactions on behalf of hundreds of merchants, tracking by MID is not justifiable. In such cases, it is better to introduce the notion into the gateway, represented by this integrated software package, and then track velocity based on that.

Obviously, the two mechanisms become absolutely critical to the payment gateway, and any malfunction in these mechanisms can cause significant impact. In order to ensure proper functioning of these audit mechanisms, an additional audit service might be required on top of them. This extra layer would allow some external monitoring services, such as Pingdom or Nagios, to do health verifications on the internal audit and velocity tracking mechanisms. Health verification system is going to ping the payment gateway every 5 minutes or so, verifying that the entire gateway system is functional and operational; as part of the process it will verify that audit and velocity tracking systems are functioning properly. While this mechanism is also not a bullet-proof one, it significantly reduces the possibility of something going wrong and you not knowing about it.


The architecture, described above, is suitable for large-scale enterprise systems. If you are dealing with a smaller-size payment system, you do not actually need such a high level of complexity. However, make sure that you do make some provisions, similar to the ones, we’ve mentioned, before you actually go live.

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.

Migrating from One Processor to Another

Every now and then gateway processing relationships have to be re-evaluated. There are numerous reasons for that. Traditionally, a change of a processor for a PSP represented a new integration project for authorization and settlement, as well as moving of existing MIDs from the current processor to the new one.

In today’s world, as demands of merchants increase, the process looks a lot more complicated. In this article we are going to explain the particularities of the migration process, applied to the modern environment.

The aspects of migration

Just as before, migration of merchants is an important process. All merchants have to be moved to the new processor’s platform and configured.

A modern-time PSP, usually, has several integration points with a processor. Among them is the traditional authorization and settlement. However, many PSPs now offer batch processing – the ability to send files, and, consequently, account updater functionality, allowing for full update of information from issuers (which is, generally, required for recurring billing). This functionality requires additional integration efforts to be supported.

Many PSPs have to deal with on-boarding of numerous merchants on weekly basis and a lot of PSPs today have an integrated on-boarding mechanism, either through API, or through a merchant boarding file. Therefore, switching from one processor to another, potentially, implies changes in the merchant on-boarding mechanism.

Chargeback management has also evolved over time. It used to be a manual process. However, in today’s world, a lot of chargeback handling procedures are automated, and, again, payment facilitators may have existing integrations to retrieve chargebacks, as well as specific procedures around chargebacks disputes and uploads of supporting documentation. Switching to a new processor might mean changes in the existing integrations, or re-training of personnel, that is used to deal with chargeback disputing portal of the current processor.

Reconciliation procedures can also be a challenge, as they, generally, involve various kinds of settlement and fees reports, used for analysis of transactions processed, settled, and funded. Switching to a new processor might mean different reporting formats, or even lack of certain reports.

Loading and updating of BIN-files is another important component of modern-time migration process. More information on BIN-files can be found in our previous articles.

It is also important to understand that while you may get an enthusiastic support during the sales phase, when you go into technical integrations, you might face an extremely tedious and long process trying to put things in place and get them certified.


While change is an inevitable and necessary part of our life, and every now and then a PSP might need to change its major processing partner, this process should be approached with caution, and involve careful preparations. Depending on the size of a PSP, the process might take up to eight months, or even a year, so the PSP must set a reasonable time frame within these limits for the process to be completed. Before making the final decision on migration, a PSP should think about all of the listed aspects and decide how they are going to be organized in the new system. That is why using a standardized processing platform-gateway, which supports all of these aspects may be a reasonable choice. Usage of such standardized processing platform\gateway is extremely relevant for those, who haven’t started any integrations yet, because it will simplify potential further migrations.