Mastercard is changing how transactions are tracked across the payment lifecycle. The Transaction Link Identifier (TLID) is a new, scheme-generated reference that links every authorization, capture, refund, chargeback, and subsequent merchant-initiated transaction back to its originating cardholder-initiated payment. From October 23, 2026, merchants must include the stored TLID in every economically-related transaction (recurring billing, subscription renewals, installments, unscheduled credential-on-file charges). Non-compliance fees begin in January 2027.
The change is operationally simple to implement, but it carries real consequences for subscription businesses, marketplaces, and any merchant running multi-PSP setups where stored credentials need to remain portable. This guide explains what TLID is, the exact technical specification, the dates that matter, how it differs from the Trace ID it replaces, and what enterprise merchants need to do now to stay ahead of the deadline.
The Mastercard Transaction Link Identifier is a unique, scheme-generated 22-character alphanumeric identifier that Mastercard assigns to every card authorization and includes in the authorization response. The identifier persists across every related message in the transaction lifecycle (captures, refunds, voids, chargebacks) and across every economically-related transaction (subscription renewals, installments, unscheduled MITs) under the same stored-credential agreement.
In simpler terms: when a cardholder makes their first payment with a merchant and authorizes that merchant to store the card, Mastercard generates a TLID. That same TLID is then carried forward into every subsequent transaction linked to that stored credential. The merchant stores it once, and reuses it on every related charge.
A few important characteristics:
Until now, Mastercard transactions have been tracked across the lifecycle using the Trace ID (also known as the scheme transaction ID or previous_payment_id), which is generated by the acquirer rather than by Mastercard itself. The Trace ID has worked, but it carries a structural weakness: because each acquirer generates its own values, duplicates can occur across different acquiring relationships, and the same transaction can carry different Trace IDs in different parts of the chain.
The TLID solves this at the network level. Because Mastercard itself generates the identifier and propagates it across every message in the lifecycle, there is no risk of duplication, no acquirer-to-acquirer translation problem, and no ambiguity about whether two transactions are related.
The benefits Mastercard cites for the change:
For merchants, the practical benefits show up in three areas: faster dispute resolution (TLID makes it trivial to link a chargebacked MIT to the original CIT where the cardholder consented), cleaner reconciliation (every transaction in a lifecycle shares the same TLID), and better authorization rates on MITs (issuers see the chain of consent more clearly).
The Mastercard rollout happens in four phases. Missing any of them creates either compliance risk or operational disruption.
| Date | Phase | What changes |
|---|---|---|
| October 17, 2025 | Lifecycle phase | Mastercard requires acquirers and merchants to pass the TLID from the original authorization response into all subsequent lifecycle messages (captures, refunds, reversals, chargebacks) |
| June 2, 2026 | Retention phase | Mastercard begins generating TLIDs for economically-related transactions (MITs, BNPL, installments). Acquirers must ensure merchants retain the TLID from card-not-present CITs and Account Status Inquiry (ASI) requests where credentials are stored |
| October 23, 2026 | Active population phase | Merchants must include the stored TLID in every economically-related MIT authorization request so Mastercard can link it back to the original CIT |
| January 31, 2027 | Compliance assessment | Mastercard begins assessing fees for non-compliance with TLID data mandates. Formal compliance is required by December 1, 2026 |
The window that matters most for most merchants is between June 2 and October 23, 2026: that is when the TLID actually starts arriving on new transactions, and when merchants need to have their storage and integration ready. Merchants who wait until October 2026 to start the work face real risk of missing the deadline, because integration testing, schema changes, and conformance work do not happen overnight.
The TLID applies to two distinct categories of transactions, and the rules differ slightly for each.
A lifecycle transaction is any message that is part of the same authorization event: the capture that follows the original authorization, the partial or full refund issued against it, a void or reversal, and any chargeback messages.
For lifecycle transactions, the TLID generated at the original authorization is automatically propagated across all related messages by the acquirer or PSP. The merchant typically does not need to do additional work, because the integration handles it transparently. The October 17, 2025 mandate covers this category.
An economically-related transaction is a separate authorization that is logically tied to an earlier one through a stored-credential agreement. The classic example is a subscription: the customer’s first payment is a CIT where they authorize the merchant to charge the card on a recurring schedule. Every subsequent renewal is a separate MIT authorization, but it is economically related to that initial CIT.
For these transactions, the merchant has to do the work of storing the TLID from the original CIT and submitting it with every subsequent MIT. This is the integration burden the October 23, 2026 mandate creates.
The same pattern applies to:
In every case, the TLID retained from the original CIT travels with every subsequent MIT, creating a verifiable chain at the network level.
The strategic value of TLID becomes visible in four specific use cases that affect day-to-day merchant operations.
When a cardholder raises a dispute on a subscription renewal claiming they did not authorize the recurring charge, the merchant traditionally has to assemble evidence linking that MIT to the original CIT where consent was given. This typically involves PAN matching, timestamp correlation, system trace IDs, and sometimes manual investigation across multiple systems.
With TLID, the chain is verifiable at the network level. The TLID on the disputed MIT traces directly back to the TLID on the original CIT, providing scheme-generated proof of the stored-credential relationship. Disputes that previously required hours of investigation can be resolved in minutes, and the success rate on representment typically improves because the evidence is cleaner and more defensible.
Every lifecycle event for a transaction shares the same TLID. The original authorization, the capture, any partial refunds, and any chargebacks all carry the same identifier. This makes reconciliation between authorization and clearing records significantly faster, and makes it trivial to assemble a complete transaction timeline for any specific charge.
For finance teams doing month-end close, the time savings are meaningful. For customer support teams investigating duplicate-charge complaints or refund timing questions, the lookup becomes a single-query operation rather than a multi-system investigation.
When the original CIT was submitted with Strong Customer Authentication (SCA) data, which is common for European transactions under PSD2 and similar regulations in Japan and other jurisdictions, that authentication context can carry forward to subsequent MITs through the TLID. Issuers see the chain of consent and authentication, which typically improves authorization rates on the renewals.
This matters most for subscription businesses operating in SCA-regulated markets, where MIT authorization rates can be 5-10 percentage points higher when the chain to the authenticated CIT is visible.
For merchants using multiple PSPs, the TLID enables a critical capability: an MIT can be processed through one PSP while referencing a CIT that was processed through a different PSP. Because the TLID is scheme-generated rather than acquirer-generated, it remains valid across acquirer boundaries.
This is the angle most coverage of TLID misses, and it matters specifically for enterprise merchants running orchestration-based architectures. Routing a subscription renewal through whichever acquirer is currently performing best, even if the original authorization went through a different one, requires the underlying chain-of-consent reference to be portable. The Trace ID was not. The TLID is.
For a deeper view of how multi-PSP routing benefits subscription and card-on-file businesses, see Gr4vy’s guide on intelligent payment routing.
The good news is that TLID implementation is operationally simple. Most merchants can complete the work in a week or two of engineering effort. The checklist:
1. Confirm your acquirer is passing TLID. All major acquirers (Stripe, Adyen, Worldpay, Checkout.com, Braintree, and others) have published their TLID handling specifications. Verify with your account manager that TLIDs are appearing in authorization responses for your Mastercard transactions.
2. Update your database schema. Add a field to your customer payment profile records that can store a 22-character alphanumeric string. The field can be a standard VARCHAR column; no encryption or PCI-compliant storage is required.
3. Capture TLID on every CIT authorization response. When you process the initial Customer-Initiated Transaction (typically the first payment with a new stored credential), parse the TLID from the authorization response and store it alongside the customer’s token or card reference.
4. Submit TLID with every economically-related MIT. When processing subscription renewals, installments, BNPL charges, or any other MIT against a stored credential, include the previously-stored TLID in the authorization request.
5. Plan for older stored credentials. Cards stored before your integration captured TLIDs will not have one. For these, the standard approach is to submit a new MIT, receive the TLID back from Mastercard via your acquirer in the authorization response, store it, and use it for all future transactions. Mastercard recommends using an undisputed MIT from at least three months prior as the basis for the new TLID lineage.
6. Continue passing Trace ID in parallel. Mastercard has not yet sunset the Trace ID, and merchants should plan to store and pass both Trace ID and TLID for the foreseeable future. The Trace ID sunset is expected eventually but no date has been announced.
7. Test conformance with your acquirer. Most major acquirers offer test environments where merchants can validate their TLID handling before going live. Run end-to-end tests covering CIT capture, MIT submission with TLID, and dispute flows before the October 2026 deadline.
Acquirers that include orchestration platforms typically handle most of this transparently. For merchants using Gr4vy, the TLID capture, storage, and propagation across all connected PSPs and acquirers is handled automatically through the platform.
For single-PSP merchants, TLID implementation is straightforward: the PSP returns the TLID, the merchant stores it, the merchant passes it back on MITs. The flow lives inside one provider relationship.
For multi-PSP merchants, the picture is more complex. A TLID generated through Acquirer A on the original CIT needs to be available to Acquirer B if a subsequent MIT is routed through it. The TLID itself is scheme-generated and globally valid, but the merchant’s integration has to make it available across all the PSP connections that might handle related transactions.
Three implementation patterns exist for this:
Pattern 1: Single-PSP-per-customer. The merchant routes every transaction for a given customer through the same PSP. The TLID lives inside that PSP’s records and is reused on MITs. This works but defeats the purpose of multi-PSP routing, because the merchant cannot dynamically route a renewal through whichever PSP is currently performing best.
Pattern 2: Merchant-managed TLID storage. The merchant stores the TLID in their own database, separate from any single PSP. When routing an MIT through any PSP, the merchant includes the stored TLID in the request. This works but requires the merchant to build the storage and propagation logic themselves, and to ensure every PSP integration handles the field correctly.
Pattern 3: Orchestration-managed TLID. The orchestration platform captures the TLID from whichever PSP processes the original CIT, stores it in a provider-agnostic vault, and automatically includes it in subsequent MITs regardless of which PSP routes them. The merchant’s application code does not need to handle TLID directly; the orchestration platform manages the full lifecycle.
The third pattern is the cleanest architectural fit for multi-PSP merchants and is the model Gr4vy’s platform implements. The TLID is captured at the orchestration layer when the original CIT is processed, stored alongside the merchant token, and automatically propagated to subsequent MITs across any connected PSP. The merchant does not need to manage TLID storage in their own database or update their application code to handle the field.
This becomes especially important for merchants planning migrations between PSPs or adding additional providers, because the TLID needs to remain valid across the migration. Acquirer-managed TLIDs that live inside a single PSP’s records create the same portability problem as PSP-locked tokens. Orchestration-managed TLIDs do not.
A common question is how TLID relates to network tokenization (Visa Token Service, Mastercard Digital Enablement Service). The short answer: they are complementary technologies that solve different problems.
Network tokens replace the stored PAN with a network-issued credential. They handle credential security and lifecycle (automatic updates when cards are reissued). They do not, by themselves, provide a way to link related transactions across the payment lifecycle.
TLIDs provide the lifecycle linkage. They identify which transactions are related to which, and which MITs flow from which CITs. They do not change how credentials are stored.
For a card-on-file or subscription transaction processed through Mastercard, the modern best-practice stack uses both: a network token to represent the credential, and a TLID to identify the relationship between transactions. For more on tokenization patterns, see Gr4vy’s guide on network tokenization vs PSP tokenization.
A handful of patterns separate smooth TLID rollouts from troubled ones:
Underestimating the schema work. While the TLID itself is just a 22-character string, the work of updating customer payment profile records, propagating the field through application code, and updating analytics and reporting systems can extend across multiple teams. The integration is technically simple but organizationally non-trivial.
Treating TLID as PCI-sensitive. Some teams default to storing any payment-related field in their PCI vault. TLIDs are not PCI-sensitive and storing them in the vault adds operational overhead without any compliance benefit. Standard database storage alongside customer profiles is the correct approach.
Skipping the back-migration plan for legacy credentials. Cards stored before TLID capture went live will not have one, and merchants need a plan for generating TLIDs for these credentials. The standard approach (issue a new MIT, capture the returned TLID, use it going forward) works but should be scheduled before the October 2026 deadline rather than reactively after.
Locking TLID storage to a single PSP. Storing the TLID inside one PSP’s records rather than at the orchestration or merchant layer creates exactly the portability problem TLID was designed to solve. Multi-PSP merchants should store TLIDs in their own database or in an orchestration platform that propagates them across all connected PSPs.
Confusing the 22-character spec with 36-character UUID. Several published articles on TLID report a 36-character length, likely confusing the TLID with standard UUID formatting. The Mastercard specification is 22 characters. Building database schemas around the wrong length creates avoidable rework.
Waiting until October 2026 to start. The integration is straightforward but it is not zero-effort. Schema changes, application updates, conformance testing with acquirers, and back-migration of legacy credentials all take time. Most merchants who start in the second half of 2026 will be cutting it close to the October 23 deadline.
The TLID is a 22-character alphanumeric identifier that Mastercard automatically generates for every card authorization. It links the original cardholder-initiated transaction (CIT) to all related lifecycle messages (captures, refunds, chargebacks) and all economically-related merchant-initiated transactions (subscription renewals, installments, unscheduled MITs) under the same stored-credential agreement.
The rollout happens in four phases: October 17, 2025 covered lifecycle transactions and is already in effect. June 2, 2026 begins TLID generation for economically-related transactions and requires acquirers to ensure merchants retain TLIDs from CITs. October 23, 2026 requires merchants to actively include the stored TLID in every MIT authorization request. January 31, 2027 begins formal compliance assessments and non-compliance fees.
The Trace ID (also called scheme transaction ID) is generated by the acquirer and can be duplicated across acquirer boundaries. The TLID is generated by Mastercard at the network level and is globally unique. TLID is intended to eventually replace Trace ID, but Mastercard has not yet announced a sunset date for the Trace ID, and merchants should plan to store and pass both for the foreseeable future.
The TLID functions like a unique identifier but uses a 22-character alphanumeric format (including hyphens and underscores) rather than the canonical 36-character hyphenated UUID format. Several published articles have reported a 36-character length, which appears to be a confusion with standard UUID formatting. The official specification, as reflected in major PSP documentation, is 22 characters.
The TLID is not PCI-sensitive and can be stored alongside customer payment profiles in standard database tables. Most implementations add a VARCHAR(22) field to the table that holds customer card references. No encryption or vault-grade storage is required.
In the near term, Mastercard is not declining transactions for missing TLID. However, Mastercard has signaled it may flag data integrity issues, and non-compliance fees begin in January 2027. Issuers may eventually decline MITs that do not carry the expected TLID. The safest interpretation of the mandate is that TLID submission becomes operationally required, with both compliance fees and downstream authorization rate risks for merchants who skip it.
No. TLID is a Mastercard-specific identifier and applies to all Mastercard acceptance brands including Maestro. Visa, American Express, and Discover have not announced similar identifiers as of mid-2026. Each network maintains its own transaction reference scheme.
If you operate with a single PSP, that PSP typically handles TLID storage and propagation transparently. If you operate with multiple PSPs, you have two practical options: store TLIDs in your own database and pass them through each PSP integration, or use an orchestration platform that captures and propagates TLIDs across all connected PSPs automatically.
For credentials stored before your integration started capturing TLIDs, the standard approach is to submit a new merchant-initiated transaction against the stored credential, receive the TLID back from Mastercard via your acquirer, store it, and use it on all subsequent transactions. Mastercard recommends using an undisputed MIT from at least three months prior as the basis for the new TLID lineage.
No. TLID and network tokens serve different purposes. Network tokens (from Visa Token Service, Mastercard Digital Enablement Service, and equivalents) replace the stored PAN with a network-issued credential that handles security and automatic lifecycle updates. TLID is a separate identifier that links related transactions across the lifecycle. The modern stack uses both: network tokens for credential representation and TLIDs for transaction linkage.
Yes. The TLID generated at the original authorization is included in all lifecycle messages, including captures, refunds, voids, and chargebacks. Merchants do not need to take additional action for these, because the TLID propagation happens automatically in the lifecycle phase that became active in October 2025. For refund authorizations specifically, Mastercard requires the TLID to be provided in the authorization response in clearing.
For most merchants, the engineering work takes a week or less. The bigger time investments are in cross-team coordination (database schema changes, application updates, analytics updates), conformance testing with acquirers, and the back-migration plan for legacy stored credentials. Most enterprise merchants should plan for 4-8 weeks of total project time from kickoff to production-ready.
Gr4vy captures the TLID from the original CIT authorization response automatically, stores it in the provider-agnostic vault alongside the merchant token, and propagates it to subsequent MITs across any connected PSP. Merchants using Gr4vy do not need to update their application code, database schemas, or PSP integrations individually to handle TLID, because the orchestration platform manages the full lifecycle. This is especially valuable for multi-PSP merchants whose MITs may be routed through a different acquirer than the original CIT.
The TLID mandate is one of the cleaner scheme changes in recent memory: low integration complexity, real operational benefits, and a meaningful improvement in how subscription and card-on-file transactions are tracked across the network. The work is straightforward, but the timeline matters. Merchants starting in mid-2026 will be comfortable; merchants starting in October 2026 will be at risk of missing the deadline.
For merchants with single-PSP setups, the practical first step is confirming with your account manager that TLID handling is configured in your acquirer’s integration and updating your customer profile schema to store the field. For merchants with multi-PSP setups, the question is whether to build TLID propagation across each PSP integration individually or to let an orchestration platform handle it centrally.
Gr4vy’s cloud-native payment orchestration platform manages TLID capture, storage, and propagation automatically across more than 400 PSPs and payment methods. The TLID flows from the original CIT through every subsequent MIT regardless of which acquirer processes the renewal, preserving the chain of consent that Mastercard’s mandate is designed to enforce.
If you’re evaluating how to handle the TLID mandate across your existing PSP relationships or want a walkthrough of how Gr4vy implements TLID propagation in a multi-PSP setup, contact our team for a stack review and integration plan tailored to your current architecture.
Peak moments don’t break systems by accident. They expose the limits that were always there.…
Last updated May 21st 2026 Around half of online merchants now use more than one…
The complexity of managing digital transactions has grown exponentially as businesses expand their reach globally.…
The choice between hosted checkout and API checkout shapes how a payment stack handles every…
Card payments don’t fail randomly. They fail because the data behind them becomes outdated. Cards…
A payment workflow is a configurable set of rules that controls how each transaction is…