PAX payment companion

LiftedConnect keeps the terminal inside the transaction.

LiftedConnect is the POS companion built for supported PAX A920 and A920Pro terminals. It runs alongside BroadPOS through PAX POSLink 2 semi-integration: LiftedPOS sends the sale, the terminal handles the card, and the result returns to the same transaction record.

The card stays where it belongs

The customer can tap, insert, or swipe on the PAX device. BroadPOS handles the card interaction and host processing. Cardholder data never touches LiftedPOS. The application receives safe result fields such as the masked account, card brand, authorization result, transaction references, and—when the merchant explicitly enables it and the processor supports it—a processor-issued token.

Tokenization is opt-in and fail-closed

Token requests apply to supported credit sales, not debit, and default off. That matters because a processor or MID without token support may reject a token request. When enabled, LiftedConnect asks the host for a token without sending raw card data into LiftedPOS. If the host returns one, the POS can retain that surrogate with the original terminal capture. The token is treated as sensitive payment metadata and is not used to decide whether a sale approved.

A foundation for cards on file and future refunds

Connecting the processor-issued token and original sale references creates the groundwork for cards on file and future refunds without asking staff to re-enter card details. Open-batch void workflows can resolve the original terminal transaction from its LiftedPOS reference. Settled return and future card-absent refund experiences can preserve that same thread. Availability depends on processor support, merchant configuration, and rollout stage; these future experiences are not represented as generally available today.

Money safety survives a network problem

LiftedConnect requires a real host response, transaction number, and authorization code before a credit sale can be treated as approved. A timeout is ambiguous, not a clean decline: LiftedPOS can inquire by the same transaction identity instead of blindly charging again. Results are queued for acknowledged delivery so a temporary connection loss does not turn into an orphaned result.

What to verify in a demo

Use the actual workflow, inspect the resulting record, and ask how the behavior is configured for your locations. Availability can depend on enabled modules, hardware, and payment setup.

Move from the feature to the operation

LiftedPOS is designed so this capability does not sit alone. It shares customer, employee, product, location, transaction, and reporting context with the rest of the system. That is the difference between checking a feature box and removing a handoff from the day.

See the whole operation move.

Open a real demo store, ring a sale, and follow what changes.

Run the live demo