Payment Cards Import

PayU allows the import of payment cards previously stored with another operator, enabling their continued use in recurring (MIT – Merchant Initiated Transaction) and card-on-file (CIT – Customer Initiated Transaction) transactions.

After a successful import, the cards are available in the PayU system, allowing customers to continue payments without the need to re-enter card details. The entire process is transparent to the end user and does not require any additional actions on their part.

Due to the sensitivity of card data, the import process requires close cooperation between:

• the merchant,
• the current payment operator,
• the PayU team.

Payment Card Import Process

1. Export payment card data from the current operator.

First, inform your current payment operator about the planned import of cards to PayU.

Provide them with this documentation and ask for confirmation of their readiness to carry out the process in accordance with the requirements described here.

2. Contact the PayU team.

Get in touch with a PayU representative, providing the following information:

• the intention to import cards,
• identifying information about the merchant and the point of sale to which the cards are to be assigned,
• information obtained from the current payment operator.

Thanks to this data, PayU will be able to prepare the appropriate technical configuration and initiate the import process.

3. Exchange of cryptographic keys and data necessary for secure transfer.

The import process uses two levels of security:

• Encryption of the contents of the export file:

  • PayU generates a pair of PGP keys (RSA, minimum 2048 bits).
  • The operator/merchant receives the public key and uses it to encrypt each line of the CSV file.
  • After encryption, each line should be encoded in base64 format.

• Authorized access to the SFTP server:

  • The operator/merchant generates a pair of SSH keys.
  • The public key should be provided to PayU to enable authentication.
  • Additionally, the IP address from which the file will be sent must be provided - it will be used to configure network access to the PayU SFTP server.

Example command to generate a pair of authentication keys

openssl req -x509 -newkey rsa:2048 -keyout private.pem -out public.pem -days 365 -nodes -subj "/CN=Your Name/emailAddress=your.email@example.com"

4. Preparation of the csv file and sending it to PayU

The .csv file should contain payment card data separated by commas (in the order of occurrence):

Columns in the CSV file

Column	Required	Additional Information
Cardholder name	No
Cardholder surname	No
Card number	Yes
Card expiration month	Yes	In two-digit format (MM).
Card expiration year	Yes	In two-digit format (YY).
Cardholder email address	Yes
Customer ID	Yes
Initial Transaction ID	No (recommended)	Recommended to process MIT payments without negatively impacting their conversion rate (accepted authorization on the card issuer side).
Authentication Level	No	Possible values: ANY – authentication occurred, NO_AUTHENTICATION – card was not authenticated, ONLY_CVV – only CVV was provided, ONLY_3DS – 3DS was used, FULL_AUTHENTICATION – full authentication occurred.
Tokenization Type	Yes	Possible values: MIT – recurring payments, without the cardholder's involvement, CIT – non-recurring/cardOnFile payments, where the cardholder is involved in the transaction.

Example row from the csv file with full data

John,Doe,4111111111111111,12,2031,john.doe@example.com,cust123,485161313910626,FULL_AUTHENTICATION,MIT

Example row from the csv file with only required data

,,4485763923503105,01,2031,jessica.rivera@example.com,cust516,,,CIT

Data file details:

The .csv file must meet the following requirements:

• Each line must be encrypted with the PGP public key provided by PayU.
• The encrypted line must be base64 encoded.
• The maximum file size is 1GB.
• The maximum number of lines is 100000.
• The file must be encoded in UTF-8.

5. File processing by PayU and testing imported cards.

After uploading the file to the SFTP server, the PayU team will carry out the import process and internal technical tests. The goal is to confirm that all cards have been successfully imported and are ready for use in the production environment.

We recommend sending the cards in two phases:

• Phase 1: Send a small number of cards (e.g., 10-20) to test the import process and ensure everything is working correctly.
• Phase 2: After successfully completing the test, send the remaining cards.

Requirements and final notes

CIT vs MIT

In order for a card to be properly used in MIT (Merchant Initiated Transaction) recurring payments, it may be necessary to provide the identifier of the first transaction (Initial Transaction ID). Lack of this information may negatively impact the effectiveness of transaction processing - in particular, it may reduce the authorization rate of recurring payments on the card issuer's side.

In the case of using the same card in both CIT and MIT processes, we suggest omitting the entry in the import file with the CIT value and leaving only one entry related to MIT.

Information about the authentication level

If the previous payment operator has data on the level of authentication performed on the card, we recommend including it in the import file. Providing this information may positively impact the authorization rate of transactions on the card issuer's side, especially in the case of MIT payments.

If no value is provided for the authentication level, the PayU system will automatically assign the default value: ANY.

Client identifier

Client identifier is important in the context of required authorization of the type trusted_merchant and when retrieving available payment methods for the client. Make sure that the identifier provided in the import file is then used in the above processes.