Understanding the difference between on-session and off-session payments is essential for delivering a smooth consumer experience and maximizing authorization success, especially for recurring and stored-credential (reference) payments.

On-session payments

What it means The consumer is present and actively participating in the payment. They may enter card details, authenticate (for example, via 3DS), or explicitly confirm the payment.

On-session payments typically occur when the consumer is establishing or actively using a payment method:

Initial subscription or setup payment The consumer provides consent and authorizes their payment method for future use.
Returning consumer using saved credentials Examples include one-click checkout or in-app purchases where the consumer initiates and confirms the payment.

Off-session payments

What it means The consumer is not present or interacting at the time the charge is made. The payment is initiated automatically or by the merchant on the consumer’s behalf.

Off-session payments are common once a payment method has already been authorized:

Subscription renewals and recurring charges The merchant initiates the charge without consumer interaction.
Usage-based or event-triggered charges Charges occur after consumption or when a predefined event happens.

How to implement

Recurring and reference payments generally fall into three categories. Each type differs in how it is initiated, whether the consumer is present (on-session), and how billing is scheduled.

Type	Description & Examples	Fields
Subscription payments	Fixed-interval recurring charges where the consumer agrees to automatic billing (monthly, yearly, etc.) for ongoing access to a product or service. Initial payment: On-session (typically) Subsequent payments: Off-session Examples: Streaming services, gym memberships, meal kits	Initial payment `initiator`:CONSUMER `scheduleType`:SCHEDULED Subsequent payments `initiator`:MERCHANT `scheduleType`:SCHEDULED
Usage based payments	Charges based on actual consumption, usage, or triggered events rather than a fixed recurring amount. Also known as variable recurring MIT. Initial payment: On-session (typically, when the payment method is first saved/authorized) Subsequent payments: Off-session Examples: Utility bills, metered usage, late fees, incidental damage charges	Initial payment `initiator`:CONSUMER `scheduleType`:SCHEDULED Subsequent payments `initiator`:MERCHANT `scheduleType`:SCHEDULED
Stored-credential payments	Payments made by the consumer using a previously stored payment method. Unlike the previous two models, these are not merchant-initiated, each payment is triggered by the consumer at the time of checkout and may require authentication. Initial payment: On-session Subsequent payments: On-session (no automatic charging) Examples: One-click checkout, in-app purchases	Initial + Subsequent payments `initiator`:CONSUMER `scheduleType`:UNSCHEDULED

Order retries and dunning cycle

When a subscription or usage based payment fails, due to insufficient funds, expired credentials, or temporary issuer restrictions merchants often implement a dunning cycle, which defines when and how many times the system will retry the charge before the subscription is suspended or cancelled. These retry attempts are still merchant-initiated and off-session, but they must be distinguished from the original scheduled charge.

How to classify retries

To ensure that a payment is clearly flagged as part of a controlled dunning process, merchants must mark every retry using:

scheduleType: SCHEDULED_RETRY
initiator: MERCHANT

This allows issuers to treat the attempt as a valid, expected recurring retry rather than a new unscheduled charge. Proper classification improves authorization rates and prevents false declines by signalling that the consumer has previously agreed to this billing.

Best practices for retries

Use SCHEDULED_RETRY only for retry attempts directly tied to a subscription or recurring billing logic.
Maintain a clear retry schedule (e.g., retry after 1 day, 3 days, 5 days).
Do not use SCHEDULED_RETRY for consumer-initiated recovery flows, those should remain on-session CIT payments.
Stop retries once the merchant’s defined dunning cycle is complete.

📘
Payment agreements
For full compatibility and compliance across all payment methods, we strongly recommend using payment agreements for any recurring payment flow. Some payment methods require a payment agreement as part of their authentication and mandate flows. Learn more about payment agreements.
When processing payments under a payment agreement, the scheduleType is determined by whether a frequency is defined on the agreement:

If a frequency is set, the payment defaults to scheduleType: SCHEDULED.

If no frequency is set, the payment defaults to scheduleType: UNSCHEDULED.