The purpose of this article is to list the key phases in the payment system integration process that should be followed in order to optimize the effort, reduce integration time, and minimize the investment into the integration process.
At a certain point developers of software products in need of credit card processing services must go through payment system integration process.
Any payment system integration is a challenging task, especially, integration with legacy platforms. Therefore, when it comes to integration, it is wise to make careful preparations and monitor the process closely to ensure its successful and timely completion. The current article is based on extensive experience of integration implementations executed by our team.
Experience suggests that there are certain steps that have to be executed in a specific order to ensure the highest efficiency of the efforts associated with the integration process. The steps are listed below in the chronological order.
Get specifications from the processor
The very first step on the way to integration would be to get the necessary specifications from the processor. Certain important conceptual issues may need to be clarified at this initial stage.
Terminal capture or host capture?
It is desirable to determine at the initial stage if the processor supports terminal capture or host capture (some information on host and terminal capture can be found here). Under terminal capture the, company (integrator) has to implement both authorization and settlement (and settlement requires separate logic and therefore increases the overall scope of work versus host capture). It is also important to determine the mechanism used within terminal capture to settle transactions, and if file and FTP server are involved, it is critical to request connectivity not only for authorization (which is, generally, done in real time), but also for settlement (which would be done through an FTP server).
Conceptual issues around merchant ID and terminal ID setup
Because of the business-specific differences related to credit card processing (e-commerce versus restaurant) the logic of payment system integration (with credit card processor) is divided by industry type. The most common industries are retail, direct marketing (MOTO), e-commerce and restaurant (some information on industry types can be found here). Each industry might have its unique features. It is important to process each submitted transaction with a proper industry indicator, because certain features, such as tip adjustment, might not be available on transactions processed under e-commerce industry type and will only be available under restaurant industry type.
There are two ways in which industry type can be specified within a transaction. Some systems will use a different merchant ID, or a different terminal ID under a merchant ID, that will be configured to specifically handle a certain kind of industry. Some other systems might use the same merchant ID across all industry types, but have the industry type indicator field within the transaction’s request.
Therefore, when planning a payment system integration, the business needs to evaluate the conceptual approach that it uses in its own system (e.g., single MID across several industries) and the conceptual approach used by the system (e.g. separate MID for every industry) and plan for any potential incompatibilities in advance.
Allocate resources and set integration timeline
The next step is to formally allocate the resources that would work on the project, schedule the major tasks and milestones, set initial timeline and expectations\priorities (as integration processes can take from one week to one year depending on the complexity of the underlying system).
Get certification specialist assigned
As specifications may be complicated and questions may arise in the process of the integration, it is important to have someone to address the questions to. Consequently, the next step is to verify that the project is open at the processor’s end and that the responsible specialist is assigned. Larger processors may have really long integration queues and it may take up to two to three months to get an integration specialist assigned to a project on the processor’s end. If certain integration-related questions remain unanswered, some aspects of development process may also have to wait, so the specialist assignment must be taken care of and planned for in advance.
The next several steps (getting test credentials, getting test cards, getting certification scenarios, connectivity testing, and development of a basic prototype, preceding the development of the actual application) can be performed more or less simultaneously.
The term “prototype” used below implies a basic independent fragment of code (mini-application) with just the core functionality, developed as “bare bone” implementation, and targeted mostly at testing of basic scenarios; the main application is, generally, much more complex. Sometimes at the prototype stage architectural mismatches in approaches can be discovered and appropriate scheduling and implementation changes can be anticipated in advance.
Get test credentials
Generally, the ability to test any code that is written is very important. Testing and connectivity credentials are required in order to connect with the processor and to be able to send test transactions.
Without the test credentials it is impossible to test the logic as it is written, so it is extremely important to have test credentials as early as possible, and test the code consistently, as development occurs (and not wait with testing until the entire implementation is done).
Get test cards
Some systems might require physical test cards in order to complete the testing during payment system integration process. Since these are physical cards, that have to be delivered by mail, and the process usually takes time, it is better to order them in advance. For those cases when PIN-debit and EBT functionality are involved, there may be a need for a physical terminal or a PIN-pad with a respective test key injected (to generate appropriate PIN-block). In such cases it is also better to provision a PIN-pad with appropriate key in advance.
Get certification scenarios
Usually, in order to officially complete certification process and receive certification letter from a processor, an integrator has to implement a certain number of test scenarios, execute them and have certification specialist review the data submitted.
Despite the fact that the actual certification process is done at the end of implementation, it is recommended to use the test scenarios to test the code as it is getting implemented, because, according to experience, there are many situations when the information explained in the specification would not match to the actual way in which the system works. In such cases the only way to catch these types of cases is by executing the test scenarios supplied by the processor.
Test scenarios must be obtained from the processor in advance, because when the actual application is implemented, it is better to use these scenarios, and not just experiment with random cases.
Some people prefer to start the implementation right after specifications are available and only utilize test cases in the very end. The testing can be performed on model cases of the integrator’s choice when the whole logic is developed. While it seems that this way is going to be quicker, it might actually end up taking more time. For instance, when the testing happens using the actual scenarios, it might turn out that some initial assumptions were invalid, and, as a result, additional changes have to be introduced into the code already written.
Test connectivity
Once test credentials are obtained (and, sometimes, once the very basic prototype is developed), the first step to take is connectivity testing. To verify FTP connectivity, a standard FTP client can be used. HTTP or socket connectivity can be tested using other tools, such as Telnet or ping. You can test connectivity using either some third-party tool (such as FTP client) or your own prototype (an extremely basic one) as explained below.
Start formal development process
After connectivity and test credentials are confirmed, the formal development can begin. Every large system has its own architectural design that must be respected, so it might take time before communication with the other end is established. Because of that our recommendation is to start communication using a simple prototype, which is separate from the main system,
Make the basic prototype
We recommend starting with development of a small prototype to test connectivity and basic transactions such as sales. Once a sale ‘approval’ is obtained from the processor, it can be concluded that the specifications are clearly understood, test credentials are working, test account is configured correctly, connectivity, interchange protocol and message format are properly implemented. This eliminates potential issues around specifics of the messaging protocol or some encoding requirements that become less detectable when testing happens within the context of a larger system.
Once the basic prototype works, you can go through formal development process to build out your solution, taking into account all architectural needs of your system.
The other approach (as opposed to the prototype-based one explained above) would be to go through all the formal development (sometimes it takes up to 3 to 4 weeks) and then start the testing process. However, with such approach at the time of testing it might become evident that certain assumptions were made incorrectly and much of the code has to be rewritten.
Certify the scenarios
After all the coding is done, the next step is to certify the aforementioned test scenarios in all supported industries, and get approvals on all of the test scenarios. When certification is completed, the integrator receives a certification letter from the certification agent of the processor responsible for the given integration.
Test scenarios can be executed in one of two ways: they can either be manually processed using virtual terminal (through which test transactions are submitted), or an emulator can be built, that will run the entire test script, one transaction at a time, at the software level, without human being involved.
The first option is time-consuming. That is why we recommend not to rely on manual testing, but rather implement all of the test cases as executable code, sometimes referred to as emulator (automatically generating all the test transactions), so that all of the test scenarios could be executed and re-executed multiple times on demand within short time frame (and in different order).
Certification process is often done offline, when test scenario’s execution log and execution time are sent to be analyzed by the certification agent (responsible specialist) of the processor; sometimes calls with the certification agent must be scheduled when he or she needs to record\capture certain data when transactions are submitted. When such calls are needed, it is better to schedule them in advance so that the logic could be corrected step by step. Beside that, it should be kept in mind that a certification agent might also have a busy schedule of his\her own, as he\she is usually working on several integration projects simultaneously.
Define the processor’s settings
Once the integration is complete, the integrator needs to think how new merchants will be boarded to process through the certification, and, therefore, potentially, develop a user interface or some form of API to configure the accounts. In order to do that, you need to identify all the parameters, assigned by the processor to each merchant for identification purposes (usually MID and TID). Once this information is identified, you can implement the on-boarding logic.
The task of providing the list of fields in the processor’s profile structure is usually reassigned to a responsible developer who will perform the actual coding.
Prepare the necessary documentation
The next and final series of steps basically envisions preparation of all the necessary documentation. It is important to document the entire integration process before putting the project to sleep. Our recommendation is to save all testing information, such as test scenarios, test URLs, test accounts, test card numbers, for the cases when re-certification might be needed or some new problems emerge in production and changes need to be introduced into the existing logic.
Our final general recommendation is to have a special project manager with a list of recommended tasks assigned to the integration project. This manager should closely monitor the overall progress of integration process on the regular basis in order to ensure its fastest completion.
Before you go into production, make sure that you have identified the proper way to get production support or to escalate your request, be it e-mail or a phone number to call in cases of emergency.
Good luck with your payment system integrations!
Visit the UniPayGateway website if you are interested in the diagram illustrating this topic.
Recommended to you
