> For the complete documentation index, see [llms.txt](https://doc.ecomm.api.tietoevry.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.ecomm.api.tietoevry.com/features/merchant-tokenization.md).

# Merchant tokenization

### Overview

The Tieto E-Commerce Payment Gateway supports Network Tokenization services provided by Visa and Mastercard, including:

* Visa Token Service (VTS) — Visa's underlying network tokenization platform.
* Token Management Service (TMS) by Visa — Visa's productized token vault and lifecycle management layer, providing a unified interface for provisioning, storing, and orchestrating network tokens.
* Mastercard Digital Enablement Service (MDES) — Mastercard's network tokenization platform.
* Secure Card on File (SCOF) by Mastercard — the MDES-based network tokenization solution optimized for stored-credential e-commerce use cases.

Network Tokenization replaces the cardholder's Primary Account Number (PAN) with a secure, network-issued token (also referred to as a DPAN), which is used in place of the underlying card credentials throughout the payment lifecycle. Tieto enables merchants to obtain, store, and transact with network tokens for both Customer-Initiated Transactions (CIT) and Merchant-Initiated Transactions (MIT) — covering stored credentials (Card-on-File), recurring billing, subscriptions, installments, and unscheduled credential-on-file use cases.

### How It Works

1. The merchant — or Tieto acting as an On-Behalf-Of Token Requestor — submits the PAN to VTS/TMS or MDES/SCOF.
2. The card network provisions a network token (token PAN + expiry) and returns it to the merchant via Tieto.
3. For each transaction, Tieto submits the network token, together with a network-generated cryptogram (Visa TAVV / Mastercard UCAF) when required, to the acquirer.
4. The card network resolves the token back to the underlying PAN and routes the transaction to the issuer for authorization.
5. The card network maintains the token's lifecycle — including automatic updates when the underlying card is reissued, replaced, or has its expiry changed — so stored credentials remain valid without merchant intervention.

### Key Benefits

* **Enhanced security:** The real PAN never enters or is stored within the merchant or gateway environment. Each transaction is further protected by a unique, single-use cryptogram issued by the network.
* **Reduced PCI DSS scope:** Because sensitive cardholder data is replaced by a non-sensitive token, merchant systems handling only network tokens fall under a reduced PCI DSS compliance footprint.
* **Higher authorization rates:** Issuers approve network-tokenized transactions at materially higher rates than equivalent PAN-based transactions, since token credentials are continuously kept current and carry an additional trust signal from the network.
* **Lower interchange fees:** Both Visa and Mastercard apply preferential interchange rates to qualifying card-not-present transactions presented as network tokens.
* **Automatic credential lifecycle management:** Lost, stolen, expired, or reissued cards are updated by the network in real time, eliminating involuntary churn on recurring and stored-credential transactions.
* **SCA / PSD2 alignment:** A valid network token cryptogram (TAVV) qualifies as Strong Customer Authentication in the EEA and UK, reducing checkout friction for eligible flows.
* **Improved customer experience:** Tokens carry card metadata (brand, type, last four, card art) that merchants can surface in checkout and account management interfaces.

### Supported Use Cases

| Transaction type                            | Description                                                                                          |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| CIT — first payment with credential storage | Cardholder consents to store credentials; initial CIT is authenticated (typically via 3-D Secure 2). |
| CIT — subsequent cardholder-present payment | Returning customer uses a stored network token at checkout.                                          |
| MIT — recurring                             | Subscriptions and fixed-schedule billing.                                                            |
| MIT — installments                          | Fixed purchase split into scheduled payments.                                                        |
| MIT — unscheduled Card-on-File              | Top-ups, automatic reloads, usage-based charges.                                                     |
| MIT — industry-practice                     | Delayed charges, no-shows, incremental authorizations, resubmissions, reauthorizations.              |

### Summary

Network Tokenization is a foundational capability of the Tieto E-Commerce Payment Gateway. By replacing sensitive card credentials with network-issued tokens via Visa's VTS/TMS and Mastercard's MDES/SCOF, and leveraging the card schemes' lifecycle management, authentication, and risk infrastructure, merchants achieve stronger security, lower processing costs, higher approval rates, and a more resilient stored-credential experience across CIT and MIT use cases.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://doc.ecomm.api.tietoevry.com/features/merchant-tokenization.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.