Handling Bank Account Transfers Worldwide

This article is targeted at those who need to deal with bank accounts in different countries while processing transactions. It explains certain aspects associated with the process in different parts of the world.

Every US based business, dealing with bank accounts internationally, should pay attention at these things and the particularity of the process in each country of operation.

Globally, there are two types of systems, which are most popular today. Systems of the first type, allow for one-phase processing of fund transfers between accounts, while systems of the second type allow for two-phase processing.

One-phase processing of bank account transfers

One-phase processing is used in such countries as the USA and Canada. In these countries inter-bank fund transfers are conducted through a nation-wide clearing house. In the US, for instance, the clearing house is the Federal Reserve. A merchant has to send a file with the list of transactions to be funded (withdrawals) to the clearing house; within one or two days it gets the requested funds from the clearing house. After that the clearing house sends transaction requests to respective banks to verify the availability of funds and complete these transactions. Usually, member banks will then have certain time period (up to sixty days in the US) to either confirm transaction or decline it. If a bank declines a transaction for whatever reason, then the return is sent to the merchant, who originated the transaction, and the funds are forcibly withdrawn from the merchant’s bank account (check our article on ACH returns for details).

Two-phase processing of bank account transfers

Two-phase processing is used in the UK (BACS), EU (SEPA), and Australia. Under this approach clearing houses are also used. However (in contrast to one-phase systems), in such systems as BACS and SEPA all bank accounts must be registered within the system before any financial transactions can be processed through them. A registration file with the list of accounts is sent by a merchant to the respective financial authority (body), which issues payment mandates to merchants. (At the stage of bank account registration invalid bank accounts can be identified). Within a certain period after the registration (generally, about two weeks after the mandates are obtained) the merchant can start processing actual transactions. After that the process, generally, follows the same patterns as during one-phase processing. The clearing house contacts member banks to clear the funds. However, most of two-phase systems, usually, provide most of the responses within three days and do not require the 60-day wait period (as the accounts are already registered in the system). However, some banks may delay payments, while some other banks may dispute them post factum.

The advantage of the first system is its simplicity, while the advantage of the second system (although more complex) is its reliability. I.e. in the second case merchants have better chances of getting their money from valid bank accounts of their customers, however, implementation of a two-phase system requires more efforts.

Conclusion

If you are a payment gateway provider, processing worldwide, and you want to process in the countries, using different banking systems, you need to pay attention at the architecture of the whole process. Your main objective in this context is to make your payment gateway capable of working with both one-phase and two-phase systems, while providing your customers with a unified integration API.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic.

EMV Parameters and EMV Keys Rotation

The purpose of this article is to explain why EMV parameters and EMV keys rotation are an essential component of EMV certification process.

The general assumption is EMV certification process includes just two basic stages: host certification and terminal certification. Respective information can be found in our respective articles here and here. However, there is another process which is also required to ensure normal functioning of EMV processing logic.

Somehow this third process is often neglected and many developers realize its importance at late stages of EMV functionality implementation. This can lead to considerable shifts of implementation deadlines. In this article we are trying to explain the essence of the process and help those who need to implement it when the time comes. The issue is particularly relevant for those who want to support more than one acquirer.

In order for EMV kernel logic embedded in payment terminal software to function properly, it needs a set of EMV application parameters and certificate authority (CA) keys. The CA keys are involved in the interaction between the EMV kernel of the terminal and the chip.

Quite often (for example, in Verifone and Ingenico terminals) the EMV kernel is going to use XML configuration file. The file includes the information on application IDs (AID), which are going to be supported by the terminal, respective parameters and keys for these AIDs.

EMV parameters are not changed very often (if changed at all). Most processors provide these parameters in pdf format. Usually, a pdf file is a contextual document, where they can be found. On their basis an XML file can be assembled.

Importance of EMV keys rotation: EMV certification perspective

In contrast to parameters, CA keys have to be changed (rotated) regularly. Most processors usually provide some sort of API (as a rule, it is a part of the main processing specification), including a subset of functions, dedicated to loading of the CA keys. Some processors will provide the initial set of keys through a document and require you to load updated keys using the API. Some processors will tell you initially to get all the keys by making a respective API call. Therefore, it is important to allocate time and resources for the implementation of this logic from the very beginning of your project planning, because there is no equivalent for this in card-not-present integrations or swipe integrations.

As we can see, in addition to host integration and terminal integration (with subsequent certifications), you also have to implement the rotation procedure for CA keys. Some of the processors will leave it up to you to implement this and will not require you to formally certify the process. Some of the processors (such as Chase Paymentech) will actually require you to demonstrate (during the certification process) that you can dynamically change the keys as transactions are getting processed.

Generally, the functionality around key rotations is appropriate for payment terminal management systems (TMS), and the function will be available in the TMS that you use. However, if you are not using any TMS, or TMS is unavailable for you, you can implement the respective logic as part of payment gateway functionality. The implementation process will depend on the number of different processors that you support and on the differences between application parameters (such as floor limit) across payment terminals. Implementation can be as simple as a file download from a server over FTP, where the file gets re-generated every time you get a different set of keys from the processor. It can be as complex as an API call where terminal identifies itself and then terminal-specific configuration file is assembled based on the most up-to-date information available from the processor that this terminal uses.

Conclusion

It is extremely important to allocate the time and resources for implementation of EMV keys rotation logic even for the most basic EMV certification. Even if you are not required to present the logic at certification stage, you are definitely going to confront the issue during production. While expiration period for a some of the keys can be up to 24 months, you will not necessarily have all that time before the initial key rotation has to be done.