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.

Payment Gateways II: Batch Transaction Processing

The purpose of this post is to familiarize merchants and resellers with the concept of batch transaction processing as an advanced feature to be considered during online payment gateway/credit card processor 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.

Real-time and batch transaction processing

The two ways in which a credit card transaction can be processed provide the basis for two processing approaches. Processing either happens in real time (transactions are authorized one-at-a-time), or it happens in batch (batch file with many transactions is sent and then processed as a whole). While real-time processing is more common in retail, batch processing is more suitable for recurring billing and bill payment (utility bills etc).

The advantage of batch processing is that it allows merchants to track multiple transactions together. This feature is especially important in recurring billing, where a large number of transactions is involved, as batch transaction processing makes it easier to manage the overall process.

Companies that need to process numerous transactions on recurring basis have two options. One option is processing transactions one-at-a-time (effectively emulating batch transaction processing). The other option is actually generating a file and sending it to the payment gateway to process.

If transactions are processed one-at-a-time, authorization and settlement represent two different steps of the process, and if something goes wrong at settlement stage, it is problematic to manage the entire batch. On high volumes of transactions the process can take very long.

The second approach is “cleaner”, primarily because transaction authorization and settlement happen at the same time: the whole procedure is done “in one shot”, there is no need to do reconciliation of the settlement at the end. File-based batch transaction processing is also suitable for merchants that process e-checks (ACH transactions), because it makes the delivery of ACH transactions somewhat easier (one file, containing all transactions, is generated).

Let us consider a health club example to illustrate how batch transaction processing works.


A health club runs recurring billing daily to collect membership dues. In addition to that it also runs a decline recycling process (reprocesses all the declines on the subsequent day). As part of the decline recycling process another attempt is made on all of the declines. Real-time processing is possible, it makes it very difficult to keep track of the transactions, processed for a given billing date, and can, potentially, be time-consuming on those billing days when large numbers of accounts need to be processed. File-based batch transaction processing, on the contrary, provides an opportunity to view every billing date within the context of a batch and transactions that go through recycling process simply constitute a portion of that main batch (sub-batch), which makes things considerably more manageable for a large-size fitness club chain.


Based on merchant’s current or future/potential needs, the merchant that needs to process considerable number of recurring billing and bill payment transactions should consider looking for a processor capable of processing large files.

The next article will cover credit card decline recycling.

Payment Gateways: Settlement (Capture)

The purpose of this article is to discuss adequate transaction settlement (capture) mechanisms as a criterion to be considered during payment gateway selection.

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

Credit card payment processing involves two phases. The first one is authorization, when the card is verified (it is checked whether the necessary sum of money is available on the account) and the money is blocked (reserved for subsequent settlement). The second one, usually taking place at the end of the business day, is capture (or settlement), when the reserved amount is withdrawn from the card-holder’s account and transferred to the merchant’s account (the funds are settled). Therefore, to complete transaction processing, settlement has to be performed.

Settlement mechanisms

In general, there are two settlement mechanisms commonly referred to as terminal capture and host capture.
In the case of the host capture most of the work required to settle transactions is actually done by the host system (payment gateway). When host capture is used, payment gateway (the host) keeps track of all the authorizations and takes care of settlement on its own.

Settlement is generally done:

  • once a day at a fixed time
  • multiple times a day within fixed settlement windows
  • on demand when end-of the day settlement message is received.

Generally, no or minimum information is required from a merchant to use host capture. Terminal capture is usually done by sending a settlement message\settlement file with the full information about the transactions that need to be settled. Terminal capture puts all the responsibility for the settlement logic upon the submitter (merchant).

While terminal capture does provide more control over the settlement process, it is easier to deal with host capture whenever it is possible, because it is easier to implement and support.

From the global perspective all types of settlement can be viewed as belonging to one or two groups: merchant-initiated or time-initiated. Terminal capture and on-demand host capture are merchant-initiated. Settlement, performed daily at fixed time, or several times a day within fixed settlement windows, we are talking about time-initiated host capture.

When choosing the settlement approach, every business needs to consider, what the best option is: merchant-initiated versus time-initiated, and host capture versus terminal capture.

Merchant perspective

In each particular case it is important for a merchant to consider all the business needs while making a choice between terminal capture and host capture mechanisms, as host capture may not support certain features needed by the merchant.


A fitness club, that works 24 hours, has three shifts of employees changing during the day. There is a common practice of settling out all of the transactions that were authorized during a shift when a shift is closed. In a situation like this, the scheduled settlement (without end-of-day message) is unacceptable for the merchant, as it has to be performed several times during the day, not necessarily at a specific time. Consequently, dealing with a processor\payment gateway, which supports only scheduled settlement, will be problematic for the fitness club.


While the preference is usually on the host capture side, merchants need to check if it fits their business model, and, at the same time, whether all the necessary features can be accommodated by the host capture system (as some features might be supported by payment gateways only under terminal capture).
If all of the features necessary can be accommodated by the host capture mechanism, it is really the preferred way of settlement.

Reseller perspective

As in the cases of other payment gateway selection criteria, while choosing a settlement mechanism, a reseller must carefully analyze the needs of the merchants it is dealing with.


One of the potential problems to be addressed by a reseller may be that each merchant might need some business specific logic. Particularly, if a payment gateway can perform settlement for a merchant at the same predefined time during the day, and merchants are situated in different time zones, it might be difficult to adjust time settings for each merchant individually to ensure proper settlement time for each timezone. Consequently, in such cases it may be easier for the reseller to delegate control of the settlement process directly to the merchant (terminal capture), than to adjust time settings to every merchant’s time zone (host capture) with the payment gateway.


While making a decision concerning settlement mechanism selection, a reseller should consider all the aspects, which are critical for a merchant. However, if resellers accept some limitations in order to simplify the integration process, they need to understand that any problems resulting from these limitations will be multiplied by the number of the merchants the resellers are dealing with.

Our next post will cover standard credit card features to be considered during payment gateway selection.