--- title: "Migration of recurring payments and card tokens to Fabrick" description: "How to migrate to Fabrick the recurring payments and card tokens managed with another PSP: key concepts, file formats and data exchange methods." url: "https://docs.fabrick.com/en/payment-hub-and-orchestra/ecommerce/features/token/migration/migration-in/" language: "en" --- # Migration of recurring payments and card tokens to Fabrick This guide is intended for **merchants interested in Fabrick's Open Payments services** who are currently operating with other **PSPs (Payment Service Providers)**. The purpose of this documentation is to guide the merchant through the **migration of recurring payments** to Fabrick's infrastructure, with particular focus on **card** and **PAN token** data. --- ## Key concepts ### Card token A **card token** is a unique identifier that replaces the **PAN (Primary Account Number)**, i.e., the number printed on the payment card. **Tokenization** allows transactions to be performed without directly using the PAN, improving security against fraud and data theft. > **Learn more** > > See the Fabrick article: [*"Tokenization in e-commerce payments: what it is and why it is useful"*](https://www.fabrick.com/it-it/insight/blog/tokenizzazione-pagamenti-ecommerce/). --- ### Recurring payments **Recurring payments** are transactions carried out at regular intervals (e.g., monthly subscriptions, installment plans) without the customer having to enter their card details each time. In **MIT (Merchant Initiated Transaction)** payments, the merchant initiates the payment independently, based on a previously completed authentication. > **Documentation** > > See [*"Recurring payments – Fabrick Docs Payment Orchestra"*](https://docs.fabrick.com/en/payment-hub-and-orchestra/ecommerce/features/recurring-payments/). --- ## Migration objective To provide all the data necessary for the new payment processor to continue existing recurring payments, and for the merchant to benefit from freedom of choice with operational continuity. --- ## Technical file requirements To complete the migration correctly, the merchant (or current PSP) will need to provide one or more files containing the required data in **CSV format**, following the technical specifications described below where possible. ### Required file format File format: - **CSV** format with **UTF-8** encoding - All rows must have the **same number of columns** - Columns can be in **any order** > **Sample CSV file.** --- ## Mandatory fields The mandatory fields vary depending on the type of data to be migrated. ### 1. Mandatory fields for recurring transaction migration | Field | Description | | -------------- | ------------------------------------------------------------------------------- | | **NetworkID** | Identifies the chain (known by the circuit and Issuer) | | **Type** | Identifies the type of recurring payment (First Recurring or First Unscheduled) | | **Card.token** | The card PAN token | --- ### 2. Mandatory fields for tokenized card PAN migration The recurring payment chain, authenticated during the first transaction performed by the user, is usually used in combination with tokenized card PANs. This approach avoids the use of sensitive data in subsequent transactions. Currently, Fabrick can work with card tokens from the MasterCard and VISA networks. If the recurring transaction was previously authenticated using a PAN token, the following fields are mandatory for migration: | Field | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **card_number** | Full tokenized card number (15 or 16 digits). The real PAN is not used, but the token associated with the card. | | **card_exp_month** | Expiry month of the tokenized card (values from 1 to 12). This data is required to validate the token and ensure that the payment is still valid. | | **card_exp_year** | Expiry year of the tokenized card (2 or 4 digits). Used together with the token to ensure that the card is still active and usable. | > **Learn more** > > See the Fabrick article: [*"Tokenization in e-commerce payments: what it is and why it is useful"*](https://www.fabrick.com/it-it/insight/blog/tokenizzazione-pagamenti-ecommerce/). --- ## Optional fields The originating PSP may include additional fields in the CSV file, beyond the mandatory ones. Such data will be used by Fabrick with the aim of providing the merchant with a migration experience that is as seamless and complete as possible. Examples of additional information that may be useful include metadata, internal identifiers, customer references, contact details, preferences, etc. At the end of the migration, Fabrick can provide the merchant with a sheet containing the new reference data identifying the recurring transaction chains and card tokens, alongside the data already provided by the merchant for easy identification and archiving. --- ## File name The name of the encrypted CSV file can be chosen freely. However, the following format is recommended: ```text __.csv.gpg ``` --- # Security and file submission The CSV file must be **encrypted** using the **public key provided by the destination Payment Service Provider**, which must also provide the **sFTP server** address details and credentials to allow Fabrick to deposit the files directly. The connection details required are: - server name - port - username --- # Expected timelines Once the data indicated in the "Security and submission" section has been received, Fabrick commits to providing the data to the new PSP **as quickly as possible**. Depending on the **quantity and type of data to be exported**, the process may take from **a few days** to **several weeks**. --- # Contacts For assistance in preparing the data or configuring the secure submission, please contact the Fabrick technical support team. > **Fabrick Support Portal.**