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.

Demystifying Bank Transfers

Many people, trying to create payment systems at different levels, often face the question of how to transfer funds from one place to another. For example, one person needs to be able to get money from another person, or some online payment or e-wallet system needs to be able to remit (or charge) the funds or to some individual’s bank account.

Fundamentally, there are three ways, in which funds can be moved between bank accounts. In this article we are going to look at these three ways and list some advantages and disadvantages of each of them.

Bank wire (bank transfer)

The first (and, perhaps, the most familiar) way is a bank wire, sometimes, also called a bank transfer, although the term “wire” is more appropriate. Bank wire is commonly done through a SWIFT system. Bank wire allows to move the funds from one bank to another (including, internationally). Generally, bank wires are executed quickly. If banks are located in the same time zone (or in neighboring time zones), the wire takes up to a few hours to clear. Execution of a wire, generally, involves bank representatives at each end of the wire, however, more and more banks now introduce automated wire submission services.

The problem with bank wires is that there are still very few systems, allowing to do wires in batch, so they usually have to be performed one by one. Beside that, bank wires, usually, carry a significant cost (especially, international ones).

Bank draft

Bank draft (sometimes also called bank transfer) is a transfer of money between two banks, using a clearing house. Examples include ACH in the US, BACS in the UK, and SEPA in Europe.

The information on the transfer is sent from the bank to the clearing house, which is responsible for contacting other banks involved and giving them respective instructions. Bank drafts are not performed in real time. Depending on the country, they take from one to three days. In many cases, if the transaction is not successful (due to lack of funds, or due to mistakes in the input), returns information might not be immediately available (see the article on ACH returns).

On the other hand, the cost of such transactions is significantly lower than the cost of wires, and bank drafts can easily be done in batches (sometimes, including hundreds of thousands of transactions).

Transfers through debit cards

This approach has a particular appeal to the US market, where the Durbin amendment regulates the interchange cost of debit card transactions. It will not necessarily work for low-amount payments, such as micro-payments, primarily, because, there is still going to be a 0.5% cost.

On the other hand, on high-ticket transactions (especially, in those cases when eventual profit margins allow it), this technique can successfully be used, limiting the selection of cards to Durbin-regulated ones, and using PIN-less debit networks.

Emerging technology

There are also initiatives, by various companies (such as Dwolla), to introduce “real-time ACH payments” (payments which will cost closer to ACH, but work as wires).

The problem with many of such systems is that the coverage of financial institutions by these systems is still very low, while a real-time transfer can be performed only if both accounts are at the banks, participating in the service.


Before deciding on your money-moving strategy, you should consider your specific use-cases and costs, and then – make your choices accordingly.

Optimizing Recurring Billing with BIN-files

As the importance of recurring billing increases, new needs emerge at merchant services market. More and more recurring billing companies turn to BIN-files in order to get vital information for optimizing their recurring billing process. In this article, we are going to explain, how usage of BIN-files can enhance recurring billing process. Some information on card intelligence can be found in our respective article.

One of the key problems faced by companies in recurring billing context is that customers can use pre-paid and gift cards while subscribing for some memberships or services. The “trick” is often used by those who want to get a free trial period, and know that (due to the low membership cost) they are not going to deal with collections agencies when the company finds out that the membership is no longer paid for (see article on collections).


A person subscribes for a pay-as-you-go membership costing $15 a month, using a pre-paid card. When the card is depleted, the member can just through it away and have the membership get cancelled, therefore relieving himself from the responsibility for canceling the service properly.

Often such cases create problems for merchants. One of the ways to avoid these problems is to use BIN-files to identify these cards and block them at the time when the accounts are initially setup.

Another advantage of BIN-files is that they can be used to identify transactions, whose processing cost is too high (too low). In subscription-based services industry the issue is even more important than in retail space. The reason is that while in retail business the card, causing money losses on transaction processing, is used just once, in recurring billing it is used regularly, and the potential losses from high processing fees are, consequently, larger. For example, if you don’t want to pay high processing costs, associated with rewards cards, you can identify them through BIN and decline them, thus, avoiding expensive processing fees.

Consequently, BIN-files, can help you in several ways:

  • You can identify expensive rewards cards and avoid processing them
  • If BIN-file indicates, that many of the cards used by a merchant, could be processed at lower rate through some specific debit network, it might be reasonable for the merchant to sign a separate agreement with the network and process the cards through this particular network (and not through Visa and MasterCard), saving on processing.
  • In our previous articles we also mentioned, that, using BIN-files, you can identify the bank that issued a given card. Therefore, you can use BIN files while conducting decline analysis to detect problems, that might be associated with a specific issuing bank. Working through this issue with one of your customers will automatically provide a solution for everybody else, carrying cards, issued by this bank.


Card intelligence through BIN-files can help you to save on processing costs, as well as detect abusive practices during recurring billing and common credit card transaction decline reasons. If you are not using BIN-files today, it may be the right time to start.

PA-DSS Certification

All developers of payment applications, at some point in the life of products face the challenge of PA-DSS certification process. In this article we are going to look at this process a little bit more in detail.

PA-DSS is an officially adopted data security standard to be followed by developers of payment applications, that are installed in the PCI environment. The difference between PA-DSS compliance and PCI compliance is that PCI certification is a mandatory procedure for a card network or an organization intended to ensure that the network\organization is following all the necessary requirements, while PA-DSS certification is particularly targeted at payment software developers and vendors. PA-DSS certification of a payment application developer company indicates a high level of compliance with the necessary rules of respective software products’ development.

More information on PCI and PA-DSS requirements can be found here and here, respectively.

Let us now look at the key elements of PA-DSS certification, and list the documents, which a software vendor should have available in order to go through certification process successfully.

PA-DSS certification phases

Generally, to conduct PA-DSS certification, a software vendor contracts a certified PA-DSS assessor, such as Coalfire, SecurityMetrics, Trustwave among others.

The key steps within PA-DSS audit are as follows:

  • Gap analysis. The process begins by software vendor filling out some form of questionnaire, allowing the assessor company to understand, which “weak points” or “gaps” will need to be addressed in the process of audit. The gaps in this context mean absence of some processes or procedures, required by PCI standard.
  • Product installation in the PA-DSS compliant lab. The product is installed in the lab environment, where it is to be tested for compliance.
  • Documentation analysis. At this stage installation documentation and diagrams are analyzed.
  • Product testing. The product is tested in all environments (operating systems) that are or will be used for its operation at clients’ sites.
  • Remediation. During this period any identified issued, that violate compliance, are addressed.
  • Final certification. After the remediation stage, when all the gaps are eliminated, the product is subject to final certification.

Documents, necessary for PA-DSS certification

If you are a software vendor, going through PA-DSS audit, we recommend you to prepare several important documents in advance, so that you could have them handy at the time of your final certification. This will simplify your PA-DSS audit process significantly.

The documents are as follows:

  • Implementation guide. This document describes the steps that must be followed in order for your application installations to comply with Payment Application – Data Security Standards (PA-DSS). The information in this document is based on PCI Security Standards Council Payment Application – Data Security Standards program. Product installation guide is one of the sections of the implementation guide. It includes the necessary PCI information on how to install and maintain the product correctly.
  • Software development life-cycle (SDLC) description. This should define the phases of define the phases of the software development cycle, paying special attention to software code review procedures, associated with PA-DSS requirements.
  • PA-DSS SDLC requirements list. This is an additional document with specific requirements to SDLC, concerning development processes, development environment, and development of the specific application. The document is a framework of the information needed to fill in your existing SDLC process with the requirements for PA-DSS. You can view it as a checklist to make sure, that each requirement is in your SDLC, and if not, add it to the appropriate location.
  • Description of training procedures for developers. The document must specify the frequency of PCI and PA-DSS compliance trainings and include the list of training materials used.
  • Description of support and troubleshooting policies. This document describes the procedures used to support and maintain the product. It should be clear from the document that cardholder data will not be compromised during product maintenance procedures (no card numbers will be accidentally stored etc).
  • Installation guide for resellers. If resellers are involved in product installation (if the product is installed by some third-party reseller and not by the software vendor company), the guide must provide instructions on how the reseller should install the product in a compliant.


PA-DSS certification is a rather complicated procedure to go through. However, if you are a payment application software vendor, PA-DSS certification provides you with additional security guaranties. Beside that, it allows your company to organize your development team and structure the development process in a more efficient way. And, finally, the status of a PA-DSS certified software vendor, definitely, strengthens your business reputation.

Credit Card BIN Files

Most modern-time credit card fraud protection tools are based on geo-location principles, IP-address filtering, and cardholder data verification. In addition to these methods a merchant can enhance the security of its business, and improve card processing strategy by adding another filtering mechanism. The filtering can be based on various attributes of a card, identifiable through credit card BIN.

The first 6 digits of a bank card number allow a merchant (and any business which processes bank card transactions) to learn additional information about the card by using pre-defined Bin ranges, that can be obtained from the acquirers. Based on the range the card number falls into, a merchant can understand additional information about the card.

Information which can be obtained from BIN file includes the following elements:

  • The maximal length of PAN (primary account number)
  • Name of the issuing bank and the country of origin of the issuing bank (country of issue)
  • Card type (credit, debit, prepaid, charge etc.) and PIN capability (such as credit with no PIN, debit with PIN only, hybrid card etc.)
  • The list of debit networks (for debit cards) that can be used to process the card outside Visa and MasterCard networks.
  • Information on whether the issuer is Durbin-regulated or not. In case of a PIN-less debit the BIN range allows you to determine if the issuing bank is regulated by Durbin amendment or not. It might be cheaper to partner with regulated debit networks (especially if you are processing million-dollar worth of transactions).
  • Information on card’s usage for healthcare transactions (FSA/HSA)
  • Ways to identify pre-paid and gift cards
  • Card class (purchase card, business card, consumer card, personal card, corporate card)

If you are a merchant, dealing with payment cards, the information, learned from card BIN is a useful component of your fraud protection strategy. Beside fraud protection, you can also use this information for interchange optimization, and to lower your processing costs.


The most typical example would be a US-based online retailer that only wants to accept US-issued cards.
Another example could be a pharmacy that wants to force HAS cards on certain types of purchases.


If you are a merchant, you should ensure that your payment system includes the logic for verification and, if necessary, filtering of payment cards, based on their BIN ranges. This will protect you from consumer fraud and unreasonably high processing fees.