Can I See Some ID, Please? | How We Approach MID Security 🔐

MIDs. Merchant IDs. What are they good for? Absolutely...something, actually. Highly useful and sometimes, somewhat overlooked. It’s worth starting with a quick definition of a Merchant ID:

'A unique identification number sequence associated with a physical or online merchant location, typically allowing payment processors involved in a transaction to know where to send which funds. It’s effectively an address within the payment ecosystem. Without a merchant ID, the networks involved won't know where to send the merchant's money.'

MIDs are a key component of Fidel’s service.

It’s just a line of random characters, sure, but it’s also a lot more. When we set up a client and connect them to our API, we request the details - including MIDs - of all the participating merchant locations. These are critical to being able to accurately track qualifying card transactions in real-time and it’s our mandate to track across all participating merchant locations.

Simply put, a Merchant ID is the single, best identifier for tracking a trading location 🔍

MIDs allow us to be highly precise in the data we deliver, particularly at locations that might be particularly difficult to track - and it all hinges on acquiring consent from the individual merchants, too.

Let’s take a shopping centre as an example. A medium-sized centre may have a single postcode, but could contain anywhere up to 50 or more separate merchants inside. The MID remediates for that complex environment, meaning we can be 99.9% accurate in what we’re tracking. We know that a certain MID relates to a single, physical store location. If it’s a busy day at the shopping centre, that high sales-turnover environment can make tracking and attributing transactions even more challenging - there's just such a large volume of payment information being generated. Unless, you’ve got those all-important MIDs in play.

So long as a merchant can provide one, Fidel can still achieve a very high match rate for transactions and locations, even in high-turnover locations, on the busiest days of the year. Not only that, but we can reduce the onboarding of those merchants to a single day. So, there’s major benefits behind acquiring MIDs. However, their great power comes with great responsibility. Uncle Ben was right, Spiderman fans.

With consent given for one payment terminal or one brand, it becomes less about pure convenience and more about custodianship and compliance.

Keeping the MIDs we receive secure is equally as important as the value they carry   🙌

Our handling of data is totally compliant to PCI DSS regulations, which sounds good (and is non-negotiable to us) but doesn’t tell you much. Fundamentally, the tokenization process is the backbone of our data handling process. At a high level, it involves taking that highly-sensitive data and assigning it an unassociated, equivalent data element that acts as a reference point to the original data - producing a 'token' that masks the original information, but still allows that information to travel safely within our API.

We use tokenisation in several different areas of our API, including how we communicate transactions with the major card networks in real-time. The MIDs themselves are submitted to Fidel via our encrypted closed-loop structure - which provides that critical tokenisation - before they're collated within our secure dashboard.

From there, Fidel passes MIDs directly to our network partners who operate with their own encryption processes or secure file transfers. Wherever the MID is delivered, it’s completely secure, concealed in the encryption language as the transaction data tokens we produce. Thanks to the card network’s own secure information transfer processes, that whole loop is secure. Any time that information is within our API, it’s unreadable to anyone outside of that circuit.

In fact, we make it a point of requesting that any information sent to us is done so via our API or SDKs to ensure it’s captured securely within our environment immediately.

It’s part of our responsibility to our clients, participating merchants and the network to place consent at the forefront of the process. That means that every merchant location is asked for their MID, or we can offer to extract it ourselves via our virtual card process, with their say-so.

Our Approach to Data 🏰

In some cases, our clients - who might work with or manage many individual merchant locations - may not want to ask all those merchants for their MIDs. There can be a couple of reasons for that.

Maybe they don't want to raise unnecessary security concerns, or are faced with practical issues in actually providing the MID itself, due it to being a relatively obscure piece of information. Funnily enough, the MID often appears on the merchant copy of paper receipts. However, the average merchant unfamiliar with the payments ecosystem would be hard-pressed to know where to look if asked for one.  

In the case of multiple merchants, the sheer quantity of different locations (and associated MIDs) can cause more friction. Sharing what amounts to a long list of identifiable information with external stakeholders isn’t always the preferred choice for merchants.

That’s why we try to make the process of providing MIDs as simple, secure and quick as possible - it has to be completely airtight to incentivise the provision of MIDs, or any data we receive at all. Simply, we opt to be custodians over the data we’re trusted with.

When we say we 'choose' to be data custodians, we mean it. It’s written into our mission statement. Along with providing the best tools to supercharge the value of payment cards, we dedicated ourselves (and asked the Fidel developer team really nicely) to ensure that Fidel APIs were robust in their security and compliance structure.

With our proprietary tokenisation in place, we can safeguard cardholder privacy and data security by ensuring all that data - including MIDs - is secure, never compromised or misused.

If you’d like to learn more about our tokenisation process, take a look at our documentation.