What Is a TRID? How Token Requestor IDs Decide Who Owns Your Network Relationship

A merchant migrates payment providers. The card-on-file network tokens they spent a year building don't come with them. That's because a network token isn't something a merchant simply owns once it's created. It's issued to whichever party the card scheme registered as the Token Requestor, and there are two distinct ways that registration can happen.

Sometimes it's the merchant itself; sometimes it's a payment gateway acting on the merchant's behalf. Which one applies decides whether a migration like this is even a problem, and it's a decision most merchants never realize they've made until they're already trying to leave.

The party the scheme actually registers is identified by one 11-digit number: the Token Requestor ID, or TRID. It's a detail most payment teams never think about until the moment they try to switch providers, at which point it decides exactly how painful that move is going to be.

To learn more about how network tokens work end to end, see our guide network tokenization.

What a TRID Actually Is

A Token Requestor ID, or TRID, is the identifier a card network assigns to whoever it registers as a Token Requestor. Structurally, a TRID is an 11-digit numeric value. The first three digits are a TSP code identifying which network issued it: Visa's TRIDs start with 4, Mastercard's start with 5. The remaining digits are the unique suffix for that specific requestor. Each network assigns its own range independently, which is the detail that causes most of the confusion downstream.

Why One TRID Isn't Enough

Each card network issues TRIDs on its own schedule, under its own enrollment process. A merchant tokenizing card-on-file credentials across Visa, Mastercard, and American Express needs three separate TRIDs, three separate enrollments, not one universal ID that covers all three. This is because network tokens are issued and controlled by the network itself, which is exactly what lets them travel end to end, from merchant to acquirer to issuer, without ever exposing the PAN. The cost of that portability is that the relationship lives at the network level: one enrollment per network, not one relationship total.

Two Official Routes to a TRID

Card schemes document this as two genuinely separate programs, not two flavors of the same thing, and the difference between them is exactly what decides who ends up holding the requestor relationship.

The Merchant Integrates Directly

Under this model, the merchant itself is certified as the Token Requestor. Mastercard's own documentation, for instance, states this plainly: eligible merchants act as Token Requestors in their own right, with a TRID unique to them. The merchant runs the API integration, holds the encryption keys, carries the certification, and the scheme recognizes the merchant, not any intermediary, as the party on the other end of that TRID.

This is also the route digital wallets take. Apple Pay and Google Pay are themselves direct Token Requestors, certified in their own name. The same applies to large merchants who choose to integrate directly rather than through a provider.

This is the cleanest form of ownership. There's no intermediary relationship to untangle later, because there was never an intermediary in the first place. It's also the reason most merchants don't take this route: it means owning the scheme certification, the key management, and the ongoing compliance work in-house, per network, rather than handing it to a provider.

A Service Provider Requests on the Merchant's Behalf

Under the on-behalf-of model, payment service providers or specialized token vault providers are certified instead, as an On-Behalf-Of Token Requestor, or OBOTR — Mastercard's name for the role, though the structure is the same across schemes. Mastercard's documentation is just as plain about this one, and it cuts against how the term "on-behalf-of" sounds: the service provider acts as the token requestor. Not the merchant.

What's merchant-specific here is the TRID itself, not the underlying relationship. The scheme allocates the OBOTR a distinct TRID for each merchant it onboards, and the OBOTR is the one required to keep track of it: mapping every token it creates back to the right TRID, the right merchant, and the right internal record. Mastercard's documentation describes this entirely as the OBOTR's bookkeeping problem. There's no separate merchant-facing account sitting behind it that the merchant could point to independently. The TRID segments merchants from each other; it doesn't register them as independent parties to the scheme. The party actually certified, and holding the encryption keys, is the OBOTR, for every merchant it represents.

Most merchants take this route anyway, for the same reason they don't take the direct route: it trades ownership of the requestor relationship for someone else carrying the integration and certification load.

What Happens When You Switch OBOTRs

This is where "no TRID, no token" gets literal, for merchants using the OBOTR model. The TRID was never an independent merchant registration to begin with. It's a parameter scoped to one OBOTR's own certified relationship with the scheme: its API credentials, its encryption key pair, its onboarding.

The standard path when switching providers is re-issuance, not reassignment: the new OBOTR enrolls its own TRID and requests fresh network tokens against the same underlying PANs. That requires PAN access somewhere in the chain, either from the merchant re-collecting card details from the cardholder, or from a provider that already holds the PAN handling the re-tokenization directly, such as a token vault.

The second path is the one worth building for. Specialized token vault providers such as PCI Proxy retain the PAN securely, which they have to in order to have requested the original network token in the first place, so a new OBOTR can request new tokens straight from the network using that PAN.

Two Kinds of Portability, Not One

It's worth separating two claims that get flattened into one: "network tokens are portable."

An already-provisioned network token can still be authorized by a different acquirer, because the token travels through the transaction chain regardless of who originally requested it. That's real, and it's the portability advantage network tokens have over proprietary gateway tokens. What doesn't automatically transfer is the right to manage that token going forward: refreshes, lifecycle updates, re-provisioning when a card is reissued. That stays with whoever the network actually certified as the Token Requestor.

What to Actually Check

Ask a direct question, per scheme: is your Token Requestor relationship registered in your own name, or in your provider's? If it's the provider's, as it is for most merchants on the on-behalf-of route, that's not a gap to fix — it's the normal shape of the model, and the trade-off most merchants choose deliberately. But it means your actual exit path runs through PAN retention and re-tokenization, not TRID portability. Confirm your provider can do that before you need it, not while a migration is already underway.