Category: Transaction Processing

Recurring Transaction

Also known as: Recurring Payment, Subscription Payment

Simply put

A recurring transaction is a payment that a customer authorizes a merchant to charge to their account automatically at set intervals, such as monthly or annually. It is commonly used for subscriptions and membership or service fees, where funds are deducted on a predetermined schedule without the customer manually initiating each payment.

Formal definition

A recurring transaction is a merchant-initiated or scheduled charge processed against a customer's payment credentials at predetermined intervals under a prior customer authorization to cover subscription, membership, or ongoing service fees. Recurring processing typically relies on stored payment credentials and a merchant agreement or mandate defining the amount and schedule; where a merchant stores cardholder data to support recurring billing, that storage remains subject to applicable PCI DSS controls, and sensitive authentication data must not be retained after authorization even to enable subsequent recurring charges. Note that the specific network rules, credential-on-file transaction identifiers, and authentication expectations for recurring transactions are governed by individual card brand and network rules, which vary by region and change over time; confirm current requirements against the applicable published standards and network documentation.

Why it matters

Recurring transactions are the backbone of subscription and membership business models, allowing merchants to collect payments automatically without requiring the customer to initiate each charge. Because they depend on payment credentials being available for future charges, they typically involve the storage of cardholder data on file. This directly affects a merchant's PCI DSS scope: any system that stores, processes, or transmits cardholder data to support recurring billing falls within scope of applicable PCI DSS controls, and that data must be protected accordingly.

A critical distinction for recurring billing is that sensitive authentication data, such as full track data, CAV2/CVC2/CVV2/CID, and PIN blocks, must not be retained after authorization, even when the intent is to enable subsequent recurring charges. Some cardholder data, such as the primary account number, may be stored under defined controls to support recurring billing, but sensitive authentication data may not be stored to facilitate future transactions. Merchants that mistakenly retain the verification code to smooth out recurring charges create both a compliance failure and an avoidable data exposure.

The operational rules governing recurring transactions, including credential-on-file transaction identifiers and authentication expectations, are set by individual card brand and network rules. These vary by region and change over time, so merchants and processors cannot assume a fixed set of requirements. Confirming current expectations against the applicable published standards and network documentation is necessary to avoid declined transactions, disputes, or noncompliance.

Who it's relevant to

Merchants and Subscription Businesses

Businesses that bill customers on a set schedule for subscriptions, memberships, or ongoing services rely on recurring transactions to collect payments automatically. They are responsible for obtaining and retaining valid customer authorization and for ensuring that any stored cardholder data used to support recurring billing is protected under applicable PCI DSS controls, without retaining sensitive authentication data after authorization.

Compliance Officers

Because recurring billing typically depends on stored payment credentials, compliance teams must account for credential-on-file storage when defining PCI DSS scope. They should confirm that sensitive authentication data is not retained to enable future charges and that recurring transaction handling aligns with current card brand and network rules, which vary by region and change over time.

Payment Processors and Acquirers

Processors and acquirers implement the systems that store credentials and initiate scheduled or merchant-initiated charges. They must apply the correct credential-on-file and recurring transaction identifiers as defined by individual card brand and network rules, and should verify current requirements against applicable published network documentation rather than assuming fixed rules.

Fraud and Risk Teams

Recurring transactions involve credentials stored for repeated use, which changes the risk profile compared to one-time customer-initiated payments. Risk teams should consider how stored-credential charges are monitored and disputed, keeping in mind that chargeback and dispute rules are governed by card brand and network rules that vary by region and change over time.

Inside Recurring Transaction

Cardholder Data on File

A recurring transaction model typically requires storing certain cardholder data such as the PAN and expiration date to submit subsequent payments without the cardholder re-entering details. This data may be stored only under defined controls, and its storage brings the environment into PCI DSS scope.

Prohibited Sensitive Authentication Data

Sensitive authentication data, including full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be retained after authorization even when encrypted. Recurring transaction setups that attempt to store these values for reuse are non-compliant.

Initial Consent and Agreement

The setup of a recurring arrangement generally involves obtaining and documenting the cardholder's agreement to repeated charges, including amount, frequency, and duration where applicable. Specific consent and disclosure requirements are governed by card brand and network rules, which vary by region and change over time.

Stored Credential Indicator

Subsequent transactions in a recurring series are commonly flagged as merchant-initiated or as using a stored credential. The exact data fields and indicators are defined by card brand and network rules rather than by PCI DSS.

Data Protection Method

To reduce the risk and scope associated with the stored PAN, merchants may apply tokenization, encryption, truncation, or masking. These transform or reduce data differently, and their effect on PCI DSS scope depends on the specific implementation and validation, not on the label alone.

Common questions

Answers to the questions practitioners most commonly ask about Recurring Transaction.

Can I store the CVV2/CVC2/CAV2 to make it easier to process future recurring charges?

No. The card verification value (CVV2/CVC2/CAV2/CID) is sensitive authentication data, which must not be stored after authorization, even when encrypted. This applies to recurring transactions the same as any other. For subsequent recurring charges, you rely on the stored credential (such as a tokenized PAN and expiration date under defined controls) and the applicable card brand recurring or credential-on-file rules, not on retaining the verification code from the initial authorization.

Does setting up a transaction as recurring mean the merchant is protected from chargebacks?

No. Classifying a transaction as recurring does not by itself shift or eliminate liability. Chargeback rights and dispute rules are governed by card brand and network rules, which change over time and vary by region. A recurring designation may affect how a dispute is handled, but it is not a guarantee against chargebacks, including those arising from friendly or first-party fraud, and merchants should confirm current network rules for the specific scenario.

How should I store card data used for recurring transactions to limit PCI DSS scope?

Cardholder data such as the PAN and expiration date may be stored under defined controls, but many organizations reduce scope by using tokenization or a third-party vault so that the actual PAN is not retained in their environment. The effect on PCI DSS scope depends on the implementation and how it is validated, not on the label alone. Sensitive authentication data must never be stored after authorization. Confirm your approach against the current published standard.

What data do I need to keep to authorize subsequent charges in a recurring series?

Subsequent charges typically rely on a stored credential, such as a tokenized or securely stored PAN and expiration date maintained under defined controls, rather than the sensitive authentication data captured at the initial authorization. The specific data elements and any required indicators for recurring or credential-on-file transactions are defined by card brand and network rules, so confirm the current requirements for each network you support.

How do I handle expired or updated cards for ongoing recurring transactions?

Recurring programs commonly address card expiration and reissuance through account or credential update mechanisms offered by the card networks or your processor, which can provide refreshed card details for stored credentials. Availability, coverage, and rules for these services vary by network and region and are governed by card brand rules, so confirm current options and requirements with your acquirer or processor rather than assuming uniform behavior.

How does authentication apply to recurring transactions versus the initial setup?

Authentication controls such as 3-D Secure, strong customer authentication, and multi-factor authentication address different risks at different points in a transaction, and their application to recurring transactions differs from the initial setup. Some frameworks and network rules treat the initial customer-initiated transaction differently from subsequent merchant-initiated charges. The applicable requirements depend on card brand and network rules and regional regulation, which vary and change, so confirm the current rules for your context.

Common misconceptions

You may store the CVV2/CVC2 to conveniently rerun recurring charges.

CVV2/CVC2/CAV2/CID are sensitive authentication data and must not be stored after authorization, even encrypted. A recurring model must operate without retaining these values, relying instead on permitted stored cardholder data and network stored-credential mechanisms.

Using a token for the stored card automatically removes the recurring environment from PCI DSS scope.

Tokenization can reduce scope, but the actual effect depends on how the solution is implemented and validated. Tokenization differs from encryption, truncation, and masking, and the label alone does not determine scope. Systems that can retrieve or process the PAN may remain in scope.

Cardholder consent for a recurring charge is a one-time technical step with fixed universal rules.

Consent, disclosure, and stored-credential flagging requirements are governed by card brand and network rules that vary by region and change over time. Practitioners should confirm current requirements against the applicable network rules rather than assuming a fixed standard.

Best practices

Never store sensitive authentication data such as CVV2/CVC2/CAV2/CID, full track data, or PIN blocks for recurring reuse; design the flow to obtain authorization without retaining these values.

Store only the cardholder data needed for the recurring arrangement, such as PAN and expiration date, and protect it using tokenization, encryption, truncation, or masking selected and validated for your environment.

Confirm the applicable data-protection and stored-credential requirements against the current published PCI DSS standard, since requirement numbering and wording differ between versions.

Flag subsequent charges using the merchant-initiated or stored-credential indicators defined by the relevant card brand and network rules, and verify these against current, region-specific network requirements.

Capture and retain documented cardholder consent covering amount, frequency, and duration in line with applicable network rules, and review it as those rules change.

Assess and document PCI DSS scope based on the actual implementation and validation of any tokenization or encryption used, rather than assuming a control's label removes systems from scope.