Start with the system boundary
In a semi-integrated flow, the POS sends transaction intent—such as an amount and transaction identity—to a supported payment device. The customer taps, inserts, or swipes on that device. The payment application and processor host handle the card interaction and authorization. The POS receives the outcome and the references it needs to keep the payment connected to the sale. That separation reduces the number of systems that should ever handle cardholder data; it does not remove the merchant's responsibility to configure, secure, and operate the complete payment environment correctly.
Know what should come back to the POS
A useful result is more than “approved” or “declined.” The record can include a masked account, card brand, authorization result, authorization code, terminal or host transaction identifiers, and references that connect the response to the original request. LiftedConnect requires a real host response, transaction number, and authorization code before a credit sale can be treated as approved. Raw card numbers and sensitive authentication data do not belong in the LiftedPOS transaction record.
Tokenization is a processor capability, not a slogan
A processor-issued token is a surrogate value returned by the payment host. It can create a safer reference to the captured payment method without copying raw card data into the POS. Token requests in LiftedConnect are opt-in, apply to supported credit sales rather than debit, and depend on the merchant, MID, processor, and host configuration. A token is payment metadata—not proof that the sale approved—and it must be stored and used with appropriate access controls.
Separate voids, returns, and future card-on-file use
An open-batch void can often identify the original terminal transaction from its LiftedPOS reference. A settled return or card-absent refund may require different processor support and original-sale references. Retaining an allowed processor token and the original transaction thread creates the groundwork for future refunds and cards on file without asking staff to re-enter card details. Those experiences are readiness work, not a promise that every processor or merchant configuration supports them today.
Treat a timeout as ambiguous
A network timeout does not prove that the host declined or never received the transaction. Blindly retrying can create a second charge. A safer design reuses the same transaction identity to inquire about the unknown result, then reconciles the terminal and POS records before another sale attempt. LiftedConnect queues results for acknowledged delivery so a temporary connection loss is less likely to leave an approved payment detached from the sale that created it.
Use this evaluation checklist
Ask a POS and payments vendor where the card is read, which application talks to the processor, what fields return, what exact evidence marks approval, how tokens are requested and protected, how debit differs from credit, what happens on timeout, how a duplicate is prevented, how the original transaction is found for a void, and which refund paths are actually enabled for your processor and MID. Run approved, declined, timeout, void, and refund scenarios in the deployment configuration—not only in a generic demonstration.
LiftedConnect supports PAX A920 and A920 Pro devices through BroadPOS and PAX POSLink 2 semi-integration. Processor tokenization and downstream uses remain merchant- and processor-dependent.
Follow the implementation, not just the diagram
Review the LiftedConnect product page, include payment recovery in the migration checklist, and confirm software and hardware costs on the pricing page. A clean architecture matters only when the deployed terminal, processor settings, staff procedure, and support path preserve it.