Tokenization (card-on-file)

Overview

Netaxept offers Tokenization (Card-on-File) services that allow merchants to securely store customer payment credentials for future transactions. Instead of storing sensitive Primary Account Numbers (PANs), Netaxept replaces card details with a secure identifier known as a token.

To support different business models and payment scenarios, Netaxept provides two tokenization methods:

• PSP Tokenization – Tokens are generated and managed within the Nets Card Vault.

• Network Tokenization – Tokens are provisioned and managed directly by the card schemes, such as Visa and Mastercard.

Both tokenization methods support card-on-file payments while reducing the need to handle sensitive card data.

Stored cards (card-on-file)

Card-on-file transactions

Storing card details, also known as Card-on-file, enables customers to save their payment information with merchants and have quicker checkouts, subscriptions, and other services. In these transactions, a customer's payment card data is securely stored for future use, with their consent. Card-on-file relies on tokenization to protect sensitive customer card information. Tokenization replaces card numbers with unique, randomly generated tokens that can be used for payments without exposing the actual card number.

Card-on-file transactions can be initiated by both merchants and consumers:

• Merchant-Initiated Transactions (MIT): Merchants initiate these transactions with the consent of customers who have previously interacted with them. MITs can be used for a variety of purposes, such as subscription fees, unscheduled card-on-file transactions, and installment payments.

• Cardholder-Initiated Transactions (CIT): These occur when a customer uses previously stored payment information to make a purchase, eliminating the need for manual entry of card details. This is frequently used in one-click payments, ensuring a swift and convenient checkout experience. To enhance security, these transactions often require authentication through 3D Secure.

Services with stored cards

With Netaxept's tokenization services, you can securely store customer payment credentials for future transactions. Supported use cases include:

• Easy payment: Returning customers do not have to enter their payment details again. Example: One-click transactions where a customer can store their payment details upon their first purchase and pay on the website or in the app later using their saved details.

• Recurring payments: A transaction in a series of transactions. The amount and interval of recurring payments are fixed. It is based on the customer's consent to allow the merchant to initiate one or more future transactions. Example: A TV streaming subscription with the same monthly bill.

• Unscheduled Card on File: Unlike recurring payments, the amount and timing of the transaction can vary. Example: Automatic top-ups of railcards or mobile phone subscriptions, where the bill changes according to usage.

• Delayed charge: Allows a supplemental charge after the initial payment has been processed. Example: A hotel needs to charge minibar expenses on top of the original bill that has already been paid.

• No-show: Allows a no-show transaction. Usually used for fees that occur because the customer does not meet the terms of an agreement. Example: A customer has booked a hotel room but does not cancel in accordance with the hotel's cancellation policy, resulting in a no-show fee to cover the cost of the reserved room.

Comparison: PSP vs. Network Tokenization

Security and customer consent

When storing payment credentials for future use, merchants must obtain the customer's consent and clearly explain how the stored payment credentials will be used.

Merchants should:

• Obtain the customer's approval before storing payment credentials.
• Clearly communicate the purpose of future transactions.
• Explain how customers can cancel recurring agreements where applicable.
• Store all tokens securely and restrict access to authorized systems and personnel.