The journey from a signed merchant application to a terminal taking its first payment runs through eight stages — across the Partner, three Priority teams, the terminal vendor, and (where applicable) Fiserv. This page maps each stage end-to-end so you know who acts, on which system, and what to expect at every handoff.

📌

Who this is for — Partners coordinating activation, ISVs sequencing their build alongside merchant onboarding, and Priority internal teams using this as the operational reference for in-person provisioning.

---

The Eight Stages

---

Stage 1 — Application Submitted

What happens. The Partner walks the merchant through the standard electronic application in MX Connect. In most cases, the equipment section is left at its default — a stage-only file — and not fully specified at this stage. Equipment specifics are captured later, in the Equipment Order Form attached to the setup request (Stage 3).

Watch-out — Leaving the equipment section at "stage-only file" is standard practice and not a blocker. The equipment build is finalized in Stage 3 when the Setup Request opens with the Equipment Order Form attached.

---

Stage 2 — Underwriting Decision

What happens. Underwriting reviews and approves the merchant account. The MID (merchant ID) and T-number (the internal handle Priority uses to reference each terminal) are created.

Watch-out — MID and T-number creation can occasionally lag the approval decision due to handoff errors between underwriting platforms. If the Setup Request needs to move before MID/TID are visible, flag the case so File Builds can sequence the work.

---

Stage 3 — Setup Request Opened

What happens. The Partner opens a setup case for the new merchant and attaches the documents required for that terminal family.

Once submitted, the case moves to the File Build Team for the next stage.

---

Stage 4 — File Build

What happens. The File Build Team manually builds the T-number file in FDPOS — Priority's file build platform. The file encodes the merchant's processing setup: MID, terminal capabilities (EMV / NFC / swipe), payment apps, tip configuration (retail vs. restaurant), surcharging, and similar settings.

⚠️

Bypass front-end variation — On Bypass front-end accounts, Priority does not have direct file-build access. The File Build Team opens a ticket with Fiserv to create the file. This introduces an external dependency and additional delay. Flag Bypass cases early so timing expectations can be set with the merchant.

---

Stage 5 — Hardware Order Placed

What happens. The Fulfillment coordinator places the hardware order on Priority's internal order site during case work. Inventory is tracked in NetSuite. Partners cannot place orders directly on this system — the order is always submitted by a Priority internal actor on the case.

📌

Partner-managed inventory — Some Partners stock vendor devices (most commonly Clover) themselves. These Partners may skip the Equipment Order Form and provision directly using their own vendor portal access. See Common Variations below.

---

Stage 6 — Shipment, Serials & Tracking

What happens. Once the warehouse ships the device, serial numbers and tracking become visible — same day or next day, depending on the feed and the carrier cutoff. The File Build Team updates the MX Connect case with the serial and tracking so the Partner can communicate timing to the merchant.

Shipping SLA. Orders placed before approximately 3:00 PM (warehouse pickup cutoff) generally ship the same day. Orders after the cutoff ship the next business day.

---

Stage 7 — Device Provisioning (Serial ↔ T-Number)

What happens. This is the final provisioning step. The serial number of the shipped device is linked to the T-number in the appropriate registry. The registry depends on the integration path:

⚠️

Critical dependency — Provisioning must complete before the device physically arrives at the merchant. If the device is delivered un-provisioned, the merchant will receive a non-functional terminal and need a remote provisioning push. Sequence shipment and provisioning together when possible.

---

Stage 8 — Activation, Billing & Go-Live

What happens. The merchant receives the provisioned device, powers it on, and it boots ready to transact. Priority Finance issues the invoice based on the terms captured in the Equipment Order Form — or per Partner inventory terms when the Partner stocks the device themselves. Revenue is recognized to the correct business unit and MID based on the accounting setup.

---

Common Variations

Partner-Managed Inventory

Some Partners — typically those reselling Clover at scale — stock vendor devices themselves and have direct access to the vendor's provisioning portal.

What changes:

• Stage 3 — Partner may submit a file build request without the Equipment Order Form (Partner inventory replaces Priority-fulfilled inventory).
• Stage 5 — Skipped. No internal Priority order is placed.
• Stage 6 — Tracking and serials are managed by the Partner directly.
• Stage 7 — Partner performs provisioning in the vendor portal.
• Stage 8 — Billing follows Partner inventory terms, not the EOF.

Bypass Front-End Accounts

For merchants on a Bypass front-end, Priority cannot build files directly in FDPOS.

What changes:

• Stage 4 — File Build Team opens a ticket with Fiserv instead of building in FDPOS. Wait time depends on Fiserv's ticket queue.
• All other stages proceed as standard.

Multiple Storefronts by Business Unit

Merchants operating across multiple Priority business units (e.g., a single merchant running Clover, MXPOS, and standalone terminals) will have separate hardware sites, MIDs, and inventory paths per BU — driven by accounting and inventory segregation, not by terminal architecture.

What changes:

• One application per BU. Each BU has its own MID, T-number(s), and Equipment Order Form.
• Reporting in MX Merchant is per-MID — there is no automatic cross-BU consolidation.

---

End-to-End Timing

The lifecycle's calendar duration depends on Underwriting and File Build queue depth, the shipping cutoff, and whether the merchant is on a Bypass front-end. The order of operations matters more than the absolute number of days.

Stages 4 and 7 are the timing-critical stages. They are the most common source of delay and the most common source of "device arrived but doesn't work" support tickets.

---

Escalation Paths

---

Where to Go Next