Developers often ask me the following question:
Should I use a third-party API to build a semi-integrated solution for PAX or integrate directly?
Let’s review each option and its pros and cons.
1- Direct Integration:
PAX integration SDK is called POSLink. You can use POSLink to integrate your Windows and Android software. There is also a low-level direct integration into PAX, which you can use to build integrated software for iOS.
POSLink provides you with functions and methods to call supported transaction types, such as Credit Sale, Credit Auth, Credit Void, Debit Sale, perform management transactions, and much more.
Depends on how complicated you want to integrate, for an experienced developer, it takes anywhere from a day to a week to build a semi-integrated payment solution. You deploy POSLink with each copy of your software.
Pros and Cons of PAX direct integration
Pros:
• You don’t need any middleware or third-party software or API.
• There will be no additional costs to your merchants. They need to buy PAX terminals, and that’s it!
• Integration is going to be processor-agnostic, meaning you can take your solution to any processor, as long PAX is certified with that processor.
• You have better control over the integration and requirements, within the framework of POSLink.
Cons:
• You are responsible for managing the BroadPOS account, which is not always easy or straightforward. You are required to have a more in-depth knowledge of payment processing in general and work with multitudes of various processors and VAR sheets.
• You solely rely on stored transactions in the PAX device that is not entirely bad, but you must have backup plans for disaster recovery reconciliations.
• You will be responsible for supporting the device and transactions in addition to your point of sale software.
• Some processors require separate certification for PAX integrations. For instance, Heartland Payments wants you to go through a certification process, which examines your integration by asking you to perform certain transactions and provide results and receipt printouts.
• Keep up with updates of POSLink and update your software accordingly.
Others could add to both lists above.
2- PAX Third-Party Integration
There is a growing number of payment companies that offer integration to PAX. In third-party integration, you will receive an API or SDK, and you must follow their specific documentation and processes.
Pros and Cons of PAX third-party integration
Pros:
• The integration time could be shorter, therefore going to market faster.
• You have support from the integration provider, and you can designate more of your time and resources to improve your core product.
• The providers usually offer support to your merchants.
• You will have OS independence solutions.
• All updates and upgrades will happen outside of your code.
Cons:
• The breadth of the API restricts the depth of your integration.
• Possible lack of required functions because of using a general API.
• Your code is relying solely on the availability of the API and its uptime.
There are always strings attached to third-party integration. It could be a monthly fee per device, or a fee per transaction, or exclusivity requirements that dictate which processors you can use. In some cases, you get the service for free in exchange for processor exclusivity, and you may even receive a percentage of the revenue generated from each one of your accounts.
I have personally built systems with PAX direct integration and by using third-party service providers.
In the long run, a good and reasonable partnership with the right kind of the third party would be much better than going through the process solo.
What to seek in an integration partnership
1- Depth and breadth of the API. Preferably, with an Omni solution.
2- Card-present and card-not-present solutions.
3- Device variety of support. PAX is by far the best device for semi-integrated solutions.
4- Fees and restrictions. I recommend staying away from the exclusivity clause.
5- Customer service quality
6- Different flavors of the semi-integrated solution. Meaning, availability of API, DLL, or middleware versions of the solution.
7- Compatibility with your software as it stands today and for future updates.
8- Hardware and software requirements. Stay away from the integration that mandates specific hardware or software or service. Each additional piece of hard or software adds another point of failure to your system.
For more information see the following articles:
Kourosh
