Path B — Vendor-Direct Integrations
Integrate directly with the terminal manufacturer's SDK or platform for device families outside the Priority Terminal API — covering PAX, Clover, and other vendor-specific paths.
Use the Vendor-Direct path when your terminal device family is not supported by the Priority Terminal API. Your software integrates directly with the manufacturer — through their developer platform, SDK, or device application — while Priority continues to authorize, settle, and report on the resulting payment through the MX Gateway.
Who this is for — ISVs building POS software for device families outside the Priority Terminal API, and Partners onboarding merchants on PAX, Clover, or other vendor-specific terminals.
How Vendor-Direct Works
Your application talks to the terminal through the manufacturer's developer platform (for example, developer.pax.us for PAX) or device-management portal (for example, Clover Dashboard for Clover). Once the terminal authorizes the payment, the transaction lands in Priority's MX Gateway and settles to the merchant's MID — the same downstream pipeline as the Priority Terminal API path.
The responsibility split looks like this:
| Responsibility | Owner |
|---|---|
| Device communication & device UI | Terminal manufacturer — your code talks to the vendor's SDK or app |
| Transaction authorization | Priority via the MX Gateway |
| Settlement & reporting | Priority — under the merchant's MID |
| Hardware procurement & file build | Priority — or Partner, if Partner-managed inventory |
| Device-to-T-number provisioning | Vendor portal (e.g., Clover Dashboard) — typically operated by Priority's File Build Team |
What's Common Across All Vendor-Direct Paths
Regardless of vendor, every Vendor-Direct deployment goes through:
- Stages 1–6 of the provisioning lifecycle — merchant application, underwriting, Setup Request, file build, hardware order, shipment. See Provisioning a Terminal.
- The Equipment Order Form (EOF) — unless the Partner manages their own inventory of that vendor's devices.
- Settlement through Priority — every authorization, decline, and refund lands under the merchant's existing MID in MX Merchant.
What Differs by Vendor
What varies is the registration, SDK, and per-vendor documentation requirements at Setup Request:
| Vendor | Developer registration | Device application or SDK | Documents at Setup Request | Sub-page |
|---|---|---|---|---|
| PAX | developer.pax.us — not cloud-based; naming a PAX sales rep on registration expedites approval | VTX-HC application | Equipment Order Form noting "MX Merchant PAX File" | PAX Direct Integration |
| Clover | Clover Dashboard access (Partner-managed or via the Clover File Build Team) | Clover device application ecosystem | Clover Setup Request case + Clover Addendum + Equipment Order Form | Clover Direct Integration |
| Ingenico | [verify] | [verify] | [verify] | [pending] |
| Valor | [verify] | [verify] | [verify] | [pending] |
When to Choose Vendor-Direct
Pick Vendor-Direct when at least one of the following is true for your deployment:
- The device family is not on the Priority Terminal API path — see Choose Your Integration Path.
- The merchant requires manufacturer-specific device features or app integrations not exposed through the Priority Terminal API.
- The Partner already operates inventory and provisioning access for that vendor's devices.
If none of these apply and the device family is supported by the Priority Terminal API, choose that path instead — it's a single API surface with no vendor relationship overhead.
Where to Go Next
Register with PAX, integrate the VTX-HC application, and activate semi-integrated PAX devices through Priority.
Open a Clover Setup Request, attach the Clover Addendum, and complete provisioning in Clover Dashboard.
The shared eight-stage onboarding lifecycle that every Vendor-Direct deployment runs through.