Skip to main content

Introduction

Mea Token Platform I-TSP or Issuer-To-Token Service Provider is a core component required by Issuer to enable the digitization (tokenization) of his cards. This guide describes the issuer integration with the MTP I-TSP. Terms such as tokenization, payment tokenization and digitization must be considered as equivalent within the scope of this guide.

I-TSP Introduction

MTP I-TSP serves and maintains the connection between the Issuer Card Management and/or Processing Systems to the Token Service Provider systems of the payment network. MTP I-TSP provides a single endpoint integration to the multiple TPS’s. Issuer that are willing to implement the card digitization must integrate with the MTP I-TSP:

  • Pre-Digitization API v2 - used to handle token provisioning process with extra layers which take care of most complexity on behalf of issuer.

  • Pre-Digitization API – used to handle the token provisioning process. Option for Issuers which want to handle rule engine complexity themselves.

  • Customer Service API – intended for issuer initiated token management.

This is required to implement both API’s of MTP I-TSP. MTP I-TSP is integrated with multiple token service providers as VTS, MDES and AmEx TS. Issuer single integration with the MTP I-TSP provides technical integration and availability of multiple token service providers. MTP I-TSP supports the recent payment network requirements with focus on minimal integration effort for the issuer. Platform is an out-of-the-box solution that is the multi-tenant cloud-based platform built for scalability, reliability and security of payment tokenization services enablement for issuers.

Pre-digitization v2 API intended to handle the token provisioning process to the consumer device or merchant e-commerce token. This API has mandatory and conditional endpoints depending on I-TSP project scope. The endpoints implemented are the same across all payment networks.

Pre-Digization API intended to handle the token provisioning process to the consumer device or merchant e-commerce token. This API has mandatory and conditional endpoints depending on the I-TSP project scope with payment network.

Customer Service API provides issuers the opportunity to retrieve the information about tokens and manage it lifecycle. This API must be also utilized for automated token lifecycle management what is a requirement of certain third-party wallets(e.g. Apple Pay, Google Pay etc.) or payment networks.

Concepts and responsibilities​

Token Requestor - One of the common roles in payment tokenization ecosystems. Token Requestor or TR-TSP that stands for Token Requestor-To-Token Service Provider is an entity that can request payment tokens and/or use it for payments. All Token Requestors are enrolled, managed and certified by the Token Service Provider. Token Requestor examples could be third-party wallets(e.g. Apple Pay or Google Pay), merchants, e-commerce programs or other payment service providers.

I-TSP - Issuer-to-Token Service Provider is the bi-directional integration between Issuer and Token Service Provider. This integration is the enablement of payment tokenization for issuers.

Payment System - Transaction processing platform of the payment network, e.g. VisaNet for Visa.

Issuing Processor - Processor integrated with the payment system for issuing transaction processing. Issuing processors are required to ignore or accept token related data in the financial authorization or clearing messages to support and participate in the payment tokenization ecosystem. Specific requirements for issuing processor must be clarified with payment network are not in scope of this guide.

Token Types​

There is no unified approach for the token types between various token service providers. MTP I-TSP consolidates token types from different token service providers into the following:

  • CLOUD - Cloud-Based Payments or can be also referred as HCE token type that stands for Host Card Emulation. This token type is used for contactless payments. Contactless payments security and behavior depends on the Limited or Single usage keys periodically replenished with token service providers that require online connection. Limited amount of authorizations can be performed offline.
  • EMBEDDED_SE - Used for contactless payments. Contactless payments security and behavior depends on the embedded secure element where cryptographic keys are stored and securely used during the authorization processing.
  • STATIC - Used in Card-Not-Present authorization. This type of token is provisioned to the payment service providers, merchants or e-commerce enablers as Card-On-File or other E-commerce token types.