Mastercard TLID and Subscriptions: Are you ready?

Unfortunately, it was anything but simple. PSP-specific handling, subcategories with varying schemas, and messaging contradictions introduced significant complexity. Merchants had to determine when and how to use identifiers, and how to handle cases where they were missing. This was further exacerbated by the emergence of new credential-format use cases, such as toggling or recycling between PAN and COF network tokens.

To illustrate a small snapshot of the known challenges merchants experience, many of you who have heard me speak about network tokens have likely heard my familiar mantra about “fixing or restarting the string” when credentials are swapped between PAN and COF network token formats. In some cases, this even requires fetching a cryptogram mid-stream, along with the ID, to repair the transaction string.

That brings us to today, with Mastercard’s release of the new Transaction Link Identifier (TLID), introduced in announcement GLB 12940.1. It is the latest installment in the endeavor to accurately connect transactions. The TLID effectively replaces the intent of the old TraceID (although you still have to send both temporarily) and hopes to address some of the questions that plagued subscription merchants:

1. How can I ensure accurate tracing between auth and clearing WITHIN a transaction?
2. How can I ensure I’m using the correct transaction ID? Is it the prior transaction or the original transaction on an MIT?
3. How do I ensure continuity between the PAN and network token credential formats when toggling between prior and current transactions in the string or during recycling activities?

So, what is TLID, and what are the revised standards for CIT/MIT?

Mastercard’s Transaction Link Identifier (TLID) is a 22-character reference code used to link related payments after a merchant authorizes the credential for storage for subsequent transactions. It serves as an agreement-level tracker that connects subsequent Merchant-Initiated Transactions (MITs) to the initial Customer-Initiated Transaction (CIT).

Specifically, the new TLID framework has been suggested by industry insiders to now include:

• Lifecycle Tracking: Connecting an authorization with future settlement/clearing activity within the same transaction
• Agreement-Level Tracking: Directly links recurring billing, installments, and renewals to the original transaction, establishing customer consent. Mastercard refers to this as Economically Related transactions.
• Parallel Integration (Temporary): Operating alongside legacy trace IDs and network references without altering or overwriting account and token data.
• Ecosystem Portability: Streamlining dispute management and ensuring seamless subscription continuity across different payment service providers (PSPs).

For a complete list of Mastercard-identified benefits, please see here.

The timeline and what dates you need to pay attention to!

• October 17, 2025: Issuers and processors must begin passing the TLID (Lifecycle only- link clearing to authorization only).
• December, 2025: Most recent update to GLB 8701 which included the spec announcement
• January, 2026: GLB 12940.1 is released including the details for Economic Linking (CIT-MIT)
• June 2, 2026: Merchants and acquirers must begin capturing and retaining the TLID returned on initial CITs for cards stored on file.
• October 23, 2026: Enforcement begins. Merchants must pass the retained TLID on all subsequent MITs and recurring charges or may become subject to higher decline rates from issuers (failure models are already underway)
• January 31, 2027: Non-compliance assessments officially begin with acquirers (pass through to merchants), reportedly ranging from $2,500 to $5,000 per month, capped at $25,000 and assessed under the Data Integrity Monitoring Program (DIMP).

NOTE: assessments only apply to the Lifecycle Linking (authorization and clearing) as of January, they do NOT apply to the CIT/MIT or Economic linking… Yet. If history serves, those fines will likely start later in 2027 or early 2028.

But 143 ≠ 365? The backfill conundrum.

If you’ve done the math (most of us have), existing subscriptions will be affected, especially those with annual billing. There is good news and bad news.

• The GOOD news: For Customer-Initiated Transactions (CITs) initiated prior to June 2nd, Mastercard states that the mandate will not apply.
• The GOOD-ish news: For monthly subscriptions, you can use a prior TLID from up to 3 months ago versus the original.
• The BAD news: If you haven’t started yet, the expectation is that even annual subscriptions must have a TLID on a prior transaction or CIT dating back to June 2nd.

The premise is that your PSP should have started storing it, but what if you manage your own or have dual processing relationships? Here are a few options for you:

Option 1: Backfill Using a Recent MIT (Recommended for Historic Subscriptions)

If the initial Customer-Initiated Transaction (CIT) occurred before TLIDs were generated or captured, use the fallback mechanism specified by Mastercard:

1. Process your next routine MIT.
2. Extract the scheme-generated TLID returned in that authorization response.
3. Save that TLID* to your database and pass it on to all future MITs in that subscription series.
   *Please note that BOTH the TraceID and the TLID must be sent temporarily.

Option 2: Trigger an Account Status Inquiry (ASI) or New CIT

If backfilling isn’t viable or data integrity is uncertain:

• Run a zero-dollar Account Verification / Account Status Inquiry (ASI) request, which prompts Mastercard to return a new valid TLID. You can then choose to restart the string as a new CIT.
• Alternatively, as a last resort, require the customer to perform a cardholder-authenticated event (such as updating their payment method or authenticating via 3DS at next login) to establish a fresh CIT and new TLID.

What else should merchants be aware of?

Confirm how your PSP handles backfilling the TLID. If you’re using a PSP such as Stripe or Adyen, a lot of the capture-and-pass mechanics are handled for you, but you still owe them specific integration updates. More importantly, you need to know their fallback behavior. What happens when they have no TLID for an MIT? Do they suppress it, submit anyway, or expect you to backfill? The answer may change your plan.

Identify where you could experience gaps in the translation of the TLID. There could be many layers where the TLID must persist ahead of the PSP. Gateways, orchestration layers, sub-processors, and downstream partners will all translate or map this new field. At any point, it could be dropped or truncated, so have a plan to review each step.

Treat the deadline as the deadline. Even if issuers are lenient during the transition, leniency isn’t something you can forecast revenue against. Plan around October 23, 2026, as the firm date as written. Also, note that at this time, you’re likely to start seeing declines associated with this, so make sure your auth data is ready to identify and parse this impact.

How does a vault help?

Credential linking (and other CIT/MIT scheme requirements) is ultimately a stored-credential-and-metadata problem. If your customer’s payment data is shared among multiple 3rd parties, then continuity, migrations, and retry optimizations become a matching game amongst disparate data sets. This is further complicated when you’re optimizing with network tokens. Small issues, such as CIT/MIT, and continuity factors, such as TLID, can cause false declines, which may lead to early PAN fall-back. (ie. ECI Indicator) Propagating TLID across the right transactions becomes a data-management task you can run centrally, rather than a scramble across every integration.