What Is a Merchant ID in Crypto Payments?

How a Merchant ID Is Structured and Assigned

A Merchant ID is typically a string of alphanumeric characters — ranging from 8 to 32 characters depending on the gateway — assigned automatically at the point of account creation. Unlike an Order ID (which is created per transaction) or a TXID (which is generated by the blockchain), the MID is static: it does not change for the lifetime of the merchant's account with that gateway. It is the stable anchor to which all transaction history, API credentials, settlement records, and compliance documentation are attached.

Some gateways use UUIDs (e.g., 550e8400-e29b-41d4-a716-446655440000) for globally unique MIDs that cannot collide across different systems. Others use shorter numeric or alphanumeric strings for readability in support contexts. The format choice has no functional significance to the merchant — what matters is consistency in how it appears across API payloads, reports, and dashboard URLs.

How the MID Appears in Integration

In a typical REST API integration, the MID is either embedded in the API key itself (many gateways encode the merchant scope into the key's prefix), passed as a header, or included in the URL path. For example, a request to retrieve transaction history might look like:

In webhook payloads, the MID appears in the notification body so that systems receiving callbacks from multiple merchants can route the event to the correct internal record. In gateway dashboards, the MID often appears in the browser URL, making it easy to share a direct link to a specific merchant's view with a support team.

MID in White-Label and PSP Environments

In a white-label payment gateway deployment, the infrastructure provider assigns a master account with its own MID. Merchants onboarded by the white-label operator each receive their own sub-MID. The sub-MID scopes the merchant's access — they can only see their own transactions, settlements, and settings — while the operator's master MID allows cross-merchant visibility.

This architecture is also used in payment service provider (PSP) models, where a licensed entity onboards multiple clients under its own regulatory umbrella. Sub-MIDs allow the PSP to maintain separate accounting, risk monitoring, and reporting for each client while managing them under a single compliance and banking relationship. Each client's transactions are isolated at the MID level, preventing one merchant's data from being visible to another.

MID vs. Order ID vs. TXID — What to Use When

MID Security — Why It Should Not Be Treated as a Secret

Unlike an API key or secret, a Merchant ID is not a credential. Knowing someone's MID does not grant access to their account — it is analogous to knowing a bank account number. Access is controlled by API keys, which are scoped to a MID but are separate from it. That said, MIDs should not be shared publicly if avoidable, because exposing your MID makes it easier for a bad actor to craft targeted phishing attempts or to identify you as a specific gateway customer for social engineering attacks.

Compliance Note: This glossary entry is provided for general educational purposes only and does not constitute financial, investment, legal, or tax advice. Industry terminology may vary across jurisdictions and providers; definitions herein may not directly reflect the specific features, terms, or specifications of Finassets' services. For details on Finassets' offerings, please refer to official product documentation or contact our team directly.