LiftedConnect payments
Connect PAX payment context to the LiftedPOS sale.
Use the verified on-device LiftedConnect engine as the foundation, then prove the production backend handoff, safe result, recovery context, and permitted processor token against the merchant environment.
A connected payment experience
Give customers a smoother card-present checkout.
On supported PAX hardware, LiftedConnect's verified on-device engine accepts a payment request and builds a card-safe host result. Connecting that result to a LiftedPOS sale still depends on the production backend handoff and merchant acceptance path. During scoped setup, we help qualify the terminal, processor, MID, recovery path, and supported token use cases for your merchant environment.
Keep card entry on PAX
The customer taps, inserts, or swipes on the configured payment device instead of placing raw card data in the POS.
Prove the result handoff
Merchant acceptance must confirm that the safe approval, decline, reference, and recovery context reaches the intended LiftedPOS sale before launch.
Prepare future use
Qualified processor token metadata can support future refunds and card-on-file workflows when the merchant setup enables them.
Use the seeded product to explore the operating path, then bring us the locations, roles, devices, records, and exceptions that matter to your business.
The architecture rule
The POS requests the payment. The host decides the outcome.
LiftedConnect's on-device PAX engine is implemented and exercised with BroadPOS/POSLink 2. The production backend endpoint, LiftedPOS ledger handoff, acknowledgement, inquiry, and merchant acceptance path remain qualification gates. This guide distinguishes the verified companion behavior from the complete workflow still being integrated.
Semi-integrated boundary
Four systems, one connected transaction thread.
The boundary reduces where raw card data should travel. It does not remove the merchant's responsibility to configure, secure, and operate the complete payment environment.
- 01LiftedPOS target
The production handoff must send amount, transaction identity, tender intent, and qualified options.
- 02LiftedConnect
The companion engine is designed to translate that request, preserve correlation, and return an allowlisted result.
- 03PAX + BroadPOS
The verified device path handles tap, insert, or swipe and communicates through the configured host.
- 04Production proof
Backend, ledger, acknowledgement, inquiry, and merchant acceptance must connect the host outcome to the correct sale.
Verified on-device result contract
“Approved” requires host evidence—not a local green screen.
LiftedConnect's on-device engine requires a real host response, transaction number, and authorization code before a credit sale is approved. Its allowlisted result can include masked account, card brand, authorization outcome, authorization code, terminal or host identifiers, and permitted references. Raw card numbers and sensitive authentication data are excluded. Persisting that result in LiftedPOS still depends on the production backend handoff.
Future-safe reference
Tokenization is a processor capability, not a slogan.
A processor-issued token is a surrogate returned by the payment host. LiftedConnect token requests are opt-in for supported credit sales rather than debit and depend on the merchant, MID, processor, host configuration, and rollout. A token is metadata—not proof of approval—and must be protected through appropriate access controls.
When retained with the original transaction thread, an allowed token can prepare qualified future refunds and card-on-file workflows without copying raw card data into LiftedPOS. Those downstream uses are processor-dependent; they are not universal product promises.
Timeout and recovery design
Unknown is not declined.
A network timeout does not prove that the host never approved a transaction. LiftedConnect's completed-result store and planned acknowledgement channel preserve identity for recovery, but the production endpoint and LiftedPOS ledger path must be wired and tested before the POS can rely on inquiry or replay.
The acceptance procedure must prove that a temporary connection loss cannot detach or duplicate a payment. Staff still need an operating rule for when to stop, inquire, reconcile, and escalate.
Original transaction thread
Separate void, return, and card-on-file paths.
The current LiftedPOS PAX path uses a controlled manual terminal reversal for card-present refunds because it does not retain a usable gateway reference. LiftedConnect's identity and safe-result contract are the foundation for a better connected path, not proof that remote voids or refunds are deployed.
Batch state, tender, terminal, MID, token availability, processor support, backend implementation, merchant permissions, and rollout decide which action is available and what evidence closes it.
Before you go live
Prove the complete payment path in your real setup.
Run these scenarios on the actual supported PAX device, BroadPOS configuration, processor, and MID before production approval.
| Scenario | Host evidence | Required LiftedPOS proof | Operator decision |
|---|---|---|---|
| Approved credit | Real response, transaction number, authorization code | Backend commits sale plus safe masked/reference fields | Enable only after connected result |
| Decline | Decline response and reason context when supplied | No approved payment posted | Choose another allowed tender |
| Timeout | Initially unknown; inquire by original identity | Ambiguous state, acknowledged recovery, no duplicate | Stop blind retry and reconcile |
| Open-batch void | Original host/terminal reference and supported void result | Connected action record after backend qualification | Verify batch state and outcome |
| Settled return | Processor-supported return result | Qualified return path or explicit manual reversal | Follow the configured path only |
| Token request | Optional processor-issued token metadata | Protected reference linked to sale after backend proof | Do not treat token as approval |
Deployment boundary
Follow the implementation, not just the diagram.
LiftedConnect's on-device engine supports PAX A920 and A920 Pro devices through BroadPOS and PAX POSLink 2. The production backend handoff into LiftedPOS is still being qualified. Exact terminal, processor, MID, tokenization, void, return, and card-on-file availability requires a completed deployment and merchant acceptance result.
LiftedPOS software is $100/month for the first station and $50/month for each additional station. A standard station is $499.99 to buy or $39.99/month to lease. Cancel anytime—there is no long-term software contract. Tenant login uses {company-prefix}.liftedpos.com/login.