Integrated Credit/Debit Testing in Dynamics NAV

Problem

Having integrated credit and debit processing is great in stores. It saves time for the clerk and prevents keying errors from being entered into the machines. The only issue is when you want to test your POS system. You don’t want to charge your own card, nor do you really care how the terminal processes your request. you just need a response back. In this tutorial we are going to make a simple C# console app to emulate a Credit/Debit machine. First a little bit on how these machines work. On your POS system you connect to a credit terminal via TCP/IP. When you want to process a card you usually send along a small message containing the amount, card type, etc. Once the customer has got their pin approved, the terminal will send back a message to the POS to confirm that the transaction took place. The POS system will go through with the sale. So we just need to catch that message sent by the POS, and then send one back to simulate the customer action.

Integrated Credit Debit

Getting Connected

We are going to use Sockets! The console application will listen on a specific port waiting for the POS to send the request. Once we have a connection, we read the full message, and then determine what we want to send back.

This class sets up the listening socket on the specified IP address and port. It assumes that the connection will be closed after sending back one message. Once a call to  GetRequest() is made the application will lock up waiting for a connection. You could add in threading here if you didn’t want things to lock up. After we get the request and formulate our response, we make a call to  SendResponse(byte[] data)  to send our info back to the POS.

The Application

This simple application waits for the request from the POS and sends back the appropriate response.  The messages that are passed back and forth always have a transaction number at the start of the string. This transaction number is what determines what is sent back. In this example a transaction number of 46 is a soft reset. Meaning that the machine is set up for a new transaction, we just need to send back a 46 to let the POS know the machine is still connected. A transaction number of 10 means a purchase. We first format our response in a list of strings. We then take that list of strings and encode them in ASCII. Between each string we add a field separator, in this case it’s the pipe character. Once the  byte array is fully created, we send it back to the POS using the class we made earlier.

Run It!

Run this application on the same network that has your POS machines. You will need to setup your POS machines to point to the test application’s IP address and not the terminals. So now, when you run a credit or debit transaction, this console app will act as the terminal and automatically send back an appropriate response. This way you don’t need any hardware at all to test your integrated debit and credit setup.

Adding More

Adding more

You could easily expand on this console by adding some user input, this way you can change the response each time. You will probably want to add more than just two types of transactions as well. You could go as far as creating a Windows Form application to easily edit and send back different responses and make it user friendly for your quality insurance testers.

 

Leave a Comment