Introduction
In Part 1 of this article, you learned how to build a simple Point of Sale (POS) app. Part 2 will explain how to add Semi-Integrated (SI) credit card payment functionality to it using the PAX SI SDK in C# with the .NET framework. This solution meets PCI requirements by securely sending transaction data from a physical payment device directly to the payment processor, EPX, without allowing any sensitive PCI data to enter your POS application or server environment.

Before getting started, review Part 1 of this article, as well as the North Developer Integration Guide.
How does the PAX SI SDK work?

- EPX’s EMV-certified and PCI-compliant application runs on the physical payment terminal.
- Your POS app initiates transaction requests to EPX’s application.
- The terminal displays a prompt for the customer to swipe, tap, or dip their card.
- The customer’s raw credit card information is securely read by EPX’s app.
- EPX’s app transmits the transaction request to EPX, where it is forwarded to the credit card network, then the customer’s bank.
- The request returns along the same route, but when it reaches the processor’s app running on the credit card terminal, it only forwards the non-sensitive data back to your POS application.
- This keeps the sensitive payment information outside of your app and the merchant’s environment, shifting most of the PCI responsibility away from your app and onto the payment provider. Learn more about how Semi-Integrated solutions work in this article.
There are two main payment components of the PAX Semi-Integrated solution:
- EPX’s BroadPOS application
- PAX’s POSLink API
EPX BroadPOS Application
PAX POSLink API
Transaction Data Flow
This tutorial will implement the following payment solution.
- A POS app written in .NET runs on a local computer, which acts as the server.
- A PAX terminal is connected to the same network as the computer.
- The merchant initiates a transaction request from the POS app, which sends a request using PAX’s POSLink API to the EPX BroadPOS app running on the PAX terminal. To learn more about each type of transaction request and their use cases, see the “SDK payment method definitions and examples” section of the North Developer Integration Guide.
- The EPX BroadPOS app uses the PAX terminal to collect the customer’s payment data.
- The EPX BroadPOS app builds and transmits the request to the EPX processor.
- EPX returns the full transaction response data to EPX BroadPOS.
- The EPX BroadPOS app forwards the non-sensitive response data to the POS app, again using PAX’s POSLink API.
Get in Touch
Talk to us about using the PAX SDK to accept in-person payments with your Point of Sale application.
Adding Payment Functionality to a POS
Starting with the POS application that was created in Part 1 of this tutorial, the payment methods will be called from both the Order Summaries and Order Details pages, and will be defined in a static class named CommonPayment.cs. Functionality to close transaction batches will be added to the Order Summaries page, and functionality to process individual payments will be added to the Order Details page.
Add a new class file named CommonPayment.cs to the project. For instructions on how to add a class file, see the “Creating the Class Files” section of Part 1 of this tutorial. CommonPayment.cs will be used to define a static class with all of the payment methods necessary to process payments from your POS.
Defining the Communication Settings
Add the following Using statements to the beginning of CommonPayment.cs and set the class type a to public static class.
Within the class definition, add the following flag that will be used to indicate when payment methods are running, and prevent user action during that time, as it may disrupt payment processing.
Next, add a method named commSettings that defines the settings used for communication between the POS and the payment terminal, and returns a CommSetting object. The specifications for PAX’s CommSetting class are documented in PAX’s POSLink API Guide.
For more information about these settings, see the “Connecting the terminal to an external POS” section of the North Developer PAX SI SDK Integration Guide.
Defining the Transaction Processing Method
Next, define a method named transaction that will process the payment transactions. The specifications for PAX’s PaymentRequest and PaymentResponse classes used in this method are documented in PAX’s POSLink API Guide.
The transaction method will be called when any of the payment buttons on the OrderDetails page are clicked. Depending on which button is clicked, specific arguments will be passed to the transaction method to perform the desired payment functionality. The transaction method accepts the following parameters:
-
transType: This is an integer that tells the processor which type of transaction to perform, such as Authorization, Refund, etc. The transaction types and their corresponding integer values are listed in the PaymentRequest class definition of PAX’s POSLink API Guide.
For more information about what each transaction type does and when to use them, see the “SDK payment method definitions and examples” section of the North Developer Integration Guide. -
labelMessage: This is a user-defined message that will be displayed on the UI after the payment process is complete, such as “Transaction authorized.” The purpose of this message is simply to let the user know the outcome of the transaction. If there is an error with the payment, the error message that was returned from the processor will be displayed instead of the labelMessage argument.
-
authId: This parameter is optional under some conditions.
- The transaction method requires the authId to perform subsequent actions on an existing authorization. An authorization is always the first payment function that’s performed, then subsequent actions may be performed on it by referencing its authId. The authId value is incremented by 1 with each new authorization.
- For requests of the authorization type, authId is not accepted because a new auth is being requested and therefore no existing auth is referenced.
- amount: This parameter is optional under some conditions.
- The transaction method requires the amount for all transaction types except voids. All transaction requests except voids must specify the dollar amount that the transaction request will act on.
- Voids can only be performed on the full amount that was originally authorized, so void requests do not accept an amount.
- newStatus: This is a user-defined status that’s displayed for each record on the OrderSummaries page to indicate the last payment functionality that has been performed, such as “Voided”.
For more information about the values that can be returned in the ResultCode property, see the Transaction Response Codes page.
Defining the Batch Close Method
Below the transaction method, add a method named batch that will be used to submit batches of captured transactions to the payment processor. The Batch method will be called when the “Close Batch” button on the OrderSummaries page is clicked. The specifications for PAX’s BatchRequest and BatchResponse classes are documented in PAX’s POSLink API Guide.
Calling the Payment Methods via the POS UI
In Form2.cs, for each of the payment button-click method definitions that were auto-generated in the “Setting Up the UI” section of Part 1 of this tutorial, add the corresponding code below. See the “SDK payment method definitions and examples” section of the North Developer PAX SI SDK Integration Guide for more details about each method and their use cases.
Calling the Batch Close Method
In Form1.cs, add the following code to the Batch Close button-click method:
Finally, add the following method to update the order statuses after the batch has been submitted.
Demonstrating the POS app
Follow the steps in the “Using the terminal” section of the North Developer PAX SI SDK Integration Guide to connect the POS to the terminal.
Click the Start button in Visual Studio Community to run the application. On the OrderSummaries page, click the Start New Order button.


Click the Sale button, and the payment terminal should prompt you to enter card data. Key in the following test card data to complete the test transaction:
Card #: 4111111111111111
Exp: 04/25
Zip: 11111
CVV: 123
The terminal should display an approval message, and the labelText field on the UI should display a status message.

Perform the same steps for each of the payment functions, paying attention to the requirements for some transaction types that are explained in the “SDK payment method definitions and examples” section of the North Developer PAX SI SDK Integration Guide. For example, if a transaction has been authorized and captured, it can be refunded, but it cannot be voided. Voids can only be performed on transactions that haven’t been captured yet. Conversely, if a transaction has not been captured, it can be voided but it cannot be refunded.
Conclusion
In Part 2 of this tutorial, you learned how to add credit card payments to the C#/.NET POS app that was built in Part 1 using the PAX Semi-Integrated SDK.
How To Get Started
North’s Sales Engineering team provides support to developers and business decision-makers to help select the best possible payment system. Contact us to learn more about how to connect your system to the North ecosystem.