--- title: "Visa Tokenized Card-on-File" slug: "visa-tokenized-card-on-file-integration-guidе" updated: 2026-07-08T19:33:52Z published: 2026-07-08T19:33:52Z canonical: "www.documentation.paynetics.digital/visa-tokenized-card-on-file-integration-guidе" --- > ## 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 Card-on-File ## Overview This document covers the functionalities and constraints of the Tokenized Card-on-File (TCoF)enablement for the Paynetics Acquiring product. It provides comprehensive information on how to integrate and operate it. ## Product Description TCoF enables merchants to store customer card details securely for future transactions, with proper indicators to comply with Visa regulations. **Scope:** - Tokenized Card-on-File (TCoF) with Visa - Secure Customer Authentication (SCA) compliance. **Out of Scope:** - Non-card-based digital wallets. - PayPal or alternative e-wallet services. Visa Tokenized Card-on-File (TCoF) allows merchants, PSPs and commerce platforms to tokenize PANs (Primary Account Numbers) entered by consumers or existing PANs held on file, replacing each PAN with a unique token (subject to issuer participation). These tokens can be used for e‑commerce and in-app transactions in the same way as PANs. ## Currency and country coverage The supported settlement currencies are **EUR, GBP, and BGN.** Important note is that the currencies that you will choose. The processing currencies are all currencies supported by Paynetics. The supported countries are EU27, Iceland, Liechtenstein, Norway, or the UK. ## Merchant Onboarding There are no additional onboarding requirements for merchants using SCOF and Network Tokenization beyond the standard Paynetics onboarding process: 1. **Automated Merchant Onboarding** – Merchants can onboard through the Paynetics onboarding API. 2. **Manual Onboarding** – For cases where automation is not feasible, manual setup is required. Merchants need to submit onboarding documents via a secure shared portal and notify Paynetics at underwriting@paynetics.digital. Once approved, merchants can start accepting TCoF and Tokenized payments. *Note: Paynetics does not manage cardholder TCoF enrollment; this is handled by Visa.* ### Onboarding via API The recommended way of onboarding merchants is via API. For more information on the process During application processing, Paynetics may contact you or the merchant to request more information. ### Manual onboarding To onboard merchants manually you will be provided with dedicated access to a secure shared storage where you must upload the filled in merchant application form together with the required documents. You must notify us by email to underwriting@paynetics.digital for your form to be reviewed. manual onboarding has limited capacity, and it’s not recommended. Paynetics can only process 10-15 applications a month under the manual flow. ## Fees set-up The fees setup follows the current procedure with no specifics. ## Payouts The payouts follow the current procedure with no specifics. ## Reporting and reconciliation You can track all transactions via API real-time. In the end of the day, a reconciliation report is sent with all transactions from the previous day via SFTP. ## Profit share Your profit share is included in the acquiring monthly commission report file. The file is sent up to the 10th day of the month. Upon your approval of the commission file, you must send us an invoice. The invoice will be duly paid as per our contractual agreement terms. ## Technical Integration Once you have signed agreement for acquiring services you will be provided with access to your Sandbox instance where you can carry on the integration. Once you have integrated the solution, you will run a set of tests validated by Paynetics and you will be ready to move to production. Migrating to production is a matter of receiving and configuring a new API key and changing the API root path. **Execute Click to Pay payment** To execute a payment, use the POST /v1/purchase or POST/v1/pre-authorization endpoint. No difference in the request parameters sent in the Purchase and Pre-authorization. The Pre-authorization request must always be followed up by capture request POST/v1/capture, otherwise the transaction will not be cleared. **Specific Request Parameters** | **card_number** | The network card token provided by token requestor | | --- | --- | | Data Type | String, length 16 | | Required | Yes | | **card_expiration_month** | The month on which the network token expires | | Data Type | String, “01” to “12” | | Required | Yes | | **card_expiration_year** | The year on which the network token expires | | Data Type | String, min current year | | Required | Yes | | **cardholder_name** | The name of the cardholder | | Data Type | String, max 27 chars | | Required | Yes | | **recurring_type** | 3 for CIT; 2 for MIT | | Data Type | 1 digit | | Required | Yes | | **pos_entry_mode** | 10 | | Data Type | 2 digits | | Required | Yes | | **digital_payment_cryptogram** | The parameter supports: - Token Authentication Verification Value TAVV - cryptogram data as per Visa VIP Field 126.8 | | Data Type | String | | Required | Yes | **Request:** **Example Request** ```json {     "reference": "dsds",     "merchant": "7cb0db766c86cdda3939871adfece952",     "amount": 1,     "currency": "EUR",     "card_number": "4111111111111111",     "card_expiration_month": "11",     "card_expiration_year": "25",    "pos_entry_mode": "10",    "recurring_type": "3",     "cardholder_name": "XXXXXX",     "wallet_payment": {         "digital_payment_cryptogram": "stringstringstringstringstri",     } } ``` **Response:** **Example Response** ```json {   "code": 0,   "data": {     "card_number": "411111XXXXXX1111",     "processing_code": "000000",     "amount": 1,     "stan": "180801",     "local_time": "145916",     "local_date": "0813",     "auth_code": "361156",     "response_code": "00",     "card_acceptor_terminal_id": "16P17777",     "card_acceptor_identification_code": "1602071111",     "currency": "978",     "transaction": "9310bc2b-171b-47f7-8d2b-d97cdfa546d1",     "cvv_status": " 06",     "ccti_id": "80",     "transaction_stamp": "0000007761232611201A",     "card": "39da5b38-15f3-4371-8a9b-09f138437b4e",     "original_network_response_code": "00"   } } ``` **3D secured transactions** **Mastercard:** Required for CIT; Optional for MIT. **3D Secure Request Parameters** | **cavv** | The Parameter supports: - CAVV (Cardholder Authentication Verification Value), applicable for Visa acceptance. | | --- | --- | | Data Type | String | | Required | Yes | | **eci** | The parameter supports the Electronic Commerce Indicator (ECI) which indicates the level of security applied. Supported values: **Visa** - 05: 3D Secure (3DS) authentication successful; transaction is secured by 3DS. - 06: authentication was attempted but was not or could not be completed. - 07: 3DS authentication either failed or could not be attempted. | | Data Type | String, maxLength: 2 | | Required | Yes | | **Version** | 3D Secure Version Number | | Data Type | Integer, value=2 | | Required | Optional | | **directory_transaction_id** | 3D Secure Directory Server Transaction ID delivered during the 3D Secure 2.0 authentication process by the directory server | | Data Type | String | | Required | Yes, if 3D Secure Version Number has been initiated. | **Request:** ```json {     "reference": "dsds",     "merchant": "7cb0db766c86cdda3939871adfece952",     "amount": 1,     "currency": "EUR",     "card_number": "4111111111111111",     "card_expiration_month": "11",     "card_expiration_year": "25",    "pos_entry_mode": "10",    "recurring_type": "3",     "cardholder_name": "XXXXXX",     "cavv": "AJkCCReZIncEQFcQBZkiAAAAAAA=",     "eci": "05",     "version": 2,     "directory_transaction_id": "7b03c772-dba0-4818-872e-849d63a5a659",     "wallet_payment": {         "digital_payment_cryptogram": " stringstringstringstringstri",         "remote_commerce_acceptor_identifier": "string"     } } ``` **Response:** **Example Response** ```json {   "code": 0,   "data": {     "card_number": "411111XXXXXX1111",     "processing_code": "000000",     "amount": 1,     "stan": "180801",     "local_time": "145916",     "local_date": "0813",     "auth_code": "361156",     "response_code": "00",     "card_acceptor_terminal_id": "16P17777",     "card_acceptor_identification_code": "1602071111",     "currency": "978",     "transaction": "9310bc2b-171b-47f7-8d2b-d97cdfa546d1",     "cvv_status": "06",     "ccti_id": "80",     "transaction_stamp": "0000007761232611201A",     "card": "39da5b38-15f3-4371-8a9b-09f138437b4e",     "original_network_response_code": "00"   } } ``` **Note:** The integration guide is applicable to all merchants integrated with Paynetics Acquiring API. **The guide is not applicable to merchants integrated with ACI Gateway.** The business of processing card payments on behalf of merchants. An acquirer receives authorisation requests from merchants, forwards them to the issuing bank, and settles funds to the merchant. Paynetics also operates as an acquirer for approved merchant categories. A **Card** is a payment instrument linked to an account or a virtual account. Cards can be issued as virtual or physical and can be configured for consumer or business use. Each card is associated with a single account and uses the balance of that account for transactions. Card behaviour, including limits, fees, usage permissions, and wallet enablement, is defined by the program and card-level configuration. Strong Customer Authentication. A regulatory requirement under PSD2 mandating that electronic payments are authenticated using at least two independent factors: something the user knows, something the user has, and something the user is. SCA is enforced at checkout via 3DS for card payments. An **Account** is a payment or e-money account used to hold funds and execute transactions. Accounts are created under a specific instance and program and are associated with either a user or a merchant. They provide the logical structure under which balances, cards, and transactions are organised. Common account purposes include: - executing card payments and transfers - holding settlement funds - pre-funding services such as OCT An account acts as a container for balances rather than holding funds directly. A **Merchant** represents a business entity that accepts payments or uses acquiring-related services. Merchants are created within an instance and can be associated with one or more accounts, including funding and settlement accounts. Merchant configuration is subject to underwriting and card scheme approvals, depending on the services enabled. Merchants become operational through **merchant onboarding**, once the relevant application has been approved. **Tokens** are unique identifiers used throughout the Paynetics platform to securely reference objects. Tokens exist for instances, programs, accounts, balances, cards, merchants, and transactions. They are mandatory in API calls and ensure secure identification without exposing sensitive data, accurate routing of operations, and consistent handling across services. For example, a balance token specifies which funds are debited or credited, a card token identifies the card used in a transaction, and a merchant token links activity to a specific merchant. The person to whom a Card is issued. The cardholder is responsible for all transactions made with the card in accordance with agreed terms. A cardholder authentication protocol used during online card payments. 3DS reduces card-not-present fraud and supports regulatory requirements including Strong Customer Authentication. Authentication can be frictionless (no user interaction required) or challenge-based (the user must actively verify the transaction).