Path C — Standalone Terminals

Accept card-present payments on a terminal without a software integration — how Standalone works, supported devices, trade-offs, and provisioning.

Use the Standalone path when the merchant accepts payments directly on the terminal — with no POS or ordering system driving the device. Staff key amounts, present the prompt to the customer, and the terminal authorizes the transaction on its own. Priority still authorizes, settles, and reports the payment through the MX Gateway, but no software integration is required on your side.

📌

Who this is for — Merchants whose operations don't need a POS application to initiate transactions, and Partners onboarding those merchants. ISVs typically choose Priority Terminal API or Vendor-Direct instead.


How Standalone Works

In a Standalone deployment:

  • Staff operate the terminal directly — keying amounts, selecting transaction types, and confirming receipts on the device itself.
  • The terminal authorizes the transaction with the card network the same way a semi-integrated terminal does.
  • Priority's MX Gateway processes the authorization and settles the payment under the merchant's MID.
  • There is no API call, no SDK integration, and no POS-to-device communication layer.

The downstream pipeline — authorization, settlement, batch close, reporting in MX Merchant — is identical to the other two paths. What's missing is the upstream software integration.


Supported Standalone Devices

Standalone deployments fall into two categories:

CategoryDevices
Standalone-onlyPAX S80 — existing devices may be reprogrammed; not available for new purchase.
Semi-integrated devices deployed as standalonePAX S920, A920, A920 Pro, A80 — devices that support either mode, deployed without an integration.

Other device families may also support standalone operation. Confirm the specific model's standalone capability via Supported Terminal Devices. [verify — broader standalone matrix pending hardware page completion]


What You Don't Get in Standalone Mode

Standalone is a trade-off: simpler deployment in exchange for fewer gateway features and no POS-side control.

CapabilityAvailable in Standalone?
MX B2B Interchange OptimizerNo — semi-integrated only [verify — confirmed for PAX; cross-vendor pending confirmation]
MX Advantage for SurchargingNo — semi-integrated only [verify — confirmed for PAX; cross-vendor pending confirmation]
Programmatic control of the transaction (initiate, cancel, refund from your POS)No — all transaction control sits on the device.
Receipt and tip data flowing into your POSNo — receipt and tip handling is device-side only.
Settlement and reporting under the merchant's MIDYes — same as the other two paths.

If any of the capabilities above matter to the merchant's operation, choose Priority Terminal API or Vendor-Direct instead.


Provisioning a Standalone Terminal

Standalone deployments run through the same eight-stage provisioning lifecycle as semi-integrated deployments. The difference is at Stage 7 (Provisioning) — the file build configures the device for standalone operation, and there is no integration credential to issue.

StageStandalone behavior
Stages 1–6Identical to semi-integrated deployments (Application → Shipment).
Stage 7 (Provisioning)Same vendor registry as the semi-integrated variant of that device family. The file build configures the device as standalone.
Stage 8 (Activation & Billing)Same as semi-integrated. The merchant powers the device on and begins transacting.

When to Choose Standalone

Choose Standalone when:

  • The merchant does not have or need a POS or ordering system to drive the terminal.
  • Staff are comfortable keying transactions directly on the device.
  • The merchant does not need gateway features like Surcharging or the B2B Optimizer.
  • The merchant wants the lightest possible deployment, with the fewest moving parts.

If any of those conditions don't hold, choose Priority Terminal API or Vendor-Direct.


Where to Go Next


.readme-logo { display: none !important; }