---
title: "Visa Tokenized Credential on File (TCOF)"
slug: "visa-tokenized-credential-on-file-tcof"
updated: 2026-07-08T19:34:27Z
published: 2026-07-08T19:34:27Z
canonical: "www.documentation.paynetics.digital/visa-tokenized-credential-on-file-tcof"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://www.documentation.paynetics.digital/llms.txt
> Use this file to discover all available pages before exploring further.

# Visa Tokenized Credential on File (TCOF)

## Overview

This document describes the integration of **Visa Tokenized Credential on File (TCOF)** transactions with the Paynetics Acquiring platform.

It explains the supported functionality, onboarding process, API integration, transaction flows, request parameters and responsibilities when processing Visa network token transactions through the Paynetics Acquiring API.

Unlike Mastercard SCOF, Paynetics **is not the Token Requestor**. The PSP remains responsible for merchant integration, token provisioning, token storage and token lifecycle management. Paynetics acts solely as the acquiring processor and forwards transactions to Worldline after validating and mapping the required Visa TCOF fields.

## Product Description

**Overview**

Visa Tokenized Credential on File (TCOF) allows merchants to process stored credential transactions using **Visa Network Tokens** instead of the original PAN.

Network Tokens are issued and lifecycle-managed through the Visa Token Service (VTS), providing improved security, authorization performance and payment continuity.

The PSP is responsible for:

- Merchant checkout
- Visa token provisioning
- Token vault
- Token lifecycle
- Token decryption

Paynetics is responsible for:

- Validating Visa TCOF transactions
- Processing transactions through the Acquiring API
- Mappings to processors
- Forwarding transactions for authorization
- Settlement and reporting

**In Scope**

- Visa Tokenized Credential on File (TCOF)
- Visa Stored Credential Framework
- Customer Initiated Transactions (CIT)
- Merchant Initiated Transactions (MIT)
- Purchase transactions
- Pre-authorizations
- EMV 3DS authenticated transactions
- Processing through Worldline Current Processing Platform (GICC)
- Processing through Worldline New Processing Platform

**Out of Scope**

- Mastercard SCOF
- Token Requestor services
- Visa Token Service enrolment
- Token provisioning
- Token lifecycle management
- Token vault
- Token decryption
- Merchant checkout implementation
- Click to Pay enrolment
- Wallet implementation

**Currency and Country Coverage**

**Supported settlement currencies**

- EUR
- GBP

**Supported processing currencies**

All currencies supported by Paynetics Acquiring.

**Supported countries**

- European Union
- EEA
- United Kingdom

## Merchant Onboarding

Visa TCOF does not require any additional merchant onboarding beyond the standard acquiring onboarding process.

**Supported onboarding methods**

- Automated Merchant Onboarding API
- Manual Merchant Onboarding

Once approved, merchants may immediately process Visa Tokenized Credential on File transactions.

**Important:** Paynetics does not participate in Visa Token Service onboarding and does not manage token provisioning. These activities remain entirely within the PSP domain.

**Onboarding via API**

The recommended onboarding method is the Merchant Onboarding API.

During underwriting Paynetics may request additional merchant information if required.

**Manual Onboarding**

Merchants may also be onboarded manually by submitting onboarding documentation through the secure document portal.

After uploading the documentation, notify: **underwriting@paynetics.digital**

Manual onboarding capacity is limited.

**Fees Setup**

No changes from the standard acquiring process.

**Payouts**

No changes.

**Reporting and Reconciliation**

No changes.

Visa TCOF transactions appear in:

- Acquiring API
- Daily reconciliation files
- Standard reporting

**Profit Share**

Standard acquiring commercial model applies.

## Technical Integration

After signing the acquiring agreement Paynetics provides:

- Sandbox
- API credentials
- Integration documentation
- Test scenarios

After successful certification:

- Production API key
- Production endpoint

## **Transaction Flow**

1. Customer selects previously stored payment credential.
2. PSP retrieves Visa Network Token.
3. PSP decrypts token (if required).
4. PSP submits transaction to Paynetics Acquiring API.
5. Paynetics validates mandatory Visa TCOF fields.
6. Paynetics maps Visa fields into the corresponding Worldline GICC fields (current platform) or Worldline New Platform fields, depending on the processing route.
7. Worldline authorizes the transaction through Visa.
8. Authorization response is returned to Paynetics.
9. Paynetics returns the response to the PSP.

## **Supported Endpoints**

- POST /v1/purchase
- POST /v1/pre-authorization

Pre-authorizations must always be completed by POST /v1/capture.

## Visa TCOF Specific Request Parameters

The following parameters are specific to Visa Tokenized Credential-on-File (TCOF) transactions. All remaining request parameters follow the standard Purchase and Pre-Authorization API specification.

| **Parameter** | **Description** | **Data Type** | **Required** |
| --- | --- | --- | --- |
| card_number | Visa Network Token (used in place of the PAN) | String, 12–19 digits, Luhn-validated | Yes |
| card_expiration_month | Network Token expiry month | String ("01"–"12") | Yes |
| card_expiration_year | Network Token expiry year | String (YY) | Yes |
| cardholder_name | Cardholder name | String, 2–45 characters | Yes |
| recurring_type | Stored-credential transaction type | Integer (1 digit) | No — defaults to 0 |
| initial_transaction | Reference to the original stored-credential transaction; links subsequent usage back to the stored credential | String | Required for recurring_type 2 / 5 (subsequent MIT / UCOF) |
| pos_entry_mode | Credential-on-file POS entry mode. For Visa TCOF, GICC DE 22.1 is set automatically to 10 (credential on file) based on wallet_identifier = network. | String (2 digits) | No — set automatically |
| wallet_payment.wallet_identifier | Must always be network for Visa TCOF | String (enumeration) | Yes |
| wallet_payment.digital_payment_cryptogram | Visa Network Token Cryptogram (TAVV) | String, exactly 28 characters | Required for recurring_type 0 / null / 1 / 3 (authenticated CIT); optional for 2 / 5 (applicable MIT) |
| cavv | Cardholder Authentication Verification Value | String, exactly 28 characters | Required for authenticated CIT; if present, eci and version become required |
| eci | Electronic Commerce Indicator (Visa: 05 / 06 / 07) | String (2 digits) | Required when cavv is present |
| version | EMV 3DS Version (1 or 2) | Integer | Required when cavv is present |
| directory_transaction_id | EMV 3DS Directory Server Transaction ID | String, 36-character UUID | Required when version = 2 |

**Supported Recurring Types**

| **recurring_type** | **Description** |
| --- | --- |
| 0 / null | Standard Customer Initiated Transaction (default) |
| 1 | Initial stored credential transaction |
| 2 | Merchant Initiated Transaction (MIT) — subsequent recurring |
| 3 | Subsequent Customer Initiated Transaction |
| 5 | Unscheduled Credential-on-File (UCOF) |

**Supported ECI Values**

| **ECI** | **Description** |
| --- | --- |
| 05 | Fully authenticated (EMV 3DS successful) |
| 06 | Authentication attempted |
| 07 | Non-authenticated transaction or Merchant Initiated Transaction |

**Example Purchase Request**

{

"merchant": "df1f946a-8b03-4a21-8eb7-dab86a77a027",

"reference": "Order-1001",

"amount": 50,

"currency": "EUR",

"card_number": "4895370012345678",

"card_expiration_month": "12",

"card_expiration_year": "28",

"cardholder_name": "John Smith",

"recurring_type": 3,

"wallet_payment": {

"wallet_identifier": "network",

"digital_payment_cryptogram": "AlhlvxmN2ZKuAAESNFZ4GoABAAAA"

},

"cavv": "jJ81HADVRtXfCBATEp01CJUAAAAA",

"eci": "05",

"version": 2,

"directory_transaction_id": "7b03c772-dba0-4818-872e-849d63a5a659"

}

**Example Response**

The response follows the standard Paynetics Purchase response format. No TCOF-specific fields are returned beyond the standard response body.

**Responsibilities**

| **PSP** | **Paynetics** |
| --- | --- |
| Merchant integration | Acquiring API |
| Merchant checkout | Validation |
| Visa Token Service | Worldline mapping |
| Token provisioning | Authorization |
| Token vault | Settlement |
| Token lifecycle | Reporting |
| Token decryption | Support |

## **3DS Transactions**

Visa TCOF fully supports EMV 3DS.

For authenticated Customer Initiated Transactions, the PSP must provide:

- CAVV (exactly 28 characters)
- ECI
- EMV 3DS Version
- Directory Transaction ID (when version = 2)
- Digital Payment Cryptogram (TAVV, exactly 28 characters)

Paynetics validates these values and maps them to the corresponding Worldline fields before forwarding the authorization.

## **Merchant Initiated Transactions (MIT)**

Merchant Initiated Transactions are supported for subsequent recurring and Unscheduled Credential-on-File (UCOF) transactions.

For MIT/UCOF (recurring_type 2 or 5), the PSP must supply the initial_transaction field, linking the subsequent usage back to the original stored-credential transaction.

The digital_payment_cryptogram is **optional** for MIT/UCOF use cases.

The PSP remains responsible for maintaining the relationship with the original customer consent and stored credential. Paynetics processes these transactions according to the Visa Stored Credential Framework.

## **Responsibilities Matrix**

| **Activity** | **PSP** | **Paynetics** |
| --- | --- | --- |
| Merchant integration | ✔ |  |
| Merchant checkout | ✔ |  |
| Token Requestor | ✔ |  |
| Token provisioning | ✔ |  |
| Token lifecycle | ✔ |  |
| Token vault | ✔ |  |
| Token decryption | ✔ |  |
| Visa Stored Credential signalling | ✔ | ✔ |
| Acquiring processing |  | ✔ |
| Mapping to Worldline |  | ✔ |
| Authorization |  | ✔ |
| Settlement |  | ✔ |
| Reporting |  | ✔ |