Merchant ID Control Design

This guide explains how to design account-level controls (ALCs) for merchant IDs. For general information on ALCs, see these guides:

• Designing Authorization Controls
• Account-Level Authorization Controls

A merchant ID (MID) is derived from DE042 of an ISO 8583 authorization request, which contains an identifier that is unique to a point of sale. An MID control at the account level can override existing MCC controls, either to ALLOW or DENY a transaction from a merchant that would otherwise be denied or allowed based on its MCC. Account-level MID controls exist independently of the product-level MID controls. If no product-level MID controls exist, you can still set MID controls, and they can overlap MCC controls and other MID controls.

Merchant ID control conventions

• A merchant ID is specific to a point of sale such as a store location or web site, not to a chain of stores.
• Product-level merchant controls follow these rules:
  • The product-level control is applied only if the MCC controls allow the transaction.
  • The product-level control includes the MID as well as terminal ID and merchant description so that it can be used to assess fees.
  • If you are using Galileo's fraud-detection engine, the engine will automatically add DENY MIDs to your product-level controls as necessary.
• An MID control must specify the entire merchant ID—no wildcards are allowed.
• The MID is not case-sensitive.
• Merchant IDs often change when a merchant replaces its card readers or makes other adjustments.
• A single ecommerce site that provides merchandise or services from third parties will use different MIDs for each vendor. See Amazon transaction in Card Transaction Examples to see different MIDs in the same transaction.
• An account-level MID control overrides product-level and account-level MCC controls but does not override the MCC blocklist.
• When Galileo denies an authorization request because of a merchant ID violation, the response code is 03 for Mastercard or 57 for all other networks.

This table shows how MID controls are applied.

• See Examples 10, 11, and 15 of MCC and Merchant ID ALC Examples for demonstrations of how account-level MID controls result in authorization requests being approved or denied.
• Consult the Authorization workflow in Designing Authorization Controls to see the order of operations when MID controls are applied.

Obtaining merchant IDs

Galileo does not have a list of merchant IDs to provide—you must compile the list yourself. You can get these numbers from the merchants by request or you can harvest that data from Galileo data sources such as the Auth API, RDFs and Authorization Events messages. However, Galileo sources return the merchant ID only after the authorization process has checked for merchant ID controls, so you cannot harvest them from the Auth API webhook payload, for example, and then create a merchant ID ALLOW control for the current authorization—the MID control would apply only to subsequent authorization requests.

Because the product-level merchant controls are used to assess fees, you will develop these controls in conjunction with Galileo and your bank during product setup. In contrast, the ALCs specify only the MID to provide a quick way to allow or deny a particular merchant.

If you would like to correlate a merchant ID with the merchant name (DE043) in your lookup table, use these fields from these Galileo data sources: