PAXSTORE-approved for PAX PayDroid · version 0.2.9

Build the approved companion into the transaction—then prove the handoff.

PAXSTORE approved LiftedConnect version 0.2.9 for PAX PayDroid on July 27, 2026. The companion runs on supported PAX A920 and PAX A920 Pro hardware alongside BroadPOS. Its on-device POSLink 2 engine, credit/debit choice, host-verdict rules, safe-result contract, and token request have been exercised on the terminal. The production backend handoff into LiftedPOS remains a rollout qualification gate rather than a generally enabled tenant workflow.

Plan a supported PAX setup See the approved application record Learn semi-integration

Distribution status: PAXSTORE-approved; companion engine verified on-device. Rollout status: the LiftedPOS backend handoff and merchant acceptance remain qualification gates. Availability depends on terminal, processor, MID, application version, network, pairing, and configuration. Review the PAX A920 setup and app guide, then run the merchant acceptance drill before choosing a production setup.

LiftedConnect standby screen on a supported PAX terminal — Companion standby

LiftedConnect credit or debit choice during PAX hardware bring-up — Verified rail choice

LiftedConnect on-device approved diagnostic result with card-safe transaction details — Verified device result

Qualified target workflow

One sale. Four controlled boundaries.

The card interaction belongs to the secure terminal stack. The merchant rollout must prove that LiftedPOS receives the safe result and retains the business context required to reconcile the sale.

01
LiftedPOS handoff
The production target creates the transaction identity and sends the sale through an authenticated companion channel. Backend enablement remains a rollout gate.
02
LiftedConnect
The companion is designed to receive that command, retain duplicate/recovery context, and hand payment work to its verified on-device engine.
03
BroadPOS + POSLink 2
Owns the customer card interaction and returns the real host result—not a transport-success guess.
04
Safe result
The production handoff must return masked account, card brand, host result, references, and any supported processor-issued token to the correct sale thread.

Card-data boundary

Cardholder data stays on the payment device.

The customer can tap, insert, or swipe through BroadPOS on the PAX terminal during a qualified payment path. Raw PAN, track data, and PIN remain in the terminal stack; LiftedConnect's allowlisted result excludes them. Delivering masked account, brand, host outcome, references, and qualified token metadata into LiftedPOS still requires the backend handoff and merchant go-live validation to be enabled and proven.

Qualified result target: Masked account, brand, authorization outcome, host references, and supported token metadata.
Stays in the terminal stack: Raw cardholder data and the secure card-interaction flow.

LiftedConnect PAX application product artwork

01 · OPT IN

Token request is off by default.

When enabled, a supported credit MID can explicitly request a token. LiftedConnect does not silently add it because processor support is required and an unsupported processor and MID can reject the transaction.

02 · FAIL CLOSED

Approval comes from the host result.

A successful transport or SDK execution is not enough. The result must carry the required host response and transaction identity before the sale is treated as approved.

03 · FUTURE READY

References create the next secure step.

When supported, the processor token and original transaction references provide the foundation for future cards on file, future refunds, open-batch voids, and recovery inquiry without re-entering card details.

Resilience by transaction identity

A timeout is ambiguous, not a clean decline.

LiftedConnect retains completed-result context on-device and defines inquiry against the original transaction identity. Its planned backend channel keeps results queued until acknowledged. That acknowledgement path must be connected to a production LiftedPOS ledger and tested end to end before it is described as a deployed recovery workflow.

Void, return, and inquiry keep the original thread.

The companion defines distinct command paths for an open-batch void, a return, and a recovery inquiry. Exact availability and behavior remain dependent on the configured host, processor, MID, terminal, and deployed backend path.

Review compatibility See station pricing

Recovery is a payment workflow

Do not turn uncertainty into a second charge.

A network timeout can leave the commercial result unknown while the terminal or host has already advanced. Recovery begins with the original transaction identity, not a blind retry.

01 · HOLD

Keep the original sale visible.

The qualified backend must preserve the LiftedPOS transaction identity and command context while the result is uncertain. A transport error is not proof that the host declined or never received the request.

02 · INQUIRE

Ask about the original transaction.

Acceptance testing must prove inquiry and queued-result behavior against the original identity before staff rely on it. The goal is to recover the real host outcome and references before deciding what happens next.

03 · RECONCILE

Match the safe result to the sale.

Confirm approval or failure, masked account, card brand, authorization result, host references, and supported token metadata. A successful SDK call without the required host result is not payment evidence.

04 · ACKNOWLEDGE

Close the companion handoff.

The target backend acknowledges a recovered result only after the POS has a durable operating record. Production endpoint, ledger commit, and replay behavior must all be proven in the merchant rollout.

Token and original-sale custody

A processor-issued token is not card data and not a universal promise.

When the merchant’s supported credit processor, MID, terminal application, and rollout are qualified, LiftedConnect can request processor-issued token metadata. That token can support future cards on file and future refunds without asking LiftedPOS to store raw PAN, track data, or PIN. The token remains processor-specific: portability, lifecycle, transaction types, and recurring-use rules come from the supported host and merchant program.

Void, return, and refund are distinct decisions.

An open-batch void, a post-settlement return, and a recovery inquiry do not mean the same thing. The original transaction references, current batch state, configured host, merchant permissions, and backend rollout determine which path is available. LiftedConnect preserves the technical command boundary; the merchant procedure decides who may act and what evidence closes the loop.

Acceptance drill

Prove the merchant’s exact payment path before opening day.

Run controlled test transactions with the actual deployed terminal and merchant setup. Record the expected evidence and owner for every branch.

Approved sale

Send one safe amount through the production handoff, complete card interaction, and match the host result and references to the LiftedPOS transaction.

Host decline

Confirm the real decline remains distinct from transport failure and does not create a completed sale.

Timeout recovery

Interrupt the channel safely, inquire using the original identity, and recover or reconcile the terminal result without blind resubmission.

Qualified token

Where enabled, verify the processor-issued token returns only on supported credit paths and never substitutes for approval evidence.

Void or return

Confirm the correct original-sale references, batch state, permissions, and receipt or audit evidence for the deployed path.

Restart and pairing

Restart the approved components, restore the authenticated companion channel, and prove that a completed result is not orphaned.