2026-10-26 Author : ZCS
A POS terminal ID, usually shortened to TID, is the identifier an acquirer, processor or terminal provider uses to distinguish a payment acceptance endpoint in its own environment. A point of sale system may contain sales software, hardware and reporting tools, while the TID belongs to the narrower payment-processing setup.
The merchant ID, or MID, answers a different question. It identifies the merchant relationship or merchant facility known to the acquirer. A single merchant can therefore have one MID connected to several terminals, each with its own TID.
A POS terminal ID tells the payment provider which configured endpoint submitted a transaction. A merchant ID tells the provider which merchant relationship that endpoint belongs to. Neither number should be confused with the terminal’s manufacturer serial number, a store code, an asset tag or a transaction reference.
That distinction becomes useful when a merchant reads a receipt, calls support, replaces a terminal or tries to trace an isolated payment problem.
A POS terminal ID is a provider-assigned identifier for a particular payment terminal or logical payment endpoint. It is commonly displayed as TID, Terminal ID, Terminal Number or another provider-specific label.
The phrase “terminal” does not always mean only the plastic device sitting on the counter. In one deployment, a TID may map closely to one physical card terminal. In another, it may identify a payment application instance, a lane, a merchant outlet endpoint or a configuration record used by the acquiring host. The provider’s documentation defines the exact scope.
The TID helps the payment environment associate a transaction with the correct endpoint configuration. That can include the merchant relationship, accepted payment methods, routing rules, receipt settings, settlement arrangement and support record. It does not by itself prove who operated the terminal or identify the customer’s card.
There is no universal TID length or format. It may be numeric, alphanumeric or displayed with leading zeroes. A merchant should preserve the value exactly as issued instead of removing characters or assuming another provider uses the same structure.
Eftpos New Zealand’s guide to finding terminal and merchant IDs illustrates the practical model: the MID links the terminal to the merchant’s banking relationship, while each terminal receives its own TID. Its receipt labels also vary by terminal network, which is why merchants should follow their provider’s instructions rather than rely on one universal receipt layout.
A merchant ID is an identifier assigned to a merchant account, merchant facility or acquiring relationship. It is commonly shortened to MID, but providers may use terms such as merchant number, merchant account number or merchant facility number.
The MID usually sits above the TID in the payment hierarchy. It helps the acquirer or payment provider identify which merchant relationship owns the transaction activity. A merchant with several checkout lanes can therefore have one MID and multiple TIDs beneath it.
That one-to-many pattern is common, but it is not a universal account rule. A business may have multiple MIDs because it operates through different acquirers, legal entities, countries, currencies, stores, sales channels or commercial agreements. Conversely, several physical terminals may share the same MID when they settle under the same merchant facility.
The MID should not automatically be treated as the company registration number, tax number, store number or bank account number. Those identifiers may be connected in the provider’s records, but they serve different purposes. The merchant should use the label and value supplied by its acquirer when support asks for a MID.
The simplest distinction is scope: the MID identifies the merchant relationship, while the TID identifies an endpoint operating under that relationship.
| Identifier | What it normally identifies | Typical scope | Common use |
|---|---|---|---|
| Merchant ID (MID) | Merchant account, facility or acquiring relationship | One merchant arrangement, sometimes covering several terminals | Account lookup, settlement configuration and merchant support |
| Terminal ID (TID) | Payment terminal or logical payment endpoint | One terminal, lane, app instance or host endpoint | Terminal lookup, transaction tracing, configuration and fault isolation |
| Store ID | Business location or outlet | One physical or operational location | Location reporting and deployment grouping |
| Serial number | Physical hardware unit made by the manufacturer | One device | Warranty, inventory, repair and physical replacement |
| TMS device ID | Device record inside a management platform | One enrolled device or software agent | Software deployment, monitoring and lifecycle management |
| Transaction reference | One payment attempt or financial event | One transaction | Search, reconciliation, refunds and disputes |
A payment receipt can include both MID and TID because the transaction belongs to a merchant relationship and originated from a particular endpoint. Handpoint’s current receipt compliance fields list the MID and TID separately and also treat the terminal serial number and transaction reference as different fields. That separation is important during troubleshooting: four identifiers can refer to four different layers of the same event.
The relationship can be written as a simple hierarchy:
This hierarchy is a working model, not a mandatory global database design. Some providers combine layers, use additional identifiers or give familiar labels different meanings. The merchant’s onboarding documents and support portal remain the authority for its own account.
No. A TID is a payment-processing identifier, while a serial number identifies physical hardware and a TMS ID identifies a record in a management system. The same device can have all three values at once.
The serial number is assigned by the manufacturer and normally remains attached to that physical unit. It is useful for inventory, warranty claims, repair history and model verification. Replacing the device necessarily introduces a different serial number because a different physical unit is being installed.
A terminal management system may create another device identifier when the unit is enrolled. That record helps an operator distribute software, monitor status, assign a merchant or retire hardware. The POS terminal management guide explains that lifecycle layer in detail. The TMS record may store the serial number and TID, but storing them together does not make them interchangeable.
The TID belongs to the payment configuration. Depending on the provider, a replacement device may be provisioned with the old logical TID, assigned a new TID or placed behind another endpoint record. Merchants should not copy a TID manually from one device to another unless the provider’s authorized process explicitly requires it.
The most likely places are the merchant receipt, terminal information screen, provider portal, transaction report and onboarding documents. Availability varies by provider, terminal model, receipt type and region.
A printed or digital merchant receipt often shows labels such as TID, Terminal ID, Terminal Number, MID or Merchant ID. The customer copy may show the same values, shorten them or omit them under the provider’s receipt policy.
Do not confuse the TID with the authorization code, retrieval reference number, invoice number, order number or masked card digits. Those fields describe the transaction or card, not the terminal endpoint.
The Trust Payments receipt guide shows TID, MID, reference and authorization code as separate receipt elements. It also notes the common multi-terminal relationship: several terminals may have unique TIDs while sharing one MID. A merchant should still check its own receipt key because field order and labels are not standardized across all providers.
Many payment applications expose an About, Device Information, Help or Configuration page. Access may require a supervisor code or support instruction. A merchant should view the identifier without changing payment parameters.
The screen may display several similar values together, including terminal name, device ID, serial number, TID, merchant number, application version and network profile. Copy the label as well as the value so support can tell which identifier was supplied.
A provider portal may list terminals beneath the merchant account and show their status, location, TID and recent transactions. Transaction exports can also include MID and TID columns, allowing a merchant to group activity by terminal.
Onboarding emails, installation sheets and service agreements may contain the same information. These records are useful when a terminal is offline or damaged and its information screen cannot be opened.
Consider a fictional bookstore with two checkout lanes. The example values below are deliberately descriptive placeholders; they do not represent any provider’s real format.
| Record | Fictional value | Meaning |
|---|---|---|
| Merchant | North Street Books | Trading location in this example |
| Merchant ID | `DEMO-MID-2048` | Merchant relationship used by both lanes |
| Lane 1 Terminal ID | `DEMO-TID-01` | Payment endpoint at the first checkout |
| Lane 2 Terminal ID | `DEMO-TID-02` | Payment endpoint at the second checkout |
| Lane 2 Serial Number | `DEMO-SERIAL-B2` | Physical hardware identifier for lane 2 |
| Example Transaction Reference | `DEMO-TXN-73K2` | One payment event processed at lane 2 |
Suppose lane 2 accepts a $42.00 card sale. The merchant’s records might associate the transaction reference with `DEMO-TID-02`, then associate that TID with `DEMO-MID-2048`. If the payment appears in the provider report but not in the POS sales report, the merchant can use the POS reconciliation workflow to compare the order, terminal transaction and later payout records.
If only lane 2 develops a communication fault, the TID narrows the incident to one endpoint. The shared MID still identifies the merchant relationship, but it does not distinguish which lane produced the error. The serial number then identifies the physical unit if repair or replacement is required.
This is why support may ask for more than one identifier. MID establishes the account context, TID identifies the endpoint, serial number identifies the hardware and transaction reference identifies the specific payment.
TID and MID reduce ambiguity. A terminal provider may support thousands of merchants and many endpoints with similar models, store names or locations. The identifiers let its systems retrieve the correct account and device records.
For a general terminal fault, support may ask for:
For a missing, duplicated or disputed transaction, support may additionally need the amount, currency, transaction type, masked card suffix, authorization code and transaction reference. A merchant should share payment details only through the provider’s approved support channel and should never send a full card number or PIN.
The pattern of affected identifiers also helps isolate the fault. One failing TID may indicate an endpoint, connection or configuration issue. Several TIDs under one MID may point to a merchant-level setting or provider incident. Similar failures across different MIDs may suggest a wider network, application or acquiring-host problem.
The physical serial number changes, but the TID and MID follow the provider’s provisioning rules. A merchant should not assume that every replacement keeps the old TID or that every new device receives a new MID.
The MID often remains associated with the merchant facility when only the hardware changes. The new device still accepts payments for the same merchant relationship unless the commercial or acquiring arrangement is also being changed.
The TID is less predictable. A provider may transfer or re-provision the existing logical endpoint, issue a new TID for the replacement terminal, or create a new record as part of a platform migration. Nuvei’s published terminal migration example kept the MID but issued a new TID for each new terminal. That is evidence of one migration policy, not a universal rule for every provider.
Before installing a replacement, the merchant should confirm:
If the TID changes, reports and integrations may show a new terminal dimension from the installation date onward. The merchant should document the change so historical activity under the old TID remains understandable.
A small terminal register can prevent support delays and reporting confusion. It does not need to contain sensitive card data.
Useful fields include:
| Field | Why record it |
|---|---|
| Store or site | Shows where the terminal is deployed |
| Lane or friendly name | Gives staff an operational label |
| MID | Connects the unit to its merchant facility |
| TID | Connects the unit to its payment endpoint |
| Model and serial number | Identifies the physical hardware |
| Provider | Shows who controls payment provisioning |
| Installation date | Establishes when activity should begin |
| Replacement history | Preserves the old-to-new identifier trail |
| Status | Distinguishes active, spare, repair and retired units |
Limit access to staff who need the register for finance, support or operations. A MID and TID are not substitutes for card credentials, but publishing payment configuration data unnecessarily can still create operational risk and make social-engineering attempts more convincing.
The register should be compared periodically with the provider portal and POS configuration. Decommissioned terminals should not remain active merely because their row still exists in a spreadsheet. Conversely, deleting the old record entirely can make historical reporting harder to explain.
The TID can segment transaction records by endpoint. That makes it useful for locating a missing payment, comparing lane totals, investigating repeated declines and checking whether a replacement terminal is routing under the intended configuration.
The TID does not mean that each terminal receives a separate bank deposit. Several TIDs can feed one MID, and a provider may combine their transactions into batches or payouts according to the merchant agreement. The POS settlement process explains why an approved payment and a bank deposit are different events.
A merchant investigating a payout should therefore avoid searching by TID alone. The complete trail may require the POS order number, transaction reference, TID, MID, batch or settlement reference, payout ID and bank deposit. Each identifier marks a different stage in the transaction lifecycle.
This layered view also explains why a terminal can display “approved” even though finance cannot yet see the amount in the bank. The TID identifies where the authorization originated; it does not prove that clearing, settlement, payout and bank posting have finished.
The serial number, Android device ID, asset tag and TMS record can all look like terminal identifiers. Record the exact label and confirm which system assigned it.
Identifiers are strings, not quantities. If a provider displays leading zeroes, preserve them. Reformatting a TID in a spreadsheet can make a valid value unusable for support searches.
The merchant-to-store relationship depends on the acquiring setup. One MID may cover several terminals, while a multi-location business may use several MIDs. Do not infer the hierarchy without checking provider records.
Copying payment parameters from an old device can create duplicate or incorrect endpoint assignments. Replacement and re-provisioning should follow the provider’s approved procedure.
A TID narrows the source terminal, but many transactions can pass through that terminal. Date, time, amount, transaction reference and authorization code help identify the specific event.
TID usually stands for Terminal ID. It identifies the payment terminal or logical endpoint within the acquirer, processor or terminal provider’s environment. The exact label and scope are provider-specific.
MID usually stands for Merchant ID. It identifies the merchant account, facility or acquiring relationship associated with the transaction. It is not automatically the merchant’s company registration or bank account number.
Yes. Several terminals can commonly operate under one MID while each has a different TID. The actual arrangement depends on the merchant’s provider, locations, currencies and acquiring agreements.
Merchants should not assume that two simultaneously active endpoints may share a TID. Some systems can re-provision or transfer a logical identifier, but duplicate active assignments can cause routing, reporting or support problems. Follow the provider’s configuration rules.
Not necessarily. Many merchant receipts display it, but customer receipts, digital receipts and provider-specific layouts may shorten, relabel or omit it. Check the terminal information screen, merchant portal or transaction report if it is absent.
Usually not when only the hardware changes and the merchant keeps the same acquiring relationship. However, the provider may issue a new TID, retain the old logical TID or change both identifiers during a wider migration. Confirm before activation.
A TID is not a card PIN or full payment credential, but it is operational account information. Share it only with authorized staff and trusted provider support channels rather than publishing it unnecessarily.
A POS terminal ID identifies the payment endpoint; a merchant ID identifies the merchant relationship. One MID can commonly sit above several TIDs, while serial numbers, TMS device IDs and transaction references identify different physical, management and transaction layers.
Merchants can usually find these identifiers on a receipt, terminal information screen, portal, report or onboarding document. When requesting support, copy both the label and value, preserve leading zeroes and provide the transaction reference when the problem concerns a specific payment.
After a terminal replacement, expect the serial number to change and verify the MID and TID with the provider. The identifier policy belongs to the acquirer or terminal provider, so no global rule can promise whether a TID will be retained or replaced.
Home 
How MMQR Payments in Myanmar Let Shops Verify Customer Transactions? 
