We connect and interface to about 20 different endpoints, each has its own message formats, connection methodologies, protocols, and different implementations of payment transactions sets, encryption and key management considerations, On-Line vs Offline transactions, Store and Forward (SAF), and flat file based reconciliation and clearing files among other details.
Here is a basic list of steps that we perform that assist us in getting the endpoint integration right:
1) Acquire the Host Message Format specifications and communication/protocol specifications that describe the communication and connection e.g: 2||4 byte length header, other header(s), length in network or host byte order, etc. and read and understand them. Perform this same task for batch flat file based formats and file transfers.
2) Request sample dumps/files of some messages as well as for online transactions, network traces that show the communication bytes of the message, manually parse them and map them back to the spec. These should include samples of request/response exchanges. [These should be from a test system.] Examples often reveal nuances not documented or kept up to date in the spec.
3) Determine which message set and transactions are in play, There are many types of transactions that will be different depending on the type (e.g Debit, Credit, Gift) and characteristics of the transaction (e.g Manual, Swiped, MOTO). You need to determine which ones map to your business requirements and which ones will be used.
4) Request and/or develop certification scripts for your implementation (it helps to see what the other side thinks is important).
5) Schedule a walkthrough – This is the key event: the probability of our success is increased by scheduling and holding one or more walkthroughs. The idea is to comb through the spec(s) and complementary material page by page, field by field and get complete alignment on the task. It’s the absolute truth that the real nature of the interface comes out in the walkthrough.
6) Develop and test your code to the specs and sample messages dumps. (Which is a small part of the project)
7) Use tools such as netcat and wireshark as well as your application logs to confirm that you are sending what you think you are, and can provide detailed information to someone on the ‘other’ end of the endpoint to help troubleshoot integration. Don’t assume that you think you are sending what your think your code does, verify it locally first.
8) Develop a good or rather great working relationships with someone on the ‘other’ end of the endpoint, that can help assist with message format questions, perform traces, and check what you are sending to what they expect, and setup regular communication throughout the project.