How to Integrate Payment Processing with Your POS System

How to Integrate Payment Processing with Your POS System

11 min read
New Product Modernization Retail POS Supply Chain Hospitality

Share

Integrating payment processing with a POS system may seem like a relatively easy task, but even here some pitfalls can hinder the success of your product. Knowing the challenges and best practices, you can mitigate risks and implement powerful payment processing capabilities in your POS product.

The best way to understand how POS payment processing integration works, is to use a real-world example as a reference. In 2013, MobiDev started collaboration with Comcash, a US-based ERP SaaS specializing in retail solutions, transforming it from a locally-based POS solution to a complex cloud-based retail ERP/POS system with advanced AI capabilities. This long-term collaboration culminated in ComCash’s acquisition by POS Nation in 2022, after successfully developing a robust ecosystem of tools.

We have summarized our practical experience and insights to give you a better idea of how a product like this can be executed. We’ll cover steps to plan the project, select payment processors, implement features, test, deliver, and support payment processing functionality for your POS system.

Benefits of Embedding Payments into a POS System

Embedded payments are one of the important POS technology trends. When customers can pay with their preferred payment methods directly through your POS system, they get a more convenient experience and reap the benefits of increased security.

By consolidating POS operations like this, you can collect and analyze transaction data in real time. This enables getting insights into customer behavior, such as purchasing patterns, payment preferences, and peak buying times, which you can use later for targeted marketing and sales forecasting.

Integrated Payment Processing vs Third-Party Payment Processing

The alternative to embedded POS payment processing is external payments. Customers would need to use their phone or a separate browser tab to send money to a destination.

For example, Alipay customers at some retail locations need to scan a barcode located on the physical register. They then have to make the payment in the Alipay app. In some cases, this might generate a temporary gift card that you can scan at the register with your phone.

This experience isn’t ideal for customers and can result in mistakes, like sending money to the wrong place. Embedded payments provide a higher quality and much more secure experience for customers.

Point of Sale Payment Processing Integration Step-by-Step

Let’s dive in and walk through the process of integrating Point of Sale (POS) payment processing step by step.

Step 1: Business Analysis and Planning

Before you begin your project, you first need to define your requirements. What do you need to achieve? Don’t reach too high or too low. Target the payment processing Integrations you know your customers are going to use. You’ll also need to consider some basic things that your project can’t do without, like regulatory compliance, like Payment Card Industry Data Security Standard (PCI DSS), security, and performance.

Taking into account the requirements of the customer, we narrow down the list of transaction types the POS should process, for example:

  • Credit and debit cards, prepaid gift cards, or EBT cards
  • Sale (sale or authorized) or refund
  • Partial payments
  • With cashback or gratuity, etc.

This is also the best time to consider the technical feasibility of your product. Can your existing POS system support the payment processing methods you want to integrate, or will you need app modernization first?

Another important part of the business analysis stage is risk assessment. What are the obstacles that you might encounter along the way? How likely is it that things may go wrong? Will there be any system downtimes? What are the risks of data breaches and the potential cost of stolen customer data? Understanding these risks will better help you make plans to develop mitigation strategies.

Step 2: Selecting Payment Processors

When looking for payment gateway integration services, you should look for processors that are already compatible with your POS system. Carefully review fees, such as transactional, monthly/yearly, and any other costs. Make sure that your chosen processor supports the features and payment types you need.

Verifying Compatibility

The next step for developers is to dive deep into the API documentation to learn more about the transactions and the request-response format, what parameters need to be included in the requests, and what data is expected to be received from the payment processor.

As a result, the integration covers two vital points:

  1. POS forms and sends valid data to the payment terminal with all the necessary parameters for each type of transaction
  2. POS expectedly reacts to the responses returned by the payment terminal

Consequently, the communication between the payment terminal and the payment processor, as well as with the bank, is out of reach because it’s encrypted and highly secure.

Step 3: Implementing Payment Processing Services Integration

The next step is to get everything working. With the payment processor API, you can implement the integration with your POS system. This is executed in two parts:

  1. Payment methods: enabling credit and debit cards, and mobile payments.
  2. Security measures: SSL encryption, and compliance with regulatory standards like PCI DSS.

Step 4: Testing POS Payment Integrations

Testing can be a lengthy part of the process, but it is essential for ensuring the quality of your product. To get started evaluating your payment processing integrations, you’ll need to do some initial setup. This will require a testing terminal, testing cards, and other elements of the development environment.

There are five important stages of testing:

  1. Functional Testing: ensuring that features work as expected.
  2. Integration Testing: ensuring the whole transaction workflow works correctly, including the POS, pin pad, and admin panel.
  3. Performance Testing: making sure all components work as quickly as needed.
  4. Security Testing: confirming that cardholder data is kept sufficiently confidential and that the POS system can’t be tampered with.
  5. User Acceptance Testing: determining if users in the real world can use the system in real situations.

1. Functional Testing

This stage of the testing process handles the basic features of the payment services integrations. It will test to make sure that all expected combinations of user data are handled correctly. We attempt to imitate the user’s behavior at this stage, investigate the types of responses that we receive from the PIN pad and explore what could go wrong.

It was at this stage that our development team managed to prevent a situation where a gift card was charged twice. In a system we were working on, the UI indicated that a gift card was voided properly. However, what was actually going on during testing was that the void request was instead being processed as a sale. As a result, the gift card was being charged twice. Because of functional testing, we were able to prevent this bug from reaching production.

2. Integration Testing

At this stage, QA engineers will ensure that every part of the integration system, like the POS, PIN pad and admin panel, communicates as expected. For instance, it’s necessary to ensure that the POS reacts as required to the responses from the payment processor. As an example, let’s say it shows a pop-up about successful payment and prints a receipt or shows an error and initializes voiding the sale, and corresponding records are created on the Admin panel.

Integration testing is easy to realize if you have a properly set-up environment. But how can you test a payment integration without a payment terminal?

One of the payment providers we dealt with operates exclusively in Canada. So, they would block requests from any other country, leaving us unable to test with the pin pad. With the client, we agreed, in this case, to resort to User Acceptance Testing (more on this below), involving the end user located in Canada. Before they went live, we prepared a set of test scenarios with clear steps and expected results to smooth the process and asked them to provide the logs afterward.

Thus, we were able to have our integration tested and received constructive feedback directly from the consumer, which helped to make the system more efficient.

3. Performance Testing

Without performance testing, you risk sending slow or corrupted experiences to production users. This is especially essential for large businesses that need to operate at scale. When you’re running a retail empire, you don’t want to worry about sales randomly being voided, wrong products being selected, stock audit records going missing, or the experience slowing down to a crawl.

Our team has developed performance test plans to check for deadlocks, timeouts, and other unexpected behavior. This allows us to catch scalability problems and ensure that the system performs as expected.

4. Security Testing

This is one of the most critical testing stages, not just for industry compliance, but for ensuring the trust of your customers. It can help uncover potential weaknesses that attackers could exploit, reduce the risk of financial losses, and safeguard company reputation and customer trust.

In addition, one of the types of security testing is verifying compliance with industry standards and regulatory requirements. For example, as testers of a business processing payment card transactions, we went through certification to comply with PCI DSS. This way, we helped mitigate the legal and financial risks associated with non-compliance.

It is important to note that since software development is dynamically developing and changing every day, and what was safe yesterday may already have critical vulnerabilities today, it is necessary to constantly monitor potential threats and identify weaknesses.

5. User Acceptance Testing

This stage of the testing phase assesses the performance and effectiveness of the system with real customers and real payment terminals and cards. This can also help reveal any bugs that may have gone unnoticed in regular testing. The feedback from test users aids in software improvements that can benefit the experience for everyone.

The UAT process can be challenging. In a previous project we worked on, our client already had a few payment system integrations running. In order to perform UAT testing on the new integrations we developed, we needed to risk running the new integrations on-site. However, this presented a number of risks to the production POS systems of the store. If anything went wrong, nobody would be able to pay for anything!

In the end, we developed a solution with the client by having the client’s support team acquire production pin pads and cards to ensure that everything worked as expected without endangering the POS environment of the store.

read more

how to keep the testing process in line with you business objectives

software testing strategy

Step 5: Certification

Payment card networks need to certify systems before they can be used with real customers. To facilitate this, providers share a list of test cases that your system must be able to fulfill. Once these have been completed, your system will meet all requirements for certification.

For instance, one of the payment systems we integrated was Datacap. They build hardware and processor-agnostic payment solutions for POS systems. They provide integrating options for physical shops, as well as online and mobile applications. At that time, our goal was to get certified for Point of Sale payment integration.

Once our project was completed, we requested a customized certification test script corresponding to the solutions we used in our application.

Such a document usually includes:

  • test credentials necessary for accessing the certification environment with predefined test cases specific to our project, e.g. Merchant ID to isolate our requests among others
  • a description of the test cards used in the test cases with additional credentials if necessary, e.g. Credit Card, Debit Card, EBT card, Prepaid Gift Card, etc.
  • test cases that might look like this
# # Transaction Card/AID Entry Expected Response
1 1.0 Sale 1/Credit Contactless Declined
2 1.2 Return 2/Debit Chip Error
3 1.3 VoidSale EBT Swipe Approved

While running the certification script, it’s a must to keep a log file for the POS that includes payment requests and responses to send for review by the payment provider’s integration team.
It’s rare to pass certification on the first attempt. Feedback from the provider is the last step to making sure your system works as expected and is compliant. In our case, we succeeded on the second attempt.

Once you’re fully certified, you can begin accepting transactions with real cards and PIN pads.

Step 6: Delivery and Maintenance

With certification out of the way, it’s time to deploy the latest version of the POS to the wild. We then can provide maintenance and support to deployed products if clients agree to it.

One of the most important aspects of deployment is end-user feedback. If shoppers are having bad experiences with terminals, understanding those experiences can help us fix bugs and make feature enhancements.

READ MORE ABOUT DEVELOPING POS SYSTEMS

From Idea to Implementation

POS Software Development Guide

Overcoming Integration Challenges

It’s crucial to understand that you can’t predict everything. For example, in our case, one peculiar challenge we faced was a payment processing integration project that passed every test before deployment. However, the customer found that there were some problems with the resulting experience. They reported that there were missing notifications on the screen about the payment process, but the transaction seemingly went through.

Nothing obvious or unusual appeared in the logs that the client provided. Everything appeared to be working as expected. It wasn’t until we set up a testing environment using exactly the same equipment that we discovered the cause: a library conflict between the payment system and the scanner brand which only occurred in this exact hardware configuration.

This is why it’s so important to work with expert software engineers and consultants who can solve unexpected issues and leverage the best practices to ensure sustainable success.

This also highlights the importance of maintaining and supporting systems after launch. Once we discovered the cause of the bug, we rolled out a patch to fix it quickly and easily.

Build Your Innovative POS Product with MobiDev

Every payment provider is unique, so you need a development team prepared to adapt to each case and successfully integrate the payment processing methods you need. You don’t have to navigate that challenge alone.

Since 2013, MobiDev has been trusted by big POS providers like Comcash (acquired by POS Nation) and SmartTab for retail software development services. We’ve also provided consulting and engineering services for retail businesses and helped them achieve their unique business needs.

If you’re ready to build an innovative POS system or need any help with improving your existing product, contact us today and we can help you reduce your time to market without breaking the bank.

Contents
Open Contents
Contents

NEED HELP WITH YOUR POS SYSTEM?

Book a call with a MobiDev representative or send us a message

+1 916 243 0946 (USA/Canada)

Contact us

YOU CAN ALSO READ

Bringing Your POS Software to the Next Level with AI

TOP 5 AI Use Cases to Bring Your POS Software to the Ne…

How To Apply Machine Learning To Demand Forecasting

How To Implement AI Demand Forecasting in Retail

POS Technology Trends and Innovations

POS Technology Trends: Innovations Reshaping Point-of-S…

We will answer you within one business day