Understanding the difference between on-session and off-session payments is essential for optimizing consumer experience and maximizing payment success rates.

On-session payments

What it means The consumer is actively involved in the payment flow, entering card details, completing authentication, or confirming the transaction.

In the context of recurring payments

The initial payment or subscription setup is on-session. The consumer provides consent and authorizes their payment method for future use.
A returning customer completing a transaction using saved payment details (e.g., one-click checkout, in-app purchase) is also considered on-session because they are present and interacting.

Off-session payments

What it means The consumer is not present or interacting when the charge occurs, common in automatic billing scenarios (e.g., monthly subscriptions) or MOTO transactions where payment is processed on the consumer’s behalf.

In the context of recurring payments

Subsequent subscription charges are typically off-session. The merchant initiates the payment without consumer interaction.
Off-session payments usually rely on previously stored credentials and strong initial authentication to maintain high approval rates.

How to implement recurring payments

Recurring 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	A subscription is a recurring billing arrangement where the consumer agrees to be charged automatically at fixed intervals (e.g., monthly, yearly) 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
Account on file 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.