Overview of Tokenization and Recurring Payments

For flexibility with real-time, recurring, and card-on-file (CoF) transactions, your merchants can create secure tokens with a customer’s card payment or eCheck data. If your merchant wants to keep multiple payment methods on file, they can save multiple tokens per customer. Merchants can then use the saved tokens to schedule CoF charges and create recurring plans.

Tokens protect the payer’s sensitive data, simplify PCI compliance for you, and do not expire. Because the customer’s information (such as an address) remains linked to each token, issuer declines due to address verification service (AVS) mismatch or similar are a lot less likely.

Important!

Payrix Pro does not support the following tokenization use cases:

• Digital wallets: Applies when card data is not stored on the merchant’s platform, such as with Apple Pay or Google Pay.

• Single-use credentials: Includes temporary card data used for hotel incidentals, flight reservations, or similar short-term transactions.

The Payrix Pro platform offers a recurring payments solution that enables you to schedule recurring transactions directly through the Portal.

Alternatively, you can create your own recurring transaction database. In this case, you need to submit a few required fields to comply with card brand mandates. See the Card on File (CoF) section for recurring payment guidelines.

Omnitoken

Omnitoken is a secure, omnichannel payment tokenization solution from Worldpay that replaces sensitive cardholder data with a unique, format-preserving token. This tokenization method protects transactions across card-present (CP) and card not present (CNP) channels. It reduces fraud, lowers your PCI compliance scope, and supports one-time and recurring payments.

The following sections provide more information on the Omnitoken service. See Enable Omnitoken for instructions on enabling this service for your merchants.

Omnitoken Fees

Using the robust Payrix Pro fee engine, Omnitoken-based actions can generate fees collected from your merchants. Below is a list of use cases where the actions qualify for fees.

Qualified for Omnitoken Fee Charges

• Minting a new Omnitoken through Terminal Sale, $0 Authorization, or Refund from new card information

• Minting a new Omnitoken through Card-Not-Present Sale, $0 Authorization, or Refund from new card information

• Minting a new Omnitoken using a pre-existing Payrix Pro token

• Lookup of an existing Omnitoken using the original primary account number (PAN) used to first mint the Omnitoken

Not Qualified for Omnitoken Fee Charges

• Reusing a Terminal-minted Omnitoken for a Sale, $0 Authorization, or Refund Card-Not-Present transaction

Notes

• Fees are incurred for both minting new tokens and looking up existing tokens based on the PAN:

  • A Minting action occurs when the VCore RAFT platform encounters a specific PAN for the first time to generate a new Omnitoken.

  • A Lookup action occurs when the VCore RAFT platform identifies a previously minted PAN and retrieves the corresponding Omnitoken.

• To avoid unnecessary lookup charges, merchants can use the actual token value instead of the PAN information in a new transaction.

See Fee Setup for information and detailed instructions for setting up merchant fees, including Omnitoken-related fees.

Chains

Chains represent a hierarchical structure designed to facilitate the sharing of tokens across different levels of the merchant hierarchy. These Chains play a crucial role in organizing and linking various business accounts within the Omnitoken ecosystem, supporting the seamless utilization of tokens across multiple merchant IDs (MIDs). By establishing this hierarchical framework, Chains enable efficient token management and distribution, enhancing coordination and operational effectiveness within the Worldpay payment processing system.

Note

Chains are activated by the Payrix Pro platform for each partner.

The SuperChain is an advanced, top-level Chain for all other Chains. It allows for the sharing of tokens across the merchant hierarchy at both the Chain and SuperChain levels. By using rollup IDs to link different business accounts, the SuperChain system ensures seamless token sharing and management within the Worldpay ecosystem. This centralized approach to managing business accounts under a unified Omnitoken hierarchy enhances efficiency and coordination across multiple MIDs.

Chain Requirements

Upon boarding the platform, your portfolio is enabled for Omnitoken with a Chain ID assigned automatically, allowing your merchants to plug and play with the new terminal to mint new Omnitokens to their Chains upon successful boarding.

Vaults

A Vault serves as a secure digital repository within a merchant’s chain where Omnitokens are stored. These Omnitokens are unique digital tokens generated from transactions to replace sensitive payment information, ensuring secure and seamless payment processing. The Vault enhances security measures by safeguarding these tokens and provides traceability for transactions. By using the Omnitoken Vault, you can securely manage and use Omnitokens for various payment transactions, aligning with industry standards and supporting advanced payment technologies.

Recurring Payments

One of the key features of tokenizing a payment method is the ability for merchants to use it to schedule recurring payments without reentering payment details. This solution gives a merchant the ability to charge their customer’s tokenized payment method in their desired amount and at their desired frequency.

Recurring payments are useful for membership plans for services like gyms and media streaming. Recurring payments are also useful for bill payments such as storage unit rentals, utilities, and mobile phone bills.

The following sections describe the functionality of recurring payments in more detail.

Plans and Subscriptions

Merchants can set up recurring payments in the portal using the following components:

1. Plans: A plan dictates the amount and frequency of the recurring payment.

2. Subscriptions: After the merchant creates a plan, they can add customers to the plan through subscriptions. A subscription links a customer’s saved payment method (a token) to the plan, tracks failed payments, and enforces limits.

Plans are not unique to a specific customer. Rather, multiple customers can be added to the same plan, and each customer will be charged the same amount at the intervals dictated in the plan. To adjust a customer’s recurring payment, merchants can adjust a customer’s subscription without making any changes to the actual plan.

Processing Schedule

The first payment in a plan is processed at the next scheduled interval based on the plan’s interval and the subscription’s recurring schedule dates.

All subscription payments are processed daily shortly after midnight Eastern Time (ET). The following table outlines the specific times and corresponding email notifications for each subscription type:

Subscription Failures and Retries

Payrix Pro doesn’t retry failed subscription payments within the same plan interval. Instead, each failure increases the Consecutive Failures count. The subscription attempts a new charge at the next scheduled interval.

When the Max. Consecutive Failures limit for a plan is reached, the subscription becomes Inactive. If no limit is set, the subscription keeps trying to charge the same payment method until you or your merchant manually changes the status to Inactive.

To track and respond to failed payments, merchants can enable a Subscription Failed alert. See Use Case: Enable Subscription Event Alerts for setup details.

Card on File (CoF)

This section provides comprehensive implementation guidelines for partners and merchants using Payrix Pro for card-on-file (CoF), sometimes called credential-on-file, transactions. A CoF transaction uses a cardholder’s previously tokenized and stored PAN. After tokenizing a customer’s payment method, the merchant can access the customer’s profile in the portal to submit a CoF payment.

The following sections describe the use cases and requirements for processing CoF payments.

Card-on-File Use Cases

Knowing when to use CoF can significantly enhance the customer checkout experience. To accurately set consumer expectations, you must understand the scenarios where this payment method can and cannot be used.

Cardholders can securely store their card for:

• Recurring Payments:

  • Subscription Payments: Examples include gym memberships and streaming services.

  • Bill Payments: Examples include utility bills, monthly car insurance, and mobile phone bills.

• Cardholder-Initiated Future Purchases: Examples include lawn care or snow removal services, and transit card top-ups.

• Installment Payments: Examples include furniture or large technology purchases.

Important!

CoF does not support the following tokenization use cases:

• Digital Wallets: Applies when card data is not stored on the merchant’s platform, such as with Apple Pay or Google Pay.

• Single-Use Credentials: Includes temporary card data used for hotel incidentals, flight reservations, or similar short-term transactions.

Cardholder Disclosure Requirements

A merchant who stores and later uses card-on-file information for future transactions must comply with the following display and disclosure requirements:

First-Time Card Capture Disclosures

When capturing the PAN for the first time, it is essential to provide the cardholder with a dedicated page, such as a link to the cardholder agreement, that distinctly outlines the following information separate from the general terms and conditions of the platform:

• A truncated version of the PAN, such as the last four digits, will be securely stored

• How the credential will be used

• Expiration date of the agreement (if applicable)

• How the cardholder will be notified if there are any changes to the agreement

Stored Card-on-File Usage Disclosures

Before using stored credentials, merchants must first establish a clear agreement with the cardholder that explicitly outlines the following details:

• Merchant name

• Merchant address or location (if applicable)

• Transaction amount and currency

• Taxes, surcharges (which require card brand registration), or any additional fees that might apply

• Cancellation and refund policies

• Transaction frequency or threshold (for example, maintaining a minimum balance)

Note

All agreements must be readily accessible to cardholders or issuers upon request.

Authorization Requirements

Once disclosure requirements are met for cardholders and issuers, a first-time card authorization must be completed to securely store the PAN and other card information. When a card-on-file is stored, it must follow authorization rules for failed transactions, including whether the card can be used after consecutive authorization failures.

First-Time Card Authorization Requirements

A PAN can be stored only after receiving valid authorization.

This requirement does not extend to token transfers between processors. If no transaction amount is due when storing the credentials, a $0 Auth (an authorization transaction with an amount of $0.00) must be approved before storing the credentials.

Note

PANs cannot be stored if the transaction is declined.

Subsequent Authorization Requirements

A stored credential can be used up to four additional times within 16 days of initial authorization failure.

If no valid authorization can be obtained, the credential should no longer be used (in other words, platforms should stop using a credential after a set number of consecutive authorization failures).

References

See the following external materials related to card-on-file information.